wdi-method 0.4.6 → 0.5.2

package/kit/.constitution/{document → method/document}/sdd-guide.md

@@ -88,7 +88,7 @@ Flows **into and out of** each boundary MUST be stated, not just the boundary. A
 direction of call is a name, not a design.
 
 Flow diagrams in `06-flows/` are written only for a flow touching money, irreversible state, or a third
-party. The lane order is the project's to fix, once, in `codebase/conventions-guide.md`. **The `No-op` lane
+party. The lane order is the project's to fix, once, in `../../project/codebase-conventions-guide.md`. **The `No-op` lane
 rule is repealed** — it was a heavy convention for a folder that had never carried a file, and it belongs to
 how a diagram is drawn rather than to what binds.
 

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

@@ -44,7 +44,7 @@ updated: '{YYYY-MM-DD}'
 | Code | HTTP | Means | Caller should |
 | --- | --- | --- | --- |
 
-## Milik platform
+## Platform-owned
 
 <!-- REQUIRED as soon as anything is owned by `_platform` — a `platform_owns` entity, an inventory row,
      an LC. V21 checks it.
@@ -72,7 +72,7 @@ updated: '{YYYY-MM-DD}'
      idempotency key convention · logging fields · rate-limit response shape.
 
      Each MUST state where it is enforced. An agreement nothing enforces is a preference, and
-     preferences belong in codebase/conventions-guide.md where nothing has to justify itself. -->
+     preferences belong in ../../../project/codebase-conventions-guide.md where nothing has to justify itself. -->
 
 ### {agreement}
 

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

