Phased delivery plan: outcomes before implementation

Each phase has a reason to exist, a defined outcome, evidence and a boundary. Durations are intentionally not prescribed. A team may aim for hour-scale tasks, but the unit is a comprehensible, independently verifiable change.

Phase	Outcome	Scope boundary	Acceptance evidence	Stop / escalate
0. Clarify product	Agreed first user problem and alternatives worth investigating	No code commitment	Hypotheses, comparison plan, first experiment	User problem cannot be stated clearly
1. Establish intake contract	Schema, error semantics and replay behaviour agreed	Contract files + fixtures only	Contract review; failure cases written	Duplicate identity meaning unresolved
2. Implement request mechanics	Request store implements contract	Store module and tests; no UI	Replay, conflict and validation tests pass	Store cannot satisfy contract without new subsystem
3. Integrate intake and audit	New requests generate exactly one creation event	Intake module + audit interface/tests	First submit vs replay vs conflict tests	Partial commit behaviour lacks a safe plan
4. Ownership workflow	Authorised assignment changes status and owner	Assignment integration, permission port, tests	Transition, version conflict and access tests	Identity/tenant rule unknown
5. Evaluate user workflow	Real participants can evaluate ownership flow	Narrow UI plus observation protocol	Recorded task results, questions and gaps	Trial cannot distinguish product hypothesis
6. Refine product scope	Keep, defer, replace or remove proposed features	Product/design artefacts + affected code	Decision linked to observed evidence	No evidence to justify the change
7. Prepare release	Evidence for operational safety and supportability	Production adapters, security, monitoring	Release checklist; rollback/recovery tested	Security or data-integrity gap remains

Before a phase begins

• The intended outcome is written in terms of observable behaviour.
• The relevant contracts and architectural decisions are linked.
• The agent knows which paths/components it may change.
• External assumptions are either resolved or explicitly named.
• Tests or checks likely to demonstrate the outcome are identified.
• The plan defines when to stop and who decides what happens next.

After a phase

The implementer returns the changed files, tests and check results, unresolved risks and any requested decision. The reviewer checks evidence against the phase—not merely whether the diff looks plausible.

A phase is accepted only when its outcome is understood. A failed or abandoned phase is not necessarily wasted if it produces useful evidence for a change of direction.

Why these phases are not a waterfall

The product and architecture may change after any phase. A market comparison can eliminate a feature before code exists. A contract test may expose an architectural flaw. A playtest or user trial may change the product’s value proposition. The next phase is chosen from current evidence, not automatically from a frozen schedule.

Only phases 1–3 are partly represented by the runnable example. The later phases are design targets and demonstration artefacts, not completed work.