The work register

The work register says what must become true, in what grouping, and how far delivery has moved. It is a plan, not a source of product behaviour.

Each module keeps its work register beside its module reference:

<module>/docs/
  index.html          normative domain and functional requirements
  work-register.md    non-normative grouping, gates and status

The first line of every register states the boundary: requirements own product behaviour; this register owns grouping, order and status. Stories cite requirement IDs and never restate their rules.

Two identifier systems

Both schemes come from established disciplines and serve different lifetimes.

Use <epic>.<story>, zero-padded to two digits. Add <epic>.<story>.<task> only when a register genuinely owns task detail.

WBS codes are positional, never derived from names. 03.04 survives a renamed epic and sorts correctly after 09.08. Once assigned, a code is never reassigned, even when its story is withdrawn.

Mandatory presentation

Group the register by WBS epic. Every epic has:

1. a zero-padded number and stable domain outcome;
2. one delivery gate annotation;
3. one compact Story | Outcome | Requirements | Status table.

## 02 — Reservation changes

**Delivery gate:** Ready. Pricing and availability contracts are accepted.

| Story | Outcome | Requirements | Status |
| --- | --- | --- | --- |
| `02.01` | Amend a reservation period | [BKG-004](index.html#bkg-004) | shipped |
| `02.02` | Cancel a reservation | [BKG-005](index.html#bkg-005) | in progress |
| `02.03` | Release equipment after cancellation | [BKG-005](index.html#bkg-005), [CAT-008](../catalog/docs/index.html#cat-008) | planned |

This is the default view. A flat backlog hides the domain grouping. A combined requirements-and-status page creates two owners for behaviour.

Statuses

Use one controlled set:

Do not add blocked or ready as statuses. Those describe the delivery gate, not progress through the work.

Delivery gates

A gate is an epic-level annotation explaining whether its stories can move and what they depend on. It can say:

• Ready — the required contracts and decisions are accepted;
• Awaits … — name the exact decision, module contract or external fact;
• Partly delivered — name where remaining dependencies or defects are owned;
• Delivered — every intended story in the epic has shipped or been withdrawn.

Write planned stories behind an unresolved gate when their outcomes and requirement links are known. The gate makes the dependency visible; it does not pretend the work is in progress. Never copy the underlying open question into the register.

The traceability join

module reference                 work register
BKG-001  ←────────────────────── 01.01
BKG-004  ←────────────────────── 02.01
BKG-005  ←────────────────────── 02.02, 02.03
CAT-008  ←────────────────────── 02.03

Every story cites at least one requirement. Every requirement is cited by a story or by a module-wide definition of done. That makes coverage a check rather than a claim.

Writing stories

Follow Plan delivery to derive outcome stories from accepted requirements. This reference owns the row contract; the guide owns the procedure for producing the rows.

Story sizing

Use the tracer-bullet sizing checks. The result still has one register row and one verifiable outcome.

Work register versus master delivery plan

The module register owns its WBS stories and local gates. The master delivery plan owns cross-module sequence, integration gates and demonstrations. It links module story codes; it never copies their rows.

How this fails

Stories restate rules. A developer can implement from the register without opening the module reference, so delivery has become a shadow specification.

A gate becomes a status. blocked hides what is missing and cannot distinguish a contract dependency from an unanswered policy decision.

Names generate codes. Renaming an epic invalidates references and collisions need a legend. Positional WBS codes avoid both.

Tasks become a third copy. A task says what to do next, points to its story, and is disposable. See tasks.