wdi-method 0.3.0

package/kit/.constitution/document/templates/meeting.md

@@ -0,0 +1,47 @@
+---
+type: meeting
+date: '{YYYY-MM-DD}'
+slug: '{slug}'
+attendees: []                # who was actually there, not who was invited
+created: '{YYYY-MM-DD}'
+---
+
+# {YYYY-MM-DD} — {topic}
+
+<!-- TEMPLATE GUIDE — act on these comments, then delete them.
+     Record what was DECIDED, not what was discussed. A transcript is not minutes, and nobody
+     rereads one. -->
+
+## Decisions
+
+<!-- Each as one sentence, present tense, stated as what now holds. A "decision" with no owner and
+     no consequence is an open question — move it down. -->
+
+## Open items
+
+<!-- Each unresolved item, with who can resolve it. Every row here MUST also be registered through
+     wdi-question so it lands in the single list; a question recorded only in a meeting note is a
+     question nobody rereads. -->
+
+| Question | Who can answer | By when |
+| --- | --- | --- |
+
+## Action items
+
+<!-- Grouped by role, each with an owner. -->
+
+**Owner** ·
+**UI/UX** ·
+**Development** ·
+**Other** ·
+
+## Client commitments
+
+<!-- Verbatim where the wording matters. Paraphrasing a commitment is how a scope dispute starts.
+     Cut this section for internal meetings. -->
+
+## DEC
+
+<!-- Back-links to the DEC- this meeting produced, filled after wdi-decision runs. A meeting whose
+     decisions have no DEC- — and a DEC- with no meeting note — are both traceability gaps that the
+     audit surfaces later at a worse time. -->

package/kit/.constitution/document/templates/model.md

@@ -0,0 +1,55 @@
+---
+type: model
+component: '{pc}'
+layer: physical              # conceptual (.what/<pc>/03-domain/) · physical (.how/<pc>/05-model/)
+created: '{YYYY-MM-DD}'
+updated: '{YYYY-MM-DD}'
+---
+
+# Model — {name}
+
+<!-- TEMPLATE GUIDE — act on these comments, then delete them.
+
+     THE LAYER RULE, and it is the one most often broken:
+
+       conceptual — .what/<pc>/03-domain/ — things, their relationships, their cardinality, and the
+                    states they move through. Column types MUST NOT appear. This is what the
+                    Product Owner can read.
+
+       physical   — .how/<pc>/05-model/ — tables, columns, types, indexes, constraints, migrations.
+
+     Set `layer` in the frontmatter and keep to it. A conceptual model with `VARCHAR(255)` in it has
+     already become a physical one, and the Product Owner has quietly lost the ability to review
+     the domain. -->
+
+## Entities
+
+<!-- One row per thing. For a conceptual model the description is what it IS to the business, not
+     how it is stored. -->
+
+| Entity | What it is | Identified by |
+| --- | --- | --- |
+
+## Relationships
+
+<!-- Direction and cardinality. State them as sentences a person would say: "satu member punya nol
+     atau satu sponsor". -->
+
+## State Lifecycle
+
+<!-- For entities that change status: which states exist, what triggers each transition, and who is
+     allowed to trigger it. G3 asks whether any state can be entered but not left — that question is
+     answered here or not at all. Cut this section for entities that never change status. -->
+
+| From | To | Trigger | Who may |
+| --- | --- | --- | --- |
+
+## Invariants
+
+<!-- What MUST always be true regardless of path taken. These usually become BR- entries and
+     database constraints at the same time; state them once here and reference from both. -->
+
+## Physical notes
+
+<!-- ONLY when layer: physical. Indexes, partitioning, retention, migration ordering. Cut entirely
+     for a conceptual model. -->

package/kit/.constitution/document/templates/oq.md

