wdi-method 0.3.0

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

@@ -0,0 +1,127 @@
+---
+name: wdi-product
+description: Use at G2 Product — when a PRD is created or an existing promise changes. Two intents, prd and update. Checks position, dispatches bmad-prd, verifies the result against prd-guide.md, and lands the memlog. Never writes the PRD itself.
+---
+
+# WDI Product
+
+G2 decides **what is built, and how it feels to use.** `bmad-prd` writes the PRD.
+
+This wrapper exists because `bmad-prd` was the only writer of a primary artifact in this method with no WDI
+wrapper at all — so nothing checked its position, nothing verified its result against the guide, and nothing
+landed its memlog where the next run would read it. Those three gaps were paid for at G2 every time.
+
+You MUST NOT write or edit `prd.md` yourself. If a check fails, name what is missing and re-dispatch.
+
+| Intent | When |
+|---|---|
+| `prd` | A functional area a reader would not think to look for in an existing PRD |
+| `update` | Anything else — the default, and by a wide margin |
+
+## Inputs
+
+| Source | What it answers |
+|---|---|
+| `.what/_product-brief/brief.md` | The problem, the primary user, the boundary the PRD MUST respect |
+| `.what/_prd/*/prd.md` | Which initiatives already have a PRD, and what each already promises |
+| `.control/registry/requirements.yaml` | The next `CAP`/`FR`/`NFR`/`UJ` ids, allocated globally |
+| `.control/decisions/` | `applied` decisions the PRD MUST already reflect |
+| `.constitution/document/prd-guide.md` | The rules the result is checked against |
+| `.control/product-glossary.md` | Terms already fixed |
+
+## Step 1 — Position, and `update` is the default
+
+The decision this skill exists for. The test is the **reader**, not the calendar:
+
+> Would someone looking for this promise open an existing document?
+
+Yes → `update`, however large the change. No → `prd`. A PRD MUST NOT be split because it grew long, and a
+release is never a reason on its own. `prd-guide.md` owns the full table.
+
+Three asks that are not this skill:
+
+| Ask | Route |
+|---|---|
+| The problem itself has changed | `wdi-problem` — a re-cut plan under a wrong problem is wasted work |
+| Only the **wording** of an `FR` is wrong, while the promise is the same | The skill already at work fixes it directly. See below |
+| A planning assumption turned out to be void | `wdi-decision`, which wraps `bmad-correct-course` |
+
+## Step 2 — Wording is not a promise
+
+The split that ended three corrections in "reported but not fixed". `prd-guide.md` owns it; what this skill
+owns is refusing to run for the wrong half.
+
+| What changed | Who does it |
+|---|---|
+| A wrong cross-reference, a retired term, a word inconsistent with an `applied` decision — **the promise is the same** | Whichever skill is already at work. Memlog records it; **one** Revision History row per pass, never one per correction |
+| Scope, the proof of done, an `FR` retired or born | This skill, intent `update` |
+
+You MUST NOT accept a wording correction as an `update` run. Doing so puts a trivial fix behind a gate, and
+that is exactly how the three earlier ones were dropped.
+
+## Step 3 — Dispatch
+
+Invoke `bmad-prd` with the detected intent, scoped to **one initiative**. Do not restate the rules to it —
+they arrive through `persistent_facts` and `doc_standards` in `_bmad/custom/bmad-prd.toml`.
+
+Name the brief and, for `update`, the existing PRD and every `applied` decision that reaches it. The skill
+globs its own default locations, which this project redirects.
+
+## Step 4 — Verify
+
+| # | Check | Fails when |
+|---|---|---|
+| 1 | Home | Anything outside `.what/_prd/<initiative>/`, or a folder still named `ISI-slug-inisiatif` |
+| 2 | Ids allocated from the registry | `FR-1` restarted, or an id invented in prose |
+| 3 | Every `FR` names its `capability`; every `NFR` names its `goal` | V15 has nothing to check |
+| 4 | Every `FR` has **exactly one** proof of done, in business language | Zero, or a second technical restatement beside it |
+| 5 | Every `NFR` names `enforced_by` | An `NFR` nothing enforces is decoration (V5) |
+| 6 | Cross-Cutting NFRs and Constraints both present | An absent section reads as "not checked" |
+| 7 | No solution shape | A framework, a table, or a transport named in `prd.md` rather than in `addendum.md` |
+| 8 | One Revision History row for this run, written for someone not in the room | Zero rows, several rows, or a row that says "Updated §4.2" |
+| 9 | Memlog at `.control/memlog/prd-<slug>.md`, slug matching the folder | A `.memlog.md` appeared inside `.what/` — `--workspace` was used |
+| 10 | `bmad-review` ran through `doc_standards` on `prd.md` and `addendum.md` | It did not fire |
+
+Check 9 MUST be fixed immediately rather than reported. V16 rejects a memlog inside the corpus.
+
+## Step 5 — `owns:`, and the collision it prevents
+
+A new or changed `FR` that claims write authority over a domain entity MUST be checked against `owns:` in
+`components.yaml`. An entity has exactly one owning Product Component; an `FR` from another PRD that needs to
+change it MUST point at the owner's `FR` rather than promising to write it itself. V21 checks this, and the
+collision has already happened once for real.
+
+Report a collision. You MUST NOT resolve it by widening one PRD's claim.
+
+## Step 6 — Impact
+
+A changed promise changes what other documents can still claim. Check, and **report** — never edit.
+
+| Found | Where it goes |
+|---|---|
+| A `UC` realising an `FR` whose promise moved | `wdi-component` intent `behaviour`, or `wdi-blueprint` when the catalogue line itself changes |
+| A blueprint inventory row with nothing promising it any more | `wdi-blueprint` |
+| A contradiction with an `applied` decision | `wdi-decision` — a new `DEC-`, never an edit to one already applied |
+| A component born by this initiative | `wdi-init` intent `component` |
+
+Then run the change-control matrix in `delivery-flow-guide.md` and **report** which gates reopen. You MUST
+NOT reopen one yourself.
+
+## Rules
+
+- You MUST NOT write a second PRD for an area that already has one. The reader test decides, and its answer
+  is `update` far more often than it feels.
+- You MUST NOT open G2 on a PRD that has not been through check 10. Gate time is for deciding, not
+  proofreading.
+- The gate reads `prd.md` and `EXPERIENCE.md` together. A PRD that passes while the experience side is
+  missing has answered half of what G2 decides.
+- Every unresolved `[ASSUMPTION]` MUST be filed through `wdi-question` before the gate opens.
+- You MUST NOT raise `status:`. Status is a stage; the `reviewed:` block is an event, and `wdi-review` writes
+  it.
+- When the PRD cannot promise what was asked, say so and stop. Route to `wdi-problem`; do not quietly narrow
+  the ask.
+
+## Output
+
+Intent dispatched · what the promise now is in one line · the result of all ten checks naming the failures ·
+the `owns:` check · impact found and where it was routed · the gates the matrix names · open questions filed.

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

