wdi-method 0.5.13 → 0.6.0

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

@@ -1,47 +1,49 @@
----
-type: lc
-id: LC-{NNN}                 # allocated from .control/registry/components.yaml
-name: '{name}'
-lc_type: service             # ui-screen · ui-composite · ui-element · gateway · service · job · store
-container: '{container}'     # the runnable/deployable unit it lives in
-component: '{pc}'            # the Product Component it belongs to
-owner: '{team or person}'
-area: '{area}'
-created: '{YYYY-MM-DD}'
----
-
-# LC-{NNN} — {name}
-
-<!-- TEMPLATE GUIDE — act on these comments, then delete them.
-
-     A Logical Component is ONE addressable unit of build. It is not a Product Component: a PC is a
-     domain slice and the box at C4 L3; an LC is something you can point at and change.
-
-     `lc_type` decides where this prose lives, and the mapping is not negotiable:
-       ui-screen · ui-composite → .how/<pc>/01-ux/
-       ui-element               → .how/_platform/design-system.md
-       gateway                  → .how/<pc>/02-contracts/ or 03-integrations/
-       service · job            → .how/<pc>/04-components/
-       store                    → .how/<pc>/05-model/
-
-     An LC MUST be registered by the time its wave CLOSES — V12 checks that
-     every `touches` entry resolves. -->
-
-## Responsibility
-
-<!-- One paragraph. What this unit is answerable for. If it needs "and" more than once, it is
-     probably two units. -->
-
-## Depends on
-
-<!-- Other LC ids, and the direction. Dependency direction is a rule carried by the spine, not a
-     preference — a dependency pointing the wrong way is a conflict to surface, not to document. -->
-
-## Interface
-
-<!-- What it exposes to the rest of the system. For a gateway this points at the contract in
-     02-contracts/ rather than restating it. -->
-
-## Notes
-
-<!-- Anything a builder cannot read off the code. Cut if there is nothing. -->
+---
+type: lc
+id: LC-{NNN}                 # allocated from .control/registry/components.yaml
+name: '{name}'
+lc_type: service             # ui-screen · ui-composite · ui-element · gateway · service · job · store
+container: '{container}'     # the runnable/deployable unit it lives in. EMPTY is legal only for a
+                            # screen born at G2 before containers exist; G3 fills it. `container-built` demands it as
+                            # soon as this LC's Product Component lists containers
+component: '{pc}'            # the Product Component it belongs to
+owner: '{team or person}'
+area: '{area}'
+created: '{YYYY-MM-DD}'
+---
+
+# LC-{NNN} — {name}
+
+<!-- TEMPLATE GUIDE — act on these comments, then delete them.
+
+     A Logical Component is ONE addressable unit of build. It is not a Product Component: a PC is a
+     domain slice and the box at C4 L3; an LC is something you can point at and change.
+
+     `lc_type` decides where this prose lives, and the mapping is not negotiable:
+       ui-screen · ui-composite → .how/<pc>/01-ux/
+       ui-element               → .how/_platform/design-system.md
+       gateway                  → .how/<pc>/02-contracts/ or 03-integrations/
+       service · job            → .how/<pc>/04-components/
+       store                    → .how/<pc>/05-model/
+
+     An LC MUST be registered by the time its spec CLOSES — `lc-registered` checks that
+     every `touches` entry resolves. -->
+
+## Responsibility
+
+<!-- One paragraph. What this unit is answerable for. If it needs "and" more than once, it is
+     probably two units. -->
+
+## Depends on
+
+<!-- Other LC ids, and the direction. Dependency direction is a rule carried by the spine, not a
+     preference — a dependency pointing the wrong way is a conflict to surface, not to document. -->
+
+## Interface
+
+<!-- What it exposes to the rest of the system. For a gateway this points at the contract in
+     02-contracts/ rather than restating it. -->
+
+## Notes
+
+<!-- Anything a builder cannot read off the code. Cut if there is nothing. -->

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

