wdi-method 0.5.4 → 0.5.9

package/kit/.constitution/method/why/portability.md

@@ -31,6 +31,12 @@ them only an *example* does — not a rule.
 Everything else — the five gates, the two fields, the fifteen skills, the templates, `validate.py`,
 `inventory.py`, `../method-glossary.md`, and the three files beside this one — carries without edit.
 
+One half-exception, and it is by design: `inventory.py` is the generic engine and carries whole, but
+it reads no code itself. The three readers live in `../../project/inventory-readers.py`, which ships
+as a skeleton and belongs to the product. A new project runs `wdi-init` intent `readers` once and
+rewrites that file, nothing else. No example ships, deliberately — an example is a guess about a
+stack nobody here has seen.
+
 ## What does NOT travel
 
 | Stays behind | Why |
@@ -38,6 +44,7 @@ Everything else — the five gates, the two fields, the fifteen skills, the temp
 | `.control/` | This product's state. A new project scaffolds its own through `wdi-init` intent `setup`, or receives empty stubs on first `install` |
 | `.what/` · `.how/` | This product's promises and build |
 | `.constitution/project/codebase-*-guide.md` | Written by the **project**, not the method. They ship as empty `Draft` stubs |
+| `.constitution/project/inventory-readers.py` | How THIS product's code is read. Seeded as a SKELETON — no patterns and no stack. `wdi-init` intent `readers` writes it against the repo in front of it |
 | `_bmad-output/` | Run workspace |
 | The `bmad-*` skills themselves | BMad's, installed by BMad. Only `_bmad/custom/*.toml` is ours |
 

package/kit/.constitution/project/README.md

@@ -22,6 +22,14 @@ Normative rules that hold **only in this product**, and are not code conventions
 - a naming or language policy that differs from the method default
 - a prohibition or obligation specific to this domain
 
+## Not a rule, but it lives here anyway
+
+`inventory-readers.py` — how this product's code is read, for the three inventories. It sits in the
+room for the same reason the rules do: the method's engine is generic, reading a stack is not, and
+`update` MUST NOT overwrite what a product wrote about its own code. What ships is a **skeleton** —
+no patterns, no stack — and `wdi-init` intent `readers` fills it in against this repo. `V27` does not
+look at it: only `.md` is a rule.
+
 ## What does not
 
 | The thing | Its home |

package/kit/.constitution/project/inventory-readers.py

@@ -0,0 +1,85 @@
+"""inventory readers — how THIS product's code is read. Owned by the product, not the method.
+
+THIS FILE IS A SKELETON. It reads nothing yet, and it says so rather than reporting an empty
+product: `SKELETON = True` below makes the engine refuse to run until the readers are written.
+Delete that line when they are.
+
+Write them with the skill rather than by hand:
+
+    wdi-init  intent `readers`
+
+That skill reads this repo — its migrations, its routes, its screens, whatever shape they take —
+and fills the three functions in for the stack actually in front of it. It is the right way round:
+the package ships no stack, and no example to be mistaken for one.
+
+The whole file is yours. `wdi-method update` never writes over it and `promote` never publishes it,
+so there is nothing here marked off-limits and nothing to merge. The engine —
+`.constitution/method/scripts/inventory.py` — is the method's and is replaced on every update.
+That is the seam: a folder, not a marked region inside a shared file.
+
+WHAT THE ENGINE EXPECTS. Three functions, each taking the repo root and returning a `Derived`:
+
+    derive_db(root)      -> Derived    the tables this product stores
+    derive_api(root)     -> Derived    the endpoints it serves
+    derive_screen(root)  -> Derived    the screens it renders
+
+Three names are INJECTED before this module executes, so import nothing for them:
+
+    Row(key, cells, source)   one row. `key` is its stable identity, used for comparison; `cells`
+                              are in the column order the engine renders; `source` is the file it
+                              was read from
+    Derived(rows, unread)     what a reader returns
+    decisions(path)           an inventory's own `states:` and `platform_rows:`, read from its
+                              frontmatter — a judgement no pattern can derive, so it is declared in
+                              the artifact it governs
+
+Nothing else is offered. Needing more of the engine means the seam is in the wrong place, and that
+is a change to make in the method — not to reach around here.
+
+THE COLUMN ORDER `cells` MUST FOLLOW:
+
+    db      Table · Owning component · What it holds · Key columns · Status
+    api     Host · Method · Path · Owning component · Description · Status
+    screen  Screen · Route · States · Owning component · UC served
+
+(The leading `No` is the engine's; it keeps the numbering stable and a reader MUST NOT supply it.)
+
+THE RULE THAT NO STACK CHANGES: whatever a pattern cannot read is appended to `unread` and
+reported. It MUST NOT be guessed, and it MUST NOT be silently dropped. An inventory assembled from
+a README, or from a route name that merely looks plausible, is worth less than none — it reads as
+derived while being invented.
+
+A kind this product genuinely does not have MAY return `Derived()`. That is a real answer, and it
+is not the same as this file still being a skeleton.
+"""
+
+from __future__ import annotations
+
+from pathlib import Path
+
+# Delete this line once the three functions below actually read something. While it is here the
+# engine refuses to run, because a skeleton returning nothing and a product owning nothing look
+# identical in the output — and only one of them is true.
+SKELETON = True
+
+
+def read(path: Path) -> str:
+    try:
+        return path.read_text(encoding="utf-8", errors="replace")
+    except OSError:
+        return ""
+
+
+def derive_db(root: Path) -> "Derived":       # noqa: F821 — injected by the engine
+    """Every table this product stores, from wherever its schema actually lives."""
+    return Derived(unread=["derive_db has not been written for this product yet"])
+
+
+def derive_api(root: Path) -> "Derived":      # noqa: F821 — injected by the engine
+    """Every endpoint this product serves, from wherever its routes are registered."""
+    return Derived(unread=["derive_api has not been written for this product yet"])
+
+
+def derive_screen(root: Path) -> "Derived":   # noqa: F821 — injected by the engine
+    """Every screen this product renders, from wherever its routes are declared."""
+    return Derived(unread=["derive_screen has not been written for this product yet"])