@@ -1,67 +1,67 @@
----
-type: design-system
-scope: _platform
-status: draft            # draft · reviewed · locked · superseded
-created: '{YYYY-MM-DD}'
-updated: '{YYYY-MM-DD}'
----
-
-# Design System — {product}
-
-<!-- TEMPLATE GUIDE — act on these comments, then delete them.
-
-     Home: .how/_platform/design-system.md. Written by wdi-ux, and it is the ONE file in _platform/
-     that wdi-blueprint does not own. Optional, like the rest of UX: it exists when the interface is
-     a substantial part of what the PRD promises.
-
-     WHY IT IS NOT IN A COMPONENT: tokens and base elements cross Product Components by definition. A
-     colour scale living in one component's 01-ux/ is a colour scale the other six will each redefine.
-
-     WHY ux.md DOES NOT SERVE IT: ux.md is the shape of DESIGN.md and EXPERIENCE.md, which are per
-     component. This is the third file, at product level, and it had no template at all.
-
-     THE CODE IS THE SSOT FOR VALUES. Where this repo's web side states a token in tokens.css, this
-     file MUST reference it rather than repeat the value. Two homes for one hex code is two hex codes
-     within a month. Read web/README.md before writing anything here — it is the authority for the
-     web side, and it MUST NOT be contradicted from this file.
-
-     Token and element NAMES are English: they are machine-facing keys, per language-guide.md. -->
-
-## Where the values actually live
-
-<!-- One line per source of truth — the stylesheet, the config, the generated file — with its path.
-     This section is what stops the rest of the document becoming a stale copy. -->
-
-## Tokens
-
-<!-- One table per scale. Name, what it is for, and where it resolves. NOT the raw value, unless this
-     file is genuinely the only place it exists. -->
-
-| Token | For | Resolves in |
-| --- | --- | --- |
-
-## Base elements
-
-<!-- The LC type `ui-element`, registered in components.yaml. One row each: what it is, its states,
-     and where its implementation lives. A composite reused across screens is `ui-composite` and
-     belongs in .how/<pc>/01-ux/, not here. -->
-
-| Element | States it MUST support | Implementation |
-| --- | --- | --- |
-
-<!-- Every element MUST state its empty, loading, error, and disabled states where they apply. The
-     populated state is the one that always gets designed; the others are the ones that ship broken. -->
-
-## Rules that bind every screen
-
-<!-- Only what a screen cannot legitimately override. Each MUST state what it prevents — a rule with
-     no failure behind it is a preference, and preferences go to codebase/conventions-guide.md.
-
-     A rule here that also holds for non-UI code is an AD-N and belongs in the spine instead. -->
-
-| Rule | Prevents |
-| --- | --- |
-
-## What this system deliberately does not cover
-
-<!-- Where a component is free to choose for itself. Absent, every local choice reads as a violation. -->
+---
+type: design-system
+scope: _platform
+status: draft            # draft · reviewed · locked · superseded
+created: '{YYYY-MM-DD}'
+updated: '{YYYY-MM-DD}'
+---
+
+# Design System — {product}
+
+<!-- TEMPLATE GUIDE — act on these comments, then delete them.
+
+     Home: .how/_platform/design-system.md. Written by wdi-ux, and it is the ONE file in _platform/
+     that wdi-blueprint does not own. Optional, like the rest of UX: it exists when the interface is
+     a substantial part of what the PRD promises.
+
+     WHY IT IS NOT IN A COMPONENT: tokens and base elements cross Product Components by definition. A
+     colour scale living in one component's 01-ux/ is a colour scale the other six will each redefine.
+
+     WHY ux.md DOES NOT SERVE IT: ux.md is the shape of DESIGN.md and EXPERIENCE.md, which are per
+     component. This is the third file, at product level, and it had no template at all.
+
+     THE CODE IS THE SSOT FOR VALUES. Where this repo's web side states a token in tokens.css, this
+     file MUST reference it rather than repeat the value. Two homes for one hex code is two hex codes
+     within a month. Read web/README.md before writing anything here — it is the authority for the
+     web side, and it MUST NOT be contradicted from this file.
+
+     Token and element NAMES are English: they are machine-facing keys, per language-guide.md. -->
+
+## Where the values actually live
+
+<!-- One line per source of truth — the stylesheet, the config, the generated file — with its path.
+     This section is what stops the rest of the document becoming a stale copy. -->
+
+## Tokens
+
+<!-- One table per scale. Name, what it is for, and where it resolves. NOT the raw value, unless this
+     file is genuinely the only place it exists. -->
+
+| Token | For | Resolves in |
+| --- | --- | --- |
+
+## Base elements
+
+<!-- The LC type `ui-element`, registered in components.yaml. One row each: what it is, its states,
+     and where its implementation lives. A composite reused across screens is `ui-composite` and
+     belongs in .how/<pc>/01-ux/, not here. -->
+
+| Element | States it MUST support | Implementation |
+| --- | --- | --- |
+
+<!-- Every element MUST state its empty, loading, error, and disabled states where they apply. The
+     populated state is the one that always gets designed; the others are the ones that ship broken. -->
+
+## Rules that bind every screen
+
+<!-- Only what a screen cannot legitimately override. Each MUST state what it prevents — a rule with
+     no failure behind it is a preference, and preferences go to ../../../project/codebase-conventions-guide.md.
+
+     A rule here that also holds for non-UI code is an AD-N and belongs in the spine instead. -->
+
+| Rule | Prevents |
+| --- | --- |
+
+## What this system deliberately does not cover
+
+<!-- Where a component is free to choose for itself. Absent, every local choice reads as a violation. -->

package/kit/.constitution/{document → method/document}/templates/inventory.md

