Review AI plans, apply & undo

Know the default before you start#

The current default is Automatically, with Undo: after a checked stage, the change applies and its card offers Undo. Select Ask me first in AI Provider Settings if you want each checked change to stop at Ready to apply with Apply and Discard.

Plugin references and migration files have a separate automatic-approval setting, off by default. Do not assume choosing Ask me first is the same as choosing a dependency policy. These preferences belong to this Mac, not the project.

Review the proposed application before approving it#

1. Open Details on the plan card. Read its Forms, startup Form, data, modules, dependencies and assumptions.
2. Check that each stage adds a coherent piece of code or layout. Ask for smaller stages when the change is hard to review.
3. In Plan mode, request a revision in the composer and review the new numbered draft. Discard plan ends the interview without applying it.
4. Only use Approve and run when the planned scope is the one you intend.

A plan waiting for approval has not created its files. In Plan mode, approval switches to Build. Older superseded cards remain readable but cannot apply obsolete actions. Follow the complete interview-to-app exercise.

Follow the stage boundaries#

Save after reviewing the applied result. Keep a Git baseline for changes you accept. Undo is useful immediate recovery, but it does not replace a durable source history.

Keep stages bounded#

An AI change set may contain up to 512 operations, including up to that limit in its candidate layout work. An addControlArray grid counts as one operation, not one operation per member. A standalone layout patch still has a 32-operation ceiling; these are different entry points. Split a larger application change into coherent stages rather than requesting one oversized change.

Understand recovered AI proposal formatting#

Since build 837, multiple change sets in one provider reply can be joined when their project, revision, activity and stage identities agree. Conflicting edits still fail validation; an incomplete part keeps the joined proposal incomplete. Since build 838, extra relativePath fields on add-module, add-test and add-form operations are ignored because McBasic™ derives those locations from the declared names.

Build 839 recognizes known unambiguous payload aliases, for example text for source. It does not guess between two competing aliases or override an already-present canonical field. All recovered proposals still pass Check, source-version, scope and Apply gates.

Let repairs use the current document version#

A proposal identifies the source or layout snapshot it expects to edit. From build 827, harmless hash spelling differences such as surrounding spaces, letter case or a sha256: prefix are normalized. A wrong document hash is still rejected by the candidate guard, but as a repairable MCB4731 instead of failing the entire request at its parsing boundary.

The guard is not disabled: a stale proposal must be repaired against current authorized source. Scope entries now carry their document hashes too, so a document supplied only through Add to Chat can be edited within that scope. You should not have to invent a hash or broaden permissions to repair a version mismatch. Inspect the repaired diff before applying.

Pause and retry with current context#

Changing provider or model during a running plan pauses further requests. Resume, Retry or Approve and run consents to the newly selected provider and current context. If no provider is configured, nothing is sent. A stage is regenerated against current source rather than reusing a stale proposal blindly.

If a request fails, read the stage status before retrying. Stop and cancellation are not successful completion. Do not report an application change as done merely because an assistant produced plausible code.

Read the remaining-work list without confusing formatting with failure#

From build 824, McBasic™ tidies the AI’s descriptions of unfinished work before validating an incomplete candidate. These descriptions are called blockers in the change-set contract. Normalization is not an Apply action: the candidate must still pass Check, permission decisions and the selected apply policy.

For example, an item containing Add validation, a line break and and error feedback becomes one line: Add validation and error feedback. It is still unfinished work. Read the list alongside the approved stage and current diff, especially when an item has been shortened. Do not treat a compact list as proof that every requirement has been implemented.

A candidate declaring itself complete cannot also list blockers. MCB4730 still reports other invalid change-set contracts. The build-824 refusal for a missing nonempty list was superseded in build 825; do not discard valid candidate work solely because the AI omitted the explanation. Once the candidate is checked and applied, the existing slice and recovery rules decide how a plan continues.

Review a procedure replacement in its full document#

From build 823, replacing a procedure preserves its existing trailing LF or CRLF line break when the replacement omits one. This prevents End Sub and the following Private Sub from becoming one token sequence. The fix applies while assembling the candidate; it does not rewrite unrelated procedures or relax compiler validation.

1. Inspect the intended handler in the change preview.
2. Open the complete document and check that its closing statement and the next procedure header are on separate lines.
3. Confirm the neighboring handler’s code is unchanged.
4. Run Check, then test both the edited action and the neighboring action.

Use the single-handler exercise to practice this check with the complete greeting code.

Recover a plan that cannot fit#

An approved stage carries plan text as well as its immediate task. It can borrow unused context allowance, but a long plan can still exceed the combined request budget. For a prompt-size failure, choose a larger suitable Request size or stop and request a shorter plan; for a context failure, reduce the selected documents. LM Studio retains its 120,000-character maximum, and smaller presets still apply. Follow the provider-specific recovery table before Retry.

If the same size check fails again, McBasic™ refreshes one error card at the bottom with Retry and Stop plan. Repeated clicking does not split a stage or reduce the plan. Stop plan and ask for smaller remaining work when a larger request is not appropriate.

Follow one stage across several applied slices#

When a checked stage applies useful work but reports specific missing pieces, McBasic™ can continue the same stage automatically. Each follow-up request targets the first remaining piece on the current source. There are at most three such slices after the initial attempt; work assigned to another planned stage is not an excuse to leave this stage incomplete.

Each slice passes through the same Check, permission, dependency and apply-policy gates. Ask me first still waits for Apply. Every applied slice is its own Undo action. If the app closes during a slice, the restored plan pauses and Resume retries that same slice rather than consuming another slice number.

Undoing a slice reverses that slice only. Continue anyway is an explicit decision to proceed without completing the stage, not a successful completion report.

Distinguish an empty follow-up from a no-change initial stage#

From builds 829–830, an operations list may be empty without failing the provider request. If it answers a follow-up slice and has no blockers, McBasic™ treats the earlier applied work as complete and advances without an empty Apply or Undo entry. An empty follow-up that still lists missing work instead stops as no progress.

Outside a follow-up slice, an empty or unchanged candidate still does not complete the stage. A card such as Stage 3 changed no file offers Retry stage or Stop plan, without Skip stage. A complete flag alone is not enough to turn an initial no-change stage into completed work.

On reopening a stored plan from builds 819–820, McBasic™ can find a stage previously recorded as applied despite changing no files. It pauses at the earliest such stage for Retry stage. Later already-applied files are retained; this is not a rollback of the entire project. Inspect current source before retrying.

Use the current card, not a typed button word#

During a pause, the one actionable card stays at the bottom of the chat; later replies and notes appear above it. When an error card owns Retry, the plan card does not expose a second live Retry. Use the buttons on the current card.

Typing only retry, continue, resume or stop, or their supported Italian equivalents, adds guidance rather than pressing the button or sending a provider request. Other messages remain normal chat requests, but a separate proposed edit cannot be applied through the paused stage’s identity. Resume, resolve or stop the plan as directed before sending that edit again.

Practice with a narrow change#

The review-and-undo tutorial changes only the first-app greeting. Set Ask me first for that exercise, discard the first proposal, then apply a reviewed proposal and test empty input, spaces and a normal name. Inspect the diff to confirm that no unrelated layout, package or migration changed.