wdi-method 0.5.3 → 0.5.9

package/kit/.constitution/method/document/templates/architecture-spine.md

@@ -1,100 +1,100 @@
----
-name: '{name}'
-type: architecture-spine
-purpose: build-substrate    # build-substrate (default) · discussion · report · deck
-altitude: feature           # initiative (keeps features) · feature (keeps epics) · epic (keeps stories)
-paradigm: '{named design pattern, e.g. hexagonal, layered, pipes-and-filters, actor}'
-scope: '{what this spine governs}'
-status: draft               # draft · final
-created: '{date}'
-updated: '{date}'
-binds: []                   # capability / unit IDs governed (from the driving spec; at epic altitude, also the inherited parent AD ids)
-sources: []
-companions: []
-reviewed:                # V13. Diisi hanya setelah bmad-review benar-benar dijalankan
-  date: ''               # '{YYYY-MM-DD}'
-  sha: ''                # commit it was reviewed at; without the SHA, staleness cannot be measured
-  lenses: []             # structure · prose · edge-case-hunter · adversarial · verification-gap
----
-
-# Architecture Spine — {name}
-
-<!-- TEMPLATE GUIDE — act on these comments, then delete them; never emit a comment in the finished spine. This is a shape, not a script: keep only the sections this spine needs and cut the rest (no empty headers). A small intent may be just paradigm + a few ADs + conventions; a platform earns more. An inherited epic spine is usually mostly Inherited Invariants + a thin Deferred. Decisions, not rationale (rationale lives in the memlog). Carry shape in diagrams; prose only where it must. -->
-
-## Design Paradigm
-
-<!-- Name the pattern (a known one loads a whole model for free) and map its layers to namespaces/directories. The smallest, most durable thing here. -->
-
-## Inherited Invariants
-
-<!-- Only when this spine inherits a higher-altitude parent. The parent's ADs/conventions/paradigm that bind here, by their ORIGINAL ids — read-only, never renumbered, not re-derived. A local decision that contradicts one is a conflict to surface, not an override. Cut this section otherwise. -->
-
-| Inherited | From parent | Binds here |
-| --- | --- | --- |
-| {AD-id / convention} | {parent spine} | {what it constrains in this scope} |
-
-## Invariants & Rules
-
-<!-- The durable heart: calls a future builder can't read off compliant code. One block per decision: stable ascending id (never reused/renumbered), Binds, Prevents (the divergence), Rule (enforceable). Tag [ADOPTED] when the user or existing reality settled it. Include a dependency-direction diagram (who may depend on whom) — it IS a rule; author it as valid mermaid, never an empty graph. -->
-
-### AD-1 — {decision}
-
-- **Binds:** {capability / unit ids / fr/nfr's, areas, or `all`}
-- **Prevents:** {the divergence this stops}
-- **Rule:** {the constraint downstream must follow}
-
-## Consistency Conventions
-
-<!-- Defaults that bind where independent builders would drift. Cut rows that don't apply; add rows the project needs. -->
-
-| Concern | Convention |
-| --- | --- |
-| Naming (entities, files, interfaces, events) | |
-| Data & formats (ids, dates, error shapes, envelopes) | |
-| State & cross-cutting (mutation, errors, logging, config, auth) | |
-
-## Stack
-
-<!-- SEED — verified current at authoring; the code owns this once it exists. Name + version only; the why lives in the memlog. One row per language, framework, key dependency, platform, or chain that's pinned. -->
-
-| Name | Version |
-| --- | --- |
-| {language / framework / key dep / platform / chain} | {pinned version} |
-
-## Structural Seed
-
-<!-- The shapes worth fixing at cold-start — not a fixed list. Include only what's non-obvious at this altitude, and use as many diagrams as convey it, each as VALID mermaid (never a placeholder or empty graph). Candidates: system/container/context view; DEPLOYMENT & ENVIRONMENTS and external provider/infra topology (cover the operational envelope here when this altitude owns it — don't let it fall through); core-entity ERD (names + relationships only; an attribute that's itself an invariant is an AD, not a diagram); a minimal source tree. The code owns the detail — this is scaffold, not a mirror to maintain. -->
-
-```text
-{root}/
-  {dir}/   # {what lives here}
-```
-
-## Capability → Architecture Map
-
-<!-- Present when a spec drove this run. Bridges the spec's capabilities to where they live + what governs them; the consistency auditor's checklist. Cut otherwise. -->
-
-| Capability / Area | Lives in | Governed by |
-| --- | --- | --- |
-| {CAP-id / area} | {component / module} | {AD-id, convention, paradigm} |
-
-## Deferred
-
-<!-- Decisions intentionally pushed down, each with the reason it can wait — including whole dimensions this altitude doesn't own yet. The half of the contract that keeps the spine lean. -->
-
----
-
-## Project overrides — WDI
-
-- **Altitude.** This project authors the `initiative` spine only, at `.how/_platform/architecture/`.
-  Component-level design belongs to `SDD-<pc>.md`, written by `wdi-component`, not to a `feature`
-  spine.
-- **This is not an HLD.** The spine constrains; it does not describe. What the system consists of
-  belongs to `c4-l1-system-context.md` and `c4-l2-containers.md`. Deployment topology has no home
-  in this corpus at all — it lives in the devops repository and is referenced from C4 L2.
-- **`AD-N` versus `DEC-NNN`.** An `AD-N` here is a living rule, edited in place. A `DEC-NNN` in
-  `.control/decisions/` is one decision event, never edited and replaced by a `superseded` pointer.
-  The two MUST NOT be interchanged.
-- **Ordering.** The spine is authored before `bmad-spec` runs, and `bmad-spec` adopts it as a
-  companion — never the reverse.
-- **Memlog.** Written to `.control/memlog/spine.md` via `--path`.
+---
+name: '{name}'
+type: architecture-spine
+purpose: build-substrate    # build-substrate (default) · discussion · report · deck
+altitude: feature           # initiative (keeps features) · feature (keeps epics) · epic (keeps stories)
+paradigm: '{named design pattern, e.g. hexagonal, layered, pipes-and-filters, actor}'
+scope: '{what this spine governs}'
+status: draft               # draft · final
+created: '{date}'
+updated: '{date}'
+binds: []                   # capability / unit IDs governed (from the driving spec; at epic altitude, also the inherited parent AD ids)
+sources: []
+companions: []
+reviewed:                # V13. Filled only after wdi-review has actually run
+  date: ''               # '{YYYY-MM-DD}'
+  sha: ''                # commit it was reviewed at; without the SHA, staleness cannot be measured
+  lenses: []             # structure · prose · edge-case-hunter · adversarial · verification-gap
+---
+
+# Architecture Spine — {name}
+
+<!-- TEMPLATE GUIDE — act on these comments, then delete them; never emit a comment in the finished spine. This is a shape, not a script: keep only the sections this spine needs and cut the rest (no empty headers). A small intent may be just paradigm + a few ADs + conventions; a platform earns more. An inherited epic spine is usually mostly Inherited Invariants + a thin Deferred. Decisions, not rationale (rationale lives in the memlog). Carry shape in diagrams; prose only where it must. -->
+
+## Design Paradigm
+
+<!-- Name the pattern (a known one loads a whole model for free) and map its layers to namespaces/directories. The smallest, most durable thing here. -->
+
+## Inherited Invariants
+
+<!-- Only when this spine inherits a higher-altitude parent. The parent's ADs/conventions/paradigm that bind here, by their ORIGINAL ids — read-only, never renumbered, not re-derived. A local decision that contradicts one is a conflict to surface, not an override. Cut this section otherwise. -->
+
+| Inherited | From parent | Binds here |
+| --- | --- | --- |
+| {AD-id / convention} | {parent spine} | {what it constrains in this scope} |
+
+## Invariants & Rules
+
+<!-- The durable heart: calls a future builder can't read off compliant code. One block per decision: stable ascending id (never reused/renumbered), Binds, Prevents (the divergence), Rule (enforceable). Tag [ADOPTED] when the user or existing reality settled it. Include a dependency-direction diagram (who may depend on whom) — it IS a rule; author it as valid mermaid, never an empty graph. -->
+
+### AD-1 — {decision}
+
+- **Binds:** {capability / unit ids / fr/nfr's, areas, or `all`}
+- **Prevents:** {the divergence this stops}
+- **Rule:** {the constraint downstream must follow}
+
+## Consistency Conventions
+
+<!-- Defaults that bind where independent builders would drift. Cut rows that don't apply; add rows the project needs. -->
+
+| Concern | Convention |
+| --- | --- |
+| Naming (entities, files, interfaces, events) | |
+| Data & formats (ids, dates, error shapes, envelopes) | |
+| State & cross-cutting (mutation, errors, logging, config, auth) | |
+
+## Stack
+
+<!-- SEED — verified current at authoring; the code owns this once it exists. Name + version only; the why lives in the memlog. One row per language, framework, key dependency, platform, or chain that's pinned. -->
+
+| Name | Version |
+| --- | --- |
+| {language / framework / key dep / platform / chain} | {pinned version} |
+
+## Structural Seed
+
+<!-- The shapes worth fixing at cold-start — not a fixed list. Include only what's non-obvious at this altitude, and use as many diagrams as convey it, each as VALID mermaid (never a placeholder or empty graph). Candidates: system/container/context view; DEPLOYMENT & ENVIRONMENTS and external provider/infra topology (cover the operational envelope here when this altitude owns it — don't let it fall through); core-entity ERD (names + relationships only; an attribute that's itself an invariant is an AD, not a diagram); a minimal source tree. The code owns the detail — this is scaffold, not a mirror to maintain. -->
+
+```text
+{root}/
+  {dir}/   # {what lives here}
+```
+
+## Capability → Architecture Map
+
+<!-- Present when a spec drove this run. Bridges the spec's capabilities to where they live + what governs them; the consistency auditor's checklist. Cut otherwise. -->
+
+| Capability / Area | Lives in | Governed by |
+| --- | --- | --- |
+| {CAP-id / area} | {component / module} | {AD-id, convention, paradigm} |
+
+## Deferred
+
+<!-- Decisions intentionally pushed down, each with the reason it can wait — including whole dimensions this altitude doesn't own yet. The half of the contract that keeps the spine lean. -->
+
+---
+
+## Project overrides — WDI
+
+- **Altitude.** This project authors the `initiative` spine only, at `.how/_platform/architecture/`.
+  Component-level design belongs to `SDD-<pc>.md`, written by `wdi-component`, not to a `feature`
+  spine.
+- **This is not an HLD.** The spine constrains; it does not describe. What the system consists of
+  belongs to `c4-l1-system-context.md` and `c4-l2-containers.md`. Deployment topology has no home
+  in this corpus at all — it lives in the devops repository and is referenced from C4 L2.
+- **`AD-N` versus `DEC-NNN`.** An `AD-N` here is a living rule, edited in place. A `DEC-NNN` in
+  `.control/decisions/` is one decision event, never edited and replaced by a `superseded` pointer.
+  The two MUST NOT be interchanged.
+- **Ordering.** The spine is authored before `bmad-spec` runs, and `bmad-spec` adopts it as a
+  companion — never the reverse.
+- **Memlog.** Written to `.control/memlog/spine.md` via `--path`.

package/kit/.constitution/method/document/templates/inventory.md

@@ -31,8 +31,8 @@ verified: ''             # commit SHA the derivation was read at; required when
      TWO WAYS THIS FILE COMES TO EXIST, and derived_from says which:
        plan  no code yet. Written as intent — the tables, endpoints, or screens planned. Nothing can
              be derived, because there is no source.
-       code  code exists. Derived by .constitution/method/scripts/inventory.py — migrations for tables,
-             route registration for endpoints, pages for screens — and THEN compared with the plan.
+       code  code exists. Derived by .constitution/method/scripts/inventory.py, reading this product's
+             patterns from .constitution/project/inventory-readers.py — and THEN compared with the plan.
              The difference is a FINDING, reported. It MUST NOT be patched into agreement by hand.
 
      MUST NOT be assembled from a README, from a route name that looks plausible, or from memory. -->

package/kit/.constitution/method/document/templates/sdd.md

@@ -6,7 +6,7 @@ created: '{YYYY-MM-DD}'
 updated: '{YYYY-MM-DD}'
 realizes: []             # UC ids this design realizes, from usecases.yaml
 binds: []                # AD ids from the spine that bind here
-reviewed:                # V13. Diisi hanya setelah bmad-review benar-benar dijalankan
+reviewed:                # V13. Filled only after wdi-review has actually run
   date: ''               # '{YYYY-MM-DD}'
   sha: ''                # commit it was reviewed at; without the SHA, staleness cannot be measured
   lenses: []             # the set risk_accepted names — NOT a fixed list

package/kit/.constitution/method/document/templates/srs.md

@@ -1,149 +1,149 @@
----
-type: srs
-component: '{pc}'
-status: draft            # draft · reviewed · locked · superseded
-created: '{YYYY-MM-DD}'
-updated: '{YYYY-MM-DD}'
-satisfies: []            # FR / NFR ids this component carries, from requirements.yaml
-reviewed:                # V13. Diisi hanya setelah bmad-review benar-benar dijalankan
-  date: ''               # '{YYYY-MM-DD}'
-  sha: ''                # commit it was reviewed at; without the SHA, staleness cannot be measured
-  lenses: []             # the set risk_accepted names — NOT a fixed list
----
-
-# SRS — {Product Component}
-
-<!-- TEMPLATE GUIDE — act on these comments, then delete them. Never emit a comment in a finished
-     SRS. Section headings stay English; the prose inside is Bahasa Indonesia, with technical terms
-     left in English per the controlled vocabulary. -->
-
-<!-- NOT a one-shot document. Despite the IEEE name, this SRS is LIVING: one per Product Component,
-     amended every wave, never signed off and frozen. -->
-
-<!-- TWO SKILLS WRITE IT, AT TWO GATES, and every section below says which:
-       [G3]  wdi-blueprint intent `catalog`. Exists at EVERY mode, including catalog
-       [G4]  wdi-component intent `behaviour`, only as deep as the component's mode
-
-     So this file EXISTS at mode: catalog. It carries the actor list and the use case catalogue, and
-     what is absent there is 04-usecases/UC-<n>-<slug>.md — the step-by-step flows.
-
-     `reviewed.lenses` MUST match what this component's risk_accepted names in components.yaml —
-     edge-case-hunter at low and medium, structure + prose at high. It is NOT read off `mode`. -->
-
-## Decision Summary · [G3]
-
-<!-- <=1 page, business language, no jargon lacking a Glossary entry. What the Product Owner reads.
-     A summary that cannot be read inside the gate's time budget IS the finding. -->
-
-## Why · [G3]
-
-<!-- Why this component exists as a separate thing. One paragraph. If it reads the same as another
-     component's Why, the boundary is wrong. -->
-
-## Actor Register · [G3]
-
-<!-- SSOT for actors, referenced by the SDD. MUST stay in this kernel, never split into a slot. Two
-     actors that turn out to be the same person MUST be merged, and G3 asks exactly this.
-
-     A variant of one actor that differs only in what is shown to them is NOT a second actor. -->
-
-| Actor | Who they are | What they may do |
-| --- | --- | --- |
-
-## UC Catalogue · [G3]
-
-<!-- THE use case list, and at mode: catalog it is the whole use-case record. One line each, and the
-     line is the artifact — not a placeholder waiting for a file.
-
-     A title MUST be a sentence a user would say, never a system term. G3 asks this as a starred
-     question.
-
-     `critical` is yes ONLY when the use case touches money, personal data, or an irreversible action.
-     Nothing else. If more than a third of this component's use cases are marked, the definition was
-     misapplied — derive it again rather than negotiating it.
-
-     `critical` decides something only at mode: deep, where every critical UC gets a full flow. -->
-
-| id | Use case | Actor | Satisfies | critical |
-| --- | --- | --- | --- | --- |
-| UC-{n} | {a sentence a user would say} | {from the Actor Register} | {FR-n} | no |
-
-## Constraints · [G3]
-
-<!-- What this component MUST work within, and where each comes from — a business rule, a regulation,
-     an external system, an applied DEC-, an AD-N. A constraint with no source is an assumption in
-     disguise; file it through wdi-question instead. -->
-
-## Non-Goals · [G3]
-
-<!-- What this component explicitly does NOT do, and which component does it instead. This does more
-     work than it looks: it is what stops the next builder adding a nearby thing here. -->
-
-## Prerequisite · [G3]
-
-<!-- What MUST already exist before this component can behave as described — another component, an
-     external system, a dataset, a credential. A prerequisite waiting on somebody outside belongs in
-     .control/questions/external.md, and that file holds go-live only, never a design gate. -->
-
-## Success Signal · [G3]
-
-<!-- How we will know this component works — observable, not aspirational. Scales with stakes: a
-     sentence for a small component, a measure with a target for one touching money or personal data. -->
-
-## Assumptions, Risks, and To Be Confirmed · [G3]
-
-<!-- THREE separate lists, and collapsing them loses the owner. An assumption is something we decided
-     to believe; a risk is something that may go wrong; a to-be-confirmed is a question with an owner.
-
-     Every to-be-confirmed MUST be filed through wdi-question before the gate opens — into
-     assumptions.md by default, blocking.md only through the three tests that file states. -->
-
-### Assumptions
-
-### Risks
-
-### To Be Confirmed
-
-## Gate Checklist · [G3]
-
-<!-- The gate questions as they apply to THIS component, answered yes / no / change. The full list
-     lives in delivery-flow-guide.md and MUST NOT be copied here. At mode: catalog only the starred
-     questions are asked. -->
-
-## Design Reference · [G3]
-
-<!-- One line pointing at the paired SDD, plus any AD-N or applied DEC- that binds this component.
-     Nothing else — solution shape MUST NOT appear in this document: no framework, no table, no
-     endpoint, no class, no queue, no file path. -->
-
----
-
-## Slots
-
-<!-- All slot content is [G4], written by wdi-component intent `behaviour` and only as deep as the
-     component's mode. At catalog every slot stays empty, and that is a finished state.
-
-     Content SHOULD stay in this kernel until the file grows past roughly 400 lines — a suggestion,
-     not a threshold. When it must split, the FIRST slot broken out SHOULD be 04-usecases/.
-
-     The numbers are READING ORDER, not classification. This is the opposite of .how/<pc>/, where
-     01-06 classify by ABCE. The two MUST NOT be conflated.
-
-     02-rules/       rules-<pc>.md — business rules binding ONLY this component. From mode: outline.
-                     A rule that turns out to bind a second component is PROMOTED to
-                     .what/business-rules.md through wdi-blueprint, never copied
-     03-domain/      domain-model.md — entities, relations, columns. [G3], exists at every mode.
-                     state-machines.md — from mode: deep only.
-                     NOT a database schema; column types MUST NOT appear here
-     04-usecases/    UC-<n>-<slug>.md, one file per full flow. At most 3 at outline and guarded;
-                     every critical UC at deep. At most EIGHT steps each — a flow needing more is
-                     either two use cases or has started describing implementation
-     05-scenarios/   SCN-<nn>-<slug>.md, long branches hanging off one UC. From mode: deep only
-
-     01-requirements/ and supplements/ are REPEALED. The first was permanently empty — FR live in the
-     PRD and this document cites them by id. The second existed for the ANX- concept, which is gone. -->
-
-## Open Items
-
-<!-- Anything still unresolved, each pointing at its row in .control/questions/. An assumption left
-     here with no id is the failure wdi-question exists to prevent. -->
+---
+type: srs
+component: '{pc}'
+status: draft            # draft · reviewed · locked · superseded
+created: '{YYYY-MM-DD}'
+updated: '{YYYY-MM-DD}'
+satisfies: []            # FR / NFR ids this component carries, from requirements.yaml
+reviewed:                # V13. Filled only after wdi-review has actually run
+  date: ''               # '{YYYY-MM-DD}'
+  sha: ''                # commit it was reviewed at; without the SHA, staleness cannot be measured
+  lenses: []             # the set risk_accepted names — NOT a fixed list
+---
+
+# SRS — {Product Component}
+
+<!-- TEMPLATE GUIDE — act on these comments, then delete them. Never emit a comment in a finished
+     SRS. Section headings stay English; the prose inside is Bahasa Indonesia, with technical terms
+     left in English per the controlled vocabulary. -->
+
+<!-- NOT a one-shot document. Despite the IEEE name, this SRS is LIVING: one per Product Component,
+     amended every wave, never signed off and frozen. -->
+
+<!-- TWO SKILLS WRITE IT, AT TWO GATES, and every section below says which:
+       [G3]  wdi-blueprint intent `catalog`. Exists at EVERY mode, including catalog
+       [G4]  wdi-component intent `behaviour`, only as deep as the component's mode
+
+     So this file EXISTS at mode: catalog. It carries the actor list and the use case catalogue, and
+     what is absent there is 04-usecases/UC-<n>-<slug>.md — the step-by-step flows.
+
+     `reviewed.lenses` MUST match what this component's risk_accepted names in components.yaml —
+     edge-case-hunter at low and medium, structure + prose at high. It is NOT read off `mode`. -->
+
+## Decision Summary · [G3]
+
+<!-- <=1 page, business language, no jargon lacking a Glossary entry. What the Product Owner reads.
+     A summary that cannot be read inside the gate's time budget IS the finding. -->
+
+## Why · [G3]
+
+<!-- Why this component exists as a separate thing. One paragraph. If it reads the same as another
+     component's Why, the boundary is wrong. -->
+
+## Actor Register · [G3]
+
+<!-- SSOT for actors, referenced by the SDD. MUST stay in this kernel, never split into a slot. Two
+     actors that turn out to be the same person MUST be merged, and G3 asks exactly this.
+
+     A variant of one actor that differs only in what is shown to them is NOT a second actor. -->
+
+| Actor | Who they are | What they may do |
+| --- | --- | --- |
+
+## UC Catalogue · [G3]
+
+<!-- THE use case list, and at mode: catalog it is the whole use-case record. One line each, and the
+     line is the artifact — not a placeholder waiting for a file.
+
+     A title MUST be a sentence a user would say, never a system term. G3 asks this as a starred
+     question.
+
+     `critical` is yes ONLY when the use case touches money, personal data, or an irreversible action.
+     Nothing else. If more than a third of this component's use cases are marked, the definition was
+     misapplied — derive it again rather than negotiating it.
+
+     `critical` decides something only at mode: deep, where every critical UC gets a full flow. -->
+
+| id | Use case | Actor | Satisfies | critical |
+| --- | --- | --- | --- | --- |
+| UC-{n} | {a sentence a user would say} | {from the Actor Register} | {FR-n} | no |
+
+## Constraints · [G3]
+
+<!-- What this component MUST work within, and where each comes from — a business rule, a regulation,
+     an external system, an applied DEC-, an AD-N. A constraint with no source is an assumption in
+     disguise; file it through wdi-question instead. -->
+
+## Non-Goals · [G3]
+
+<!-- What this component explicitly does NOT do, and which component does it instead. This does more
+     work than it looks: it is what stops the next builder adding a nearby thing here. -->
+
+## Prerequisite · [G3]
+
+<!-- What MUST already exist before this component can behave as described — another component, an
+     external system, a dataset, a credential. A prerequisite waiting on somebody outside belongs in
+     .control/questions/external.md, and that file holds go-live only, never a design gate. -->
+
+## Success Signal · [G3]
+
+<!-- How we will know this component works — observable, not aspirational. Scales with stakes: a
+     sentence for a small component, a measure with a target for one touching money or personal data. -->
+
+## Assumptions, Risks, and To Be Confirmed · [G3]
+
+<!-- THREE separate lists, and collapsing them loses the owner. An assumption is something we decided
+     to believe; a risk is something that may go wrong; a to-be-confirmed is a question with an owner.
+
+     Every to-be-confirmed MUST be filed through wdi-question before the gate opens — into
+     assumptions.md by default, blocking.md only through the three tests that file states. -->
+
+### Assumptions
+
+### Risks
+
+### To Be Confirmed
+
+## Gate Checklist · [G3]
+
+<!-- The gate questions as they apply to THIS component, answered yes / no / change. The full list
+     lives in delivery-flow-guide.md and MUST NOT be copied here. At mode: catalog only the starred
+     questions are asked. -->
+
+## Design Reference · [G3]
+
+<!-- One line pointing at the paired SDD, plus any AD-N or applied DEC- that binds this component.
+     Nothing else — solution shape MUST NOT appear in this document: no framework, no table, no
+     endpoint, no class, no queue, no file path. -->
+
+---
+
+## Slots
+
+<!-- All slot content is [G4], written by wdi-component intent `behaviour` and only as deep as the
+     component's mode. At catalog every slot stays empty, and that is a finished state.
+
+     Content SHOULD stay in this kernel until the file grows past roughly 400 lines — a suggestion,
+     not a threshold. When it must split, the FIRST slot broken out SHOULD be 04-usecases/.
+
+     The numbers are READING ORDER, not classification. This is the opposite of .how/<pc>/, where
+     01-06 classify by ABCE. The two MUST NOT be conflated.
+
+     02-rules/       rules-<pc>.md — business rules binding ONLY this component. From mode: outline.
+                     A rule that turns out to bind a second component is PROMOTED to
+                     .what/business-rules.md through wdi-blueprint, never copied
+     03-domain/      domain-model.md — entities, relations, columns. [G3], exists at every mode.
+                     state-machines.md — from mode: deep only.
+                     NOT a database schema; column types MUST NOT appear here
+     04-usecases/    UC-<n>-<slug>.md, one file per full flow. At most 3 at outline and guarded;
+                     every critical UC at deep. At most EIGHT steps each — a flow needing more is
+                     either two use cases or has started describing implementation
+     05-scenarios/   SCN-<nn>-<slug>.md, long branches hanging off one UC. From mode: deep only
+
+     01-requirements/ and supplements/ are REPEALED. The first was permanently empty — FR live in the
+     PRD and this document cites them by id. The second existed for the ANX- concept, which is gone. -->
+
+## Open Items
+
+<!-- Anything still unresolved, each pointing at its row in .control/questions/. An assumption left
+     here with no id is the failure wdi-question exists to prevent. -->