Repository navigation
planning: after a changed answer, take the user to the dependents it made stale #5909
Description
Severity: high
Problem
When an answer with dependents is changed, the page moves on as if nothing else changed. After a save, send() calls nextNeeding(1) (index.html:1722) and toasts "Saved Q1. Now Q22." (index.html:1725). nextNeeding (index.html:1555-1559) walks rail order from the saved question and takes the next question that needsYou. It does not prefer the questions this save just made stale. The toast names none of them. When Show is set to Open, stale questions are answered, so they fail passes() (index.html:662) and nextNeeding skips them.
The server only marks dependents that already hold a decision (server.py:365-366). Marking undecided dependents is #5796 G3 hole 1. This issue covers what the page does after the save.
Expected
After a save that makes questions stale or upstream-pending:
- the toast names them ("Q17 and Q54 need review; 7 more wait on them");
- the next question is the first newly stale descendant, then its descendants in dependency order, as the terminal loop's "Recompute the tree" step does (
context/loop.mdstep 6); - this happens whatever the Show filter is.
Suggested fix
- In
send()(index.html:1716-1727), diff the stale and upstream-pending ids before and afterrefresh(). Prefer the first new stale id in tree order overnextNeeding(1), and switch the filter to Review when the current filter hides it. - Put the new ids in the toast at index.html:1724-1725.
- Leave the server-side cascade to feat(planning): interview page does not enforce answer order or react to changed answers like the terminal interview #5796 G3.
Acceptance criteria
- If changing Q1 makes Q17 and Q54 stale, the page lands on Q17 with a toast naming Q17 and Q54, under Show set to All or Open.
- A UI test in
surface/tests/covers landing on the stale dependent.
Activity
kyle-sexton commentedon Oct 4, 2026
This was generated by AI during triage.
Routing: delegable,
agent-ready,work-class: scoped(C3, bug fix),priority: medium. The priority is the assessed default. The reporter rated it high, but it blocks no other work and has no deadline.Verified against current code:
send()moves tonextNeeding(1)and toasts "Saved Qn. Now Qm." It does not compare which questions the save made stale. Basis: verified, plugins/planning/surface/index.html:1688-1727.nextNeedingwalks rail order from the saved question and skips any question that failspasses(). Basis: verified, index.html:1555-1559.passes()requires an unanswered question, so a stale answered dependent is skipped. Basis: verified, index.html:660-663.Where I looked: the page's
send,nextNeeding,firstNeeding,passes,refresh, the server's stale derivation, the terminal loop's "Recompute the tree" step (context/loop.mdstep 6),docs/out-of-scope/(nothing matches).Cluster check: no shared decision. #5769's open decision 3 (recommended answering order across the frontier) is a different ordering: it governs what to answer first overall, and this issue governs where to go right after a save. #5796 G3 (server cascade) is scoped out by this issue's own body.
Agent Brief
Type: Bug
Summary: After a save that makes other questions stale or upstream-pending, the page names them and takes the user to the first newly stale one, whatever the Show filter is.
Current behavior:
After a decision save, the page moves to the next question in rail order that needs the user and passes the current filter. The toast names only that question. The questions the save just made stale are not preferred or named. Under Show: Open they are skipped entirely, because they are answered.
Desired behavior:
Key interfaces:
send()(the decision path afterrefresh()),nextNeeding(),passes(), and the Show filter state (S.filter, valuereview).stateofstaleandupstream-pendingfrom the server).Acceptance criteria:
Out of scope:
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): 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 #5909).A save that makes answers stale lands on the first of them in dependency order, switches Show: Open to Review when needed, names them in the toast, and
nvisits the rest first.Verified: ui_page phase 4 checks the landing, the filter switch, the toast and
n. The fullsurface.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