wdi-method 0.5.13 → 0.6.0

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

@@ -28,7 +28,7 @@ them only an *example* does — not a rule.
 | `templates/design-system.md` | The pointer to wherever this project keeps its tokens | Re-point at that project's token file |
 | `templates/oq.md` | One example of a bad question title | Cosmetic |
 
-Everything else — the five gates, the two fields, the fifteen skills, the templates, `validate.py`,
+Everything else — the five gates, the two fields, the sixteen 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

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

@@ -6,6 +6,11 @@ status: Reference
 
 **Opened when:** you are about to change a rule and need to know what you would break.
 
+`wave` and `story` appear below wherever this file records **what happened** — a past incident, a repealed
+ceremony, a skill's old name. Those are evidence and MUST NOT be rewritten into `spec` and `ticket`;
+`../method-glossary.md` owns that rule. Where this file states a rule still in force, it uses the current
+terms.
+
 This file **explains**. It does not bind — `../document/*-guide.md` does, and where the two disagree the guide
 wins and the disagreement is a defect to report. **A rule MUST NOT be born here.** If this file notices a
 rule that should exist, it says so as a finding and the rule is written in its guide.
@@ -42,7 +47,9 @@ Every decision in this method traces to one of these. Anything that traced to no
 4. **Breadth once, depth per component.** The global portrait is born once and thin; depth is born when its
    component is actually worked on.
 5. **What can be derived is not written by hand.** Inventories, structure maps, the decision index, the
-   global catalogue, story status.
+   global catalogue, ticket status. This principle stood here alone for a long time, binding nothing —
+   this file explains and MUST NOT hold a rule — while reviews kept re-finding the same drift. It is now
+   a rule: `../document/corpus-guide.md` § A derived fact has exactly one home.
 6. **Mandatory is a cost and must buy something.** A mandatory rule that prevents no concrete failure is
    repealed, not loosened.
 
@@ -74,8 +81,8 @@ client through a contract — will demand the artifacts as a deliverable, the to
 
 ## Why `mode` has no third scope
 
-`mode` cannot be overridden per wave or per `SPEC.md`. A wave MAY cross several components, so a per-wave
-override would give one component two different depths depending on which wave touched it — while the
+`mode` cannot be overridden per spec or per `SPEC.md`. A spec MAY cross several components, so a per-spec
+override would give one component two different depths depending on which spec touched it — while the
 document is one, and living.
 
 > Depth belongs to the component, not to the work.
@@ -190,7 +197,7 @@ Not theory. In the previous run, 41 cross-component business rules from seven pa
 merged and de-duplicated **serially**, because the target file had no key — and that merge was the most
 expensive part of the pass.
 
-Keys that exist: the Product Component, the inventory source, the endpoint number, the story, the wave.
+Keys that exist: the Product Component, the inventory source, the endpoint number, the ticket, the spec.
 Things with no key: the glossary, the cross-component rules, the spine.
 
 ## Why nine ceremonies were repealed
@@ -237,7 +244,7 @@ symmetric, the rule demanded a section that would be empty or invented — and t
 exception but a field: `built` says whether the implementation is ours, and the match became one-directional.
 
 **A definition left unwritten will be re-argued in the next corpus.** That is the general lesson, and it is
-why `built` is checked by V25 rather than merely described here: prose that nothing verifies is prose that
+why `built` is checked by `container-built` rather than merely described here: prose that nothing verifies is prose that
 gets contradicted by the first person in a hurry.
 
 ## What is not here

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

@@ -27,7 +27,7 @@ Normative rules that hold **only in this product**, and are not code conventions
 `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
+no patterns, no stack — and `wdi-init` intent `readers` fills it in against this repo. `custom-room-declared` does not
 look at it: only `.md` is a rule.
 
 ## What does not
@@ -48,7 +48,7 @@ very failure this rule prevents.
 
 ## The shape of a file here
 
-Frontmatter is required, and `V27` checks it:
+Frontmatter is required, and `custom-room-declared` checks it:
 
 ```yaml
 ---

