Bulk Action Preview

This reference defines the compact plan preview shown when the user picks Auto-resolve with best judgment on the rest partway through the per-finding walk-through. The preview gives the user a single-screen view of what the agent is about to do with the findings they have not yet seen one at a time, with exactly two options to Proceed or Cancel.

The top-level routing choices do not use this preview. Their report, rendered in the same turn as the routing question, already shows every pending finding and its recommended action (references/walkthrough.md).

Interactive mode only.

When the preview is shown

After the user picks Auto-resolve with best judgment on the rest from a per-finding question, and before the remaining findings are resolved. Scope: the current finding and everything the walk-through has not yet presented. Already-decided findings are not included; their count appears in the header.

The user confirms with Proceed or backs out with Cancel. There are no per-item decisions inside the preview; per-item decisions are the walk-through's job.

Withdrawal revalidation (before composing the plan)

The walk-through's withdrawal rule (references/walkthrough.md, "Withdrawing findings the user's earlier answers resolved") is not confined to the one-by-one loop; it applies to every finding this preview is about to act on. Before sorting findings into Applying / Appending / Skipping buckets, judge each in-scope finding against the decisions already settled. Those are the earlier walk-through answers the user already gave, including a finding resolved by another finding's Apply in the same plan. A finding those decisions already resolve or contradict does not belong in an action bucket: it is withdrawn, not applied, deferred, or skipped.

Put each such finding in the Withdrawing (N): bucket instead. A withdrawal triggered by a staged Apply remains provisional here too: if that Apply is in this same plan and later fails at execution, revert the withdrawal per the walk-through's provisional rule. Do not silently drop a withdrawn finding. The bucket shows the user what earlier answers retired, so they can Cancel if the agent misread them.

Preview structure

The preview is grouped by the action the agent intends to take. Bucket headers appear only when their bucket is non-empty.

<Path label> — <scope summary>:

Applying (N):
  [P0] <section> — <one-line plain-English summary>
  [P1] <section> — <one-line plain-English summary>

Appending to Open Questions (N):
  [P2] <section> — <one-line plain-English summary>

Skipping (N):
  [P2] <section> — <one-line plain-English summary>

Withdrawing (N):
  [P2] <section> — resolved by <earlier decision>

Worked example:

Auto-resolve plan — 8 remaining findings (3 already decided):

Applying (4):
  [P0] Requirements Trace — Renumber R4 (the auth-token requirement) to match unit reference
  [P1] Unit 3 Files — Add read-fallback for renamed report file
  [P2] Key Technical Decisions — Use framework's Deprecated field rather than hand-rolling
  [P3] Overview — Correct wrong count (says 6, list has 5)

Appending to Open Questions (2):
  [P2] Scope Boundaries — Unit 2/3 merge judgment call
  [P2] Risks — Alias compatibility-theater concern

Skipping (2):
  [P2] Miscellaneous Notes — Low-confidence style preference
  [P3] Abstraction Commentary — Speculative, subjective

Header wording

The header reads Auto-resolve plan — N remaining findings (K already decided):. The K already decided counter tells the user the walk-through was partially completed.

Per-finding line format

Each line uses the compressed form of the framing guidance from the subagent template: observable consequence first, no internal section numbering unless needed to locate the issue. The one-line summary is drawn from the persona-produced why_it_matters by taking the first sentence (and, when the first sentence is too long for the preview width, paraphrasing it tightly to fit).

• Shape: [<severity>] <section> — <one-line summary>
• Width target: keep lines near 80 columns so the preview renders cleanly in narrow terminals. Truncate with ellipsis when necessary.
• No section numbering unless the reader needs it to locate the issue (when multiple findings hit the same named section).
• Self-contained identifiers — the one-line summary obeys the shared rendering floor (references/rendering-floor.md): it is consequence-first and applies the opaque-token policy to all three classes (navigation anchors like R4/U3 keep the ID and gloss at first mention; provenance anchors like tickets/PRs appear only when the event drives the decision; mechanism symbols like functions/files translate to their role). A summary whose only description of a referenced item is a bare identifier of any class is not acceptable. The floor is the single source of these rules.

