WORK-492
ID:WORK-492Status:done

Consolidate plan status vocabulary into a single source of truth

Make enums.ts the one place that defines status/severity/complexity/priority vocabularies, with derived lifecycle helpers, so consumers stop re-declaring the lists and drift becomes a build failure instead of a latent bug. This lands before the downstream status additions so they inherit the consolidated shape.

Priority:highComplexity:complexMilestone:v0.28.0Source:SPEC-117
main View source

Criteria completion

Criteria completion: 7 of 7 (100%) checked; history from Jul 9 to Jul 140%25%50%75%100%Jul 9Jul 14

Relationships

Implements 1
Related 3
Branches 3
main current done
changeset-release/main doneclaude/milestone-v0-28-0-llvtfa doneclaude/plan-runes-status-vocab-jcq1tx ready
History 3
  1. cf13ce1
    • ☑ `enums.ts` exposes derived `TERMINAL_STATUSES`, `ACHIEVING_STATUSES`, `ACTIONABLE_STATUSES` (per `PlanRuneType`) and `isTerminal` / `isAchieving` / `isActionable` helpers
    • ☑ `tags/{spec,work,bug,decision,milestone}.ts` import status/severity/complexity/priority value lists from `enums.ts` (no local re-declaration)
    • ☑ `mcp-bindings.ts` status and severity enums derive from `enums.ts`
    • ☑ `next.ts`, `status.ts`, `validate.ts` use the `enums.ts` terminal/actionable helpers instead of local `DONE_STATUSES` / `ACTIVE_STATUSES` / `READY_STATUSES` sets
    • ☑ `render-pipeline.ts` / `index.ts` terminal/resolved sets derive from `TERMINAL_STATUSES`; ordering tables (which carry sort intent) remain but are covered by an exhaustiveness test
    • ☑ A test asserts every canonical status value has a `config.ts` `sentimentMap` entry and a status-ordering entry (drift fails CI)
    • ☑ No behavioural change to `plan next` / `status` / `validate` output on the current corpus (pure refactor, verified against snapshots)
    by bjornolofandersson
  2. 283ce5a
    Created (ready)by bjornolofandersson
  3. 9a519fd
    Content editedby Claude
    plan: add v0.28.0 plan-model-hardening milestone and work breakdown

Acceptance Criteria

  • enums.ts exposes derived TERMINAL_STATUSES, ACHIEVING_STATUSES, ACTIONABLE_STATUSES (per PlanRuneType) and isTerminal / isAchieving / isActionable helpers
  • tags/{spec,work,bug,decision,milestone}.ts import status/severity/complexity/priority value lists from enums.ts (no local re-declaration)
  • mcp-bindings.ts status and severity enums derive from enums.ts
  • next.ts, status.ts, validate.ts use the enums.ts terminal/actionable helpers instead of local DONE_STATUSES / ACTIVE_STATUSES / READY_STATUSES sets
  • render-pipeline.ts / index.ts terminal/resolved sets derive from TERMINAL_STATUSES; ordering tables (which carry sort intent) remain but are covered by an exhaustiveness test
  • A test asserts every canonical status value has a config.ts sentimentMap entry and a status-ordering entry (drift fails CI)
  • No behavioural change to plan next / status / validate output on the current corpus (pure refactor, verified against snapshots)

Approach

enums.ts grows the derived sets alongside the existing VALID_* records. Membership-only consumers import; structure-carrying consumers (sentiment maps, orderings) keep their tables but gain an exhaustiveness test keyed off the canonical list. Fold in the WORK-491 fixes structurally if that item hasn't landed yet.

Dependencies

  • WORK-491 — the drift fixes become structural once this lands (either order works; if 491 ships first, this generalises it)

References

  • SPEC-117 — spec (Vocabulary module, Consumers stop re-declaring vocab)

Resolution

Completed: 2026-07-09

Branch: claude/milestone-v0-28-0-llvtfa PR: refrakt-md/refrakt#565

What was done

  • enums.ts is now canonical: added TERMINAL_STATUSES/ACHIEVING_STATUSES/ACTIONABLE_STATUSES, isTerminal/isAchieving/isActionable, DONE_STATUS_SET, TERMINAL_STATUS_UNION, and shared WORK_STATUS_DISPLAY_ORDER/BUG_STATUS_DISPLAY_ORDER.
  • Rune schemas, mcp-bindings.ts, next/status/validate, render-pipeline.ts and index.ts orderings all import from enums.ts.
  • test/vocabulary.test.ts asserts every canonical status has a sentiment-map + ordering entry.

Notes

  • Verified byte-identical plan next/status/validate output on the corpus. DONE_STATUS_SET is scoped to work+bug ({done,fixed}) to preserve the exact dependency-satisfaction semantics; a full achieving-union would have wrongly treated accepted specs as satisfied deps.