wdi-method 0.5.13 → 0.6.0

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

@@ -1,110 +1,132 @@
-# Product Brief Template
-
-A flexible starting structure for the executive product brief. Adapt aggressively to the product, the purpose, and the domain. Drop sections that do not earn their place, add sections the product needs, reorder freely. The brief serves the product's story, not the template's shape.
-
-## Default Structure
-
-```markdown
-# Product Brief: {Product Name}
-
-## Executive Summary
-
-[2-3 paragraph narrative: what this is, what problem it solves, why it matters, why now. Compelling enough to stand alone — if someone reads only this section, they should understand the vision.]
-
-## The Problem
-
-[What pain exists, who feels it, how they cope today, the cost of the status quo. Be specific: real scenarios, real frustrations, real consequences.]
-
-## The Solution
-
-[What is being built, how it solves the problem. Focus on the experience and the outcome, not the implementation.]
-
-## What Makes This Different
-
-[Key differentiators. Why this approach over alternatives, what is the unfair advantage. Be honest. If the moat is execution speed, say so. Do not fabricate technical moats.]
-
-## Who This Serves
-
-[Primary users — vivid but brief. Who they are, what they need, what success looks like for them. Secondary users if relevant.]
-
-| Role | Need | Tier |
-|---|---|---|
-| {role} | {what they need from this product} | **primary** |
-| {role} | {…} | secondary |
-| {role} | {…} | secondary |
-
-[Exactly one row MUST be `primary`. Every user and stakeholder who touches the product belongs in this table — including the ones who never open it, but pay for it, approve it, or are accountable for it. Shared goals that cut across roles go in a line under the table.]
-
-## Goals
-
-[What the product is trying to achieve, one line each. Number them `BG-1`, `BG-2`, … — `BG` is the first link of the traceability chain `BG → CAP → FR/NFR → UC → DEC → Story → Test`, so these IDs are cited downstream and MUST stay stable once written.]
-
-- **BG-1** — core value: [the goal that justifies the product existing at all]
-- **BG-2**: [...]
-
-[MUST NOT be numbered `G1`, `G2` — `G1`–`G5` already name the five gates.]
-
-## Success Criteria
-
-[How we know this is working. Mix of user success signals and business objectives. Measurable.]
-
-## Scope
-
-[Boundary document, not a feature list. Keep both lists tight.]
-
-### Scope In
-
-[What is in for the first version.]
-
-### Scope Out
-
-[What is explicitly out, written as items. MUST NOT be left to be inferred from absence — the value of this list is that it names what someone will otherwise assume is coming. Per-release MVP scope belongs in the PRD; this is the product boundary.]
-
-## Constraints
-
-[What is fixed before design starts and cannot be traded away: platform scope, integration boundary, regulatory limit, milestone boundary, a timeline that is genuinely immovable. One line each, and each MUST say what it forbids.]
-
-[Technical constraints that only shape implementation belong in `addendum.md`, not here. A constraint that emerges from a design decision becomes `AD-N` in the architecture spine — MUST NOT be appended to this list later.]
-
-## Assumptions
-
-[What is believed true but not verified, and that the brief would be wrong without. State each so it could be proven false.]
-
-[An assumption that starts to wobble MUST be promoted to a row in `.control/registry/risks.yaml` with an owner. An assumption nobody would act differently about is not worth listing.]
-
-## Prerequisites
-
-[What MUST exist or be granted before work can start: access, accounts, data, an upstream system, a decision someone else owns.]
-
-[Any prerequisite not yet satisfied MUST have a matching row in `.control/questions/external.md` naming who is being waited on and by when.]
-
-## Vision
-
-[Where this goes if it succeeds. What it becomes in 2-3 years. Inspiring but grounded.]
-```
-
----
-
-## Project overrides — WDI
-
-- **Home.** `.what/_product-brief/brief.md`, with `addendum.md` beside it. Set through
-  `run_folder_pattern = "_product-brief"`; both filenames are fixed by the skill and MUST NOT be
-  expected to change.
-- **Singleton.** One brief per product, spanning every release. A second product MUST get its own
-  repository rather than a second brief.
-- **Decision Summary.** MUST name exactly one problem, one **primary** user, and one measure of
-  success. Secondary users and stakeholders are listed, not ranked away. If the primary cannot be
-  chosen, the discovery is not finished.
-- **Six sections above the BMad default.** `Who This Serves` carries a full stakeholder table;
-  `Scope` is split into In and Out; and `Goals`, `Constraints`, `Assumptions`, and `Prerequisites`
-  are added. The last three have no home anywhere else in the corpus.
-- **No Product Component list.** The slicing is born at the tail of G2 through `wdi-init` intent
-  `component`, which reads
-  the brief and every PRD once a domain model exists. A list guessed at G1 is a guess made before
-  there is anything to guess from.
-- **Raw material stays out.** Research, brainstorming, and pressure-test output live in
-  `_bmad-output/` and stay there. It MUST NOT be folded in, and MUST NOT be promoted into `.what/` —
-  a `DEC-` or the PRD cites it by path instead.
-- **Dying cheap is a pass.** A brief that concludes the idea is not worth building is a valid G1
-  outcome, and the most profitable one.
-- **Memlog.** Written to `.control/memlog/brief.md` via `--path`.
+# Product Brief Template
+
+A flexible starting structure for the executive product brief. Adapt aggressively to the product, the purpose, and the domain. Drop sections that do not earn their place, add sections the product needs, reorder freely. The brief serves the product's story, not the template's shape.
+
+**The brief states the current design. It is not a history of itself.** A section MUST NOT carry a
+correction block, a "previously" note, or a record of who changed what — that belongs in
+`.control/decisions/` or is not worth keeping. See `corpus-guide.md` § The corpus is written in the
+present tense.
+
+**A derived fact has exactly one home, and it is never this document.** `Goals` cites
+`goals.yaml`; it does not restate what a goal says. `Assumptions` and `Prerequisites` are not
+sections here at all — they live in `.control/questions/`, and this brief is never their second copy.
+See `corpus-guide.md` § A derived fact has exactly one home.
+
+## Default Structure
+
+```markdown
+# Product Brief: {Product Name}
+
+> **This is the working brief.** It points at the registry instead of repeating it, so `Goals` is one
+> line and there is no Assumptions or Prerequisites section here.
+>
+> **To read or hand over one complete, self-contained document, run `/wdi-report render brief`.**
+> It writes `.what-rendered/_product-brief/brief.md` with the goals, the open assumptions, and the open
+> prerequisites filled in from their own homes. That file is regenerated, never hand-edited.
+
+## Why
+
+[2-3 paragraphs: what this is, what problem it solves, why it matters, why now, and where it goes if
+it succeeds. One narrative — do not split "what this is" from "where this goes" into two sections.
+Compelling enough to stand alone: if someone reads only this section, they understand the vision.]
+
+## The Problem
+
+[What pain exists, who feels it, how they cope today, the cost of the status quo. Be specific: real
+scenarios, real frustrations, real consequences.]
+
+## The Solution *(optional — one paragraph, no more)*
+
+[What kind of thing is being built — the bet, not the feature list. "A self-serve app, not a managed
+service"; "an API, not a dashboard." One paragraph. The moment this needs a second paragraph it has
+started designing, and design is G2's job, not G1's.]
+
+## What Makes This Different *(optional)*
+
+[Key differentiators. Why this approach over alternatives, what is the unfair advantage. Be honest. If
+the moat is execution speed, say so. Do not fabricate technical moats.]
+
+## Who This Serves
+
+[Primary users — vivid but brief. Who they are, what they need, what success looks like for them. Secondary users if relevant.]
+
+| Role | Need | Tier |
+|---|---|---|
+| {role} | {what they need from this product} | **primary** |
+| {role} | {…} | secondary |
+| {role} | {…} | secondary |
+
+[Exactly one row MUST be `primary`. Every user and stakeholder who touches the product belongs in this table — including the ones who never open it, but pay for it, approve it, or are accountable for it. Shared goals that cut across roles go in a line under the table.]
+
+## Goals
+
+Goals — see `.control/registry/goals.yaml` → `goals:`.
+
+[This section is a POINTER, not a list. `BG-N` and its statement live in the registry — that is what
+lets `wdi-product` cite `BG-N` without a second copy drifting from this one. If a goal needs a reason
+beyond its statement, that reason is a `why:` field on the goal's own row in the registry, not a
+paragraph here. `BG` is the first link of the traceability chain `BG → CAP → FR/NFR → UC → DEC →
+Ticket → Test`.]
+
+[MUST NOT be numbered `G1`, `G2` — `G1`–`G5` already name the five gates.]
+
+## Success Criteria
+
+[Exactly ONE measurable figure that proves this worked. Not a mission statement, not a mix of signals
+— one number, with a timeframe. "40% of visitors who start checkout finish it, within three months of
+launch." A criterion nobody could check without opening the code is not a criterion.]
+
+## Scope
+
+[Boundary document, not a feature list. Keep both lists tight. This is the PRODUCT boundary — what
+belongs in this product at all, ever. Per-release MVP scope belongs in the PRD's own Scope section,
+not here.]
+
+### Scope In
+
+[What belongs to this product's boundary — not "what ships first," which is the PRD's call.]
+
+### Scope Out
+
+[What is explicitly out, written as items. MUST NOT be left to be inferred from absence — the value of this list is that it names what someone will otherwise assume is coming. Per-release MVP scope belongs in the PRD; this is the product boundary.]
+
+## Constraints
+
+[What is fixed before design starts and cannot be traded away: platform scope, integration boundary, regulatory limit, milestone boundary, a timeline that is genuinely immovable. One line each, and each MUST say what it forbids.]
+
+[Technical constraints that only shape implementation belong in `addendum.md`, not here. A constraint that emerges from a design decision becomes `AD-N` in the architecture spine — MUST NOT be appended to this list later.]
+```
+
+---
+
+## Project overrides — WDI
+
+- **Home.** `.what/_product-brief/brief.md`, with `addendum.md` beside it. Set through
+  `run_folder_pattern = "_product-brief"`; both filenames are fixed by the skill and MUST NOT be
+  expected to change.
+- **Singleton.** One brief per product, spanning every release. A second product MUST get its own
+  repository rather than a second brief.
+- **Why replaces Executive Summary and Vision.** BMad's default carries both as separate sections with
+  near-identical instructions — one narrative, told once, is what a reader actually gets.
+- **Success Criteria MUST name exactly one measurable figure**, checked at G1 — this is the ★ question
+  the gate asks and the section the brief is most often thin on.
+- **Who This Serves.** MUST name exactly one **primary** user. Secondary users and stakeholders are
+  listed, not ranked away. If the primary cannot be chosen, the discovery is not finished.
+- **Goals is a pointer, not a list.** `BG-N` and its statement are authored straight into
+  `.control/registry/goals.yaml` by `wdi-problem` when it lands the brief — landing the
+  registry row is part of producing the brief, not a follow-up. This section MUST NOT restate a
+  goal's text; a stated reason beyond the statement belongs in that row's `why:` field.
+- **No Assumptions or Prerequisites section.** Both moved out entirely: an assumption goes through
+  `wdi-question` into `.control/questions/assumptions.md`, a prerequisite into
+  `.control/questions/external.md`. The brief cites neither by restating it — the generated deliverable
+  (`.what-rendered/_product-brief/brief.md`) is where a reader sees them assembled with everything else.
+- **No Product Component list.** The slicing is born at the tail of G2 through `wdi-init` intent
+  `component`, which reads
+  the brief and every PRD once a domain model exists. A list guessed at G1 is a guess made before
+  there is anything to guess from.
+- **Raw material stays out.** Research, brainstorming, and pressure-test output live in
+  `_bmad-output/` and stay there. It MUST NOT be folded in, and MUST NOT be promoted into `.what/` —
+  a `DEC-` or the PRD cites it by path instead.
+- **Dying cheap is a pass.** A brief that concludes the idea is not worth building is a valid G1
+  outcome, and the most profitable one.
+- **Memlog.** Written to `.control/memlog/brief.md` via `--path`.

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