package/kit/skills/wdi-blueprint/SKILL.md

@@ -1,203 +1,203 @@
----
-name: wdi-blueprint
-description: Use at G3 Blueprint — the one whole-product portrait, written once. Two intents, catalog and platform. Owns the use case catalogue, actors, domain model, cross-component business rules, the glossary, the spine, C4, cross-cutting, and the three inventories. Never writes a single component's depth.
----
-
-# WDI Blueprint
-
-G3 decides **the whole portrait of the system**: which use cases exist, their entities, their tables, their
-endpoints, their screens, and the invariants that bind everything built from them. Once per product.
-
-Two intents, run in this order:
-
-| Intent | Writes | Wraps |
-|---|---|---|
-| `catalog` | Per `<pc>`: § Actor Register · § UC Catalogue · `03-domain/domain-model.md`. Product level: `.what/business-rules.md` · `.control/product-glossary.md` · `usecases.yaml` | — |
-| `platform` | `.how/_platform/`: the spine · C4 L1/L2/L3 · `cross-cutting.md` · the three inventories. Registry: `containers` | `bmad-architecture` |
-
-**Blueprint content is untouched by `mode` and by `risk_accepted`.** Everything above exists at every mode,
-including `catalog`. That is what keeps the order non-circular: `mode` is first needed at G4.
-
-You MUST NOT write a single component's depth — full UC flows, local rules, failure behaviour, contracts. All
-of that is `wdi-component` at G4. You MUST NOT write a promise; when the blueprint proves a PRD wrong, that is
-`wdi-product`, not a quiet edit here.
-
-## Inputs
-
-| Source | What it answers |
-|---|---|
-| `.what/_product-brief/brief.md` | The problem, the primary user, the boundary the portrait MUST respect |
-| `.what/_prd/*/prd.md` — **every one** | Every promise made: the `FR`/`NFR` the portrait has to cover |
-| `.control/registry/components.yaml` | Which components exist, and their `owns:` |
-| `.control/product-glossary.md` | Terms already fixed |
-| `.control/decisions/` | `accepted` and `applied` decisions an `AD-N` usually sits behind |
-| `src/` · `web/` | What actually runs, when this is not a new project |
-| `.constitution/method/document/srs-guide.md` · `architecture-guide.md` | The rules the result is checked against |
-
-## Step 1 — Position
-
-- The components MUST already exist. If `components.yaml` holds no `product_components`, route to `wdi-init`
-  intent `component` — the slicing is born at the tail of G2, from the brief plus every PRD.
-- `catalog` runs before `platform`. The spine is written against a portrait that exists.
-- If the spine and C4 set already exist, `platform` is an **amendment**, never a create. A second create
-  overwrites what three waves of annotation put there.
-- If the ask is one component's mechanism or its full flows, route to `wdi-component`.
-- If the ask is what the product promises, route to `wdi-product` — an invariant is not a promise.
-
-## Step 2 — Intent `catalog`, in order
-
-The order is binding, and each step is the input to the next. Writing them out of order produces use cases
-whose nouns nobody defined.
-
-1. **Glossary.** Every domain noun, into `.control/product-glossary.md`, alphabetically, each citing the
-   document and section its definition came from. You MUST NOT invent a definition — cite a source, or route
-   the term to `wdi-question`. Two words meaning one thing is **drift**, and it MUST be resolved to one word
-   in the same pass, with the losing synonym corrected in the documents that use it.
-2. **UC Catalogue**, per component. One line per use case: `UC-N` · title · actor · the `FR` it satisfies ·
-   `critical` yes/no. A title MUST be a sentence a user would say, not a system term.
-3. **Actor Register**, per component. It stays in the SRS kernel; it is the SSOT the SDD mirrors.
-4. **Domain model** — entities, relations, columns — into `.what/<pc>/03-domain/domain-model.md`. Conceptual;
-   database column types belong to `.how/`.
-5. **Cross-component business rules** into `.what/business-rules.md`. A rule binding only one component is
-   G4 work and MUST NOT be written here.
-
-`critical` means the use case touches **money, personal data, or an irreversible action**. Nothing else. If
-the count passes a third of a component's use cases, derive it again — `delivery-flow-guide.md` owns the rule
-and it MUST NOT be negotiated.
-
-**A method term MUST NOT be written into `.constitution/method/method-glossary.md`.** A product term binds one
-project; a method term binds every project the method is installed in. Raise it as a proposal, state where it
-appeared and why the existing vocabulary does not cover it, and hand it to the owner.
-
-## Step 3 — Parallel where there is a key, serial where there is not
-
-This is not theory. In the previous run, 41 cross-component business rules from seven parallel agents had to
-be merged and de-duplicated **serially**, because the target file had no key — and that merge was the most
-expensive part of the pass.
-
-> Parallel fan-out is only for output with a natural key. Output that is a shared list with no key MUST be
-> written by one agent that reads the whole input.
-
-| Work | Parallel? | Key |
-|---|---|---|
-| UC catalogue, actors, entities per component | yes | Product Component |
-| Glossary, cross-component business rules, the spine | **no** | there is none |
-| The three inventories | yes, one agent per source | table · endpoint · screen |
-
-Three guards when running parallel: each agent writes only its own keyed file; shared files are written in one
-serial pass afterwards; the owner reviews the merged result, not N agent reports. Open questions from N agents
-arrive as **one** ranked batch.
-
-## Step 4 — Intent `platform`
-
-Dispatch `bmad-architecture` at **initiative** altitude for the spine. Do not restate the rules to it — they
-arrive through `persistent_facts` in `_bmad/custom/bmad-architecture.toml`, which installs
-`architecture-guide.md` there rather than as `doc_standards` deliberately.
-
-Then verify and land:
-
-| # | Check | Fails when |
-|---|---|---|
-| 1 | Home | The spine landed anywhere but `.how/_platform/ARCHITECTURE-SPINE.md` |
-| 2 | Every `AD-N` carries Binds, Prevents, and Rule | One is blank — an `AD-N` with no Prevents is a preference |
-| 3 | Every `AD-N` is an invariant | Breaking it in one component would not break another. It is a seed, and MUST be marked as one |
-| 4 | Stack, tree, and data shapes marked as seeds | Written as contracts, which makes the spine wrong at the first upgrade |
-| 5 | No alternatives or cost in the spine | Those live in the `DEC-` behind it; a second copy drifts |
-| 6 | Nothing but invariants | A statement affecting one component only — that is its SDD |
-| 7 | Memlog at `.control/memlog/spine.md` | A `.memlog.md` appeared inside `.how/` — `--workspace` was used |
-
-Check 7 MUST be fixed immediately. V16 rejects a memlog inside the corpus.
-
-**Land the C4 set by amending, never overwriting.** The files are living and already carry annotations,
-including a pre-method provenance note that MUST survive. When the incoming set contradicts an annotation
-already there, you MUST stop and report it, and MUST NOT resolve it by preferring the newer drawing. Where a
-C4 file and the spine disagree, the spine wins and the disagreement MUST be reported. One
-`c4-l3-<container>.md` per `built: true` container **holding more than one Product Component**. A
-`built: false` container gets no L3 at all, and a one-PC container needs none because the L2 matrix already
-places it. **Not one of the three waits for a wave** — `architecture-guide.md` owns that.
-
-**Register the containers** in `containers:` in `components.yaml`, in the same act as landing the L2. It is
-not a follow-up, and it unblocks everyone else: an `LC` MUST name its container.
-
-Each container MUST carry `built:` — `true` when we write what is inside it, `false` when we deploy
-someone else's implementation. It decides whether the container gets an L3, an `LC`, and a heading in the
-codebase map (V25). Something whose **runtime we do not deploy** is an external system: it belongs at L1,
-and registering it here promises a codebase-map section that will never exist.
-
-**Fill each PC's `containers:` in the same act, and land the matrix at L2** — the registry is the SSOT and
-the L2 table renders it. A PC MUST list every `built: true` container it lives in; listing only the main
-one is the error the matrix exists to catch. Complete for every PC at G3, untouched by `mode`.
-
-You MUST NOT register a
-`product_component` or a `logical_component`.
-
-**Register what `_platform` owns** in the same pass — a domain entity through `platform_owns`, an inventory
-row through that inventory's `platform_rows:`, an `LC` through its `component:`. The test is in
-`corpus-guide.md` and both halves MUST hold. Each one MUST then be described under `## Platform-owned` in
-`cross-cutting.md`, in the same act: V21 checks that second half, because owning something without
-documenting it is taking ownership without taking responsibility.
-
-A judgement the pattern cannot derive MUST live in the artifact it governs, not in a script and not in a
-skill: an inventory's `platform_rows:` and `states:` are declared in that inventory's own frontmatter, so
-re-derivation preserves them. Anywhere else, the next run deletes the owner's decision.
-
-`_platform` is **not** a Product Component. You MUST NOT give it a `mode`, a `risk_accepted`, an SRS, or a
-G4, and you MUST NOT move an entity there because its owner is hard to decide.
-
-## Step 5 — The three inventories
-
-They land in `.how/_platform/` with **one owner: this skill.** No negotiation with `wdi-ux`, and no second
-copy inside any SDD.
-
-| State | How each is born |
-|---|---|
-| No code yet | Written as a **plan** — the tables, endpoints, and screens intended. Nothing can be derived, because there is no source |
-| Code exists | **Derived first** by `.constitution/method/scripts/inventory.py` — migrations for tables, route registration for endpoints, pages for screens — then compared with the plan. The difference is a **finding**, not hand work |
-
-An inventory MUST NOT be assembled from a README or from route names that look plausible. Numbers are stable:
-a new row takes the next number, never a renumber.
-
-## Step 6 — The roll-up, and what the owner actually reads
-
-Regenerate `.control/generated/blueprint.md` with `validate.py --generate`. It assembles the UC catalogue, the
-actor lists, the domain model, and the three inventories into **one page**.
-
-**That page is what G3 reviews** — not seven files. The catalogue and actors stay in their component kernels as
-their permanent home; the roll-up is a view. One fact, one home, one view.
-
-You MUST NOT hand-write anything under `.control/generated/`.
-
-## Step 7 — Review and questions
-
-- No `doc_standards` fires for an SRS or for the spine. Dispatch `wdi-review`, which reads the lens set from
-  each component's `risk_accepted`.
-- You MUST NOT open G3 on a portrait that has not been through it.
-- Every unresolved to-be-confirmed MUST be filed through `wdi-question`, in **one** ranked batch — into
-  `assumptions.md` by default, `blocking.md` only through its three tests.
-- A decision surfacing while writing goes to `wdi-decision`, never into the document as a parenthetical.
-- An `AD-N` that reverses or narrows an earlier one MUST go through `wdi-decision` first. Editing an `AD-N` in
-  place is how a reversal happens with nobody deciding it.
-
-## Step 8 — A PRD that arrives after G3
-
-The blueprint is **living and amended**, not repeated. `wdi-init` intent `component` births the new
-components, this skill adds their rows to the catalogue and the three inventories, and **G3 reopens over the
-delta only**. The 45-minute session does not run again for one additional initiative.
-
-## Rules
-
-- You MUST NOT write into `.how/<pc>/`, and `design-system.md` in `_platform/` belongs to `wdi-ux`.
-- You MUST NOT regenerate the C4 set from scratch. The loss of annotations is invisible in a diff that reads
-  as a rewrite.
-- You MUST NOT raise `status:`. Status is a stage; the `reviewed:` block is an event.
-- You MUST NOT write a definition into `.constitution/` at all — not the method glossary, not a guide.
-- When the portrait cannot be drawn because a PRD has not settled what it must cover, say so and stop.
-- Memlog: one per Product Component at `.control/memlog/<pc>.md`, plus `.control/memlog/spine.md` for
-  `platform`, through `memlog.py --path`. `--workspace` MUST NOT be used.
-
-## Output
-
-Intents run · the catalogue and inventories as counts, per component · glossary terms written, proposed, and
-rejected with the rule that rejected each · the `AD-N` that are new or changed · what was amended in the C4
-set and what contradicted it · containers registered · plan-versus-code differences reported · whether the
-roll-up regenerated and `wdi-review` ran · the one ranked batch of questions.
+---
+name: wdi-blueprint
+description: Use at G3 Blueprint — the one whole-product portrait, written once. Two intents, catalog and platform. Owns the use case catalogue, actors, domain model, cross-component business rules, the glossary, the spine, C4, cross-cutting, and the three inventories. Never writes a single component's depth.
+---
+
+# WDI Blueprint
+
+G3 decides **the whole portrait of the system**: which use cases exist, their entities, their tables, their
+endpoints, their screens, and the invariants that bind everything built from them. Once per product.
+
+Two intents, run in this order:
+
+| Intent | Writes | Wraps |
+|---|---|---|
+| `catalog` | Per `<pc>`: § Actor Register · § UC Catalogue · `03-domain/domain-model.md`. Product level: `.what/business-rules.md` · `.control/product-glossary.md` · `usecases.yaml` | — |
+| `platform` | `.how/_platform/`: the spine · C4 L1/L2/L3 · `cross-cutting.md` · the three inventories. Registry: `containers` | `bmad-architecture` |
+
+**Blueprint content is untouched by `mode` and by `risk_accepted`.** Everything above exists at every mode,
+including `catalog`. That is what keeps the order non-circular: `mode` is first needed at G4.
+
+You MUST NOT write a single component's depth — full UC flows, local rules, failure behaviour, contracts. All
+of that is `wdi-component` at G4. You MUST NOT write a promise; when the blueprint proves a PRD wrong, that is
+`wdi-product`, not a quiet edit here.
+
+## Inputs
+
+| Source | What it answers |
+|---|---|
+| `.what/_product-brief/brief.md` | The problem, the primary user, the boundary the portrait MUST respect |
+| `.what/_prd/*/prd.md` — **every one** | Every promise made: the `FR`/`NFR` the portrait has to cover |
+| `.control/registry/components.yaml` | Which components exist, and their `owns:` |
+| `.control/product-glossary.md` | Terms already fixed |
+| `.control/decisions/` | `accepted` and `applied` decisions an `AD-N` usually sits behind |
+| `src/` · `web/` | What actually runs, when this is not a new project |
+| `.constitution/method/document/srs-guide.md` · `architecture-guide.md` | The rules the result is checked against |
+
+## Step 1 — Position
+
+- The components MUST already exist. If `components.yaml` holds no `product_components`, route to `wdi-init`
+  intent `component` — the slicing is born at the tail of G2, from the brief plus every PRD.
+- `catalog` runs before `platform`. The spine is written against a portrait that exists.
+- If the spine and C4 set already exist, `platform` is an **amendment**, never a create. A second create
+  overwrites what three waves of annotation put there.
+- If the ask is one component's mechanism or its full flows, route to `wdi-component`.
+- If the ask is what the product promises, route to `wdi-product` — an invariant is not a promise.
+
+## Step 2 — Intent `catalog`, in order
+
+The order is binding, and each step is the input to the next. Writing them out of order produces use cases
+whose nouns nobody defined.
+
+1. **Glossary.** Every domain noun, into `.control/product-glossary.md`, alphabetically, each citing the
+   document and section its definition came from. You MUST NOT invent a definition — cite a source, or route
+   the term to `wdi-question`. Two words meaning one thing is **drift**, and it MUST be resolved to one word
+   in the same pass, with the losing synonym corrected in the documents that use it.
+2. **UC Catalogue**, per component. One line per use case: `UC-N` · title · actor · the `FR` it satisfies ·
+   `critical` yes/no. A title MUST be a sentence a user would say, not a system term.
+3. **Actor Register**, per component. It stays in the SRS kernel; it is the SSOT the SDD mirrors.
+4. **Domain model** — entities, relations, columns — into `.what/<pc>/03-domain/domain-model.md`. Conceptual;
+   database column types belong to `.how/`.
+5. **Cross-component business rules** into `.what/business-rules.md`. A rule binding only one component is
+   G4 work and MUST NOT be written here.
+
+`critical` means the use case touches **money, personal data, or an irreversible action**. Nothing else. If
+the count passes a third of a component's use cases, derive it again — `delivery-flow-guide.md` owns the rule
+and it MUST NOT be negotiated.
+
+**A method term MUST NOT be written into `.constitution/method/method-glossary.md`.** A product term binds one
+project; a method term binds every project the method is installed in. Raise it as a proposal, state where it
+appeared and why the existing vocabulary does not cover it, and hand it to the owner.
+
+## Step 3 — Parallel where there is a key, serial where there is not
+
+This is not theory. In the previous run, 41 cross-component business rules from seven parallel agents had to
+be merged and de-duplicated **serially**, because the target file had no key — and that merge was the most
+expensive part of the pass.
+
+> Parallel fan-out is only for output with a natural key. Output that is a shared list with no key MUST be
+> written by one agent that reads the whole input.
+
+| Work | Parallel? | Key |
+|---|---|---|
+| UC catalogue, actors, entities per component | yes | Product Component |
+| Glossary, cross-component business rules, the spine | **no** | there is none |
+| The three inventories | yes, one agent per source | table · endpoint · screen |
+
+Three guards when running parallel: each agent writes only its own keyed file; shared files are written in one
+serial pass afterwards; the owner reviews the merged result, not N agent reports. Open questions from N agents
+arrive as **one** ranked batch.
+
+## Step 4 — Intent `platform`
+
+Dispatch `bmad-architecture` at **initiative** altitude for the spine. Do not restate the rules to it — they
+arrive through `persistent_facts` in `_bmad/custom/bmad-architecture.toml`, which installs
+`architecture-guide.md` there rather than as `doc_standards` deliberately.
+
+Then verify and land:
+
+| # | Check | Fails when |
+|---|---|---|
+| 1 | Home | The spine landed anywhere but `.how/_platform/ARCHITECTURE-SPINE.md` |
+| 2 | Every `AD-N` carries Binds, Prevents, and Rule | One is blank — an `AD-N` with no Prevents is a preference |
+| 3 | Every `AD-N` is an invariant | Breaking it in one component would not break another. It is a seed, and MUST be marked as one |
+| 4 | Stack, tree, and data shapes marked as seeds | Written as contracts, which makes the spine wrong at the first upgrade |
+| 5 | No alternatives or cost in the spine | Those live in the `DEC-` behind it; a second copy drifts |
+| 6 | Nothing but invariants | A statement affecting one component only — that is its SDD |
+| 7 | Memlog at `.control/memlog/spine.md` | A `.memlog.md` appeared inside `.how/` — `--workspace` was used |
+
+Check 7 MUST be fixed immediately. V16 rejects a memlog inside the corpus.
+
+**Land the C4 set by amending, never overwriting.** The files are living and already carry annotations,
+including a pre-method provenance note that MUST survive. When the incoming set contradicts an annotation
+already there, you MUST stop and report it, and MUST NOT resolve it by preferring the newer drawing. Where a
+C4 file and the spine disagree, the spine wins and the disagreement MUST be reported. One
+`c4-l3-<container>.md` per `built: true` container **holding more than one Product Component**. A
+`built: false` container gets no L3 at all, and a one-PC container needs none because the L2 matrix already
+places it. **Not one of the three waits for a wave** — `architecture-guide.md` owns that.
+
+**Register the containers** in `containers:` in `components.yaml`, in the same act as landing the L2. It is
+not a follow-up, and it unblocks everyone else: an `LC` MUST name its container.
+
+Each container MUST carry `built:` — `true` when we write what is inside it, `false` when we deploy
+someone else's implementation. It decides whether the container gets an L3, an `LC`, and a heading in the
+codebase map (V25). Something whose **runtime we do not deploy** is an external system: it belongs at L1,
+and registering it here promises a codebase-map section that will never exist.
+
+**Fill each PC's `containers:` in the same act, and land the matrix at L2** — the registry is the SSOT and
+the L2 table renders it. A PC MUST list every `built: true` container it lives in; listing only the main
+one is the error the matrix exists to catch. Complete for every PC at G3, untouched by `mode`.
+
+You MUST NOT register a
+`product_component` or a `logical_component`.
+
+**Register what `_platform` owns** in the same pass — a domain entity through `platform_owns`, an inventory
+row through that inventory's `platform_rows:`, an `LC` through its `component:`. The test is in
+`corpus-guide.md` and both halves MUST hold. Each one MUST then be described under `## Platform-owned` in
+`cross-cutting.md`, in the same act: V21 checks that second half, because owning something without
+documenting it is taking ownership without taking responsibility.
+
+A judgement the pattern cannot derive MUST live in the artifact it governs, not in a script and not in a
+skill: an inventory's `platform_rows:` and `states:` are declared in that inventory's own frontmatter, so
+re-derivation preserves them. Anywhere else, the next run deletes the owner's decision.
+
+`_platform` is **not** a Product Component. You MUST NOT give it a `mode`, a `risk_accepted`, an SRS, or a
+G4, and you MUST NOT move an entity there because its owner is hard to decide.
+
+## Step 5 — The three inventories
+
+They land in `.how/_platform/` with **one owner: this skill.** No negotiation with `wdi-ux`, and no second
+copy inside any SDD.
+
+| State | How each is born |
+|---|---|
+| No code yet | Written as a **plan** — the tables, endpoints, and screens intended. Nothing can be derived, because there is no source |
+| Code exists | **Derived first** by `.constitution/method/scripts/inventory.py`, which reads this product's patterns from `.constitution/project/inventory-readers.py`, then compares with the plan. The difference is a **finding**, not hand work. A product with no reader file is told so and nothing is derived — it is never guessed |
+
+An inventory MUST NOT be assembled from a README or from route names that look plausible. Numbers are stable:
+a new row takes the next number, never a renumber.
+
+## Step 6 — The roll-up, and what the owner actually reads
+
+Regenerate `.control/generated/blueprint.md` with `validate.py --generate`. It assembles the UC catalogue, the
+actor lists, the domain model, and the three inventories into **one page**.
+
+**That page is what G3 reviews** — not seven files. The catalogue and actors stay in their component kernels as
+their permanent home; the roll-up is a view. One fact, one home, one view.
+
+You MUST NOT hand-write anything under `.control/generated/`.
+
+## Step 7 — Review and questions
+
+- No `doc_standards` fires for an SRS or for the spine. Dispatch `wdi-review`, which reads the lens set from
+  each component's `risk_accepted`.
+- You MUST NOT open G3 on a portrait that has not been through it.
+- Every unresolved to-be-confirmed MUST be filed through `wdi-question`, in **one** ranked batch — into
+  `assumptions.md` by default, `blocking.md` only through its three tests.
+- A decision surfacing while writing goes to `wdi-decision`, never into the document as a parenthetical.
+- An `AD-N` that reverses or narrows an earlier one MUST go through `wdi-decision` first. Editing an `AD-N` in
+  place is how a reversal happens with nobody deciding it.
+
+## Step 8 — A PRD that arrives after G3
+
+The blueprint is **living and amended**, not repeated. `wdi-init` intent `component` births the new
+components, this skill adds their rows to the catalogue and the three inventories, and **G3 reopens over the
+delta only**. The 45-minute session does not run again for one additional initiative.
+
+## Rules
+
+- You MUST NOT write into `.how/<pc>/`, and `design-system.md` in `_platform/` belongs to `wdi-ux`.
+- You MUST NOT regenerate the C4 set from scratch. The loss of annotations is invisible in a diff that reads
+  as a rewrite.
+- You MUST NOT raise `status:`. Status is a stage; the `reviewed:` block is an event.
+- You MUST NOT write a definition into `.constitution/` at all — not the method glossary, not a guide.
+- When the portrait cannot be drawn because a PRD has not settled what it must cover, say so and stop.
+- Memlog: one per Product Component at `.control/memlog/<pc>.md`, plus `.control/memlog/spine.md` for
+  `platform`, through `memlog.py --path`. `--workspace` MUST NOT be used.
+
+## Output
+
+Intents run · the catalogue and inventories as counts, per component · glossary terms written, proposed, and
+rejected with the rule that rejected each · the `AD-N` that are new or changed · what was amended in the C4
+set and what contradicted it · containers registered · plan-versus-code differences reported · whether the
+roll-up regenerated and `wdi-review` ran · the one ranked batch of questions.