@@ -0,0 +1,88 @@
+---
+name: wdi-question
+description: Use when something cannot be decided now and must not be silently assumed. Files it into one of four lists in .control/questions/ by what the reader has to do about it, and closes it in place when the answer arrives.
+---
+
+# WDI Question
+
+Free of stage and free of role. The purpose is narrow: make sure an unresolved thing is written down
+where it will be seen, instead of becoming an assumption nobody remembers making.
+
+The old single list reached `OQ-146` and stopped being readable. It is now four files in
+`.control/questions/`, split by **what the reader has to do about it** — not by subject, and not by
+severity.
+
+| File | Holds | Read when |
+|---|---|---|
+| `blocking.md` | Holds a gate. Target ≤3 per Product Component | Every gate |
+| `assumptions.md` | An assumption the agent took itself. One line: the assumption plus the cost of being wrong | Swept once per gate; MAY be skipped |
+| `external.md` | Waiting on a file, an action, or a credential from outside. Owner and `by_when` required | Before go-live — **not** at a design gate |
+| `answered.md` | Archive. Closed in place, never deleted | Almost never; only to stop a question being reopened |
+
+**Only `blocking.md` holds a gate.** `external.md` holds go-live; `assumptions.md` holds nothing.
+
+## The default class is `assumptions.md`
+
+A question is filed there 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, you MUST take the answer yourself and record it as one line — the assumption, and
+what it costs if it is wrong.
+
+**You MUST NOT register a question as blocking "to be safe."** That habit is what produced 146 ids and
+a list nobody read, and the cost is paid at every gate afterwards.
+
+## One batch, per gate, already ranked
+
+Inside a single working pass you do **not** ask. You collect. The batch is delivered once, at the gate,
+ranked, and it MUST NOT be dribbled out as each question surfaces.
+
+A healthy batch on `mode: catalog`: **≤3 blocking questions, plus ≤15 one-line assumptions.** A batch
+larger than that is a signal about the pass, not about the corpus — say so rather than delivering it
+as a list.
+
+When N agents ran in parallel, their questions arrive as **one** ranked batch, never as N reports.
+
+## Registering
+
+| Field | Rule |
+|---|---|
+| Question | One sentence, answerable. "How should referrals work?" is a topic, not a question |
+| Blocks | What cannot proceed — a gate, an `FR`, a story, or nothing |
+| Owner | Who can answer. A question with no owner is a wish |
+| By when | The moment it must be answered, usually a gate |
+
+Ids stay `OQ-`, allocated from the highest ever used including closed ones. An id MUST NOT be reused.
+
+A question whose discussion outgrows one line gets `.control/questions/OQ-NNN-<slug>.md` in the same
+folder, from `templates/oq.md`, and the list keeps a one-line pointer. The old home
+`.control/supplements/` is gone.
+
+## Closing
+
+An answered question is closed **in place** — the answer written beside it with the date and who
+answered — then moved to `answered.md`. You MUST NOT delete the entry.
+
+If the answer amounts to a decision that is expensive to reverse, the closure MUST route to
+`wdi-decision`. This list records that an answer arrived; a `DEC-` records what was chosen and what it
+cost.
+
+## Rules
+
+- You MUST NOT answer the question yourself when the owner is the client or a stakeholder. Drafting a
+  proposed answer for them to confirm is useful; recording it as settled is not.
+- An `[ASSUMPTION]` tag left in a PRD, an SRS, or an SDD MUST be filed here before that document
+  passes its gate. That is precisely the failure this skill exists to prevent.
+- A question past its "by when" MUST be raised, not silently carried forward. Carried forward twice is
+  a signal that either the owner is wrong or the question is not real.
+- A row MUST move between files when its class changes, and MUST NOT be copied into a second one. An
+  assumption that turns out to touch money moves to `blocking.md`; it does not appear in both.
+- Terms MUST match `.control/product-glossary.md`.
+
+## Output
+
+Which file each question landed in, the blocking ones ranked, the assumptions as one-line rows, and
+anything routed on to `wdi-decision`.

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