@@ -1,52 +1,51 @@
----
-type: lifecycle
-component: '{pc}'
-status: draft            # draft · reviewed · locked · superseded
-created: '{YYYY-MM-DD}'
-updated: '{YYYY-MM-DD}'
-entities: []             # the domain entities whose lifecycles this file carries
----
-
-# State Lifecycle — {Product Component}
-
-<!-- TEMPLATE GUIDE — act on these comments, then delete them.
-
-     Home: .what/<pc>/03-domain/state-machines.md. Written at G4, at mode: deep ONLY. Below deep it
-     MUST NOT be written to fill a slot.
-
-     One section per entity that has more than one state. An entity with a single state has no
-     lifecycle and MUST NOT get a section.
-
-     WHY THIS HAS ITS OWN TEMPLATE: a transition table does not resemble an ERD, so it cannot be
-     lodged inside model.md. What it needs stated — who may move a thing, and what makes a state
-     terminal — has no column in an entity diagram.
-
-     THIS IS BEHAVIOUR, NOT SCHEMA. The state VALUES are English, because they are enum values and
-     language-guide.md governs that. Their LABELS — what a user reads — are not written here; they
-     belong to the screen. A value rendered straight to the screen is the known pitfall this repo
-     already records.
-
-     G3 asks whether there is a state that can be entered but not left. This file is where that is
-     answered, and an unreachable or inescapable state is a FINDING, not a documented fact. -->
-
-## {Entity}
-
-**States:** `{value}` · `{value}` · `{value}`
-**Initial:** `{value}` — and what creates it
-**Terminal:** `{value}` · `{value}` — and why nothing leaves them
-
-| From | To | Trigger | Who may | Guard | Side effect |
-| --- | --- | --- | --- | --- | --- |
-
-<!-- `Who may` names an actor from the SRS Actor Register, or `System` for an automatic transition.
-     `Guard` is the business rule that has to hold — cite the BR- id rather than restating it.
-     `Side effect` is what else changes; a transition with an invisible side effect is the one that
-     surprises someone while the code is being written.
-
-     Every state in the list above MUST appear at least once as a `To`, except the initial one, and
-     at least once as a `From`, except a terminal one. That is the check, and it is mechanical. -->
-
-### What is deliberately not modelled
-
-<!-- A state someone will look for and not find, and why. A schema value nothing uses — say so:
-     until the schema is cleaned, it has no label, no transition, and no meaning. -->
+---
+type: lifecycle
+component: '{pc}'
+status: draft            # draft · reviewed · locked · superseded
+created: '{YYYY-MM-DD}'
+entities: []             # the domain entities whose lifecycles this file carries
+---
+
+# State Lifecycle — {Product Component}
+
+<!-- TEMPLATE GUIDE — act on these comments, then delete them.
+
+     Home: .what/<pc>/03-domain/state-machines.md. Written at G4, at mode: deep ONLY. Below deep it
+     MUST NOT be written to fill a slot.
+
+     One section per entity that has more than one state. An entity with a single state has no
+     lifecycle and MUST NOT get a section.
+
+     WHY THIS HAS ITS OWN TEMPLATE: a transition table does not resemble an ERD, so it cannot be
+     lodged inside model.md. What it needs stated — who may move a thing, and what makes a state
+     terminal — has no column in an entity diagram.
+
+     THIS IS BEHAVIOUR, NOT SCHEMA. The state VALUES are English, because they are enum values and
+     language-guide.md governs that. Their LABELS — what a user reads — are not written here; they
+     belong to the screen. A value rendered straight to the screen is the known pitfall this repo
+     already records.
+
+     G3 asks whether there is a state that can be entered but not left. This file is where that is
+     answered, and an unreachable or inescapable state is a FINDING, not a documented fact. -->
+
+## {Entity}
+
+**States:** `{value}` · `{value}` · `{value}`
+**Initial:** `{value}` — and what creates it
+**Terminal:** `{value}` · `{value}` — and why nothing leaves them
+
+| From | To | Trigger | Who may | Guard | Side effect |
+| --- | --- | --- | --- | --- | --- |
+
+<!-- `Who may` names an actor from the SRS Actor Register, or `System` for an automatic transition.
+     `Guard` is the business rule that has to hold — cite the BR- id rather than restating it.
+     `Side effect` is what else changes; a transition with an invisible side effect is the one that
+     surprises someone while the code is being written.
+
+     Every state in the list above MUST appear at least once as a `To`, except the initial one, and
+     at least once as a `From`, except a terminal one. That is the check, and it is mechanical. -->
+
+### What is deliberately not modelled
+
+<!-- A state someone will look for and not find, and why. A schema value nothing uses — say so:
+     until the schema is cleaned, it has no label, no transition, and no meaning. -->

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

@@ -1,55 +1,68 @@
----
-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: "one member has zero
-     or one 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. -->
+---
+type: model
+component: '{pc}'
+layer: physical              # conceptual (.what/<pc>/03-domain/) · physical (.how/<pc>/05-model/)
+created: '{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.
+
+     `Code name` closes the loop this table used to leave open. The conceptual model is written for
+     the Product Owner, so its Entity column carries the word the BUSINESS uses — which is not always
+     the identifier code must use. Naming both, in one row, is what stops an agent inventing a third
+     word. `../language-guide.md` owns which language the code name is written in, and the one
+     exception for an Indonesian administrative or legal noun.
+
+     `Never called` is the synonym that was rejected, kept on purpose. A term resolved silently comes
+     back: the losing word is still in somebody's head, in an old document, and in the client's
+     email. Naming it here is what makes reintroducing it a finding instead of a habit. Leave the
+     cell empty when no synonym ever competed — an invented one is noise.
+
+     Every row's definition MUST live in `.control/product-glossary.md`, not here. This table points;
+     the glossary defines. -->
+
+| Entity | What it is | Identified by | Code name | Never called |
+| --- | --- | --- | --- | --- |
+
+## Relationships
+
+<!-- Direction and cardinality. State them as sentences a person would say: "one member has zero
+     or one 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/method/document/templates/oq.md

@@ -1,45 +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. -->
+---
+type: oq
+id: OQ-{n}
+component: '{pc}'            # or `_platform`
+blocks: []                   # gate, FR, UC, or ticket 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. -->