@@ -3,7 +3,6 @@ type: c4
 level: 2                     # 1 (system context) · 2 (containers) · 3 (components)
 container: '{container}'     # level 3 only — one file per container
 created: '{YYYY-MM-DD}'
-updated: '{YYYY-MM-DD}'
 ---
 
 # C4 L{n} — {title}
@@ -21,8 +20,8 @@ updated: '{YYYY-MM-DD}'
                                      already says which PC lives where, so a one-PC container needs no
                                      file of its own.
 
-     ALL THREE LAND AT G3, and not one of them waits for a wave. Which container a PC lives in cannot
-     be discovered by a wave, because a wave picks its stories FROM that answer.
+     ALL THREE LAND AT G3, and not one of them waits for a spec. Which container a PC lives in cannot
+     be discovered by a spec, because a spec picks its tickets FROM that answer.
 
      THE AXIS THAT CONFUSES PEOPLE: a container runs its own code or stores its own data; a Product
      Component is a domain slice. They cross. One container holds several PC boxes, and one PC may
@@ -60,16 +59,17 @@ updated: '{YYYY-MM-DD}'
 
 <!-- L2 ONLY, and MANDATORY there — complete at G3, with no exceptions and no dependence on `mode`.
 
-     One row per container with `built: true`, listing every PC that lives in it. This table is a
-     RENDERING of each PC's `containers:` in components.yaml; that registry is the SSOT and V25 fails
-     when the two disagree.
+     The matrix's one home is each PC's `containers:` in components.yaml — `container-built` demands it
+     be complete at G3. It is NOT written here as a table any more: `.how-rendered/blueprint.md` renders
+     it from the registry, so there is nothing to keep in step. (The old comment here claimed
+     `container-built` compared this table with the registry. It never did — it checks the registry
+     field alone. The table was an unguarded copy.) What THIS section states is the prose a registry
+     cannot hold — why a component sits where it does, when that is not obvious.
 
