Verified AI Repair

An AI model can propose a convincing patch and still leave the workspace broken. Workspai treats repair as a transaction with a goal, scope, allowed actions, and completion evidence.

Examples of user goals include:

• prepare this workspace for release;
• repair dependency vulnerabilities without a breaking change;
• raise test coverage to 75% and keep the build passing.

Plan a bounded goal

npx workspai workspace goal plan dependency-security \
  --scope project:api \
  --json

Or define a measurable coverage target:

npx workspai workspace goal plan test-coverage \
  --scope project:web \
  --target 75 \
  --json

The plan records the project boundary, required stages, approval points, and evidence needed for completion. The VS Code Studio can execute that contract while the CLI remains the source of diagnostic and verification truth.

The repair transaction

The CLI-owned Repair Engine exposes the complete durable lifecycle:

npx workspai workspace repair capabilities --json
npx workspai workspace repair plan --card doctor --project api --json
npx workspai workspace repair approve --transaction repair_123 --approved-by local-user --json
npx workspai workspace repair execute --transaction repair_123 --json
npx workspai workspace repair status --transaction repair_123 --json

Other explicit modes cover propose, decide, resume, list, rollback, and cancel. Approval is bound to the immutable plan hash and causal action set. The CLI owns checkpointing, mutation, reconciliation, validation, verification, closure, conflict-aware rollback, and the durable event timeline. An IDE or agent is a governed consumer of that protocol, not a second mutation authority.

The complete transaction order is:

1. read canonical evidence and build a bounded plan;
2. validate preconditions and bind approval to the immutable plan;
3. recheck the exact target immediately before mutation;
4. checkpoint governed files and acquire the transaction lock;
5. execute the deterministic action or validated model proposal;
6. reconcile dependency state and run audit, test, and build checks;
7. refresh the exact evidence producer required by the target;
8. run canonical verification;
9. close, roll back, or return decision-required with a durable receipt.

plan never mutates and approve never executes. execute rejects stale, tampered, or unapproved plans. The CLI also bounds proposed files, paths, and payload size; rejects secret and governed-evidence edits; and checks checkpoint hashes before rollback. These are protocol guarantees, not prompt suggestions.

For a dependency blocker, Workspai first audits and classifies the finding. It then applies the approved repair, reconciles the manifest, lockfile, and installed tree, runs the focused audit and declared test/build checks, refreshes workspace intelligence, and finally verifies the goal.

Changing package.json alone is not completion. Workspai waits for the lockfile and installed tree to agree before evaluating the result.

Transactions live under .workspai/repair/transactions/<id>/. The latest public result is .workspai/reports/workspace-repair-last-run.json. A consumer must read the terminal state from that durable evidence; a changed file or a successful subprocess is not a closed repair transaction.

Check the result

npx workspai workspace goal status --json
npx workspai workspace verify --strict --json

A goal completes only when its declared evidence is current and its gate accepts the result. A blocker that remains unresolved stays visible; the model does not get to mark its own work as successful.

Where the model decides

Workspai executes deterministic repair capabilities directly when the contract permits them. The model is used where a source-level decision is genuinely needed. Every change still returns to Doctor, the intelligence loop, and verification.

If an executable is missing, an ecosystem adapter is unsupported, risk exceeds the approval boundary, or the repair needs human intent, the transaction enters decision-required. It cannot claim success from an ephemeral proposal or a plausible source diff.

If source files change after checkpointing, rollback is conflict-aware. Workspai does not overwrite a newer user edit merely to restore the old snapshot. The transaction reports the conflict and keeps the decision visible.

Start with Workspace Doctor to understand how the original finding and repair capability are produced.