@@ -0,0 +1,45 @@
+---
+type: oq
+id: OQ-{n}
+component: '{pc}'            # or `_platform`
+blocks: []                   # gate, FR, UC, or story ids — empty means it blocks nothing
+owner: '{who can answer}'
+by_when: '{gate or date}'
+status: open                 # open · answered
+created: '{YYYY-MM-DD}'
+---
+
+# OQ-{n} — {the question, as one answerable sentence}
+
+<!-- TEMPLATE GUIDE — act on these comments, then delete them.
+
+     Most open questions need only a line in one of the four lists in .control/questions/. This file
+     exists for the
+     few whose discussion outgrows one line; the list then keeps a one-line pointer here.
+
+     The title MUST be answerable. "How should referrals work?" is a topic, not a question. -->
+
+## Why it is open
+
+<!-- What makes this undecidable right now — missing information, a stakeholder who has not
+     answered, a dependency that has not landed. -->
+
+## What it blocks
+
+<!-- Concretely. If it blocks nothing, say so — a question that blocks nothing MAY still be
+     registered, but mixing blockers with curiosities makes the list useless exactly when it
+     matters. -->
+
+## Options considered
+
+<!-- Only if any exist. A proposed answer for the owner to confirm is useful; recording it as
+     settled is not. -->
+
+## Answer
+
+<!-- Filled when it closes, WITH the date and who answered. The entry is closed in place and MUST
+     NOT be deleted — the record of what was once uncertain is what stops it being reopened in three
+     months.
+
+     If the answer amounts to a decision that is expensive to reverse, closing here is not enough:
+     route it to wdi-decision so a DEC- carries what was chosen and what it cost. -->

package/kit/.constitution/document/templates/prd.md