package/kit/.constitution/project/codebase-brownfield-guide.md

@@ -1,18 +1,18 @@
----
-status: Draft            # Article 4: Draft MAY be read as guidance, MUST NOT reject a change
-ratified_by: null        # the commit whose content ratifies this file
----
-
-# brownfield — codebase guide
-
-**Loaded when:** writing or reviewing code.
-
-> **Born empty on purpose.** This file is filled by the first wave's distillation — `bmad-spec`'s
-> `brownfield.md` companion is promoted here before the wave closes.
->
-> Writing it up front means guessing at a convention no code has yet. It MUST NOT be filled before
-> code exists that ratifies it.
-
-> **Status.** While `draft`, its contents MAY be read as guidance but MUST NOT be used to reject a
-> change. It rises to `accepted` when the first wave's distillation fills it from real code, and
-> `ratified_by` MUST then carry the commit holding that code.
+---
+status: Draft            # Article 4: Draft MAY be read as guidance, MUST NOT reject a change
+ratified_by: null        # the commit whose content ratifies this file
+---
+
+# brownfield — codebase guide
+
+**Loaded when:** writing or reviewing code.
+
+> **Born empty on purpose.** This file is filled by the first spec's distillation — what the
+> contract and the tickets established about the brownfield is promoted here before the spec closes.
+>
+> Writing it up front means guessing at a convention no code has yet. It MUST NOT be filled before
+> code exists that ratifies it.
+
+> **Status.** While `draft`, its contents MAY be read as guidance but MUST NOT be used to reject a
+> change. It rises to `accepted` when the first spec's distillation fills it from real code, and
+> `ratified_by` MUST then carry the commit holding that code.

package/kit/.constitution/project/codebase-conventions-guide.md

@@ -1,18 +1,18 @@
----
-status: Draft            # Article 4: Draft MAY be read as guidance, MUST NOT reject a change
-ratified_by: null        # the commit whose content ratifies this file
----
-
-# conventions — codebase guide
-
-**Loaded when:** writing or reviewing code.
-
-> **Born empty on purpose.** This file is filled by the first wave's distillation — `bmad-spec`'s
-> `conventions.md` companion is promoted here before the wave closes.
->
-> Writing it up front means guessing at a convention no code has yet. It MUST NOT be filled before
-> code exists that ratifies it.
-
-> **Status.** While `draft`, its contents MAY be read as guidance but MUST NOT be used to reject a
-> change. It rises to `accepted` when the first wave's distillation fills it from real code, and
-> `ratified_by` MUST then carry the commit holding that code.
+---
+status: Draft            # Article 4: Draft MAY be read as guidance, MUST NOT reject a change
+ratified_by: null        # the commit whose content ratifies this file
+---
+
+# conventions — codebase guide
+
+**Loaded when:** writing or reviewing code.
+
+> **Born empty on purpose.** This file is filled by the first spec's distillation — what the
+> contract and the tickets established about the conventions is promoted here before the spec closes.
+>
+> Writing it up front means guessing at a convention no code has yet. It MUST NOT be filled before
+> code exists that ratifies it.
+
+> **Status.** While `draft`, its contents MAY be read as guidance but MUST NOT be used to reject a
+> change. It rises to `accepted` when the first spec's distillation fills it from real code, and
+> `ratified_by` MUST then carry the commit holding that code.

package/kit/.constitution/project/codebase-stack-guide.md

