vscode: review-flag gestures must prompt for comment prose (native inline thread, Submit/Cancel) — remove the promptless deck default

[amrmelsayed]

Owner-directed design fix (2026-08-25, ruled during the 1049 dev-review session); drafted by the spir-1049 builder, verified and filed by main. Claims verified at source: DECK_FLAG_BODY at review-queue/feedback.ts:34, used at :121; the comment-controller authoring path exists in comments/builder-review.ts.

Problem

The review-flag feedback gestures (codev.feedbackCurrentHunkToBuilder, -CurrentFileToBuilder, -SelectionToBuilder, all in review-queue/feedback.ts → route()) enqueue a comment with a fixed, promptless body — DECK_FLAG_BODY = "Flagged for review from Stream Deck." — and never ask the reviewer for the actual comment. Wrong for both triggers:

• Stream Deck dial: the dial is used with dictation, so it should open an input for the reviewer to speak/type the comment, not stamp a placeholder.
• VS Code command / keybinding: flagging from the editor also skips any prompt and, worse, mislabels the comment "from Stream Deck" regardless of trigger.

Owner ruling: promptless flagging must not exist at all.

Desired behavior

A flag gesture (dial or keyboard; file / hunk / selection) opens a comment-authoring input at the anchor — the native inline comment thread reply box, the same UX as spec/plan comment authoring (comments/plan-review.ts / builder-review.ts: createCommentController + vscode.CommentReply). Multi-line and dictation-friendly, with Submit / Cancel / Edit / Delete. The typed/dictated text becomes the comment body. DECK_FLAG_BODY is deleted.

Scenarios to handle

1. Author, don't stamp. The gesture creates an empty, not-yet-queued comment thread at the anchor and focuses its reply box; on Submit the authored body enters the per-builder queue (ReviewQueueStore). The queue-mount machinery exists in builder-review.ts; the gap is an authoring entry point that does NOT pre-populate the queue with a placeholder.
2. Forward-mode parity. In codev.diffCodelensMode === 'forward' the gesture currently forwards a range ref to the PTY immediately with no prose. It must also prompt, then forward the ref + authored body together. No promptless branch remains.
3. Cancel / empty submit. Escape, or an empty/whitespace body, enqueues and forwards nothing and leaves no orphan empty thread mounted.
4. Validate the anchor before prompting. The existing guards (no active builder diff; cursor not in a changed hunk → "place the cursor in a changed hunk") fire BEFORE the input opens, so the reviewer never authors into a void.
5. All three verbs. File, hunk, and selection get the same authoring flow — not hunk-only.
6. Multi-line + dictation. The input must accept multi-line prose; a single-line showInputBox truncates dictated paragraphs — which is why the native comment thread reply, not an input box, is the correct surface.
7. Deck focus ergonomics. A dial press must bring the target builder-diff editor / comment box to focus so dictation lands in the right field; when no builder diff is active, the press surfaces a clear "focus a builder diff first" message rather than a silent no-op.
8. Edit / delete before flush. A comment authored this way is a first-class queue entry — editable (vscode: edit + preview-side delete on review comments (make the markdown reviewer functional) #1055) and deletable (vscode: codelens-driven review comments in the unified diff editor — per-builder queue with batched submit to PTY (follow-up to #789) #1037) before the batched "Submit Review (N)" flush to the PTY, not a locked placeholder.

Acceptance criteria

• No code path enqueues or forwards a review comment without reviewer-authored prose.
• DECK_FLAG_BODY and any "from Stream Deck" default body are gone.
• File / hunk / selection, in both queue and forward modes, all prompt.
• Cancel / empty leaves no artifact (no queue entry, no forwarded text, no mounted thread).
• Authoring UX matches spec/plan comment authoring (multi-line, Submit/Cancel).

Scope / area

area/vscode. Core change is review-queue/feedback.ts (route()), reusing the comment-controller authoring path from comments/builder-review.ts. The Stream Deck side (apps/streamdeck, command-relay.ts) is unaffected: it only presses the existing feedback-* verbs; the behavior change is entirely VS Code-side.

Related (do not fold in)

• vscode: codelens-driven review comments in the unified diff editor — per-builder queue with batched submit to PTY (follow-up to #789) #1037 (review-queue), Stream Deck SD+: two-zone builder workflow (selectors + action palette, dial-driven feedback queue) #1410 (deck feedback verbs) — origin of the current behavior.
• vscode: resolve state on review comments + builder workflow for signalling addressed (#1055 follow-up) #1131 (resolve / addressed state on review comments) — adjacent, separate.
• vscode: next/prev hunk ignores where the reviewer scrolled — re-anchor the cursor to the viewport before delegating to compareEditor.nextChange #1546 — other hunk-cursor bug in the same command family.

[amrmelsayed]

Also related (do not fold in): #1534 — forward-hunk press errors inside a visibly changed hunk (frozen hunk ranges). Same command family; its anchor-staleness bug interacts with scenario 4 here (validate-before-prompt must validate against FRESH hunk ranges, or the prompt gate inherits #1534's false negative).

[amrmelsayed]

On it! Working on this with the PIR protocol (plan + dev-approval gates before PR).