@@ -0,0 +1,226 @@
+# PRD Template
+
+## Essential Spine *(almost always present)*
+
+```markdown
+---
+title: {Initiative Name}
+initiative: {slug}
+created: {YYYY-MM-DD}
+updated: {YYYY-MM-DD}
+---
+
+# PRD: {Initiative Name}
+*Working title — confirm.*
+
+## Revision History
+
+| Date | What changed | Why | Releases affected |
+|---|---|---|---|
+| {YYYY-MM-DD} | Initial version | — | {target release} |
+
+[One row per Update run, newest last. Written for an outside reader — a client or sponsor who was
+not in the room — so state what the promise now is, not which section was edited. This table is not
+the memlog: the memlog records every decision inside a run and is an audit trail; this records what
+changed for the reader. Neither replaces the other.]
+
+## 0. Document Purpose
+[1 paragraph: who this PRD is for (PM, stakeholders, downstream workflow owners), how it's structured (Glossary-anchored vocabulary, features grouped with FRs nested, assumptions tagged inline and indexed). If UX work or other inputs already exist, name them here and reference where they live — this PRD builds on them, it does not duplicate.]
+
+## 1. Vision
+[2-3 paragraphs: what this is, what it does for the user, why it matters. Compelling enough to stand alone.]
+
+## 2. Target User
+
+### 2.1 Jobs To Be Done
+[Bulleted. Emotional, social, functional, contextual — whichever apply. Even "this is for me as the builder" is a valid framing for a hobby project.]
+
+### 2.2 Non-Users (v1) *(add when the audience boundary is non-obvious)*
+[Who this is explicitly not for in v1.]
+
+### 2.3 Key User Journeys
+*Named-persona narratives the product enables. Numbered globally as UJ-1 through UJ-N. FRs reference journeys by ID inline ("realizes UJ-3"); SMs may also cross-reference. If a UX doc already exists, mirror its UJ IDs here and point to the source.*
+
+**Default shape:** a named scene with entry state, path, climax, and resolution. Each beat forces specificity the team would otherwise leave implicit — auth assumptions, screen order, what tells the user value landed. Read together as a short narrative; the example below shows the form.
+
+- **UJ-1. {One-line title — persona doing the thing.}**
+  - **Persona + context:** one line, grounded enough to explain the *why*.
+  - **Entry state:** authenticated? which surface? coming from where?
+  - **Path:** 3-5 concrete beats — taps, screens, decisions.
+  - **Climax:** the moment value is delivered and how the user knows.
+  - **Resolution:** state they're left in, what's next.
+  - **Edge case** *(optional)*: one real failure mode and what the user does next.
+
+  *Written out, that becomes:*
+  > **UJ-3. Priya checks the trip damage before she's even home.**
+  > Priya, budgeting on a single income with a new baby, finishes a grocery run and gets in the car. Already authenticated via biometric on a previous session. She opens the app, taps the FAB camera, and scans the receipt. The app OCRs the total and shows a single-screen overlay: this trip $84.20, weekly cap $250, $172.10 remaining, three days left in the week. She closes the app and drives home. **Edge case:** if she scanned a receipt earlier today, the app asks whether this replaces or adds to that trip before counting it against the cap.
+
+- **UJ-2. ...**
+
+**Scope dial:**
+- **Lighter** — hobby/solo, library/CLI, or when the UJ is essentially a JTBD restated: a single sentence works (`{Persona}, {context}, {what they do and why}.`).
+- **Heavier** — auth, multi-device handoff, complex navigation, or anything feeding downstream UX/architecture: add a numbered Flow, an Edge cases list, and a capability → FR mapping (`The system must {capability}. → FR-N`).
+
+## 3. Glossary
+*Downstream workflows and readers must use these terms exactly. FRs, UJs, and SMs use Glossary terms verbatim; introducing a synonym anywhere in the PRD is a discipline violation. If §4 introduces a new domain noun, add it to the Glossary in the same pass.*
+
+- **Term** — Definition. Relationships to other Glossary terms. Cardinality where relevant.
+- **Term** — ...
+
+[Every domain noun the rest of the document uses. Defined once. No synonyms anywhere else in the PRD.]
+
+## 4. Features
+*Each subsection is a coherent feature: behavioral description first, FRs nested under it, optional feature-specific NFRs and notes. FRs are numbered globally (FR-1 through FR-N) so downstream artifacts have stable references even if features get reorganized. Reference user journeys by ID inline ("realizes UJ-2") where the chain matters.*
+
+### 4.1 {Feature Name}
+**Capability:** CAP-N — serves BG-N. *(WDI. One feature is one capability; both IDs come from `requirements.yaml`. This is the link that makes the feature schedulable — size, priority, owner, target release, and dependencies on other capabilities all live on the `CAP` entry, not here.)*
+
+**Description:** [Behavioral narrative — how this feature works, who uses it, the user experience, edge cases. Realizes UJ-X, UJ-Y. Use Glossary terms exactly. Embed inline `[ASSUMPTION: ...]` tags where you inferred without confirmation.]
+
+**Functional Requirements:**
+
+#### FR-1: {Short capability name}
+
+[Actor] can [capability] [under conditions]. Realizes UJ-X.
+
+**Proof of done:** *(WDI, required)* [One sentence a Product Owner can check without opening the code. Business language, no HTTP codes and no table names. This is the sentence that lets one FR become one testable unit of work — it is not the same as the technical consequences below, and one MUST NOT be written in place of the other.]
+
+**Consequences (testable):**
+- {Specific testable condition, e.g. "System returns HTTP 429 when request rate exceeds 100/sec per merchant."}
+- {Another testable condition.}
+
+**Out of Scope:** *(optional — what this FR explicitly does NOT cover)*
+- {bound}
+
+#### FR-2: ...
+
+**Feature-specific NFRs:** *(only if any apply uniquely to this feature)*
+- Performance / security / accessibility / etc. specific to this feature.
+
+**Notes:** *(optional — open questions specific to this feature, `[NOTE FOR PM]` callouts)*
+
+### 4.2 {Feature Name}
+...
+
+## 5. Non-Goals (Explicit)
+[Bulleted. What this product is *not* and what it will *not* do in v1. Does outsized work for downstream readers and workflows — prevents the "let me also add this nearby thing" failure mode at every level (epic, ticket, code). Inline `[NON-GOAL for MVP]` callouts within §4 Features cover deferred items within features; this section captures the broader "we are not building X / we are not becoming Y" statements.]
+
+## 6. MVP Scope
+
+### 6.1 In Scope
+[Bulleted, crisp.]
+
+### 6.2 Out of Scope for MVP
+[Bulleted. Each item with a one-line reason if the reason matters. Mark items deferred to v2/v3 explicitly. Add `[NOTE FOR PM]` callouts where a deferred item is emotionally load-bearing — flags it for revisit if timeline permits.]
+
+## 7. Success Metrics
+
+*Each SM cross-references the FR(s) it validates. Counter-metrics counterbalance specific primary or secondary metrics.*
+
+**Primary**
+- **SM-1**: Metric — definition, target. Validates FR-X, FR-Y.
+
+**Secondary**
+- **SM-2**: Metric — definition, target. Validates FR-Z.
+
+**Counter-metrics (do not optimize)**
+- **SM-C1**: Metric — why this should *not* be optimized. Counterbalances SM-1.
+
+[Length scales with stakes. Hobby/utility PRD: a single sentence may be enough ("Success: I use this weekly and don't abandon it after a month"). Public launch / enterprise: full quantitative breakdown with measurement methods. Counter-metrics are as load-bearing as primary metrics — they prevent the architect from optimizing the wrong thing and the dev from gaming the wrong target.]
+
+## 8. Open Questions
+[Numbered. Things still unknown — they become future tickets or follow-up research, not silent gaps.]
+
+## 9. Assumptions Index
+*Every `[ASSUMPTION]` from the document, surfaced for explicit confirmation:*
+- Inline assumption from §X.Y — short description.
+- ...
+```
+
+---
+
+## Adapt-In Menu *(add the clusters the product calls for)*
+
+### Cross-cutting quality and shape *(most non-trivial PRDs)*
+- **Cross-Cutting NFRs** — system-wide non-functional requirements not tied to a single feature (performance, security, reliability, observability). Add when system-wide quality attributes are meaningful.
+- **Constraints and Guardrails** — Safety, Privacy, Cost. Subsection per cluster. Add when any of these are real concerns.
+- **Why Now** — add when timing is load-bearing (a market shift, a technology enabler, a regulatory deadline). Drop when timing is incidental.
+
+### Consumer / branded products
+- **Aesthetic and Tone** — visual references, anti-references, voice/tone for any product-generated text.
+- **Information Architecture** — top-level surfaces, navigation, screens.
+- **Monetization** — free vs. paid, pricing assumptions, ads policy.
+- **Platform** — web, mobile, PWA, native, v1 vs. v2+.
+
+### Enterprise initiatives
+- **Stakeholders and Approvals** — who must sign off, at what stage.
+- **Risk and Mitigations** — operational, security, business, reputational risk register.
+- **ROI / Business Case** — quantified benefit, cost, payback period.
+- **Operational Requirements** — SLAs, RTO/RPO, support tier, on-call expectations.
+- **Integration and Dependencies** — SSO, existing enterprise systems, data sources, downstream consumers.
+- **Rollout and Change Management** — phased rollout plan, training, internal communication.
+- **Data Governance** — residency, sovereignty, classification, retention.
+- **Audit Trail / Decision Provenance** — formal documentation requirements for regulated environments.
+
+### Regulated domains
+- **Compliance and Regulatory** — HIPAA, PCI-DSS, GDPR, SOX, SOC 2, Section 508 / WCAG 2.1 AA, FedRAMP, etc. — whichever apply. If any item needs depth, add a `[NOTE FOR PM]` callout to revisit or move to an addendum.
+
+### Developer products (libraries, APIs, CLIs, SDKs)
+- **API Contracts / Public Surface** — endpoint shapes, breaking change policy.
+- **Versioning and Deprecation Policy**.
+- **Performance Budgets** — latency, throughput, resource use.
+- **Language / Runtime Targets and Dependency Policy**.
+
+### Embedded / hardware
+- **Hardware Constraints** — memory, power, form factor.
+- **Deployment and Update Mechanism** — OTA, manual, image-based.
+- **Environmental and Reliability Requirements**.
+
+### Small-scope all-inclusive *(use when scope is 1-2 stories' worth and the user wants a single captured artifact — chosen during the Right-skill check in Discovery)*
+- **Stories** — story-level specs listed inline at the end of the doc. Each story: *"As a [persona], I can [action] [under conditions]. Acceptance: [testable criteria]."* Numbered Story-1, Story-2, ... for reference. Pair with very lean §1 Vision, §2 Target User (often just JTBD + one UJ), §3 Glossary (handful of terms), §4 Features (often a single feature), §6 MVP Scope (in/out very tight). The whole doc fits on a page or two and captures intent + implementable stories in one place. If the user doesn't want the captured artifact at all, `bmad-build` is the better path — this cluster is only for "I want a doc *and* the stories."
+
+
+---
+
+## Project overrides — WDI
+
+These rules replace the corresponding BMad defaults for this project. They are additive to the
+shape above; nothing in the shape is removed.
+
+- **Scope.** One PRD per **initiative / functional area** — not per product, not per component, and
+  not per release. It is a **living document** and is never frozen.
+- **Change.** A behaviour change, a correction, or a new feature closely tied to what is already
+  here MUST land through `bmad-prd` intent *Update* on this same file. A second PRD MUST NOT be
+  created because the release changed; create one only when the functional area is genuinely
+  different and would not read well merged in.
+- **Revision History.** Every Update run MUST add exactly one row, written for an outside reader.
+  It is what preserves "what did we promise back then" now that the document is not frozen.
+- **Release.** Carried by `CAP.target_release` in `.control/registry/requirements.yaml` — the only
+  place a promise's release is written — and by `release` in `waves.yaml` for the execution side. It
+  MUST NOT be expressed through this document's folder name or title, and an `FR` MUST NOT carry a
+  release of its own; it inherits one from its capability. Naming a release in prose as context MAY
+  happen; the registry is what binds.
+- **Numbering.** `FR-N`, `NFR-N`, `UJ-N`, and `CAP-N` MUST be allocated from
+  `.control/registry/requirements.yaml`. They MUST NOT restart at 1 in a new PRD — the sequence is
+  global to the product, and a later PRD continues the earlier one.
+- **Two Adapt-In clusters are not optional here.** `Cross-Cutting NFRs` and `Constraints and
+  Guardrails` MUST be present. G2 passes on numbered FR **and NFR**, so a PRD with no NFR section
+  cannot clear it; and a constraint discovered at G4 costs a decision that a sentence here would
+  have prevented. Every other Adapt-In cluster stays conditional as BMad intends.
+- **Constraints state the delta.** Product-wide constraints already live in
+  `.what/_product-brief/brief.md`. This section MUST carry only what binds *this initiative* beyond
+  them, and MUST say "none beyond the brief" when there is nothing — an absent section reads as
+  "not checked".
+- **Prerequisites are not written here.** An initiative that cannot start until another one ships is
+  a `depends_on` between `CAP` entries in `requirements.yaml`. Restating it in prose creates a
+  second home that will drift.
+- **§2 MUST name which stakeholders from the brief this initiative serves**, using the same role
+  names. A PRD that invents its own user labels breaks the trace back to `BG-N`.
+- **Vocabulary.** Every domain noun MUST already exist in `.control/product-glossary.md`, used verbatim. A
+  new noun introduced here MUST be added to the Glossary in the same pass, not defined inline.
+- **Boundary.** This document promises; it MUST NOT design. Behaviour of the system belongs to
+  `SRS-<pc>.md`, and solution shape to `SDD-<pc>.md`.
+- **Assumptions.** Every `[ASSUMPTION]` left unresolved at Finalize MUST be registered through
+  `wdi-question` before this PRD passes G2.
+- **Memlog.** Written to `.control/memlog/prd-<slug>.md` via `--path`, never beside this file. The
+  slug matches this PRD's folder.