@@ -0,0 +1,146 @@
+---
+name: wdi-reconcile
+description: Use before a gate, or after a batch of changes, to find drift between .what, .how, and .control — against each other and against the rules in .constitution. Scoped to what the gates already passed have actually produced, and to what each component's mode actually demands. Read-only — it reports, it never edits.
+---
+
+# WDI Reconcile
+
+Documents drift apart quietly. An SRS gets amended while its SDD does not; a `DEC-` is accepted and never
+applied; a story ships behaviour the use case never described. None of this shows up as an error, which is
+why it needs a pass that looks for it on purpose.
+
+This skill is **read-only**. It MUST NOT edit anything. Its output is a report, and every fix it
+recommends is performed by another skill.
+
+## Step 1 — Scope by gate, then by `mode`
+
+Two filters, and skipping either produces a report that is red where the plan says it should be.
+
+**By gate.** The corpus is built gate by gate, so most of it is legitimately absent most of the time.
+Establish which gate the work stands at — `wdi-help` answers that — and check only what has been passed.
+
+| Gate passed | In scope |
+|---|---|
+| G1 | `brief.md` |
+| G2 | + every `_prd/<initiative>/`, UX output wherever it currently sits, `product_components` with `mode` and `risk_accepted` |
+| G3 | + every `.what/<pc>/` § UC Catalogue and § Actor Register, `domain-model.md`, `business-rules.md`, the spine, the C4 set, `containers`, the three inventories |
+| G4 | + whatever each component's `mode` demands in `.what/<pc>/` and `.how/<pc>/` |
+| G5 | + `SPEC.md`, `waves.yaml`, story files, tests, `defects.yaml`, RTM rows |
+
+**By `mode`.** An artifact a component's `mode` does not demand MUST NOT be reported as missing. A
+component at `catalog` has an SDD skeleton and no depth, and that is a **finished** state — G4 is skipped
+there. Reporting it as a gap is the failure that would make this pass unusable at the setting most
+projects run.
+
+An artifact a **later** gate produces MUST NOT be reported as missing either. That is not drift, it is
+the plan. The corpus running ahead of the code is likewise normal and deliberate.
+
+A narrower scope MAY be asked for — one Product Component, one initiative, one layer. State the scope
+in one line before checking, and say what it excluded.
+
+## Step 2 — Run the validators first
+
+Run `uv run .constitution/scripts/validate.py`, and `uv run .constitution/scripts/inventory.py` when code
+exists. V1–V24 answer everything that can be **counted**, and you MUST NOT re-derive by reading what they
+already report. Carry their findings as they came, then spend the reading on what no validator can see.
+
+`.control/generated/` is their output and MUST NOT be read as an independent source. When it is
+missing or stale, say so and name `validate.py --generate` rather than working around it.
+
+## Step 3 — What only a reader can find
+
+| Direction | Question |
+|---|---|
+| Top-down | Does every `applied` `DEC-` actually appear in the files its `touches` names? |
+| Bottom-up | Does anything in `.how/<pc>/` describe behaviour that `.what/<pc>/` never promised? |
+| Decisions | Is there an `accepted` `DEC-` that was never applied, or an `applied` one with an empty `touches`? The second is V8; the first no validator can see |
+| Chain | `BG → CAP → FR/NFR → UC → story → test` — where does it break? |
+| Depth | Does any document carry more than its component's `mode` demands? Over-writing is drift too, and it is the direction nobody looks for |
+| Vocabulary | Does any document use a domain noun that `.control/product-glossary.md` does not define, or a synonym for one it does? Detect against the rule in `wdi-blueprint`; MUST NOT keep a second rule here |
+| Registry | Does `components.yaml` still describe what the corpus contains — a `<pc>` folder with no entry, an `LC` with no prose in the slot its `type` names, a container in the C4 set but not in `containers`, `owns:` claiming an entity another component also claims |
+| Inventory | Do the three inventories still match the code? `inventory.py` answers it; carry its findings rather than re-deriving them |
+| **Constitution** | Does an artifact break the rule its own guide states? |
+| **Homeless output** | Does anything in `_bmad-output/` have no row in the ownership table in `corpus-guide.md`, or a row whose named owner is not installed? |
+| **Evidence** | V24 answers the mechanical half — does every cited path still resolve. What is left for a reader: does the file still **contain** what is cited |
+
+The chain check overlaps the validators on purpose. Validators answer what can be counted; this pass
+answers what has to be read — a `UC` that exists and is wrong passes V2 and fails here.
+
+### The Constitution check
+
+The other checks compare documents with each other. This one compares a document with the rule that
+governs it, and the four failures worth looking for are the ones no ID chain records:
+
+| Looks like | Rule it breaks |
+|---|---|
+| Solution shape in `.what/` — a table, an endpoint, a framework | `corpus-guide.md`, and it is the most common one |
+| A promise appearing first in `.how/` | The same rule, in the other direction |
+| A file in the wrong slot | `.what/` numbers are reading order, `.how/` numbers are ABCE classification |
+| A layer written by a skill that does not own it | The ownership table in `corpus-guide.md` |
+| A rule stated in a `.constitution/method/` file | `status: Reference` — it explains, it MUST NOT bind |
+| A `Reference` file contradicting a guide | The guide wins, and the contradiction is a defect to report |
+
+You MUST NOT invent a rule to fail an artifact against. Every finding here MUST quote the guide it comes
+from. A file at `status: Draft` MAY be read as guidance but MUST NOT be used to reject anything — that
+holds for all three `codebase/*-guide.md` — and a file at `status: Reference` MUST NOT be cited to reject
+anything at all.
+
+### What the Evidence check is, and what it is not
+
+It checks whether **citations still resolve**. It does **not** check whether the code implements the
+corpus, and you MUST NOT widen it into that.
+
+A general corpus-versus-code comparison would be red through the middle of every wave, and a check
+that is always red is a check people learn to skip. What is already covered elsewhere MUST NOT be
+re-reported here:
+
+| Already answered by | Case |
+|---|---|
+| A red RTM row | Promised, not built yet |
+| V2 · V3 | Documented, never scheduled |
+| V4 | A story closed with no named test |
+| `inventory.py` | The plan and the code disagreeing about a table, endpoint, or screen |
+
+That leaves exactly one gap, and it is the one this check fills: **a descriptive claim about code
+that already exists, which has quietly stopped being true.** A file renamed, a function removed, a
+route unregistered — nothing in the ID chain moves, so no validator can see it.
+
+Two properties keep the check healthy:
+
+- It fires **only where a citation exists**. Prose with no cited source produces no finding, so there
+  is no flood.
+- It is cheap: a path and symbol lookup, not a semantic judgement.
+
+A claim the check proves absent MUST be labelled `[MISSING]` in the document rather than deleted —
+see the evidence ladder in `sdd-guide.md`, which owns that rule.
+
+## Output — an action matrix
+
+Each finding gets four fields, and the last two are what make the report usable:
+
+| Field | Content |
+|---|---|
+| What | The drift, stated concretely with both sides quoted |
+| Where | File and section on each side |
+| Which is right | Your reading, stated as a judgement, not hidden as a fact |
+| Who fixes it | The skill that owns the layer needing the change — `wdi-problem` · `wdi-product` · `wdi-blueprint` · `wdi-component` · `wdi-ux` · `wdi-build` · `wdi-init` · `wdi-decision` · `wdi-question` · `wdi-log` · `wdi-systematic-debugging` · a human |
+
+A finding you cannot assign to a fixer MUST be reported as an open question rather than left as an
+observation.
+
+Separate **drift** from **conflict** in the report, because they are answered differently: drift has
+a right side and needs carrying across; a conflict has no clearly right side and needs deciding.
+
+## Rules
+
+- You MUST NOT edit. Not a typo, not a heading, not a link. The value of a read-only pass is that its
+  report can be trusted to describe the state before anything moved.
+- You MUST NOT rank a finding as minor because it is small. Vocabulary drift is small and is the one
+  that compounds fastest.
+- When two documents disagree and neither is clearly right, that is a decision, not a drift. Route it
+  to `wdi-decision` and say so.
+- An output with no home MUST be reported as a gap in the method, and its home MUST NOT be guessed. The
+  gap has nowhere else to surface. Exploration output — research, brainstorming, forge, PRFAQ — is
+  homeless **by rule** and MUST NOT be reported.
+- Run before every gate, and after any batch of edits that touched one layer without the other.
+  Running it only when something feels wrong defeats it — drift is silent by definition.

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

