ADR 033 Strict Sequential Actor Workflow Acceptance

Context

The migration has many valid domain contracts, adapters, routes, tests, and screenshots. They do not form one ordered acceptance standard. Existing pages mix a 13-stage actor chain, a separate A-to-Z booking list, mock UI evidence, actual read evidence, runtime failures, and backend-only settlement output. This made it possible to improve a later surface while the first actor workflow remained unproved.

The required product journey is ordered: headquarters creates a branch, the branch manager owns its profile, a mother joins and books, the branch handles the booking and assigns a caregiver, payment and care delivery occur, both actors use schedules and daily reports, then caregiver, branch, and headquarters settlements close. Each transition depends on authority and facts created by the prior transition.

Decision

workflow/sanmopia_actor_chain.v1.yaml is the acceptance SSOT for full legacy migration. Starlight renders the same phase ids and acceptance case ids. A validator fails documentation checks when order, source anchors, cases, verification state, or page references drift.

Every phase declares:

• actor, preconditions, command, query, state before and after, and authoritative outputs;
• exact legacy PHP or JavaScript source anchors and known legacy defects;
• target DDD context and feature, public contract, backend command/query, and actor UI;
• happy path, authorization, validation, revision/conflict, exact replay, and cleanup cases;
• required API, primary-state, desktop, mobile, animated WebP, documentation, repository-revision, privacy, and cleanup evidence.

Progress is strict and sequential:

documented -> RED -> implementation -> automated tests -> isolated actual actor
-> state/replay proof -> desktop/mobile/WebP -> docs/ADR -> PASS -> next phase RED

Only one phase may be red. Every earlier phase must be pass; every later phase must be blocked. Code reconnaissance and preservation are allowed in a blocked phase. Product mutation, success evidence, or a completion claim is not. A later partial implementation may remain in the repositories, but it is not migration acceptance evidence until its phase becomes current and passes.

Phase acceptance stops at the transition owned by that phase. A producing phase must prove its actual actor mutation, persisted replay-safe handoff, and immutable downstream lineage contracts. It must not require actual commands or actor evidence from a blocked consumer phase. The consumer proves that execution when its own phase becomes current. For P04 this means actual legal confirmation and booking handoff are required; P05-P13 booking handling, assignment, payment, service, attendance, report/document, payout, and settlement execution are not P04 gates.

PASS Rule

A phase may become pass only when all required cases have executable contract, backend, and frontend test references; an isolated actual actor run proves the same state transition; exact replay creates no duplicate; conflicting replay fails without mutation; unauthorized actors are rejected; cleanup succeeds; and redacted desktop, mobile, and real-transition animated WebP evidence is registered in Starlight with four-repository revisions.

When the transition emits a handoff, PASS also requires the handoff and its downstream lineage to be persisted, immutable, replay-safe, and cleanup-proved. It does not require the blocked consumer phase to execute that handoff.

Read-only 200, an empty projection, a screenshot, a mocked route, a unit test, or a backend driver alone cannot satisfy the rule. Failure evidence remains valuable but keeps the phase red.

Architecture Boundary

The manifest describes acceptance; it owns no product behavior. Product code remains Layer-first DDD with Context then Feature Slice. CQRS appears only inside a feature when needed. Dependency direction stays domain <- application <- adapters/interfaces <- orchestration. Each phase test names the owning feature and cannot authorize sibling-feature deep imports.

Supabase remains primary persistence, SpiceDB remains relationship authorization, and Restate remains durable workflow execution where already selected. JavaScript uses pnpm; Python uses uv. Image builds, when explicitly requested, use the FractalOps remote Buildx path under ADR-023. This decision does not authorize online deployment.

Consequences

Work slows at the current first gap and accelerates afterward: no ambiguous parallel completion claims, no reused mock visuals, no stale narrative-only checklist, and no settlement success detached from onboarding and booking. Existing useful work is preserved, then verified in order.

implementation: implemented means only that the manifest validator, rendered page, and sequential gate are committed and actively gate the workspace. It does not mean the migration is complete. P01 and P02 are pass; P03 is the single red phase with partial new/no-history evidence; P04-P13 remain blocked. Full migration completion still requires every manifest phase to be pass with all required evidence.

Revision History

• 2026-07-15: accepted after actor runtime work exposed that implementation and evidence existed without one ordered pass/fail authority.
• 2026-07-16: implementation status moved to implemented after the canonical manifest, validator, rendered Starlight page, and P01 executable RED scaffold were all committed. This closes only the governance mechanism; migration completion and every phase PASS remain governed separately by the manifest.
• 2026-07-16: P01 moved to pass after one clean four-repository revision set proved all six cases with an actual HQ actor, two cross-HQ authority races, exact replay, primary-state and cleanup invariants, redacted desktop/mobile screenshots, and a real-transition animated WebP. P02 became the single red phase; this does not authorize P03-P13 work or claim full migration completion.
• 2026-07-17: P02 moved to pass after its canonical actual actor/browser evidence pack closed all six cases. P03 became the single red phase. A fresh no-history P03 actor run and actual withdrawal browser are partial evidence only; missing runtime-resource cleanup, immutable composition, integrated six-case coverage, and historical-account privacy gaps prevent PASS. Synthetic UI WebP remains a separate class.
• 2026-07-17: final P03 actor network replay, clean four-repository pins, and wrapper teardown closed the runtime-resource and composition-pin gaps. Integrated six-case coverage and historical-account privacy gaps still keep P03 RED/partial.
• 2026-07-19: phase ownership was made explicit after the P04 checklist incorrectly required actual P07/P08/P10/P11-P13 execution. Producer PASS now ends at the actual transition, persisted replay-safe handoff, and immutable downstream lineage; blocked consumers prove execution only in their own phase.