Status dashboard set numbering diverges from command index resolution when DAG is present

[skytect]

Human Note	Set number in table in rapid:status confused me as it was different from the actual set number.
Version	v6.0.0
Skill	status, discuss-set, start-set, plan-set, execute-set

Bug Description

When a DAG is present, /rapid:status displays sets numbered in wave order (grouped under wave headers, numbered sequentially across waves). All command skills (discuss-set, start-set, plan-set, execute-set) resolve numeric indices against STATE.json insertion order via resolveSet() in src/lib/resolve.cjs.

The numbers shown in the status dashboard don't match what the commands resolve to, causing users to operate on the wrong set.

What happened: User ran /rapid:discuss-set 9 intending to discuss the set shown as #9 in the status dashboard (a Wave 3 set). RAPID resolved it to a different set (STATE.json position 9), which was actually a Wave 4 set. The wrong set got discussed.

What should have happened: Numeric index 9 should resolve to the same set in both contexts.

Steps to Reproduce

1. Initialize a project with a DAG where wave order differs from STATE.json insertion order (e.g., sets added in a different order than topological sort produces)
2. Run /rapid:status and note the numbered sets under wave headers
3. Run /rapid:discuss-set N where N maps to different sets in wave vs insertion order
4. Observe that the command resolves to the wrong set

Example divergence:

Dashboard # (wave order)	STATE.json # (insertion order)	Set
9	11	set-C
10	9	set-A
11	12	set-D
12	10	set-B

Sets 1-8 matched in both orderings. Divergence started where the DAG placed a later-inserted set into an earlier wave.

Root Cause / Suggested Fix

Two independent numbering systems with no shared source of truth:

• skills/status/SKILL.md (lines 83-104): assigns sequential numbers in DAG wave order
• src/lib/resolve.cjs resolveSet() (lines 46-89): indexes into milestone.sets[] from STATE.json insertion order, no DAG awareness

Fix options:

1. Make resolver DAG-aware: When DAG.json exists, resolveSet() reorders sets by wave before indexing. Keeps wave-ordered UX.
2. Make status use insertion order: Remove wave-based renumbering from the status skill. Simpler but loses wave-grouped display.
3. Show both indices: Status uses insertion-order numbers but groups under wave headers visually. Numbers always match commands.

Workaround

Use set names instead of numeric indices: /rapid:discuss-set my-set-name instead of /rapid:discuss-set 9.

Related Issues

• DAG generation ignores CONTRACT.json dependency edges due to format mismatch #4 (DAG generation issues)
• Planner should optimize for wall-clock time, not minimal wave count #40 (planner wave optimization)

Co-Authored-By: Claude Opus 4.6