package/kit/skills/wdi-build/SKILL.md

@@ -96,8 +96,10 @@ Three rules this corpus adds. All three MUST be stated in the dispatch of any st
 - **The corpus is not the worker's to change.** A worker MUST NOT edit `.what/`, `.how/`, or an `applied`
   `DEC-`. A deviation from the SDD or an `AD-N` is **reported**, and it becomes a `DEC-` through
   `wdi-decision` — never absorbed as a code patch.
-- **Verification is run, not assumed.** `go build ./...` and `go test ./...` from `src/`, where `go.mod` lives;
-  `npm run check` from `web/`. A green `korpus.yml` MUST NOT be reported as proof the code compiles.
+- **Verification is run, not assumed.** The commands are this product's, and they live in
+  `.constitution/project/codebase-stack-guide.md` — build, test, and whatever the front end needs, each with
+  the directory it runs from. A skill MUST NOT carry one product's build line. A green registry workflow
+  MUST NOT be reported as proof the code compiles; they answer different questions.
 
 ### Step 1 — plan
 

package/kit/skills/wdi-init/SKILL.md

@@ -1,13 +1,13 @@
 ---
 name: wdi-init
-description: Use for anything that must exist before work can start or continue — scaffolding the registries at install, birthing Product Components after G2, setting or changing a component's mode, setting or reviewing its risk_accepted, and refreshing the two structure maps. Five intents. Never writes .what/ or .how/ content beyond a skeleton.
+description: Use for anything that must exist before work can start or continue — scaffolding the registries at install, birthing Product Components after G2, setting or changing a component's mode, setting or reviewing its risk_accepted, refreshing the two structure maps, and writing this product's inventory readers. Six intents. Never writes .what/ or .how/ content beyond a skeleton.
 ---
 
 # WDI Init
 
