Phase 2 Completion: Orders with Lifecycle

This page is the completion record for Phase 2 of the Orders v2 effort: what was built, how it was verified, and the state it hands to review. It complements the Goal (what Phase 2 set out to do), the Design (how), the Decisions (the rulings, as amended), and the Atlas (the ticket/PR map). Status at the snapshot date: the implementation is complete and in review — the twelve-PR stack is on operations main 8.4.1 awaiting the reviewer pass and the bottom-up merge cascade; nothing here claims a merge that has not happened.

How this page reached the site

This record was first proposed in documentation PR #160, which was closed unmerged on 2026-09-09 rather than merged. Its content re-landed in two reviewable parts — this page among them — after a triage of the review findings that PR had accumulated but never posted. The status paragraph above is unchanged from the original and still reads as of its snapshot date.

What Phase 2 built

Everything below is implemented and in review, not merged and not running. The Orders module reference states the runtime’s side of the same fact — designed, build pending — and the two agree: a twelve-PR stack awaiting its reviewer pass is complete work that the deployed system does not yet carry.

• The procurement/order module — a durable, server-side order with full history on the occurrence-log anatomy: Order and OrderLine subjects, the four stored states with two computed views (DEC-05), the SupplierBinding with freeze-at-submit (DEC-04), draft-only cancel (DEC-02), and order-side demand holds (DEC-01). See the Orders module reference.
• The receipt edge, both directions — received amounts accrue from demand’s production-delivery notifications, and revocations reverse them (DEC-03 as amended by F9b; after-close reversals refuse and alarm). A read-only-first self-heal probe re-drives missed receipts as the recovery floor.
• Transaction hardening — commit-side envelopes and the unique committed-successor fork guard across the five occurrence tables; refusals survive rollback as first-class rows.
• Demand station-validation — the tenant-validated station placeholder gate, cheapest-first in the guard order.
• Legacy retirement — the client-side PO sheet’s backend (procurement/orders) is removed; the UI’s operations surface was verified independent of it before removal.
• An API-test regime — the baseline suite plus a backward-compatibility category (ui-compat) derived from a 26-scenario UI→API survey, both riding the standing api-tests infrastructure.

How it was verified

Verification ran at three levels, evidence recorded on the Phase-2 umbrella ticket PDEV-1117:

1. Suite-level — the full stack gate green at its tip; every increment carries its own tests (unit, integration, api-test extensions) added in the same PR as the behavior.
2. Backward-compatibility campaign on real dev (2026-08-22/23) — snapshot of the dev databases, an authoritative 8.4.0 baseline capture (32/32), deploy of the Phase-2 feature build, equality 32/32 with every pinned response matched, a Playwright UI regression derived from the standing UI test catalog (10/10, including the full card lifecycle round-trip live), and a manual regression pass. dev was then restored to 8.4.0 with byte-verified snapshot data.
3. Model-side — the formal design record’s verification program runs against the same design the module implements (law probes in the code witness the model’s laws); the receiving-side exclusivity law family was additionally proven inductive, superseding its long-running solver soak.

Decisions as built

All five product decisions (DEC-01…05) shipped as recorded in Decisions, one with an amendment discovered during the build: DEC-03/F9b — received quantity is financially binding at close, so delivery revocations post a compensating decrement and post-close reversals refuse and alarm. The Atlas maps every decision to the increments that implement it.

Open at hand-off

• Review and merge — the stack merges bottom-up once review completes; the reconstituted transaction-hardening PR and both Phase-3 increments ride behind it as drafts.
• The frontend track — the Phase-2 UI increments (order queue, composition, PO-sheet retirement) are queued and unblocked by backend completion.
• Phase 3 — the kanban lifecycle cutover onto the same anatomy; its two backend increments are built and audited as drafts, and its project documentation follows this consolidation.

Traceability

• Map of tickets, PRs, and decisions: Atlas.
• Verification evidence and the campaign verdict: PDEV-1117.
• The design anatomy this module instantiates: Domain Design Overview.