Repository navigation
planning: make Reconfirm on a stale question say exactly what it records #5910
Description
Severity: high (can misrecord an answer)
Problem
On a stale question whose kept decision is an accept, choice 1 reads "Reconfirm the recommendation" and sends kind: accept (reconfirmOf, index.html:1021-1029). If Claude revised the recommendation after the user accepted it, that accept records the revised text, not the text the user accepted. Choice 2 ("Rec ", choicesOf index.html:1034-1040) then records the same thing. A user who reads "Reconfirm" as "keep what I chose" accepts text they may never have read.
Expected
Reconfirm states the decision it records. When the recommendation changed after the kept accept, either remove Reconfirm (choice 2 already accepts the current text), or label it "Accept the revised recommendation" and keep the old text under Previous (the banner at index.html:1074-1075 already renders previousRecommendation).
Suggested fix
In reconfirmOf (index.html:1021), for k === "accept", compare the question's current contentRev with the contentRev on the kept decision's event. The page sends that value on every decision (index.html:1698), and the server checks and stores it (server.py:1009, 1037). If they differ, return null or relabel. Flagging such answers for re-confirmation in general is #5769 gap 4; this issue covers only the misleading label.
Acceptance criteria
- After a
revisewithrecon a stale, accepted question, no choice reads "Reconfirm the recommendation" unless the recommendation is unchanged since the accept. - A test covers Reconfirm after a recommendation revise.
Activity
kyle-sexton commentedon Oct 4, 2026
This was generated by AI during triage.
Decision defaulted: when the recommendation changed after the kept accept, drop the Reconfirm row. The
Recrow already records the revised text — veto before mergeBasis: verified, plugins/planning/surface/index.html:1021-1029 (
reconfirmOfreturns anacceptReconfirm without checking whether the recommendation changed) and index.html:1035-1037 (choicesOfalways addsRec, which sends the sameaccept). The vetoable alternative: keep the row and relabel it "Accept the revised recommendation". Dropping the row adds no new wording and leaves one row per outcome. Judgment: fewer moving parts.Routing: decision-defaulted,
agent-ready,work-class: scoped(C3, bug fix),priority: medium. The priority is the assessed default. The reporter rated it high (it can misrecord an answer), but it blocks no other work and has no deadline.Verified against current code:
accept, row 1 reads "Reconfirm the recommendation" and sendsaccept, which records the current recommendation text. Basis: verified, index.html:1021-1029.op_replysetspreviousRecommendation) and index.html:1075.contentRevwith thecontentRevon the decision event. The value the page sends, and the server stores, on a decision is notq.contentRev. It isq.contentRevplus a count of that question's decision and undo events (crev,snapOf). Basis: verified, index.html:601, 1167, 1698. The two values differ on almost every answered question, so comparing them directly would drop Reconfirm everywhere. The brief states the behavior instead.Where I looked:
reconfirmOf,choicesOf,altsOf,armKindand the shortcut help (theakey), the stale banner,context/surface.md(Upstream changed paragraph, which says "Reconfirm is choice 1"),docs/out-of-scope/(nothing matches).Cluster check: no shared decision. #5769 gap 4 (flag answers whose recommendation changed for re-confirmation in general) is scoped out by this issue's body. #5815 (sibling, untriaged) changes the
Recrow's text in the same choice builder, so dispatch the two one after the other.Agent Brief
Type: Bug
Summary: On a stale question, Reconfirm for a kept accept appears only when the recommendation is unchanged since that accept. Otherwise the user picks
Rec(the revised text) or another choice.Current behavior:
A stale question whose kept decision is an accept shows "Reconfirm the recommendation" as row 1. If Claude revised the recommendation after the accept, that row records the revised text, which the user may never have read, while it reads as "keep what I chose".
Desired behavior:
accept, the Reconfirm row is offered only when the question's recommendation text is the same as it was when that accept was recorded. When the recommendation changed after the accept, no Reconfirm row is offered.replywithrecorrevisewithrec.ashortcut armsRec.Upstream changed), where its own recommendation did not change.Key interfaces:
reconfirmOf(q): returns null for a kept accept when the recommendation changed after it.choicesOf(q),armKind(), the stale banner text, and the shortcut help entry fora.Acceptance criteria:
revisewithrecon a stale, accepted question, no row reads "Reconfirm", andRecshows the revised recommendation.Out of scope:
Recrow shows (planning: show the whole recommendation in the interview page's Accept choice #5815).kyle-sexton commentedon Oct 4, 2026
This was generated by AI during work-loop.
Ratify autonomous dispatch of this C3 bug-fix item?
Classification:
work-class: scoped(C3), bug-fix-shaped (confirmed at triage this cycle). Intended dispatch: the work-loop worker lane, through/work-items:work, to a draft PR the lane never merges. Once ratified, the lane dispatches the interview-page items #5815, #5908, #5910 and #5911 one at a time, because they edit overlapping page code. First drain is not complete and no item-level ratification exists, so it is queued here. Ratify through/work-items:attend-queueand it dispatches on a later cycle.Lane: work-loop, instance melo-worker-1, cycle 1.
fix(planning): offer Reconfirm on a kept accept only while its recomm…
fix(planning): take the user to the dependents a changed answer made …
kyle-sexton commentedon Oct 11, 2026
Delivered on branch
feat/planning-interview-page-batchin draft PR #7182, one commit for this issue (withCloses #5910).A kept accept offers no Reconfirm once the question's own recommendation changed after it;
aarms Rec and Previous keeps the old text. The shortcut help andsurface.mdsay so.Verified: ui_page phases 4 and 5 cover the unchanged (Reconfirm offered) and changed (no Reconfirm) cases. The full
surface.test.shwas last run in full before the final page commits; the later commits were checked with the ui_page phases. Its one standing failure (AC34 "user name found") is an environment artifact that also fails on main.Left for a human: the PR stays a draft until Kyle flips it to ready, which starts the CI and review lanes.
The
needs-humanlabel was left for Kyle to clear.Generated by Claude Code