Skip to main content
Purpose: Single canonical set of status values for the spec portfolio. All registry entries, scripts, and reports should use these values. Legacy or variant strings are mapped here for consistency. Last Updated: 2026-03-09

Two orthogonal axes

Encore specs carry two independent status fields. They measure different things and neither is derived from the other.

status: — org lifecycle (“is the work done?”)

Canonical values (all lowercase). SSOT: scripts/specs/schema/spec-status.ts. Note: ready (folded → in_progress), implemented (folded → complete), and superseded (folded → archived) are intentional folds — they are not canonical values. informational is removed entirely. Read by: eos-spec navigator (done/active filter), generate-spec-index.ts, generate-status-registry.ts, generate-feature-catalogue.ts, validate-compliance-gate.ts. The navigator reads the body bold-text **Status:** field; the index reads the YAML status: field — keep both representations consistent.

pipeline_status: — spec→test authoring stage (“how far through the pipeline?”)

Fixed enum, increasing maturity:
stub is the honest entry state: “spec exists, has not traversed the pipeline.” A spec is never assigned a pipeline_status it cannot prove with on-disk evidence (plan / tasks / acceptance criteria / research appendix). Read by: validate-pipeline-status.ts, scripts/registry/govern.ts, eos-spec stage-ranking, backfill-pipeline-status.ts.
Do not map between the axes. A spec marked status: complete from before the pipeline existed is almost always pipeline_status: stub — it shipped without ever going through the modern pipeline. Seeding one field from the other asserts facts that are not true.

Canonical Status Set


Mapping: Legacy / Variant → Canonical

Use this table when normalizing existing data or parsing external sources.

Enhancement / Expansion Status

  • Enhancements: Shown as N/M (e.g. 3/3) in registry. All complete ⇒ treat spec as having enhancements done.
  • Expansion phases: Tracked in DEFERRED_DASHBOARD.md. Status per expansion: ✅ Phase Complete, 📋 Specified, 🚧 In Progress.

Usage

  • audit-spec-completion.js uses this taxonomy in formatStatus() so that --update-registry writes only canonical values.
  • Weekly governance report and any new tooling should classify specs into: Done, In Progress, Backlog/Specified, Archived.
  • When adding new status variants (e.g. from a new core), add a mapping row above and update the audit script if it parses that source.

See Also