spec

A spec is the implementation unit in abcd's workflow. Where an intent describes what and why in human/customer terms, a spec describes how in technical terms. Each spec lives in the native spec store as a directory whose location encodes its status, decomposed into numbered tasks; the companion harness ccpm is the primary deeper backend (adr-26).

When to use

Use "spec" when referring to a specced technical work block with an spc-N identifier. Specs have acceptance criteria, task lists, and are driven to completion by the pluggable run seam (adr-27) or direct implementation.

When NOT to use

Do not call a spec a "feature" (too generic), "sprint" (carries Scrum cycle connotations), or "milestone" or "phase": both are retired as units of the record (adr-2609212115255771). A spec's end condition is its intent's acceptance criteria, and nothing above the intent groups specs for sequence; the unit below a spec is the step.

Examples

• "Spec spc-3 is the lifeboat coverage experiment, closed in the native spec store."
• "Task spc-3.1 is the first implementation task of that spec."

Related terms

• record families — the one page that maps the record families and how they relate
• intent — the human-authored document that a spec realises
• phase: the retired arc that once bundled many specs

Open question (adr-35): this entry previously related a spec to a voyage, glossed as "a full lifecycle that contains many specs". adr-35 retires that sense: voyage is now the operations namespace at ~/.abcd.noindex/voyage/<source-root-sha>/, and it contains no specs. Whether abcd still needs a term for the end-to-end project lifecycle — the container the old gloss reached for — is not settled by adr-35 and is not decided here.