package/kit/.constitution/document/templates/questions.md

@@ -0,0 +1,75 @@
+---
+type: questions
+list: blocking           # blocking · assumptions · external · answered
+status: draft            # draft · reviewed · locked · superseded
+created: '{YYYY-MM-DD}'
+updated: '{YYYY-MM-DD}'
+---
+
+# {Pertanyaan yang Memblokir | Asumsi | Menunggu Pihak Luar | Terjawab}
+
+<!-- TEMPLATE GUIDE — act on these comments, then delete them.
+
+     ONE template, four lists, all in .control/questions/. `list:` decides which row shape below
+     survives; delete the other three.
+
+     THE SPLIT IS BY WHAT THE READER HAS TO DO — not by subject and not by severity. That is the whole
+     design, and it is what the single old list could not express: it reached OQ-146 and the majority
+     of its weight was answered entries.
+
+       blocking     holds a gate. Read at every gate. Target <=3 per Product Component
+       assumptions  the DEFAULT class. Swept once per gate; MAY be skipped. Holds nothing
+       external     waiting on a file, an action, or a credential from outside. Holds GO-LIVE ONLY,
+                    never a design gate. Owner and `Sebelum` required on every row
+       answered     archive. Closed in place, never deleted
+
+     WHY oq.md IS NOT THIS: oq.md is the shape of ONE question whose discussion outgrew a line, and it
+     lives beside these four as OQ-NNN-<slug>.md with a one-line pointer from the list. This is the
+     shape of the four LISTS.
+
+     A ROW MOVES BETWEEN FILES WHEN ITS CLASS CHANGES, and it MUST NOT be copied into a second one.
+
+     Ids stay OQ-, allocated from the highest ever used including closed ones. An id MUST NOT be
+     reused. The literal values inside the tables stay Bahasa Indonesia — [BELUM DITETAPKAN] and the
+     rest — wherever they appear, including inside an English template. -->
+
+## The class test
+
+<!-- Keep this block in blocking.md and assumptions.md; delete it from the other two.
+
+     A question is filed in `assumptions` unless it passes one of three tests. One is enough:
+
+       1. It touches money, personal data, or a legal obligation.
+       2. It changes the wording of an FR's promise.
+       3. Answering it wrong forces a rewrite of more than one Product Component.
+
+     Failing all three, the agent takes the answer itself and records it as one line.
+
+     A question MUST NOT be filed as blocking "to be safe". That habit is what produced 146 ids. -->
+
+## Terbuka
+
+<!-- list: blocking · external -->
+
+| id | Pertanyaan | Memblokir | Owner | Sebelum |
+|---|---|---|---|---|
+
+<!-- list: assumptions — keep this shape instead
+| id | Asumsi | Akibat kalau salah | Diambil | Oleh |
+|---|---|---|---|---|
+-->
+
+<!-- An empty list is a legitimate state and MUST be written as one, with the date and one line
+     saying why. An empty table with no sentence reads as an unfinished file. -->
+
+## Terjawab
+
+<!-- list: answered only.
+
+     | id | Pertanyaan | Jawaban | Tanggal | Oleh |
+
+     The answer is written beside the question, not in place of it. The record of what was once
+     uncertain is what stops the same question being asked again in three months.
+
+     An answer amounting to a decision that is expensive to reverse MUST also go to wdi-decision. This
+     list records that an answer arrived; a DEC- records what was chosen and what it cost. -->