-     A `built: false` container is NOT a row here. Every PC's data lives in the database by
-     definition, so a column for it would say the same thing seven times, and the data inventory
-     already records which PC owns which table. -->
+     A `built: false` container is never in the matrix. Every PC's data lives in the database by
+     definition, so a row for it would say the same thing seven times. -->
 
-| Container | Product Components living in it |
-| --- | --- |
+Product Components per container — see `.control/registry/components.yaml`, each PC's `containers:`.
 
 ## What is deliberately not shown
 

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

@@ -1,52 +1,51 @@
----
-type: contract
-component: '{pc}'
-lc: LC-{NNN}                 # the gateway this contract belongs to
-direction: exposed           # exposed (we serve it) · consumed (a third party serves it)
-created: '{YYYY-MM-DD}'
-updated: '{YYYY-MM-DD}'
----
-
-# Contract — {name}
-
-<!-- TEMPLATE GUIDE — act on these comments, then delete them.
-
-     Lives in .how/<pc>/02-contracts/ when we expose it, .how/<pc>/03-integrations/ when we consume
-     someone else's.
-
-     Where a machine-readable spec exists — OpenAPI, protobuf, a schema file — THAT is the source of
-     truth and this document MUST point at it rather than restate it. A restated schema drifts from
-     the generated one within a wave. Write here only what the machine spec cannot carry. -->
-
-## Source of truth
-
-<!-- Path or URL to the machine-readable spec, or `none` if this contract is prose-only. -->
-
-## Purpose
-
-<!-- Which UC this serves, and what the caller is trying to achieve. -->
-
-## Operations
-
-<!-- One row per operation. Keep it thin — detail belongs to the machine spec. -->
-
-| Operation | Purpose | Realizes |
-| --- | --- | --- |
-
-## Error behaviour
-
-<!-- What the caller sees when things go wrong, and which of those are expected rather than
-     exceptional. This is the part a generated spec carries worst and a caller needs most. -->
-
-| Condition | Response | Caller should |
-| --- | --- | --- |
-
-## Compatibility
-
-<!-- What counts as a breaking change here, and how it is announced. A contract with no stated
-     breaking-change policy will be broken by someone acting in good faith. -->
-
-## Constraints
-
-<!-- Rate limits, size limits, timeouts, idempotency, ordering guarantees. Anything the caller MUST
-     honour that the schema does not express. -->
+---
+type: contract
+component: '{pc}'
+lc: LC-{NNN}                 # the gateway this contract belongs to
+direction: exposed           # exposed (we serve it) · consumed (a third party serves it)
+created: '{YYYY-MM-DD}'
+---
+
+# Contract — {name}
+
+<!-- TEMPLATE GUIDE — act on these comments, then delete them.
+
+     Lives in .how/<pc>/02-contracts/ when we expose it, .how/<pc>/03-integrations/ when we consume
+     someone else's.
+
+     Where a machine-readable spec exists — OpenAPI, protobuf, a schema file — THAT is the source of
+     truth and this document MUST point at it rather than restate it. A restated schema drifts from
+     the generated one within a spec. Write here only what the machine contract cannot carry. -->
+
+## Source of truth
+
+<!-- Path or URL to the machine-readable spec, or `none` if this contract is prose-only. -->
+
+## Purpose
+
+<!-- Which UC this serves, and what the caller is trying to achieve. -->
+
+## Operations
+
+<!-- One row per operation. Keep it thin — detail belongs to the machine spec. -->
+
+| Operation | Purpose | Realizes |
+| --- | --- | --- |
+
+## Error behaviour
+
+<!-- What the caller sees when things go wrong, and which of those are expected rather than
+     exceptional. This is the part a generated spec carries worst and a caller needs most. -->
+
+| Condition | Response | Caller should |
+| --- | --- | --- |
+
+## Compatibility
+
+<!-- What counts as a breaking change here, and how it is announced. A contract with no stated
+     breaking-change policy will be broken by someone acting in good faith. -->
+
+## Constraints
+
+<!-- Rate limits, size limits, timeouts, idempotency, ordering guarantees. Anything the caller MUST
+     honour that the schema does not express. -->

