planning: say "decided after you answered" on a stale question and show the review count in the meter

[kyle-sexton]

Severity: low

Problem

The group header and the filter now show questions that need re-review (the Review filter and "N to review", #5903), and the meter already leaves stale questions out of "answered" (settled, index.html:642 and 852). Two gaps remain:

• The stale banner says "Stale: Q5 changed." (index.html:1067) even when Q5 did not change: it was decided for the first time after this question was answered. staleBy() (index.html:606-610) returns those prerequisites, but the banner text does not tell the two cases apart.
• The header meter reads "40 of 103 answered" and does not say how many answered questions are waiting for review, so a stale question drops out of the count with no explanation.

Expected

• The banner reads "Q5 was decided after you answered this" when the prerequisite had no earlier decision, and "Q5 changed" only when an earlier decision was replaced.
• The meter shows "· N to review" beside the pending-research count when any answered question needs review.

Suggested fix

• index.html:1067: for each id in staleBy(q), check whether that prerequisite had a decision event older than this question's last decision (lastDecisionSeq, index.html:605, applied to earlier events). If it had none, word it "was decided after you answered this".
• renderHeader (index.html:853): count live(q) && isAnswered(stateOf(q)) && needsYou(q) and append "· N to review". This is the same predicate as the Review filter.

Acceptance criteria

• If Q6 was accepted before Q5 was ever decided, Q6's banner reads "Q5 was decided after you answered this".
• With one stale answered question, the meter shows "1 to review", and that question is not counted as answered.

[kyle-sexton]

This was generated by AI during triage.

Routing: delegable, agent-ready, work-class: scoped (C3, bug fix), priority: low (the reporter rated it low; nothing it blocks).

Verified against current code:

• The stale banner always reads "Stale: changed." for a stale question with no upstreamChanged. staleBy() returns the prerequisites decided after this question was, and falls back to every prerequisite, but nothing tells the two cases apart. Basis: verified, plugins/planning/surface/index.html:605-610, 1067.
• The meter already leaves stale questions out of "answered": settled requires !needsYou(q), and needsYou includes isStale. Basis: verified, index.html:639, 642, 853. So the remaining gap is only the missing "N to review" note on the meter. Group headers already show "N to review" since fix(planning): show only unanswered questions under Open and keep position after an answer #5904 (index.html:784).

Where I looked: the page's stale banner, staleBy, lastDecisionSeq, settled, needsYou, passes (the Review filter), renderHeader, the group counter, context/surface.md (Upstream changed paragraph), and docs/out-of-scope/ (nothing matches).

Cluster check: no shared decision with #5769 (constraint staleness), #5909 or #5910. #5922 (untriaged) changes the related upstream-pending chip. It is a different state but sits next to this banner, so dispatch the two one after the other.

Agent Brief

Type: Bug
Summary: The stale banner says whether a prerequisite changed or was decided for the first time after this answer, and the header meter shows how many answered questions wait for review.

Current behavior:

• A stale question whose prerequisite was decided for the first time after this question was answered reads "Stale: Q5 changed.", even though Q5 never had an earlier decision.
• The header meter reads "N of M answered". A stale answered question drops out of N with no explanation on the meter.

Desired behavior:

• For each prerequisite the stale banner names, the wording depends on the prerequisite's decision history before this question's latest decision:
  • It had no earlier decision: "Q5 was decided after you answered this".
  • An earlier decision was replaced: "Q5 changed".
  • With several prerequisites, each is worded for its own case.
• The Upstream changed banner (a dependency's recommendation was revised) keeps its current wording.
• When any live answered question needs review (the same predicate as the Review filter: live, answered, needs you), the meter appends "· N to review" beside the pending-research count. When none does, nothing is appended.

Key interfaces:

• staleBy(q) and the stale-banner text in the detail view.
• lastDecisionSeq(id), or an equivalent that finds a prerequisite's decision events older than this question's latest decision.
• renderHeader(): the meter text. Use the same predicate as the Review filter so the two counts always agree.

Acceptance criteria:

• If Q6 was accepted before Q5 was ever decided, Q6's banner reads "Q5 was decided after you answered this".
• If Q5 had a decision before Q6 was accepted and Q5's decision then changed, Q6's banner reads "Q5 changed".
• With one stale answered question, the meter shows "1 to review", and that question is not counted as answered.
• With no question to review, the meter shows no review count.
• A UI test in the surface test suite covers both banner wordings and the meter count.

Out of scope:

• The upstream-pending chip and banner wording (planning: name the stale ancestor, not the direct parents, when the interview page marks a question upstream-pending #5922).
• Constraint-driven staleness (planning: mark interview recommendations stale when a new constraint arrives mid-interview #5769) and the server-side stale cascade (feat(planning): interview page does not enforce answer order or react to changed answers like the terminal interview #5796 G3).
• Navigation after a save (planning: after a changed answer, take the user to the dependents it made stale #5909) and the Reconfirm label (planning: make Reconfirm on a stale question say exactly what it records #5910).

[kyle-sexton]

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-queue and it dispatches on a later cycle.

Lane: work-loop, instance melo-worker-1, cycle 1.