@@ -1,69 +1,69 @@
----
-type: inventory
-kind: db                 # db · api · screen · endpoint — decides the row shape below
-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
----
-
-# Inventory — {tables | endpoints | screens | endpoints of {pc}}
-
-<!-- TEMPLATE GUIDE — act on these comments, then delete them.
-
-     ONE template, four kinds. Only the row shape differs; the rules are the same for all four.
-
-       kind: db      -> .how/_platform/inventory-db.md
-       kind: api     -> .how/_platform/inventory-api.md
-       kind: screen  -> .how/_platform/inventory-screen.md
-       kind: endpoint-> .how/<pc>/02-contracts/00-inventory.md, at mode: deep only
-
-     The first three are BLUEPRINT output, born at G3 by wdi-blueprint intent `platform`. They exist
-     at every `mode`, including catalog, and they are what makes catalog usable at all: the use case
-     list plus these three plus C4 is the whole record a builder gets there.
-
-     THE NUMBER IS STABLE. A new row takes the next `No`, never a renumber. Renumbering renames every
-     file after it and breaks every link pointing at them. A removed row keeps its number and its
-     status becomes `removed`; the number MUST NOT be reused.
-
-     TWO WAYS THIS FILE COMES TO EXIST, and derived_from says which:
-       plan  no code yet. Written as intent — the tables, endpoints, or screens planned. Nothing can
-             be derived, because there is no source.
-       code  code exists. Derived by .constitution/scripts/inventory.py — migrations for tables,
-             route registration for endpoints, pages for screens — and THEN compared with the plan.
-             The difference is a FINDING, reported. It MUST NOT be patched into agreement by hand.
-
-     MUST NOT be assembled from a README, from a route name that looks plausible, or from memory. -->
-
-## Rows
-
-<!-- kind: db -->
-
-| No | Table | Owning component | What it holds | Key columns | Status |
-| --- | --- | --- | --- | --- | --- |
-
-<!-- kind: api  — keep this block and delete the others
-| No | Method | Path | Owning component | Description | Status |
-| --- | --- | --- | --- | --- | --- |
--->
-
-<!-- kind: screen
-| No | Screen | Route | Owning component | Actor | UC served |
-| --- | --- | --- | --- | --- | --- |
--->
-
-<!-- kind: endpoint
-| No | Method | Path | Spec file | Status |
-| --- | --- | --- | --- | --- |
--->
-
-<!-- Status values: draft · published · deprecated · removed. A row with no status reads as
-     published, which is the one reading that is never safe. -->
-
-## Findings
-
-<!-- Only when derived_from: code. Each difference between the plan and what the code actually does,
-     one line each, with which side is being reported — not which side was changed. Nothing here is
-     resolved by editing the other side; a finding routes to the skill that owns it. -->
+---
+type: inventory
+kind: db                 # db · api · screen · endpoint — decides the row shape below
+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
+---
+
+# Inventory — {tables | endpoints | screens | endpoints of {pc}}
+
+<!-- TEMPLATE GUIDE — act on these comments, then delete them.
+
+     ONE template, four kinds. Only the row shape differs; the rules are the same for all four.
+
+       kind: db      -> .how/_platform/inventory-db.md
+       kind: api     -> .how/_platform/inventory-api.md
+       kind: screen  -> .how/_platform/inventory-screen.md
+       kind: endpoint-> .how/<pc>/02-contracts/00-inventory.md, at mode: deep only
+
+     The first three are BLUEPRINT output, born at G3 by wdi-blueprint intent `platform`. They exist
+     at every `mode`, including catalog, and they are what makes catalog usable at all: the use case
+     list plus these three plus C4 is the whole record a builder gets there.
+
+     THE NUMBER IS STABLE. A new row takes the next `No`, never a renumber. Renumbering renames every
+     file after it and breaks every link pointing at them. A removed row keeps its number and its
+     status becomes `removed`; the number MUST NOT be reused.
+
+     TWO WAYS THIS FILE COMES TO EXIST, and derived_from says which:
+       plan  no code yet. Written as intent — the tables, endpoints, or screens planned. Nothing can
+             be derived, because there is no source.
+       code  code exists. Derived by .constitution/method/scripts/inventory.py — migrations for tables,
+             route registration for endpoints, pages for screens — and THEN compared with the plan.
+             The difference is a FINDING, reported. It MUST NOT be patched into agreement by hand.
+
+     MUST NOT be assembled from a README, from a route name that looks plausible, or from memory. -->
+
+## Rows
+
+<!-- kind: db -->
+
+| No | Table | Owning component | What it holds | Key columns | Status |
+| --- | --- | --- | --- | --- | --- |
+
+<!-- kind: api  — keep this block and delete the others
+| No | Method | Path | Owning component | Description | Status |
+| --- | --- | --- | --- | --- | --- |
+-->
+
+<!-- kind: screen
+| No | Screen | Route | Owning component | Actor | UC served |
+| --- | --- | --- | --- | --- | --- |
+-->
+
+<!-- kind: endpoint
+| No | Method | Path | Spec file | Status |
+| --- | --- | --- | --- | --- |
+-->
+
+<!-- Status values: draft · published · deprecated · removed. A row with no status reads as
+     published, which is the one reading that is never safe. -->
+
+## Findings
+
+<!-- Only when derived_from: code. Each difference between the plan and what the code actually does,
+     one line each, with which side is being reported — not which side was changed. Nothing here is
+     resolved by editing the other side; a finding routes to the skill that owns it. -->