-Five intents, one skill, because all five answer the same question: **what has to exist before the
+Six intents, one skill, because all six answer the same question: **what has to exist before the
 next piece of work makes sense?** A registry row, a folder pair, a depth setting, a risk note, a map
-of where things are.
+of where things are, a reader that can see this product's code.
 
 | Intent | Does | Precondition | How often |
 |---|---|---|---|
@@ -16,6 +16,7 @@ of where things are.
 | `mode` | Change `mode` — global in `index.yaml`, or one component in `components.yaml`. Guided | — | any time |
 | `risk` | Set or review one component's `risk_accepted`, with disclosure of what it touches | the component exists | any time, usually before G4 |
 | `structure` | Re-derive `.control/structure-codebase.md` and `structure-document.md` from the tree on disk | — | when folders change, and at wave close |
+| `readers` | Write `.constitution/project/inventory-readers.py` for **this** repo's stack, then prove it by running the engine | code exists | once, and again when the code's shape moves |
 
 ## Two boundaries
 
@@ -131,11 +132,44 @@ caller is unsure: a map is cheap to check and expensive to get wrong.
 A hand-edited map MUST be treated as drift: re-derive, then say what the hand edit claimed that the tree
 does not support.
 
+## Intent `readers`
+
+`inventory.py` is two halves. Comparing what was derived against the plan, reporting the gap, keeping
+the numbers stable — that is the same in every stack and belongs to the method. **Reading the code is
+not**, so the package ships a skeleton and no example: an example is a guess about somebody else's
+stack, and the whole point of deriving rather than assembling is that nothing is guessed.
+
+The file is `.constitution/project/inventory-readers.py`. All of it is the product's — `update` never
+writes over it and `promote` never publishes it — so there is no protected region inside it and
+nothing to merge.
+
+1. **Read the repo before writing a line.** Where does the schema live, how are routes registered,
+   how are screens declared. A stack you have not confirmed on disk MUST NOT be assumed from a
+   filename or a dependency list.
+2. Fill `derive_db`, `derive_api`, and `derive_screen`. The contract, the injected names, and the
+   column order per kind are in the skeleton's own docstring and MUST NOT be restated here.
+3. **Delete the `SKELETON = True` line.** While it stands the engine refuses to run, and that is
+   deliberate: a skeleton returning nothing and a product owning nothing read identically.
+4. **Prove it, and this step is not optional.** Run `uv run .constitution/method/scripts/inventory.py`,
+   then open at least one file each reader claims to have read and confirm the rows match what is
+   actually written there. A regex that returns plausible rows from the wrong place is the failure
+   mode this intent invites, and running the engine is the only thing that catches it.
+5. Whatever a pattern cannot read goes to `unread`. You MUST NOT widen a pattern until it stops
+   reporting; an honest `unread` is worth more than a row nobody checked.
+6. Report what each reader reads, in one line per kind, and what it deliberately does not.
+
+A kind this product genuinely does not have returns `Derived()` — a real answer. You MUST NOT return
+it to make the output quiet.
+
+The rows themselves are **not** yours to land. This intent produces the reader; `wdi-blueprint` intent
+`platform` owns the three inventories, and a plan-versus-code gap is its finding to route.
+
 ## Rules
 
 - You MUST NOT write `.what/` or `.how/` content beyond a skeleton and its frontmatter. Behaviour is
   `wdi-blueprint` and `wdi-component`; mechanism is `wdi-component`.
-- You MUST NOT write into `.constitution/`.
+- You MUST NOT write into `.constitution/method/`. Intent `readers` writes exactly one file in
+  `.constitution/project/`, and nothing else there.
 - You MUST NOT fill `mode` or `risk_accepted` with a value the owner has not confirmed. Both are the
   owner's, and a proposal recorded as a decision is the one failure disclosure cannot survive.
 - You MUST NOT create a Product Component because a folder would look tidy. A PC no `FR` points at is a