Twelve issues to get the ball rolling

The outbox table is written but nothing consumes it: the dispatch hook is commented out, the unpublished-rows index has no reader, and published_at is never set. Add a relay (poller via @nestjs/schedule — not currently a dependency) that reads unpublished rows in insertion order, dispatches to subscribers, and marks rows published only when all downstream effects succeed.

• Idempotent retries keyed on event_id; multiple independent subscribers.
• First background process in the API — factor it so tests can drive one tick.

Only contract.created is emitted today. Product add/remove and status transitions have TODO markers where events belong, and a ContractUpdatedEvent class exists but is never used. Emit typed events (product_added, product_removed, status_changed, pricing changes) with payloads carrying enough delta for subscription sync.

Provisioning-on-activation landed, but it's a synchronous inline call with no retry (failures are only logged), and nothing syncs changes after activation — product or pricing changes, suspend, terminate. Move projection onto the relay: consume contract.* events, create/update/cancel the OM subscription, retry on failure.

OM cuts the usage invoice at cycle close; nothing in Commerce hears about it. Add the OM webhook handler (only the MT handler exists; wire OPENMETER_WEBHOOK_SECRET) and implement the billing_status state machine — pending → active → past_due → collections → closed — which today is an inert free-form string. On paid, hand off to settlement kickoff.

The invoices module (create/finalize/void, line items, status sync) has no reference to contracts and no connection to OpenMeter. Add the contract linkage, and generate the customer-facing MT e-invoice (detail + payment page) from the OM invoice at cycle close — the bridge between "usage was billed" and "customer can pay".

Email on invoice issued / due / overdue using the landed email module; escalate overdue invoices (drives billing_status → past_due / collections). Scope per the project description's "Dunning/Overdue Invoice Handling".

The committed balance is the risk mechanism for untrusted buyers, and the project description names all three balance types — but the COMMITTED / COMMITTED_DOWNPAYMENT accounts are write-dead: provisioned, read in balance queries, never posted to. Every ledger recipe touches only AVAILABLE, and the disbursement journey drains AVAILABLE directly.

• Add the commit recipe (earmark on contract commitment).
• Release from COMMITTED, not AVAILABLE, in the settlement journey.

Seller funds should sit in Pay-In Holding for a seasoning period before becoming spendable; today the release fires immediately (notBefore: new Date(), marked "follow up" in the code). The delayed-release machinery already honors notBefore — only the delay value is stubbed. Decide the source of the delay (per-contract term vs. config) and set it. Small, high correctness value; first brick of the project's "payout engine" (frequency / risk controls).

Payout creation (wire/ACH payment order) works standalone but isn't stitched into the disbursement journey after holding release. Add the cash-out leg or trigger, including the design decision the project owns: automatic on release vs. seller-initiated ("how often / how you get paid out").

RTP, wire, and stablecoin pay-ins are pushed by the buyer — we can't originate them. Build the Expected Payment flow: create the EP, reconcile the inbound MT transaction, credit the party's AVAILABLE on arrival (today's recipes only cover originated ACH), and expose account details so a customer knows where to push. Overdue EPs (expected_payment.overdue) surface for manual review.

Two places in the code literally say "no reconciliation pipeline yet" — ACH returns / failed POs and settlement-leg anomalies currently only alert Sentry. A v0: automated retry with backoff where safe, a manual-review queue for the rest. Grows with the funds flows; worth an early skeleton so anomalies have somewhere to land.

Scripted journeys already cover onboard→fund and settle→payout. Grow this into the e2e proof of the flagship flow — fund → commit → settle → season → cash out — asserting ledger balances at every step, plus failure paths (ACH return, failed payout) and idempotency checks. Each issue above gets a journey as it lands; this is also how the "everyone actually uses the thing" goal gets teeth.