@@ -0,0 +1,205 @@
+---
+name: wdi-report
+description: Use when someone needs numbers about this project — progress for a client update, an estimate before the work is committed, or task rows ready to paste into a tracker. Three intents, progress and estimate and dispatch. Never invents a number.
+---
+
+# WDI Report
+
+Three intents, and the first is deliberately fenced off from the other two **because their rules are opposite**.
+
+| Intent | Answers | Rule |
+|---|---|---|
+| `progress` | What has moved, what is late, how much is proven | **Entirely derived.** MUST NOT write one number, date, or percentage that did not come from the registry or from git |
+| `estimate` | How big this is, what the tasks are, how much load, what the timeline looks like | **Forward-facing.** MUST state which inputs exist and how precise that makes it, and MUST be labelled an estimate |
+| `dispatch` | Task rows ready for an outside tracker | Reads the same table as `estimate`; recomputes nothing |
+
+Confusing the first two is the failure this split exists to prevent: a forward-looking figure presented in the
+voice of a derived one is the most expensive kind of wrong.
+
+## What owns what
+
+| Owner | Produces |
+|---|---|
+| `.constitution/scripts/validate.py` | `generated/rtm` · `dag` · `status` · `risks` · `components` · `decisions` · `blueprint` · `estimate` |
+| `.constitution/scripts/timeline.py` | `generated/timeline` · `generated/report` · `.control/reports/<period>.md` |
+| `.constitution/scripts/inventory.py` | The three inventories, derived from code |
+| `wdi-reconcile` | Drift between corpus and registry — read-only, no file |
+| **this skill** | The judgment on top: whether the tables are fresh enough to report on, and the human commentary written at publish time |
+
+All three scripts are deterministic and already written. You MUST NOT hand-derive anything they produce, and you
+MUST NOT write into `generated/` yourself. Your job starts where their output stops being self-explanatory.
+
+---
+
+# Intent `progress`
+
+## Step 1 — Refresh, or refuse
+
+```bash
+uv run .constitution/scripts/timeline.py --refresh --generate
+```
+
+`--refresh` runs the validators first, so both halves of `generated/` are derived at the same commit. Read what
+it prints before reading anything else:
+
+| What it says | What you MUST do |
+|---|---|
+| `rtm/status belum ada` (exit 3) | Stop. The tables cannot be built, so there is nothing honest to report |
+| `git tidak menjawab` (exit 3) | Stop. Every actual date comes from git; without it there is no time dimension |
+| `registry punya perubahan yang belum dicommit` | Say so in the report header. The numbers describe a working tree, not `main` |
+| `story tanpa riwayat git` | Name those stories. They count toward progres janji but cannot appear under Proven |
+| `n temuan validator` | Report the count and, if any are red, say which gate they block |
+
+A report built on stale tables is worse than no report: it looks authoritative and is not.
+
+## Step 2 — Read the derived time dimension
+
+You MUST NOT derive dates yourself. `timeline.py` reads each story file's history and takes the first commit whose
+frontmatter status left `draft` as the start, and the commit where it became `done` as the end. `FR` spans its
+stories; `CAP` spans its `FR`, and closes only when every story under it is closed.
+
+None of this is written back into any registry. A stored copy would be a second home for one fact, and the stored
+copy is the one that goes wrong.
+
+## Step 3 — Read `generated/timeline` and `generated/report`
+
+`timeline` gives one row per `CAP`, plan beside actual, plus a gantt. `state` is `not-started`, `in-progress`,
+`done`, or **`overdue`** — the last being V14.
+
+You MUST list every overdue row **by name**, with what it is waiting on. The script prints them individually for
+the same reason: aggregating them into a count is how a slipping plan stays comfortable.
+
+`report` gives five composed sections covering the span since the last published report: **Proven** (RTM rows that
+turned green, named) · **Moved** (`CAP` and `FR` that started or closed) · **Late** · **Defects** (grouped by
+`root_cause`) · **Gates** (dated from the history of `index.yaml`).
+
+Section 4 grouped by root cause is worth reading twice: it answers how many defects were a wrong requirement rather
+than wrong code, and that ratio is a fact about the method, not about the team.
+
+The left edge is the `asof` of the newest published report. When there is none, the script says the period is
+unbounded on the left, and you MUST repeat that rather than picking a date.
+
+## Step 4 — Publish
+
+```bash
+uv run .constitution/scripts/timeline.py --publish weekly
+```
+
+A published report is **frozen**. It states what was true on a date, exactly like minutes. The script refuses to
+overwrite one (exit 4) rather than trusting anyone to remember.
+
+- You MUST NOT edit a published report. If it was wrong, the next report says so.
+- The `## Catatan` block is the one part a person writes, once, at publish time, before the commit.
+- Commentary MUST cite rather than restate: a slip has a cause, and that cause already lives in a `DEC-`, an
+  `OQ-`, a risk, or a defect.
+
+## Step 5 — Lead with the honest number
+
+| Measure | Formula | Answers |
+|---|---|---|
+| **Progres janji** | green RTM rows ÷ total RTM rows | How much is **proven** |
+| Progres kerja | stories `done` ÷ stories in wave | How much was worked on |
+| Kesiapan gate | green validators ÷ applicable validators | Whether the next gate can open |
+
+You MUST present **progres janji** first and label it as the one that counts. Progres kerja MUST NOT lead a
+client-facing report: a story can be `done` while its RTM row is still red because the test has no name or the `UC`
+does not exist — and that gap is exactly what the client is entitled to know.
+
+---
+
+# Intent `estimate`
+
+**It runs as early as G1, and sharpens every time an input arrives.** That is what makes it useful for sizing a
+project before there is a line of code.
+
+## Step 1 — State the input, and the precision it buys
+
+You MUST say which of these exist and stop at the honest level. Claiming precision the inputs do not support is the
+one thing this intent can get badly wrong.
+
+| Input available | What can be estimated | Precision |
+|---|---|---|
+| **G1** — the brief | T-shirt size · rough capability count · the first risk list | very rough |
+| **+ G2** — the PRD | **The candidate task list = the `FR` list** · `estimate_mandays` per `CAP` · `must/should/could/wont` · order from `depends_on` between `CAP` | rough |
+| **+ tail of G2** — components born | Tasks grouped per component = per Epic · **`mode` per component, so document load is counted too** · `risk_accepted` marks exposure | medium |
+| **+ G3** — the blueprint | Table, endpoint, and screen counts → real implementation load, not load guessed from an `FR` count | good |
+| **+ G4** — component depth | Stories and test names → measured load | best |
+
+## Step 2 — Inputs
+
+`requirements.yaml` (`estimate_mandays`, `priority`, `depends_on`, `target_release`) · `components.yaml` (`mode`,
+`risk_accepted`, `risk_note`) · the three `inventory-*.md` when they exist.
+
+`estimate_mandays` on `CAP` is the **source**, and it is used for real here rather than being decoration. When it is
+absent, say so — an estimate with no mandays input is a T-shirt size, and it MUST be reported as one.
+
+## Step 3 — The output: one task table
+
+Written to `.control/generated/estimate.md` by `validate.py --generate`. **Default one row per `FR`**, because that
+is the ideal shape of a wave and because an `FR` has had a proof of done since birth.
+
+| Column | Content |
+|---|---|
+| Task | The title, from the `FR` |
+| `FR` | Its id |
+| Epic | The Product Component |
+| `mode` | That component's depth — this is what makes document load visible |
+| Paparan | `risk_accepted` + `risk_note` |
+| Beban | Mandays, derived from the parent `CAP`'s `estimate_mandays`, divided among its `FR` |
+| Prioritas | From the `CAP` |
+| Bergantung pada | From `depends_on` |
+| Rilis | The `CAP`'s `target_release` |
+
+## Step 4 — Say what it is, and what it is not
+
+> A row in the estimate table is a **candidate** task. A wave in `waves.yaml` is a **real** one. The first missing
+> is normal; the second is not.
+
+The table is planning, not commitment. One row MAY become one wave, and three neighbouring rows MAY be merged into
+one. **That merge is a human decision made when the wave opens**, and this intent MUST NOT pretend to already know
+the answer.
+
+- Every output MUST carry the word estimate, visibly, at the top.
+- You MUST NOT present a mandays figure without naming what it was derived from.
+- You MUST NOT include a date this intent computed itself. Plan dates come from `planned_end` on a `CAP`; where
+  there is none, the timeline is stated in sequence and dependency, not in dates.
+
+---
+
+# Intent `dispatch`
+
+Reads `.control/generated/estimate.md` and `waves.yaml`. **It recomputes nothing.**
+
+It emits rows in a form that can be pasted into an outside tracker: Epic (the Product Component), Task (the wave, or
+the candidate row where no wave exists yet), Sub-task (the story, where one exists), labels for `FR` and `CAP`, and
+Fix Version from the release.
+
+- Output goes **to the screen**. This intent MUST NOT write a file, and MUST NOT write to the tracker — entering it
+  is a human act.
+- The corpus never reads back from the tracker. **The corpus is the source of truth; the tracker is a view.**
+- A row whose Task is still a candidate MUST be marked as one. A candidate pasted as a real Task is how a tracker
+  fills with issues nobody committed to.
+
+---
+
+## Rules
+
+- You MUST NOT invent progress. When a table is missing or stale, name it and stop.
+- You MUST NOT report `progress` in stories. The planning layer speaks in `CAP`, `FR`, and defects; stories are the
+  execution layer and are born too late to plan against.
+- You MUST NOT hand-write anything under `generated/`. There is no exception.
+- You MUST NOT re-run `--publish` to "fix" a report. The refusal is the rule working.
+- When plan dates have moved since the last report, you MUST say so and point at the commit.
+- When there is no previous report, say the period is unbounded on the left rather than picking a date.
+- You MUST NOT mix the intents in one output. A derived number and a forward-looking one MUST NOT appear in the same
+  table without the labels that separate them.
+
+## Output
+
+**`progress`:** the published path, the freshness commit, progres janji, then the five sections — overdue rows named
+individually, never counted away.
+
+**`estimate`:** which inputs exist and the precision that buys, the task table, and what is a candidate rather than
+a commitment.
+
+**`dispatch`:** the paste-ready rows, on screen, with candidates marked.