Acceptance Criteria
enums.ts exposes derived TERMINAL_STATUSES, ACHIEVING_STATUSES, ACTIONABLE_STATUSES (per PlanRuneType) and isTerminal / isAchieving / isActionable helperstags/{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.tsnext.ts, status.ts, validate.ts use the enums.ts terminal/actionable helpers instead of local DONE_STATUSES / ACTIVE_STATUSES / READY_STATUSES setsrender-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)