When no why_it_matters is available for a finding (rare — only if persona output was malformed), fall back to the finding's title directly. Note the gap in the completion report if it affects more than a few findings in the same run.

Question and options

Treat the preview and its confirmation as two ordered user-facing events:

1. Preview event — emit the complete preview body as user-visible assistant text in the conversation. Content composed only in hidden thinking or reasoning does not count. Do not place the preview only inside the question interface's input.
2. Decision event — after the preview event is visible, invoke the harness's agent-callable blocking-question capability and wait for the answer. Success means the user can see the preview while choosing Proceed or Cancel, and the workflow does not continue until they answer.

If the preview event has not occurred, do not invoke the blocking-question capability. If the harness exposes no such capability or a real question call errors, preserve the same interaction as visible chat: put the numbered Proceed / Cancel options immediately below the visible preview and wait for the user's reply. Never omit the preview or continue silently.

Match the host's blocking question tool already in the current tool list. Presence in the current tool list is proof the tool exists; never call a user-facing question tool to discover whether it exists. If a matching tool is listed but unloaded, use the host's tool-discovery primitive to load that capability; do not search for another host's tool name.

Stem: The agent is about to resolve the remaining findings above. Proceed?

Options (exactly two):

• Proceed — execute the plan as shown
• Cancel — do nothing, return to the current finding's question

Cancel semantics

Return the user to the current finding's per-finding question. The walk-through continues from where it was, with prior decisions intact. Cancel changes no on-disk or in-memory state.

Proceed semantics

When the user picks Proceed:

• For each finding in the plan, execute the recommended action. Apply findings join the in-memory Apply set with the ones the user already picked during the walk-through; all dispatch together in the single end-of-walk-through Apply pass (see walkthrough.md). Defer findings go through references/open-questions-defer.md. Skip findings are recorded as no-action. Then emit the unified completion report (see walkthrough.md).
• Recorded items: when an Apply or Skip in this batch completes for a finding the document already records under Deferred / Open Questions, follow the removal rule in references/open-questions-defer.md.
• Withdrawing bucket: each finding in this bucket is recorded withdrawn in the decision list, annotated with the decision that retired it. No document edit, no Open Questions append. It carries into the completion report's Withdrawn bucket and follows the same durability rule as a walk-through withdrawal (provisional when retired by a staged Apply that has not yet landed).

Failure during Proceed (e.g., an Open Questions append fails for one finding during a batch Defer) follows the failure path defined in references/open-questions-defer.md: show the failure right away with Retry / Fall back / Convert to Skip, continue with the rest of the plan, and record the failure in the completion report's failure section.

Edge cases

• Zero findings in a bucket: omit the bucket header. A preview with only Apply and Skip does not show an empty Appending to Open Questions (0): line. The same holds for Withdrawing (0):, which is the common case when no earlier decision settled a remaining finding.
• All findings in one bucket: preview still shows the bucket header; Proceed / Cancel still offered.
• N=1 preview (only one finding in scope): the preview still uses the grouped format, just with a single-line bucket. Proceed / Cancel still apply.
• Open Questions append unavailable (document is read-only, or the append flow reports it cannot run): the plan may still contain per-finding Defer recommendations from synthesis. Before rendering the preview, downgrade every Defer recommendation to Skip when the session's cached append-availability is false, and show the downgrade on the preview itself (e.g., a Skipping — append unavailable (N): bucket, or a note in the header: N Defer recommendations downgraded to Skip — document is read-only.).
• **Walk-through Auto-resolve with best judgment on the rest with zero remaining findings:** the walk-through's own logic suppresses Auto-resolve with best judgment on the rest as an option when N=1 and otherwise, so the preview should never be invoked with zero remaining findings. If it is, render Auto-resolve plan — 0 remaining findings and fall through to Proceed with no-op.