@@ -1,18 +1,18 @@
----
-status: Draft            # Article 4: Draft MAY be read as guidance, MUST NOT reject a change
-ratified_by: null        # the commit whose content ratifies this file
----
-
-# stack — codebase guide
-
-**Loaded when:** writing or reviewing code.
-
-> **Born empty on purpose.** This file is filled by the first wave's distillation — `bmad-spec`'s
-> `stack.md` companion is promoted here before the wave closes.
->
-> Writing it up front means guessing at a convention no code has yet. It MUST NOT be filled before
-> code exists that ratifies it.
-
-> **Status.** While `draft`, its contents MAY be read as guidance but MUST NOT be used to reject a
-> change. It rises to `accepted` when the first wave's distillation fills it from real code, and
-> `ratified_by` MUST then carry the commit holding that code.
+---
+status: Draft            # Article 4: Draft MAY be read as guidance, MUST NOT reject a change
+ratified_by: null        # the commit whose content ratifies this file
+---
+
+# stack — codebase guide
+
+**Loaded when:** writing or reviewing code.
+
+> **Born empty on purpose.** This file is filled by the first spec's distillation — what the
+> contract and the tickets established about the stack is promoted here before the spec closes.
+>
+> Writing it up front means guessing at a convention no code has yet. It MUST NOT be filled before
+> code exists that ratifies it.
+
+> **Status.** While `draft`, its contents MAY be read as guidance but MUST NOT be used to reject a
+> change. It rises to `accepted` when the first spec's distillation fills it from real code, and
+> `ratified_by` MUST then carry the commit holding that code.

package/kit/assets/bmad-custom/bmad-architecture.toml

@@ -2,7 +2,7 @@
 # The spine holds the invariants that keep separately built units from diverging.
 # Structure (stack, tree, data shapes) is treated as a seed, not a contract.
 #
-# Order binds: the spine comes first, and bmad-spec reads it as a companion — never the other
+# Order binds: the spine comes first, and the spec's contract reads it as a companion — never the other
 # way round.
 
 [workflow]

package/kit/assets/bmad-custom/bmad-correct-course.toml

@@ -9,7 +9,7 @@
 #
 # The main danger is not the path but this skill's habit of editing directly: its default is
 # "direct updates to epics, stories, or PRD sections". In this repo that MUST NOT happen —
-# document changes go through wdi-decision intent `apply`, and wave content through wdi-build.
+# document changes go through wdi-decision intent `apply`, and spec content through wdi-build.
 # That is why the prohibition is installed as a persistent fact, held from activation, rather than
 # as end-of-run polish.
 
@@ -18,11 +18,11 @@
 persistent_facts = [
   "file:{project-root}/.constitution/method/document/delivery-flow-guide.md",
   "file:{project-root}/.constitution/method/document/corpus-guide.md",
-  "This skill MUST NOT write or edit anything in {project-root}/.what/ or {project-root}/.how/. Its output is a proposal; document changes are made by wdi-decision intent `apply` once the `DEC-` is accepted, and wave content by wdi-build.",
-  "epics.md and sprint-status.yaml are NOT used in this repo — we run the stories route. Neither MUST be read as a source, and neither MUST be created.",
-  "The impact scan MUST cover .what/_prd/, .what/<pc>/, .how/_platform/, .how/<pc>/, SPEC.md, .control/registry/waves.yaml, and the story files. .what/<pc>/ is unknown to this skill entirely, and without this it goes stale silently.",
+  "This skill MUST NOT write or edit anything in {project-root}/.what/ or {project-root}/.how/. Its output is a proposal; document changes are made by wdi-decision intent `apply` once the `DEC-` is accepted, and spec content by wdi-build.",
+  "epics.md and sprint-status.yaml are NOT used in this repo, and neither is the stories route they belong to. Neither MUST be read as a source, and neither MUST be created.",
+  "The impact scan MUST cover .what/_prd/, .what/<pc>/, .how/_platform/, .how/<pc>/, SPEC.md, .control/registry/specs.yaml, and the ticket files. .what/<pc>/ is unknown to this skill entirely, and without this it goes stale silently.",
   "Every plan change that is expensive to reverse MUST become a `DEC-` through wdi-decision, not a paragraph inside the proposal. A course correction is itself one `DEC-` of type course-correction.",
-  "A correction that voids more than 30% of a wave's stories MUST NOT be handled as a patch. Say so, and let the wave be re-cut through wdi-build.",
+  "A correction that voids more than 30% of a spec's tickets MUST NOT be handled as a patch. Say so, and let the spec be re-cut through wdi-build.",
 ]
 
 on_complete = "Hand the landing to wdi-decision: the whole proposal becomes one `DEC-` of type course-correction, and its run folder MUST NOT be deleted. MUST NOT land itself, MUST NOT edit .what/ or .how/."