package/kit/.constitution/document/templates/rtr.md

@@ -0,0 +1,61 @@
+---
+type: rtr
+id: RTR-{wave}
+wave: '{W<N>}'
+size: L                  # the wave size that made this required
+status: draft            # draft · reviewed · locked · superseded
+created: '{YYYY-MM-DD}'
+---
+
+# RTR-{wave} — Retrospective, wave {W<N>}
+
+<!-- TEMPLATE GUIDE — act on these comments, then delete them.
+
+     Home: .control/reports/RTR-<wave>.md, landed by wdi-build at wave close. Its old home
+     .control/supplements/ is gone.
+
+     REQUIRED on wave `L`. Advisory on `S` and `M`, and skipping it MUST be stated rather than left
+     silent — V19 is advisory for exactly that reason. It is tied to wave SIZE, never to `mode`: depth
+     of documents and volume of work are different things.
+
+     THE SPEC FOLDER IS EPHEMERAL AND THIS IS NOT. bmad-retrospective writes RETROSPECTIVE.md inside
+     the run folder; this is the archived form, and it is the only part that survives the wave.
+
+     WRITE WHAT WAS LEARNED, NOT WHAT HAPPENED. A wave-by-wave narrative is recoverable from git; what
+     is not recoverable is what somebody now knows and would otherwise forget. Every section below is
+     one question, and a section with nothing under it MUST be cut. -->
+
+## What this wave shipped
+
+<!-- One line. Which FR, and whether the RTM rows for them are green. Not a story list. -->
+
+## What took longer than expected, and why
+
+<!-- G5's question 5. One cause, named concretely. "Underestimated" is not a cause. -->
+
+## What the corpus got wrong
+
+<!-- The section this method exists to feed. Every defect whose root_cause was `requirement` or
+     `architecture` rather than code, by BUG- id — and what in .what/ or .how/ was wrong.
+
+     This ratio is a fact about the METHOD, not about the team, and it is the only place it is
+     recorded per wave. -->
+
+| BUG- | Root cause | What was wrong upstream | Fixed where |
+| --- | --- | --- | --- |
+
+## What we would do differently
+
+<!-- Only items with an owner and a next action. An observation nobody owns is not a finding; it is a
+     feeling, and it MUST be cut rather than carried forward into the next wave's reading. -->
+
+| Change | Owner | Where it lands |
+| --- | --- | --- |
+
+<!-- `Where it lands` MUST name a file or a skill. A retrospective item that lands nowhere is why
+     retrospectives get a reputation for being theatre — and it is what makes the next one skippable. -->
+
+## What is deliberately carried forward
+
+<!-- Follow-ups accepted rather than fixed, each pointing at its OQ- or DEC-. Anything here that has
+     no id is being lost right now. -->

