Files
deepseek-harness/apps/web/tests/snapshots/plan-review/review.expected.md
creatixchu 2363ef01eb feat(web): render a plan review as a decision card, not a quiz
The Web composer now renders a request that declares the `plan-review` intent
as its own surface: the waiting-approval card language — amber "Plan review"
strip, the plan as the scrolling markdown body, the question as the card's
accessible name — over one decision row of Chat about it / Refuse / Approve.
Gone from that surface are the 1/1 pager, the numbered radio rows, the custom
answer row, and Skip/Submit, which made approving a plan read as sitting an
exam.

Approve and Refuse answer with the asker's own option labels and keep its
descriptions as tooltips; Chat about it cancels the request so the composer
returns and the user can simply say what they want. Copy is bilingual under the
existing `question` namespace.

The shape choice lives inside the single composer entry rather than a second
chain registration, so the two surfaces cannot race the same carrier, and
`planReviewOf` falls back to the generic flow for any request it cannot render
as a card — the client sits downstream of a wire boundary and every request
must stay answerable.
2026-07-30 19:09:35 +08:00

1.4 KiB

  • region "Approve this plan and leave plan mode?":
    • text: Plan review
    • heading "Add --greeting flag to CLI" [level=1]:
      • text: Add
      • code: "--greeting"
      • text: flag to CLI
    • list:
      • listitem:
        • strong: Locate the CLI entry point
        • text: (e.g.,
        • code: cli.py
        • text: ","
        • code: main.go
        • text: ","
        • code: index.js
        • text: etc.) and find the argument parser definition (argparse, click, cobra, yargs, or similar).
      • listitem:
        • strong: Register a new optional string argument
        • text: named
        • code: "--greeting"
        • text: with a short alias (
        • code: "-g"
        • text: if available) and a sensible default value (e.g.,
        • code: ""Hello""
        • text: ).
      • listitem:
        • strong: Thread the parsed value
        • text: through the main handler function so it is passed where the greeting string is used (e.g., the welcome/response message).
      • listitem:
        • strong: Update the help text
        • text: so
        • code: "--help"
        • text: or
        • code: "-h"
        • text: shows the new flag with its description.
      • listitem:
        • strong: No tests or config changes
        • text: unless they already exist and directly validate the flag's presence.
    • status
    • button "Chat about it":
      • img
      • text: Chat about it
    • button "Refuse"
    • button "Approve"