/cverify skips advancing done -> verified, wrongly believing it's an invalid transition

[joshft]

Summary

/cverify mis-classifies the done -> verified workflow transition as invalid, so it skips advancing the phase after writing the verification report. The orchestrator (or human) then has to call workflow-advance.sh verified manually.

Where / what happened

During a /cauto run, after /ctdd completed the workflow was in phase done (correct — /ctdd ends at done). /cverify ran, wrote a passing verification report, and then reported:

"Workflow phase is already done — the /cauto pipeline advanced the state machine past verify during its run, so I did NOT call workflow-advance.sh verified (invalid transition from done)."

This reasoning is wrong on two counts:

1. done -> verified IS a valid transition. workflow-advance.sh usage explicitly lists verified: done -> verified (requires /cverify report file exists). The report existed.
2. done is the normal phase /cverify runs in (the documented order is done -> /cverify -> verified -> /cdocs -> documented). /cverify treated its own expected starting phase as "past verify."

Running bash .correctless/hooks/workflow-advance.sh verified immediately afterward succeeded ("Phase: verified"), confirming the transition was valid the whole time.

Impact

/cverify silently does not advance the state machine. In a /cauto pipeline the orchestrator may compensate (as happened here), but a human running /cverify standalone is left stuck in done with no indication that the advance was skipped due to a false "invalid transition" belief — they'd have to know to run workflow-advance.sh verified themselves.

Likely cause

A prompt-level reasoning gap in skills/cverify/SKILL.md around the final "advance workflow" step — the skill appears to treat phase done as "verification already happened" rather than "ready to verify". Worth pinning the expected start phase (done) and the expected transition (verified) explicitly, and asserting the advance actually fired (read back the phase) rather than reasoning about validity.

Severity

Low/medium — not a data-correctness bug, but a workflow-stall papercut that defeats the skill's own final step; recurs whenever /cverify runs from its normal done start phase.

[joshft]

Related variant: slug mismatch blocks the manual verified advance when the spec has a workflow-init collision suffix

Hit on a fresh /cauto run. After working around the non-advance described here by calling workflow-advance.sh verified manually, the gate still refused:

ERROR: Verification report not found at .correctless/verification/{slug}-N-verification.md.
Run /cverify first — it must write the report file.

Root cause — two different slug derivations for the same report:

• /cverify derived the task-slug as the logical slug (collision suffix stripped) and wrote .correctless/verification/{slug}-verification.md.
• The verified-transition gate (and /cdocs) derive the slug from the spec-file basename, which retains the workflow-init collision suffix ({slug}-N.md), so they look for .correctless/verification/{slug}-N-verification.md.

So for any spec whose workflow-init assigned a collision suffix (e.g. when {slug}.md already existed, init creates {slug}-N.md), the gate's expected filename never matches /cverify's output. Manual workaround was to cp the report to the -N-verification.md name.

Fix direction: pick one canonical slug derivation for the verification-report filename and use it in BOTH the writer (/cverify) and every reader (the verified gate + /cdocs) — either always the spec basename (suffix included) or always the logical slug, but not a mix. Pairs with the auto-advance fix in this issue: even once done -> verified auto-advances, the slug mismatch would still block it for collision-suffixed specs.