spec-awarenesslisted

# Spec Awareness Spec-driven development is the standard. Every capability should have a persistent specification in `docs/specs/` (with `type: spec` YAML frontmatter) before implementation begins. Specs are the persistent source of truth for what the system does. Backlog items in `docs/backlog/` describe changes to make — they are transient and get archived when done. ## Spec Organization: Domain > Capability Specs model the **product architecture**, not the code structure. They are organized by domain (a product-level bounded context) and capability (a specific behavior within that domain). ### Hierarchy ``` docs/specs/ {domain}/ {capability}.md # active or deprecated spec ``` ### Definitions | Term | Definition | Stability | Example | |------|-----------|-----------|---------| | **Domain** | A product-level bounded context — a coherent area of functionality. Domains change on a product-strategy timescale (years). | Very stable | `identity`, `workflow`, `execution` | | **Capability** | A specific behavior the system provides within a domain. The unit of specification. | Stable | `authentication`, `headless-mode`, `tdd-discipline` | | **Spec** | A file describing one capability: `docs/specs/{domain}/{capability}.md` | Persistent | `docs/specs/execution/headless-mode.md` | ### Naming Convention - **Domain names:** lowercase kebab-case, product-oriented (not code-oriented). Examples: `identity`, `workflow`, `data-pipeline` — NOT `src-services`, `api`, `f