package/kit/assets/bmad-custom/bmad-prd.toml

@@ -27,16 +27,22 @@ doc_standards = ["file:{project-root}/.constitution/method/document/prd-guide.md
 # activation. prd-guide.md remains authoritative; where the two disagree, the guide wins and the
 # line here MUST be fixed.
 persistent_facts = [
-  "file:{project-root}/.control/registry/requirements.yaml",
+  "file:{project-root}/.control/registry/goals.yaml",
   "file:{project-root}/.constitution/method/document/prd-guide.md",
 
-  "FR-N, NFR-N, UJ-N, and CAP-N MUST be allocated from requirements.yaml and MUST NOT restart from 1. The next initiative's PRD continues the previous PRD's sequence — the sequence is global, one product, one sequence.",
+  "BG-N is allocated from goals.yaml, which this PRD only READS. CAP-N, FR-N, NFR-N, and UJ-N are all allocated from this initiative's own requirements-<slug>.yaml, where <slug> is this PRD's folder name under .what/_prd/ — one file, one writer. None of them MUST restart from 1. The next initiative's PRD continues the previous PRD's sequence — the sequence is global, one product, one sequence.",
+
+  "Every FR's statement and proof of done, and every NFR's statement and enforced_by, are written directly into requirements-<slug>.yaml on the id's own row — as part of finishing this PRD, not a later step. The PRD's own §3 Features section cites the id under a Realizes: line and MUST NOT also carry the full statement or proof of done in prose. A promise written in both places is the same fact with two homes.",
 
   "This PRD is a living document. A behaviour change, a closely related feature addition, or a promise correction MUST go through intent Update on the same PRD. A new PRD MUST NOT be created just because the release changed; it is created only when the functional area is genuinely different and reads badly if merged.",
 
+  "§1 Why This Initiative states a DELTA against the product brief's own Why section — what this initiative changes, adds, or unlocks beyond it. It MUST NOT restate the product's vision from scratch; on a single-initiative product, one sentence pointing back to the brief is enough.",
+
+  "This template carries no Document Purpose section, no Glossary section, no Non-Goals section, no Open Questions section, and no Assumptions Index section — all five were removed. A domain noun MUST already exist in .control/product-glossary.md, used verbatim; a new one is raised through wdi-question in the same pass, never defined in this document. An open question or an unresolved [ASSUMPTION] tag is filed through wdi-question into .control/questions/ the moment it is found, never batched into a section.",
+
   "Every intent Update run MUST add exactly one row to the PRD's Revision History table: the date, what changed in language an outside reader understands, and why. That table is for the reader; the memlog is for the audit. Neither MUST substitute for the other.",
 
-  "A release MUST NOT be stated through the PRD's folder name or its title. It is carried by the target_release field in requirements.yaml and waves.yaml. Naming a release number inside the PRD's prose MAY be done as context, but the registry remains what binds.",
+  "A release MUST NOT be stated through the PRD's folder name or its title. It is carried by the target_release field on the CAP row in requirements-<slug>.yaml, and by specs.yaml. Naming a release number inside the PRD's prose MAY be done as context, but the registry remains what binds.",
 
   "Every memlog.py call — init, append, set, and the read on resume or intent Update — MUST use --path {project-root}/.control/memlog/prd-FILL-initiative-slug.md. The slug MUST match run_folder_pattern above, and both lines MUST change together when the initiative changes. --workspace MUST NOT be used.",
 ]

package/kit/assets/bmad-custom/bmad-product-brief.toml

@@ -22,9 +22,13 @@ doc_standards = ["file:{project-root}/.constitution/method/document/brief-guide.
 persistent_facts = [
   "Every memlog.py call — init, append, set, and the read on resume or intent Update — MUST use --path {project-root}/.control/memlog/brief.md. --workspace MUST NOT be used; it would place a .memlog.md inside .what/, and no memlog is allowed to live in the corpus.",
 
-  "The brief template opens with permission to drop a section that does not fit. That permission MUST NOT apply to the eight mandatory sections: The Problem, Who This Serves, Goals, Success Criteria, Scope In, Scope Out, Constraints, Assumptions — plus Prerequisites. Other template sections MAY be dropped.",
+  "The brief template opens with permission to drop a section that does not fit. That permission MUST NOT apply to the eight mandatory sections: Why, The Problem, Who This Serves, Goals, Success Criteria, Scope In, Scope Out, Constraints. The Solution and What Makes This Different stay optional. Other template sections MAY be dropped.",
 
-  "Goals MUST be numbered BG-1, BG-2, and so on. They MUST NOT be numbered G1, G2 — G1 through G5 are the names of this method's five gates, and BG is the first link in the BG -> CAP -> FR/NFR -> UC -> Story -> Test traceability chain.",
+  "The brief MUST NOT carry an Assumptions section or a Prerequisites section — both were removed from the template. An assumption belongs in .control/questions/assumptions.md, a prerequisite in .control/questions/external.md, each filed through wdi-question, never restated in the brief.",
+
+  "Goals MUST be numbered BG-1, BG-2, and so on. They MUST NOT be numbered G1, G2 — G1 through G5 are the names of this method's five gates, and BG is the first link in the BG -> CAP -> FR/NFR -> UC -> Ticket -> Test traceability chain. The brief's own Goals section is a POINTER ONLY — 'Goals — see goals.yaml -> goals:' — and MUST NOT restate a goal's statement. The statement for each BG-N is written directly into .control/registry/goals.yaml -> goals:, as part of finishing the brief, not left to a later step.",
+
+  "Success Criteria MUST name exactly ONE measurable figure, with a timeframe — not a mission statement, not a mix of signals. A criterion nobody could check without opening the code fails this.",
 
   "The Who This Serves table MUST carry exactly one row marked primary, and MUST cover every stakeholder including one who never opens the product.",
 

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

@@ -12,7 +12,7 @@ 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` | — |
+| `catalog` | Per `<pc>`: § Actor Register · § UC Catalogue · `03-domain/domain-model.md`. Product level: `.what/business-rules.md` · `.control/product-glossary.md` · `usecases.yaml` | `mattpocock-skills:domain-modeling` |
 | `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,
@@ -40,7 +40,7 @@ of that is `wdi-component` at G4. You MUST NOT write a promise; when the bluepri
   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.
+  overwrites what three specs 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.
 
@@ -65,6 +65,60 @@ whose nouns nobody defined.
 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.
 
+### Domain modelling is active, and `mattpocock-skills:domain-modeling` is its engine
+
+The domain model is not written by taking dictation. **You MUST invoke
+`mattpocock-skills:domain-modeling`** to derive it, the same way the spine goes through
+`bmad-architecture` — this skill never does the deriving itself, it positions the engine, verifies the
+result against `srs-guide.md`, and lands it in this method's template.
+
+Four behaviours are what the engine is invoked for. Verify each one actually happened before landing
+anything; an engine run that produced none of them is a transcription, and the run MUST be reported as such:
+
+1. **A term challenged the moment it conflicted** with what the glossary already defines.
+2. **Fuzzy language split** — *"you said account: the Customer or the User?"* Two words for one thing is
+   drift and Step 1 catches it. **One word for two things is worse and nothing else catches it**, because
+   both readings survive review looking correct.
+3. **Relationships stress-tested with invented edge scenarios.** This feeds two things asked for elsewhere
+   here: the `critical` derivation, and the branches that become `05-scenarios/` at `deep`.
+4. **The model cross-referenced against the code**, where code exists, with every contradiction surfaced.
+   `wdi-reconcile` compares documents with documents and `inventory.py` compares the three inventories with
+   code — **nothing else compares the domain model with the code.**
+
+#### Where it MUST NOT write, and which of its rules MUST NOT be followed
+
+It writes **as it goes, at the repo root**, by its own instruction — *"update `CONTEXT.md` right there,
+don't batch these up"* — creating its folders lazily. So its write location MUST be pointed at
+`_bmad-output/` **before** it starts, not corrected after. Four of its artifacts are class C working output
+here, and **none MUST be landed**:
+
+| Its artifact | Where the fact goes instead |
+|---|---|
+| `CONTEXT.md` — its own rule makes it *"a glossary and nothing else"*, so the mapping is exact | `.control/product-glossary.md` |
+| `CONTEXT-MAP.md` — where each bounded context lives | `components.yaml` + the two structure maps |
+| `docs/adr/` — **Article 3** forbids a `docs/` layer for corpus or rules outright | `.control/decisions/` |
+| An ADR file — the name is retired here | a `DEC-` through `wdi-decision` |
+
+**Its ADR test is narrower than ours and MUST NOT be used.** It offers an ADR only when a decision is hard
+to reverse **and** surprising **and** the result of a real trade-off. `decision-guide.md` asks one question
+instead — *"in three months, is the answer readable from the code?"* — which deliberately keeps the decisions
+that sound small. So it will stay silent on decisions this method wants recorded: apply our test to what it
+surfaces, and MUST NOT read its silence as *"nothing worth recording happened"*.
+
+#### When it is not installed
+
+`bmad-guide.md` §*When an engine earns being invoked at all* owns the general rule. For this engine: it is a
+**plugin, not part of this package's install**, so its absence is a real state and not a defect. Report it
+once, name the four behaviours above as the standard the derivation is still held to, and carry them out
+here. You MUST NOT block G3 on a missing plugin, and you MUST NOT report its absence as a finding.
+
+#### What lands, whatever produced it
+
+The entity table's `Code name` and `Never called` columns, plus the glossary entry each row cites —
+`language-guide.md` owns which language the code name is written in. And one rule holds regardless of engine:
+**the conceptual layer stays conceptual.** A column type appearing in `03-domain/` means the model has
+quietly become physical, and `templates/model.md` owns that.
+
 **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.
@@ -106,7 +160,7 @@ Then verify and land:
 | 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.
+Check 7 MUST be fixed immediately. `memlog-home` 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
@@ -114,14 +168,19 @@ already there, you MUST stop and report it, and MUST NOT resolve it by preferrin
 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.
+places it. **Not one of the three waits for a spec** — `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.
+not a follow-up.
+
+**And fill every `LC` whose `container:` is empty, in that same act.** Screens registered by `wdi-ux` at
+G2 are born without one on purpose — containers do not exist yet — and this is the moment the answer
+does. `container-built` starts demanding it as soon as a Product Component lists containers, so filling it here is what
+keeps the board clean without anyone tracking a to-do.
 
 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,
+codebase map (`container-built`). 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
@@ -134,7 +193,7 @@ You MUST NOT register a
 **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
+`cross-cutting.md`, in the same act: `entity-one-writer` 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
@@ -159,13 +218,13 @@ 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
+Regenerate `.how-rendered/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/`.
+You MUST NOT hand-write anything under `.control/generated/`, `.what-rendered/`, or `.how-rendered/`.
 
 ## Step 7 — Review and questions
 
@@ -174,7 +233,9 @@ You MUST NOT hand-write anything under `.control/generated/`.
 - 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.
+- A decision surfacing while writing is **written into the document as its own content** — stated as what
+  now holds, present tense. Never as a parenthetical aside, and never routed to `wdi-decision` merely for
+  being a decision: that is only for one with no home here at all, or one touching an `AD-N`.
 - 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.