package/kit/.constitution/{document → method/document}/templates/sdd.md

@@ -137,7 +137,7 @@ reviewed:                # V13. Diisi hanya setelah bmad-review benar-benar dija
                        alone does not say what a column means. LC type store
      06-flows/         [deep]. Sequence diagrams ONLY for flows involving money, irreversible state, or
                        a third party. Lane order is fixed once for the project in
-                       codebase/conventions-guide.md; the No-op lane rule is REPEALED
+                       ../../../project/codebase-conventions-guide.md; the No-op lane rule is REPEALED
 
      supplements/ is REPEALED along with the ANX- concept it existed for. -->
 

package/kit/.constitution/{document → method/document}/templates/structure-codebase.md

@@ -1,129 +1,129 @@
----
-type: structure
-scope: codebase
-verified: '{YYYY-MM-DD}'      # the day the tree was actually read
-commit: '{sha}'               # the commit it was read at — staleness is measured against this
----
-
-# Codebase Structure
-
-<!-- TEMPLATE GUIDE — act on these comments, then delete them.
-
-     This file is DESCRIPTIVE. It states what the code tree looks like today. It MUST NOT carry
-     naming rules (conventions-guide.md), versions (stack-guide.md), or ratified legacy shapes
-     (brownfield-guide.md) — reference them instead.
-
-     Written and refreshed only by `wdi-init` intent `structure`, never by hand. Rules for both maps live in
-     .constitution/structure-guide.md.
-
-     THE SHAPE: annotated trees, not prose. Folders are complete; files are marked ★ inline and only
-     when they earn it. A tree that lists every file is unmaintainable, and an unmaintainable map
-     stops being read — that is how every source-tree document before this one died.
-
-     THREE SECTIONS, and the split is by DEPLOYABILITY, not by size or importance:
-       Top level   every base folder in the repo root
-       Container   runs or deploys on its own — the same word C4 L2 and components.yaml use
-       Library     an includable artifact — compiled or imported into something else, never run
-
-     "Container" is the kit's word, defined in templates/c4.md and carried by every LC's `container`
-     field. It MUST NOT be swapped for "application", "service", or "app" here — a synonym for a
-     term that already has a glossary entry is drift, and `wdi-reconcile` hunts for it. It does not
-     mean a Docker image; packaging is a separate question.
-
-     A unit that is neither is not a unit; it stays a line in Top level. When a unit stops being
-     separately deployable, it MUST move sections rather than keep its old heading. -->
-
-## Verified
-
-<!-- One line: date, commit SHA, and how the tree was read. If the commit is no longer an ancestor
-     of HEAD, this map is stale and MUST be refreshed before a gate reads it. -->
-
-## Top level
-
-<!-- Every base folder in the repo root, COMPLETE — including the dull ones. An unlisted folder is
-     the one people misuse, because nothing told them what it was for. Tag each entry so the two
-     sections below are predictable: [container] · [lib] · [docs] · [tooling] · [generated]. One
-     line of purpose per entry; no second line. -->
-
-```text
-{repo-root}/
-├── {unit}/                   # [container] what it is answerable for
-├── {unit}/                   # [lib] ...
-└── {folder}/                 # [docs] ...
-```
-
-## Containers
-
-<!-- One subsection per unit that runs or deploys on its own. Repeat the block below verbatim per
-     unit; if there is only one, there is still a subsection — a repo grows a second container
-     without warning.
-
-     Heading names MUST match the `container` values used in components.yaml, so an LC's container
-     can be checked against this map instead of trusted. A container with no code in this repo MUST
-     NOT get a subsection — it belongs to c4-l2-containers.md. A folder that builds more than one
-     container MUST say which. -->
-
-### {container}
-
-<!-- One line: what it is, and how it ships. Then the tree: folder convention first, ★ on the files
-     that earn it. Descend only until directories stop carrying distinct roles, and describe a
-     repeating shape ONCE with a placeholder such as <feature>/ rather than per instance. -->
-
-```text
-{container}/
-├── {entry-file}              # ★ ENTRY: what execution actually does first
-├── {folder}/                 # convention: what belongs here
-│   └── {file}                # ★ why this one is key
-└── {folder}/<feature>/       # the shape every feature repeats
-    ├── {sub}/                #   what goes in it
-    └── {sub}/                #   ...
-```
-
-<!-- One line, only when the unit has one: the authoritative call direction through those folders.
-     A builder who gets this wrong writes code that works and is still wrong. Cut if there is none;
-     do not invent one to fill the slot. -->
-
-**Flow:** {layer} → {layer} → {layer}
-
-## Libraries
-
-<!-- One subsection per includable artifact — compiled into or imported by something else, never
-     deployed on its own. A library is deliberately NOT a container, and MUST NOT appear at C4 L2.
-
-     Same block shape as a container, minus the entry point: a library that has one is a container
-     wearing the wrong label. -->
-
-### {library}
-
-<!-- One line: what it holds, and who consumes it. Then the annotated tree. -->
-
-```text
-{library}/
-├── {folder}/                 # convention: what belongs here
-│   └── {file}                # ★ why this one is key
-└── {folder}/
-```
-
-**Consumed by:** {units}
-
-## Generated
-
-<!-- Anything not written by hand, with its generator: codegen output, vendored trees, migration
-     snapshots. A generated folder edited by hand is a defect, so it MUST be named here even when it
-     looks like ordinary source. Cut the section if there is none. -->
-
-| Path | Generated by |
-| --- | --- |
-
-## Unclaimed
-
-<!-- Folders that exist but no one can state a purpose for. These are findings, not layout. Leave
-     them here, named, until they are claimed or deleted — inventing a purpose to empty this section
-     is the failure mode it exists to catch. Cut the section only when it is genuinely empty. -->
-
----
-
-<!-- Keep this legend last, and keep it one line. -->
-
-★ = key file: entry point, wiring root, the single place a rule is enforced, or a file that must be
-opened before behaviour in its folder can be changed.
+---
+type: structure
+scope: codebase
+verified: '{YYYY-MM-DD}'      # the day the tree was actually read
+commit: '{sha}'               # the commit it was read at — staleness is measured against this
+---
+
+# Codebase Structure
+
+<!-- TEMPLATE GUIDE — act on these comments, then delete them.
+
+     This file is DESCRIPTIVE. It states what the code tree looks like today. It MUST NOT carry
+     naming rules (conventions-guide.md), versions (stack-guide.md), or ratified legacy shapes
+     (brownfield-guide.md) — reference them instead.
+
+     Written and refreshed only by `wdi-init` intent `structure`, never by hand. Rules for both maps live in
+     .constitution/method/structure-guide.md.
+
+     THE SHAPE: annotated trees, not prose. Folders are complete; files are marked ★ inline and only
+     when they earn it. A tree that lists every file is unmaintainable, and an unmaintainable map
+     stops being read — that is how every source-tree document before this one died.
+
+     THREE SECTIONS, and the split is by DEPLOYABILITY, not by size or importance:
+       Top level   every base folder in the repo root
+       Container   runs or deploys on its own — the same word C4 L2 and components.yaml use
+       Library     an includable artifact — compiled or imported into something else, never run
+
+     "Container" is the kit's word, defined in templates/c4.md and carried by every LC's `container`
+     field. It MUST NOT be swapped for "application", "service", or "app" here — a synonym for a
+     term that already has a glossary entry is drift, and `wdi-reconcile` hunts for it. It does not
+     mean a Docker image; packaging is a separate question.
+
+     A unit that is neither is not a unit; it stays a line in Top level. When a unit stops being
+     separately deployable, it MUST move sections rather than keep its old heading. -->
+
+## Verified
+
+<!-- One line: date, commit SHA, and how the tree was read. If the commit is no longer an ancestor
+     of HEAD, this map is stale and MUST be refreshed before a gate reads it. -->
+
+## Top level
+
+<!-- Every base folder in the repo root, COMPLETE — including the dull ones. An unlisted folder is
+     the one people misuse, because nothing told them what it was for. Tag each entry so the two
+     sections below are predictable: [container] · [lib] · [docs] · [tooling] · [generated]. One
+     line of purpose per entry; no second line. -->
+
+```text
+{repo-root}/
+├── {unit}/                   # [container] what it is answerable for
+├── {unit}/                   # [lib] ...
+└── {folder}/                 # [docs] ...
+```
+
+## Containers
+
+<!-- One subsection per unit that runs or deploys on its own. Repeat the block below verbatim per
+     unit; if there is only one, there is still a subsection — a repo grows a second container
+     without warning.
+
+     Heading names MUST match the `container` values used in components.yaml, so an LC's container
+     can be checked against this map instead of trusted. A container with no code in this repo MUST
+     NOT get a subsection — it belongs to c4-l2-containers.md. A folder that builds more than one
+     container MUST say which. -->
+
+### {container}
+
+<!-- One line: what it is, and how it ships. Then the tree: folder convention first, ★ on the files
+     that earn it. Descend only until directories stop carrying distinct roles, and describe a
+     repeating shape ONCE with a placeholder such as <feature>/ rather than per instance. -->
+
+```text
+{container}/
+├── {entry-file}              # ★ ENTRY: what execution actually does first
+├── {folder}/                 # convention: what belongs here
+│   └── {file}                # ★ why this one is key
+└── {folder}/<feature>/       # the shape every feature repeats
+    ├── {sub}/                #   what goes in it
+    └── {sub}/                #   ...
+```
+
+<!-- One line, only when the unit has one: the authoritative call direction through those folders.
+     A builder who gets this wrong writes code that works and is still wrong. Cut if there is none;
+     do not invent one to fill the slot. -->
+
+**Flow:** {layer} → {layer} → {layer}
+
+## Libraries
+
+<!-- One subsection per includable artifact — compiled into or imported by something else, never
+     deployed on its own. A library is deliberately NOT a container, and MUST NOT appear at C4 L2.
+
+     Same block shape as a container, minus the entry point: a library that has one is a container
+     wearing the wrong label. -->
+
+### {library}
+
+<!-- One line: what it holds, and who consumes it. Then the annotated tree. -->
+
+```text
+{library}/
+├── {folder}/                 # convention: what belongs here
+│   └── {file}                # ★ why this one is key
+└── {folder}/
+```
+
+**Consumed by:** {units}
+
+## Generated
+
+<!-- Anything not written by hand, with its generator: codegen output, vendored trees, migration
+     snapshots. A generated folder edited by hand is a defect, so it MUST be named here even when it
+     looks like ordinary source. Cut the section if there is none. -->
+
+| Path | Generated by |
+| --- | --- |
+
+## Unclaimed
+
+<!-- Folders that exist but no one can state a purpose for. These are findings, not layout. Leave
+     them here, named, until they are claimed or deleted — inventing a purpose to empty this section
+     is the failure mode it exists to catch. Cut the section only when it is genuinely empty. -->
+
+---
+
+<!-- Keep this legend last, and keep it one line. -->
+
+★ = key file: entry point, wiring root, the single place a rule is enforced, or a file that must be
+opened before behaviour in its folder can be changed.