package/kit/.constitution/document/templates/rules.md

@@ -0,0 +1,47 @@
+---
+type: rules
+scope: global            # global · component — decides the home and the id prefix
+component: '{pc}'        # omit entirely when scope: global
+status: draft            # draft · reviewed · locked · superseded
+created: '{YYYY-MM-DD}'
+updated: '{YYYY-MM-DD}'
+---
+
+# Business Rules — {the product | Product Component}
+
+<!-- TEMPLATE GUIDE — act on these comments, then delete them.
+
+     ONE template, two scopes, and the scope decides everything about where this file lives:
+
+       scope: global     -> .what/business-rules.md          born at G3, by wdi-blueprint
+       scope: component  -> .what/<pc>/02-rules/rules-<pc>.md born at G4, from mode: outline up
+
+     THE TEST IS REACH, NOT IMPORTANCE. A rule binding more than one Product Component is global; a
+     rule binding only one is that component's. A rule written locally that turns out to bind a
+     second component MUST be PROMOTED to the global file, never copied. Two copies of one rule is
+     how components start disagreeing about the same policy.
+
+     A rule MUST be checkable. If a reviewer cannot tell whether the behaviour obeys it, it is not a
+     rule yet — it is an intention, and it belongs in the SRS prose.
+
+     A rule MUST NOT state a mechanism. "The turn is not consumed until commitment" is a rule; "a
+     row is written to the queue table" is a mechanism and belongs to .how/.
+
+     Ids are allocated GLOBALLY and never restart. A retired rule keeps its id and is marked retired
+     with what replaced it — never deleted, because documents still cite it. -->
+
+## Rules
+
+| id | Rule | Binds | Source | Status |
+| --- | --- | --- | --- | --- |
+| BR-{n} | {one checkable sentence, present tense} | {which components, or `all`} | {FR-n · DEC-n · UC-n · a person and a date} | active |
+
+<!-- `Source` MUST name where the rule came from. A rule with no source is an assumption in
+     disguise, and it goes through wdi-question instead.
+
+     `Status`: active · retired. A retired row states what replaced it in the Rule column. -->
+
+## Retired
+
+<!-- Rows moved here keep their ids. Each MUST name what replaced it and the date it stopped
+     holding. This section MAY be absent until the first rule retires. -->

