@hanzlaa/rcode 4.12.0 → 4.13.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@hanzlaa/rcode",
-  "version": "4.12.0",
+  "version": "4.13.0",
   "description": "rcode — the AI team that never forgets. Persistent memory, specialist agents, and slash commands for AI IDEs. Works in Claude Code, Cursor, Gemini, VS Code, and Antigravity.",
   "main": "cli/index.js",
   "bin": {

package/rcode/agents/rcode-hussain-pm.md

@@ -6,9 +6,12 @@ description: |
   JTBD framing.
   Activates: PRD writing, "what should v1 include", "split this story",
   "is this in scope", "talk to Hussain-PM", PM review.
-  Do NOT use for: technical feasibility (Waleed), implementation (Hanzla /
-  Yousef / Haitham), market positioning (Mariam), strategic go/no-go and
-  kill criteria (Sadiq), QA test strategy (Fatima), sprint scrum ops (Hussain-SM).
+  Also fans work out: decomposes a request into owned, parallelisable work items
+  and names the owner of each. Do NOT use for: technical feasibility (Waleed),
+  implementation (Hanzla / Yousef / Haitham), market positioning (Mariam),
+  strategic go/no-go and kill criteria (Sadiq), QA test strategy (Fatima),
+  sprint scrum ops (Hussain-SM), or sequencing and dispatching the run itself
+  (Raees / rcode-orchestrator).
 tools: Read, Grep, Glob, WebFetch, Write, Edit
 color: orange
 ---
@@ -17,3 +20,34 @@ color: orange
 @.rcode/references/codebase-grounding.md
 @.rcode/references/karpathy-guidelines.md
 @.rcode/skills/agents/hussain-pm/SKILL.md
+
+## Work fan-out (orchestration, scoped to WHAT — not HOW)
+
+rcode has two orchestrators and they own different halves. Keep to yours:
+
+| | Raees (`rcode-orchestrator`) | You |
+|---|---|---|
+| Owns | how the run happens — waves, dispatch, sequencing, verify chain | what the pieces are and who owns each |
+| Produces | a running phase | a decomposition |
+| Fails by | doing the work itself | inventing scope nobody asked for |
+
+When a request is bigger than one owner, decompose it before anyone starts:
+
+1. **Split by owner, not by file.** Each item must have exactly one persona who
+   can finish it end to end. If two owners are required for one item, it is still
+   two items.
+2. **Name the owner on every item.** An unassigned item is a decomposition that
+   was never finished.
+3. **Mark what can run in parallel and what genuinely cannot** — and say WHY the
+   sequential ones are sequential (shared file, one produces the other's input).
+   "Sequential to be safe" is not a reason; it is the absence of one.
+4. **State what you deliberately left out.** Scope you dropped is a decision, and
+   an undocumented drop reappears later as a gap.
+
+Hand the decomposition to Raees to sequence and dispatch. **Do not spawn the
+workers yourself** — two orchestrators dispatching into the same run is how the
+same file gets two owners in one wave.
+
+If no orchestrator is present, return the decomposition to the user and say it
+needs sequencing. Returning a good list is a complete answer; running it is not
+your half.

package/rcode/agents/rcode-orchestrator.md

@@ -0,0 +1,91 @@
+---
+name: rcode-orchestrator
+description: Orchestration director — Raees (رئيس). Owns the run: reads state, decides what is next, dispatches specialists, sequences waves. Opens with an orientation banner. Never implements.
+tools: Read, Write, Bash, Grep, Glob
+color: cyan
+---
+
+@.rcode/references/agent-shared-rules.md
+@.rcode/references/no-unauthorized-git-ops.md
+@.rcode/references/karpathy-guidelines.md
+
+<role>
+You are Raees (رئيس) — the orchestration director for this rcode project. You own
+the run, not the code. You decide what happens next, who does it, in what order,
+and you report what actually happened.
+
+You do NOT implement, plan, verify, or review yourself. Every one of those has an
+owner. Your failure mode is doing the work — the moment you start editing files
+instead of dispatching, the run has no orchestrator.
+</role>
+
+## Session opening — mandatory, before any other output
+
+The user should never have to guess what you are about to do. Open every
+invocation with an orientation block, in this exact order:
+
+```
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+ rcode ► RAEES — {project name}
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+
+Where you are   {phase N — name} · {status} · {X/Y phases complete}
+What I read     {the state/roadmap/verification files you actually opened}
+What I'll do    {2-4 numbered steps, each naming its owner agent}
+What I need     {decisions blocked on the user, or "nothing — starting now"}
+```
+
+Rules for that block:
+
+- **Read state before writing it.** `progress init` and the phase's artifacts
+  come first; a banner written from assumption is worse than no banner.
+- **Name the owner of every step.** "Plan phase 12 (rcode-planner)" — not "plan
+  the phase". The user is entitled to know who is being spawned on their tokens.
+- **Surface blockers before starting, not after.** If step 3 needs a decision the
+  user hasn't made, say so in `What I need` and stop at step 2.
+- **State counts, not adjectives.** "2 sprints, 14 tasks, 3 waves" — never "a few
+  things to do".
+- Every persona introduces itself in one line (see `response-style.md`); yours is
+  this banner instead, because a run spends the user's tokens before it produces
+  anything. It is orientation, not persona performance: no backstory, no "as your
+  orchestrator I will…", no greeting longer than the banner itself.
+
+## During the run
+
+Report each dispatch as it happens and each return as it lands — a silent
+orchestrator is indistinguishable from a stalled one. On every return, state
+what the agent actually produced, not what it was asked to produce.
+
+Close with what changed, what is still open, and the single next step.
+
+## The other orchestrator
+
+`rcode-hussain-pm` also orchestrates, on the other axis. He owns WHAT the pieces
+are and who owns each; you own HOW the run happens — sequencing, waves, dispatch,
+the verify chain. When work is bigger than one owner, the decomposition is his
+and the running of it is yours.
+
+**Never both dispatch into the same run.** If a decomposition already exists, take
+it and sequence it; do not re-cut it. If none exists and the work clearly needs
+one, ask for it rather than inventing scope — inventing scope is his failure mode
+and you should not borrow it.
+
+## Routing
+
+Route from context, never from a keyword table alone — read the files the work
+touches, the migrations it alters, and the decisions already recorded, then pick
+the lens that evidence needs. `select-panel` is a signal, not the verdict; when
+your reading disagrees with it, your reading wins and you say which file made you
+override.
+
+## Critical rules
+
+- **Never implement.** Dispatch to `rcode-executor`, `rcode-hanzla`, or the
+  domain specialist. If no agent fits, say so — do not fill the gap yourself.
+- **Never mark work complete on an agent's say-so.** Completion comes from the
+  verification path, and a `passed` with no `falsification: upheld` is
+  self-certified.
+- **Never skip the orientation block**, including on resumed or chained runs. A
+  resumed run is exactly when the user has lost track of where things stand.
+- **Never claim a wave ran in parallel unless it did** — report the actual shape,
+  including waves forced sequential by file overlap.

package/rcode/agents/rules/executor/correctness-hazard-scan.md

@@ -0,0 +1,98 @@
+# rcode Executor: Correctness Hazard Self-Audit
+
+Read this before Step 5 (Summary Creation) whenever the plan touched
+**async code, shared/mutable state, or a third-party library's async API**.
+This exists because these bug classes reliably survive `npm test` / `tsc`
+and only get caught in human PR review — the goal is to catch them first.
+
+Static checks (tests pass, types clean) prove the code is well-formed. They
+do not prove it is correct under concurrency, under React's re-render
+model, or against a library's actual (not assumed) async contract. This
+scan is what closes that gap.
+
+---
+
+## When to run this
+
+Run it if the diff for this plan touched ANY of:
+- a database read-modify-write (read a row, compute, write it back)
+- React state updates (`setState`, `useState` setters, reducers)
+- a call into an async library API (`mutate`, `.then`, callbacks, queues)
+- code reachable from more than one entry point/event at once (two API
+  routes touching the same record, two UI handlers touching the same state)
+
+If none of these apply, skip — don't burn a pass on a pure sync CRUD change.
+
+## Hazard 1 — Concurrency races (read-modify-write)
+
+**Pattern to grep for:** a `Read` followed later by a `Write`/`Update`
+using a value derived from that read, where two callers could interleave.
+
+**Ask explicitly:** "If two requests hit this at the same instant, what
+happens?" If the answer requires the reads and writes to stay in program
+order, but nothing enforces that (no transaction, no row lock, no atomic
+increment/decrement, no optimistic-concurrency version check) — it's a race.
+
+**Fix pattern:** push the read-modify-write into the database as one
+atomic operation (`UPDATE ... SET x = x + 1`, `INSERT ... ON CONFLICT`,
+a transaction with the correct isolation level) instead of
+read-in-app-then-write.
+
+## Hazard 2 — React state updater purity
+
+**Pattern to grep for:** any `setX(prev => ...)` / reducer function body
+that calls something other than a pure computation on `prev` — a side
+effect (`deleteFileObject`, a network call, a mutation of an object
+that also exists elsewhere) invoked *inside* the updater.
+
+**Why it matters:** React may call an updater function more than once per
+state change (Strict Mode, concurrent rendering, batched replays). Any
+side effect inside it runs that many times too.
+
+**Fix pattern:** the updater computes and returns the next state only.
+Side effects happen in the event handler or an effect, outside the
+updater, exactly once.
+
+**Recurrence note:** if this fix has already been applied once in this
+codebase in a similar handler, grep for the same shape (`set\w+\(\s*\w+\s*=>` followed
+by a call other than array/object spread) across the whole diff, not just
+the file that was fixed — the same author habit tends to repeat in sibling
+handlers.
+
+## Hazard 3 — Async library footguns (assumed vs. actual contract)
+
+**Pattern to grep for:** consecutive/rapid calls into an async library
+API each with their own inline callback (`mutate(x, { onSuccess })`
+called twice before the first resolves; `.then()` chains fired in a loop).
+
+**Do not assume intuitive behavior** — check the library's actual
+contract before shipping. Known real-world case: TanStack Query's
+`mutate()` per-call `onSuccess`/`onError` callbacks are dropped for a
+mutation if a **newer** call to the same mutation starts before the
+earlier one resolves — only the latest call's callbacks run. If code
+depends on every call's callback firing, that's already broken.
+
+**Fix pattern:** either use `mutateAsync` + `await` in sequence, or read
+the docs for exactly how "concurrent calls to the same mutation" are
+handled before relying on per-call callbacks — do not assume the naive
+"each call gets its own independent completion" model.
+
+---
+
+## What to do if a hazard is found
+
+Treat it as **Deviation Rule 1 (auto-fix bugs)** — fix it now, before
+SUMMARY.md, same as any other logic error. Do not defer it to PR review;
+that is the exact failure mode this file exists to close.
+
+## Self-Check addition
+
+Add to the SUMMARY.md Self-Check block:
+
+```
+- [ ] Correctness hazard scan run (concurrency / state-updater purity / async-library contract) — N/A or PASSED
+```
+
+If a hazard was found and fixed, note it under deviations with the
+hazard name (e.g. "Hazard 2: state-updater purity — `deleteFileObject`
+moved out of `setItems` updater in `FileList.tsx`").

package/rcode/agents/rules/executor/execution-flow.md

@@ -86,6 +86,14 @@ For each task in sequence:
      This enables resume-work to see progress if executor crashes
    - Continue to next
 
+### Step 4.5: Correctness Hazard Self-Audit
+If this plan's diff touched async code, shared/mutable state, or a
+third-party library's async API, read
+`.rcode/agents-rules/executor/correctness-hazard-scan.md` and run the scan
+BEFORE Summary Creation — not after, and not left for PR review. Fix any
+hazard found under Deviation Rule 1 and note it in SUMMARY.md deviations.
+Skip this step entirely for plans that never touched those surfaces.
+
 ### Step 5: Summary Creation (Pattern A only)
 After all auto tasks complete:
 1. Create SUMMARY.md at `.planning/phases/XX-name/{phase}-{plan}-SUMMARY.md`

package/rcode/agents/rules/executor/self-check.md

@@ -35,6 +35,12 @@ Before finalizing SUMMARY.md, verify plan execution was complete and correct.
 - [ ] All imports resolve (no broken paths)
 - [ ] All tests passing (if tests were modified)
 
+### Correctness Hazards (if diff touched async/state/mutation code)
+- [ ] Read `.rcode/agents-rules/executor/correctness-hazard-scan.md` and ran the scan, or confirmed N/A (no async/shared-state/library-async surface touched)
+- [ ] No read-modify-write against shared state without a transaction/atomic op/lock
+- [ ] No side effects inside React state updater/reducer functions
+- [ ] No reliance on an async library's per-call callback firing without checking its actual concurrent-call contract
+
 ### Success Criteria
 - [ ] Original plan `<success_criteria>` met
 - [ ] All `<verify>` checks pass
@@ -191,6 +197,7 @@ git stash
 - [ ] Task names in SUMMARY don't match plan
 - [ ] Deviations list is incomplete
 - [ ] You're unsure whether code works
+- [ ] Diff touched async/shared-state/library-async code and the correctness hazard scan wasn't run
 
 **If any flag raised:**
 1. Don't create SUMMARY yet
@@ -217,6 +224,7 @@ Verification performed:
 - [ ] Success criteria verified
 - [ ] Stubs documented or resolved
 - [ ] Deviations documented
+- [ ] Correctness hazard scan run (or N/A — no async/shared-state/library-async surface touched)
 
 **Issues encountered and resolved:**
 [List any red flags caught and how you fixed them]

package/rcode/agents/rules/orchestrator/contract.md

@@ -0,0 +1,76 @@
+# Orchestrator Contract — Raees (رئيس)
+
+`@`-included by `plan.md` and `execute.md`. The session running those workflows
+IS the orchestrator — rcode has no separate process dispatching on your behalf,
+which is exactly why this role has to be adopted explicitly rather than assumed.
+Raees is not spawned as a subagent here; a subagent cannot reliably spawn the
+executors and planners these workflows need.
+
+The persona file (`rcode/agents/rcode-orchestrator.md`) is the same contract for
+direct `/rcode-orchestrator` invocation. Keep the two in step.
+
+## Open with the orientation banner
+
+Before the first subagent is spawned, always:
+
+```
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+ rcode ► RAEES — {project}
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+
+Where you are   {phase N — name} · {status} · {X/Y phases complete}
+What I read     {the files you actually opened this run}
+What I'll do    {2-4 numbered steps, each naming its owner agent}
+What I need     {decisions blocked on the user, or "nothing — starting now"}
+```
+
+- **Fill it from the run's own pre-flight/INIT data, never from memory.** A banner
+  written from assumption is worse than no banner.
+- **Name the owner of every step** — "Execute wave 1 (rcode-executor ×3)", not
+  "run the plans". The user is entitled to know who is spawned on their tokens.
+- **Surface blockers before starting, not after.** If a later step needs a decision
+  the user hasn't made, put it in `What I need` and stop before that step.
+- **Counts, not adjectives.** "2 sprints, 14 tasks, 3 waves" — never "a few things".
+- **Banner on resumed and chained runs too.** A resume is exactly when the user has
+  lost track of where things stand.
+
+## Never implement
+
+Your job is to dispatch, monitor, checkpoint, and report. The moment you edit a
+file instead of dispatching, the run has no orchestrator.
+
+> **STOP.** Spawn the owning agent with the plan as context.
+
+Bypassing this produces a built project with no execution trace, no SUMMARY.md,
+and a dashboard frozen at `planned` (issue #915). The same applies to planning: a
+SPRINT.md with no `rcode-planner` Task() behind it was written by an orchestrator
+that started doing the work.
+
+## Report every dispatch and every return
+
+A silent orchestrator is indistinguishable from a stalled one. On each return,
+state what the agent actually produced — not what it was asked to produce. Close
+with what changed, what is still open, and the single next step.
+
+Never claim a wave ran in parallel unless it did; report waves forced sequential
+by file overlap as sequential.
+
+## Routing
+
+Route from context, never from a keyword table alone: read the files the work
+touches, the migrations it alters, and the decisions already recorded, then pick
+the lens that evidence needs. `select-panel` is a signal, not the verdict — when
+your reading disagrees with it, your reading wins and you name the file that made
+you override.
+
+## The other orchestrator
+
+`rcode-hussain-pm` owns WHAT the pieces are and who owns each; you own HOW the run
+happens. Never both dispatch into the same run — if a decomposition exists, take
+it and sequence it rather than re-cutting it.
+
+## Completion is not yours to declare
+
+A phase is complete when the verification path says so. A `passed` VERIFICATION.md
+with no `falsification: upheld` is self-certified — do not mark the phase complete
+on it.

package/rcode/agents/rules/sprint-checker/dimensions.md

@@ -330,6 +330,44 @@ For each `<task>` in each plan:
 - If `<automated>` is absent with no Wave 0 dependency → **BLOCKING FAIL**
 - If `<automated>` says "MISSING", a Wave 0 task must reference the same test file path → **BLOCKING FAIL** if link broken
 
+### Check 8a2 — Always-Green Assertions
+
+Scan every `<automated>` block for commands that can never fail:
+
+```bash
+grep -nE 'grep +-[a-zA-Z]*v[a-zA-Z]* ' "${PHASE_DIR}"/*-SPRINT.md
+```
+
+- Any `grep -qv` / `grep -vq` used as an "X must not appear" check → **BLOCKING FAIL**.
+  `-v` inverts per-line matching, so it exits 0 whenever ANY line fails to match — it
+  passes on almost every file, including one that DOES contain the forbidden pattern.
+  Required form: `! grep -q PATTERN FILE`.
+- `test ! -f` is fine; `! test -f` is fine; a bare `test -f` used to assert absence → **BLOCKING FAIL**.
+
+### Check 8a3 — Red-First Evidence for Guard Tests
+
+A **guard test** is any test whose purpose is to make a class of mistake
+impossible: meta-tests, schema invariant tests, forbidden-pattern scans,
+coverage/manifest tests, lint-rule tests. Identify guard-test tasks by their
+`<files>` (a `meta-*`, `*-guard*`, `*-invariant*`, or `tests/unit/*-scan*` path)
+or by an `<action>` that describes asserting a rule across a file set.
+
+For each guard-test task:
+
+- The `<action>` must state the red step — run the new test against the current
+  unfixed tree and record that it FAILS, before applying the fix. If it does not
+  → **BLOCKING FAIL**.
+- If the task both adds the guard and fixes the violation, the red step must come
+  first in the action text, not after.
+
+**Why this is blocking, not a warning:** a guard test that was never observed red
+proves nothing. It may glob the wrong path, match nothing, or assert a condition
+that is already true. It then reports green forever and the invariant it was
+written to protect rots silently underneath it. Confirmed live: a scope-coverage
+meta-test globbed only `src/app/api/**/route.ts`, so every Server Action was
+invisible to it and an authorization chokepoint went unenforced across nine
+phases with a fully green CI.
+
 ### Check 8b — Feedback Latency Assessment
 
 For each `<automated>` command:

package/rcode/agents/rules/verifier/reachability-check.md

@@ -6,8 +6,11 @@ entry point, can ever land on it. That gap is how a phase gets marked "passed"
 while the delivered page has no nav link, no sidebar entry, and no way in
 except typing its exact URL — code-complete, unusable.
 
-**When to run:** Any phase whose must-haves include a user-facing route, page,
-or screen (not API-only, not CLI-only, not backend/schema-only phases).
+**When to run:** Steps 6b/10b apply to any phase whose must-haves include a
+user-facing route, page, or screen. **Step 6c below applies to EVERY phase,
+including API-only, CLI-only, and backend/schema-only ones** — the same failure
+has a backend shape, and it is the more dangerous one because no missing nav
+link makes it visible.
 
 ## Step 6b — Reachability (static)
 
@@ -29,6 +32,46 @@ gap, not a reason to skip this check. A phase that ships pages with nowhere to
 click from IS the gap. Report it as: "No app shell/navigation exists — every
 delivered page is orphaned from UI by definition."
 
+## Step 6c — Production reachability (every phase, no exceptions)
+
+The UI version of this check asks "can a user reach this page". The backend
+version asks the same question about code: **is the delivered module reachable
+from a production entrypoint, or only from tests?**
+
+For each non-UI artifact this phase delivered (a service, repository, engine,
+job, or the function that is the phase's actual deliverable):
+
+1. List every importer of the module:
+   ```bash
+   grep -rn "from ['\"].*<module-basename>" src/ tests/ app/ lib/ 2>/dev/null
+   ```
+2. Classify each importer as production or test (`tests/`, `*.test.*`,
+   `*.spec.*`, `__tests__/` are tests).
+3. **If every importer is a test file → BLOCKING FAIL, classify as
+   ORPHANED-FROM-PRODUCTION.** The phase's own tests pass because they import
+   the implementation directly; the application calls something else, or
+   nothing.
+
+Then verify the opposite direction, which is how the dangerous version hides:
+
+4. Find what production actually calls for this phase's behaviour (the action,
+   route handler, or command the user triggers) and read it. Does it call the
+   delivered module, or does it re-implement the behaviour inline?
+5. **Two implementations of the same behaviour side by side — one tested and
+   unreachable, one shipped and untested — is a BLOCKING FAIL**, even when the
+   suite is fully green. Name both paths in VERIFICATION.md.
+
+**Why this is blocking:** confirmed live on a real project — a phase whose whole
+purpose was "closing a cycle produces an immutable snapshot" shipped with the
+production close-action setting a status field and returning, while the
+snapshot-producing service had exactly one importer in the repo: its own test.
+Green suite, verified phase, feature that never ran. The audit-attribution seam
+failed the same way, in the same commit range, for the same reason.
+
+**This check subsumes "the tests pass".** A passing test that imports the
+implementation directly proves the implementation works. It proves nothing about
+whether anything calls it.
+
 ## Step 10b — Live smoke check (dynamic)
 
 Static reachability (6b) can be fooled by a nav link that renders but is

package/rcode/bin/lib/progress.cjs

@@ -104,6 +104,13 @@ function cmdProgress(args, { PROJECT_ROOT, RCODE_DIR, PLANNING_DIR }) {
     return String(p?.number ?? p?.id ?? p?.name ?? '').trim();
   }
 
+  // Phase-number normalizer. Disk dirs are historically zero-padded
+  // ("03-evidence-ledger") while ROADMAP tables and state.json use bare
+  // integers ("3"), so every diskByNum lookup MUST go through this or the
+  // phase silently reports "disk state unavailable" forever — no amount of
+  // `state sync --from-disk` fixes it, because sync is not what's broken.
+  const normNum = (k) => String(k ?? '').trim().replace(/^0+(\d)/, '$1');
+
   function walkPhaseDirs() {
     if (!fs.existsSync(phasesDir)) return {};
     const byNum = {};
@@ -113,7 +120,7 @@ function cmdProgress(args, { PROJECT_ROOT, RCODE_DIR, PLANNING_DIR }) {
       // Phase 14 / #476 — \d+ supports high-N phase dirs (1000+).
       const numMatch = entry.match(/^(\d+(?:\.\d+)?)/);
       if (!numMatch) continue;
-      const num = numMatch[1];
+      const num = normNum(numMatch[1]);
       const files = fs.readdirSync(full);
       byNum[num] = {
         path: full,
@@ -133,7 +140,7 @@ function cmdProgress(args, { PROJECT_ROOT, RCODE_DIR, PLANNING_DIR }) {
   function enforceStrictGate(insightsList) {
     if (!strictMode) return;
     const blocking = (insightsList || []).filter(i =>
-      i && (i.kind === 'drift' || i.kind === 'undercount') && i.severity !== 'info'
+      i && (i.kind === 'drift' || i.kind === 'undercount' || i.kind === 'stale-state') && i.severity !== 'info'
     );
     if (blocking.length === 0) return;
     process.stderr.write('✖ State drift detected — state.json is out of sync with disk.\n');
@@ -159,7 +166,7 @@ function cmdProgress(args, { PROJECT_ROOT, RCODE_DIR, PLANNING_DIR }) {
     // Undercount: phases that exist on disk but not in state.
     // Accept any of `number`, `id`, or `name` as the phase identifier — the codebase historically writes different fields.
     // Also normalize "07" / "7" / 7 to a comparable form.
-    const norm = (k) => String(k ?? '').replace(/^0+(\d)/, '$1');
+    const norm = normNum;
     const statePhaseNums = new Set(statePhases.map(p => norm(phaseKey(p))));
     const diskPhaseNums = Object.keys(diskByNum);
     const missingFromState = diskPhaseNums.filter(n => !statePhaseNums.has(norm(n)));
@@ -171,6 +178,28 @@ function cmdProgress(args, { PROJECT_ROOT, RCODE_DIR, PLANNING_DIR }) {
       });
     }
 
+    // Stale-state: the INVERSE of phantom-complete — the phase has a passing
+    // VERIFICATION.md on disk but state.json still says planned/in_progress.
+    // Every other detector here is tuned to catch OVER-claiming; nothing
+    // caught under-reporting, which is why a real project ran nine phases with
+    // `executions: 0` and a dashboard reading 1/13 while the disk said 10/13.
+    // Silence in the one direction is not safety, it is a blind spot.
+    const staleState = [];
+    for (const p of statePhases) {
+      const st = String(p.status ?? '').toLowerCase();
+      if (st === 'complete' || st === 'completed' || st === 'done' || st === 'verified' || p.completed) continue;
+      const disk = diskByNum[normNum(phaseKey(p))];
+      if (!disk || !disk.has_verification) continue;
+      staleState.push(normNum(phaseKey(p)));
+    }
+    if (staleState.length > 0) {
+      insights.push({
+        kind: 'stale-state',
+        severity: 'warn',
+        message: `${staleState.length} phase(s) have a VERIFICATION.md on disk but are not marked complete in state.json: ${staleState.slice(0, 5).join(', ')}. Completion was never written back — your real progress is higher than this dashboard shows. Run: node .rcode/bin/rcode-tools.cjs state sync --from-disk`,
+      });
+    }
+
     // Phantom-complete: phase claimed Complete (in ROADMAP or state) but missing
     // PLAN.md AND SUMMARY.md on disk. User-visible bug: /rcode-status would
     // happily report 'all complete' while /rcode-audit correctly flagged the
@@ -188,7 +217,7 @@ function cmdProgress(args, { PROJECT_ROOT, RCODE_DIR, PLANNING_DIR }) {
     for (const p of roadmapPhases) if (claimedComplete(p)) completeKeys.add(norm(phaseKey(p)));
     for (const p of statePhases) if (claimedComplete(p)) completeKeys.add(norm(phaseKey(p)));
     for (const k of completeKeys) {
-      const disk = diskByNum[k] || diskByNum[k.padStart(2, '0')];
+      const disk = diskByNum[normNum(k)];
       // Only flag when the phase dir EXISTS — purely-state-only entries are a
       // separate problem (drift/undercount above). Here we want claim-vs-files.
       if (!disk) continue;
@@ -224,7 +253,7 @@ function cmdProgress(args, { PROJECT_ROOT, RCODE_DIR, PLANNING_DIR }) {
       });
       for (const p of inProgressPhases) {
         const key = norm(phaseKey(p));
-        const disk = diskByNum[key] || diskByNum[key.padStart(2, '0')];
+        const disk = diskByNum[normNum(key)];
         if (!disk) continue;
         const dirName = disk.dirName;
         const gitArgs = ['log', '--oneline', '--since=7 days ago', '--', `.planning/phases/${dirName}/`];
@@ -265,7 +294,7 @@ function cmdProgress(args, { PROJECT_ROOT, RCODE_DIR, PLANNING_DIR }) {
     };
     const pendingExec = statePhases.filter(p => {
       if (isPhaseDone(p)) return false;
-      const disk = diskByNum[phaseKey(p)];
+      const disk = diskByNum[normNum(phaseKey(p))];
       return disk && disk.plan_count > disk.summary_count;
     }).slice(0, 3);
     for (const p of pendingExec) {
@@ -285,7 +314,7 @@ function cmdProgress(args, { PROJECT_ROOT, RCODE_DIR, PLANNING_DIR }) {
     const inProgressNoPlan = statePhases
       .filter(p => (p.status === 'in_progress' || p.status === 'in-progress'))
       .filter(p => {
-        const disk = diskByNum[phaseKey(p)];
+        const disk = diskByNum[normNum(phaseKey(p))];
         return !disk || disk.plan_count === 0;
       })
       .slice(0, 2);
@@ -299,7 +328,7 @@ function cmdProgress(args, { PROJECT_ROOT, RCODE_DIR, PLANNING_DIR }) {
     if (allDone) {
       // Count unverified phases (complete but no VERIFICATION.md on disk)
       const unverifiedCount = statePhases.filter(p => {
-        const disk = diskByNum[phaseKey(p)];
+        const disk = diskByNum[normNum(phaseKey(p))];
         return (p.status === 'complete' || p.completed) && disk && !disk.has_verification;
       }).length;
       const hasDrift = (insights || []).some(i => i.kind === 'roadmap-drift' || (i.message && i.message.includes('ROADMAP')));
@@ -339,12 +368,11 @@ function cmdProgress(args, { PROJECT_ROOT, RCODE_DIR, PLANNING_DIR }) {
    */
   function computeWeightedProgress(stPhases, diskMap) {
     if (!stPhases.length) return { weighted: 0, pct: 0 };
-    const norm = (k) => String(k ?? '').replace(/^0+(\d)/, '$1');
     let sum = 0;
     for (const p of stPhases) {
-      const k = norm(phaseKey(p));
+      const k = normNum(phaseKey(p));
       if (p.status === 'complete' || p.completed) { sum += 1; continue; }
-      const disk = diskMap[k] || diskMap[phaseKey(p)];
+      const disk = diskMap[k];
       if (!disk) continue;
       if (disk.summary_count > 0)       { sum += 1;    continue; }
       if (disk.has_verification)         { sum += 0.85; continue; }
@@ -410,7 +438,7 @@ function cmdProgress(args, { PROJECT_ROOT, RCODE_DIR, PLANNING_DIR }) {
     phases: (() => {
       // Prefer ROADMAP-parsed phases when available; fall back to state.phases
       // when the roadmap doesn't use a parseable format. Normalize "07" / "7" / 7.
-      const norm = (k) => String(k ?? '').replace(/^0+(\d)/, '$1');
+      const norm = normNum;
       const source = roadmapPhases.length > 0 ? roadmapPhases : statePhases.map(p => ({
         number: phaseKey(p),
         name: p.name || '',
@@ -424,7 +452,7 @@ function cmdProgress(args, { PROJECT_ROOT, RCODE_DIR, PLANNING_DIR }) {
           ...p,
           number: k,
           status: p.status || (sp && sp.status) || null,
-          disk: diskByNum[k] || null,
+          disk: diskByNum[normNum(k)] || null,
           in_state: !!sp,
         };
       });