design: staged-vs-applied edit/ast_edit preview

[joeshull]

Child of #135

Needs a design session. Visual badge is not the hard part; staged-vs-applied semantics are.

Problem

ast_edit (and preview-mode edit) can stage a proposal. TUI shows ⟨proposed⟩ and prepends PREVIEW_PENDING_NOTICE ("files NOT modified yet… write xd://resolve / xd://reject"). Dashboard EditToolRenderer paints the same diff as an applied edit.

Apply/discard is a later write xd://resolve|reject, not a button on the edit card. Wrong product pick: making the edit card itself Approve/Reject vs treating resolve/reject as the only action surface.

Design questions

1. Badge-only (⟨proposed⟩ + notice) vs interactive Apply/Discard on the originating card?
2. If interactive: how does the card invoke resolve/reject without a second agent turn?
3. How are stacked previews associated (pending-invoker id / label)?
4. Does a staged ast_edit stay visually distinct after a later resolve/reject in the same turn?

Out of scope

• resolve/reject completed-result banners → LIST: agent-specable tool cards (unwrap + eval/browser/hub/todo/search/...) #120
• plan approval → sibling propose issue
• ast_edit/ast_grep/lsp result cards (counts, hunks) → LIST: agent-specable tool cards (unwrap + eval/browser/hub/todo/search/...) #120

Pointers

• PREVIEW_PENDING_NOTICE + queueResolveHandler: @oh-my-pi/pi-coding-agent/src/tools/resolve.ts
• Staging: src/tools/ast-edit.ts ~432–456, ~524 (⟨proposed⟩ TUI-only)
• Dashboard: packages/client/src/components/tool-renderers/EditToolRenderer.tsx

[joeshull]

Parent: #117. Result cards for ast_edit/lsp: #120. resolve/reject banners: #120. Plan host: #121.

[joeshull]

Proposal (unreviewed)

Draft from design session. Not locked.

Rec

A. Display-only proposed badge when toolDetails.applied === false. Keep existing staged notice + diff. No Apply/Discard on the source card.

Approaches

• A (rec): badge + notice; resolution is a later write xd://resolve|reject
• B: Apply/Discard on the source card (needs a new client→agent resolve path)
• C: infer staged state by parsing result text

Locked answers (proposed)

1. Badge-only. No interactive buttons.
2. Only a later write xd://resolve|reject dispatches queueResolveHandler.
3. No cross-card association in design: staged-vs-applied edit/ast_edit preview #123. Queue ids are not dashboard payloads; LIST: agent-specable tool cards (unwrap + eval/browser/hub/todo/search/...) #120 owns banners.
4. Source card stays evidence of a proposal after later resolve/reject.

UX

display-only. Warning-style proposed badge + files-not-modified notice. No new click targets.

Out

No PromptBus, no client resolve command, no stacked-preview matching, no #120/#121 work.

[joeshull]

Locked: A

Display-only proposed badge when toolDetails.applied === false. Keep staged notice + diff. No Apply/Discard on the source card.

Resolution is a later write xd://resolve|reject (#120). No PromptBus, no client resolve command, no stacked-preview matching.