package/kit/.constitution/document/templates/scn.md

@@ -0,0 +1,40 @@
+---
+type: scn
+id: SCN-{NN}
+component: '{pc}'
+attaches_to: UC-{NN}         # exactly one UC — a scenario that fits two is two scenarios
+created: '{YYYY-MM-DD}'
+---
+
+# SCN-{NN} — {what this branch is}
+
+<!-- TEMPLATE GUIDE — act on these comments, then delete them.
+
+     A scenario exists so a Use Case does not get fat. It is a long branch lifted out of one UC, and
+     it MUST attach to exactly one. If it seems to belong to two, the UC boundary is wrong — fix that
+     instead of duplicating the scenario.
+
+     WRITTEN AT `mode: deep` ONLY. Below deep, a branch that will not fit stays inside its UC file or
+     is not written; a scenario file MUST NOT be created to fill the slot. -->
+
+## Where it branches
+
+<!-- The UC and the numbered step this leaves from. -->
+
+## Condition
+
+<!-- What makes this branch taken rather than the main flow. -->
+
+## Flow
+
+<!-- Numbered, same discipline as the UC: behaviour only, no design shape. -->
+
+1.
+
+## Outcome
+
+<!-- Where the user and the system end up, and whether they can rejoin the main flow. -->
+
+## Why it is not in the UC
+
+<!-- One line. If the honest answer is "it just felt long", it probably belongs back in the UC. -->