Repository navigation
planning: let Claude move a question to another group and set the group order #5914
Description
Severity: med
Problem
revise can already change a question's dependsOn, with checks for unknown ids and cycles (checked_depends, round.py:816-838, used in op_revise at round.py:856 and 902-907). It cannot move a question to another group: op_revise has no group field. Groups cannot be reordered: put_group (round.py:541-556) appends a new group and leaves an existing one where it is, and the group op takes only id, title, summary and dependsOn (round.py:727-732). In the audited session Claude wrote "Questions can't be moved between groups (a page limit), so I'll gate them with dependencies instead."
Expected
Claude can move a question to another group and set the group order, each through apply with validation.
Suggested fix
- Extend
op_revise(round.py:840) and itsOP_ARGSentry (round.py:1308) withgroup. Refuse an unknown group, and record a history line as thedependsOnchange does (round.py:925-933). - Add an
orderfield to thegroupop (round.py:1340), or agroup-orderop that takes the full id list and refuses missing or unknown ids. - Add both to
schema/ops.schema.jsonand to the ops table incontext/surface.md.
Acceptance criteria
revisewithgroupmoves a question, and the rail shows it in the new group without a reload.- A group-order op changes the rail order, and refuses a list that leaves out or invents a group.
Activity
kyle-sexton commentedon Oct 4, 2026
This was generated by AI during triage.
Decision defaulted: group order is a new
group-orderop that takes the full list of group ids, not anorderfield on thegroupop — veto before mergeBasis: verified, plugins/planning/surface/index.html:687-688 (the Groups rail lists groups in
doc.groupsarray order, so a full-list op maps directly onto it) and the issue's acceptance criterion "refuses a list that leaves out or invents a group", which only a full-list op can check. The alternative, a per-grouporderfield, is additive and reversible.Routing: decision-defaulted,
agent-ready,work-class: scoped(C3, feature),priority: medium(assessed default). The request is additive: one new field onreviseand one new op, each validated. No existing op changes meaning.Verified against current code:
reviseacceptsdependsOnwith unknown-id and cycle checks, but has nogroupfield. Basis: verified, plugins/planning/surface/round.py:838 (op_revise) and round.py:1306-1324 (its argument list).groupop takes onlyid,title,summaryanddependsOn;put_groupappends a new group and leaves an existing one in place, so order cannot change. Basis: verified, round.py:539-556 and round.py:1338-1341.groupis checked against known groups when added. Basis: verified, round.py:339.Where I looked:
op_revise,op_group,put_group, the op argument table, the ops schema, the interview skill's ops table, the rail'ssections(), anddocs/out-of-scope/(no match).Cluster check: none. #5796 covers frontier gating by
dependsOn; this item does not change gating.Agent Brief
Type: Feature
Summary: Claude can move a question to another group with
revise, and set the order of groups with a newgroup-orderop, both throughapplywith validation.Current behavior:
A question's group is fixed once added;
revisecannot change it. Groups appear in the order they were first created, and no op reorders them. Sessions work around this by gating questions with dependencies instead.Desired behavior:
reviseacceptsgroup. An unknown group id is refused with a message naming it. A move records a history line on the question, as adependsOnchange does, and warns that the summaries of the old and new groups predate the move.group-orderop takes the complete list of existing group ids and reorders the groups to match. It refuses a list that leaves out a group, names an unknown group, or repeats one, and writes nothing on refusal.dependsOnlocking; the two stay independent.Key interfaces:
op_reviseand its argument list: newgroupfield.group-orderop with anidslist, registered with the other ops and in the ops schema.Acceptance criteria:
revisewithgroupmoves a question, and the rail shows it in the new group without a reload.revisewith an unknowngroupis refused and changes nothing.group-orderchanges the rail order, and refuses a list that leaves out, invents, or repeats a group.Out of scope:
orderfield on thegroupop (the vetoable alternative above).kyle-sexton commentedon Oct 4, 2026
This was generated by AI during work-loop.
Approve this for autonomous dispatch (with its defaulted decision), or keep it for a human?
Triage marked this decision-defaulted as a feature-shaped C3 (
work-class: scoped). The work-loop admission gate human-gates feature-shaped C3 work, so the lane removedagent-readyand appliedneeds-human. To dispatch it, flip it back through/work-items:attend-queue.Lane: work-loop, instance melo-worker-1, cycle 1.
feat(planning): let revise move a question to another group and add g…
kyle-sexton commentedon Oct 11, 2026
Delivered on branch
feat/planning-interview-page-batchin draft PR #7182, one commit for this issue (withCloses #5914).revisetakesgroup(CLI--group) to move a question to an existing group in place, with a history line and stale-summary warnings; a newgroup-orderop reorders the groups (every id once).Verified: New
TestRegroupintest_round.py; the Python suites passed (401 tests). 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. Its label note also asks for Kyle's attend-queue approval before autonomous dispatch; that is unchanged.Generated by Claude Code