package/kit/.constitution/method/document/templates/cross-cutting.md

@@ -3,7 +3,6 @@ type: cross-cutting
 scope: _platform
 status: draft            # draft · reviewed · locked · superseded
 created: '{YYYY-MM-DD}'
-updated: '{YYYY-MM-DD}'
 ---
 
 # Cross-Cutting — {product}
@@ -47,7 +46,7 @@ updated: '{YYYY-MM-DD}'
 ## Platform-owned
 
 <!-- REQUIRED as soon as anything is owned by `_platform` — a `platform_owns` entity, an inventory row,
-     an LC. V21 checks it.
+     an LC. `entity-one-writer` checks it.
 
      Something lands here only when NO Product Component's promise is the reason it exists AND more than
      one component depends on it. corpus-guide.md owns that test, and it refuses the one use people

package/kit/.constitution/method/document/templates/design-system.md

@@ -3,7 +3,6 @@ type: design-system
 scope: _platform
 status: draft            # draft · reviewed · locked · superseded
 created: '{YYYY-MM-DD}'
-updated: '{YYYY-MM-DD}'
 ---
 
 # Design System — {product}

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

@@ -1,69 +1,68 @@
----
-type: integration
-component: '{pc}'
-status: draft            # draft · reviewed · locked · superseded
-created: '{YYYY-MM-DD}'
-updated: '{YYYY-MM-DD}'
-provider: '{who owns it outside the team}'
----
-
-# Integration — {third-party name}
-
-<!-- TEMPLATE GUIDE — act on these comments, then delete them.
-
-     Home: .how/<pc>/03-integrations/<name>.md. Written at G4, from mode: guarded up, and only when
-     the component actually consumes a third party.
-
-     WHY THIS IS NOT contract.md: contract.md is the shape of an endpoint WE publish, and we can
-     change it. This is something SOMEBODY ELSE owns. Two things have no column in contract.md and
-     are the whole reason this template exists — who owns it outside the team, and what happens when
-     they change it without telling anyone.
-
-     COMMERCIAL FACTS MUST NOT APPEAR HERE. A rate limit that exists because of what was negotiated
-     is written as the technical fact — "300 requests per minute" — and never as the negotiation.
-     repo-guide.md owns that boundary, and this file is the most common place it leaks. -->
-
-## Who owns it
-
-| | |
-| --- | --- |
-| Provider | {the organisation} |
-| Our contact | {a role, and where the person's name is recorded — not the name} |
-| Where credentials live | {the devops repo and path. NEVER the credential} |
-| Notice we get before a breaking change | {a period, or `none` — and `none` is the answer that changes the design} |
-
-## What we use it for
-
-<!-- Which FR or UC depends on it, by id. An integration no promise depends on is one we are
-     carrying for free. -->
-
-## What we send and receive
-
-<!-- Only the surface we actually touch. A full API description belongs to their documentation, cited
-     by URL, and copying it here creates a second version that goes stale silently. -->
-
-| Direction | Operation | Carries | Contains personal data |
-| --- | --- | --- | --- |
-
-## When it changes without telling us
-
-<!-- The section that earns this file. For each: how we would notice, how long we would run wrong
-     before noticing, and what happens meanwhile. "We would see errors" is not an answer unless
-     something is actually watching. -->
-
-| Change | How we notice | Blast radius | What we do |
-| --- | --- | --- | --- |
-
-## When it is slow, absent, or lying
-
-<!-- The same three failures the SDD's Failure Behaviour asks about, for this boundary. State the
-     timeout, the retry policy, what the user sees, and what gets logged. A retry policy with no cap
-     is an outage amplifier. -->
-
-| Failure | Timeout | Retry | What the user sees | What is logged |
-| --- | --- | --- | --- | --- |
-
-## What we would do without them
-
-<!-- One paragraph. Not a migration plan — the honest answer, which is sometimes "the feature stops".
-     Writing it is what makes the dependency visible before it has to be replaced in a hurry. -->
+---
+type: integration
+component: '{pc}'
+status: draft            # draft · reviewed · locked · superseded
+created: '{YYYY-MM-DD}'
+provider: '{who owns it outside the team}'
+---
+
+# Integration — {third-party name}
+
+<!-- TEMPLATE GUIDE — act on these comments, then delete them.
+
+     Home: .how/<pc>/03-integrations/<name>.md. Written at G4, from mode: guarded up, and only when
+     the component actually consumes a third party.
+
+     WHY THIS IS NOT contract.md: contract.md is the shape of an endpoint WE publish, and we can
+     change it. This is something SOMEBODY ELSE owns. Two things have no column in contract.md and
+     are the whole reason this template exists — who owns it outside the team, and what happens when
+     they change it without telling anyone.
+
+     COMMERCIAL FACTS MUST NOT APPEAR HERE. A rate limit that exists because of what was negotiated
+     is written as the technical fact — "300 requests per minute" — and never as the negotiation.
+     repo-guide.md owns that boundary, and this file is the most common place it leaks. -->
+
+## Who owns it
+
+| | |
+| --- | --- |
+| Provider | {the organisation} |
+| Our contact | {a role, and where the person's name is recorded — not the name} |
+| Where credentials live | {the devops repo and path. NEVER the credential} |
+| Notice we get before a breaking change | {a period, or `none` — and `none` is the answer that changes the design} |
+
+## What we use it for
+
+<!-- Which FR or UC depends on it, by id. An integration no promise depends on is one we are
+     carrying for free. -->
+
+## What we send and receive
+
+<!-- Only the surface we actually touch. A full API description belongs to their documentation, cited
+     by URL, and copying it here creates a second version that goes stale silently. -->
+
+| Direction | Operation | Carries | Contains personal data |
+| --- | --- | --- | --- |
+
+## When it changes without telling us
+
+<!-- The section that earns this file. For each: how we would notice, how long we would run wrong
+     before noticing, and what happens meanwhile. "We would see errors" is not an answer unless
+     something is actually watching. -->
+
+| Change | How we notice | Blast radius | What we do |
+| --- | --- | --- | --- |
+
+## When it is slow, absent, or lying
+
+<!-- The same three failures the SDD's Failure Behaviour asks about, for this boundary. State the
+     timeout, the retry policy, what the user sees, and what gets logged. A retry policy with no cap
+     is an outage amplifier. -->
+
+| Failure | Timeout | Retry | What the user sees | What is logged |
+| --- | --- | --- | --- | --- |
+
+## What we would do without them
+
+<!-- One paragraph. Not a migration plan — the honest answer, which is sometimes "the feature stops".
+     Writing it is what makes the dependency visible before it has to be replaced in a hurry. -->

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

@@ -4,7 +4,6 @@ kind: db                 # db · api · screen · endpoint — decides the row s
 scope: _platform         # `_platform` for the three product-level inventories; `{pc}` for kind: endpoint
 status: draft            # draft · reviewed · locked · superseded
 created: '{YYYY-MM-DD}'
-updated: '{YYYY-MM-DD}'
 derived_from: plan       # plan · code — see the TEMPLATE GUIDE
 verified: ''             # commit SHA the derivation was read at; required when derived_from: code
 ---