ADR 030 Branch Onboarding and Own-profile Authority

Context

The legacy branch administration flow creates or updates BRANCH_TB, checks active login-id duplication, and writes membership-fee history. Its detail-read controller replaces a branch user’s requested index with the authenticated session branch, but the submit controller trusts the caller-supplied URL index without an equivalent HQ-role or own-branch binding.

P01 branch onboarding is complete at assembly daec45376021c9df3fb7821c745e21766b32eae8, contract e4534e41c0cd9b06d6193e8850088469f798d162, backend f75548e76866ea10bf36c0f34824262850d0f8aa, and frontend e429d59d31eadc046a2e1920ad29dc088fe15dba. One clean four-repository revision set across isolated actor and browser runs proves the actual HQ actor, Supabase primary state, SpiceDB authority, provider completion, exact replay, typed serial and cross-HQ conflicts, cleanup, and redaction-reviewed desktop/mobile/animated WebP evidence. No online deployment occurred.

P02 remains RED. The authenticated invitation activation and own-profile interfaces must resolve the actor’s branch on the server, wait for authorization relationship delivery, and prove allowed mutation, forbidden cross-branch and HQ-only mutation, stale revision, conflicting replay, exact replay, cleanup, and browser evidence. The existing generic profile mutation still accepts a caller-selected profile id and therefore is not the own-profile authority. ADR implementation remains partial even though P01 is PASS.

The 2026-07-13 actor-chain audit stopped at step 1, branch add. At that time, an update command that could upsert an empty profile was not evidence of branch onboarding.

Decision

Create two branch-operations feature outcomes.

HQ branch onboarding command

branch_operations / branch_onboarding owns a contract-first HQ command. One idempotent orchestration outcome must:

validate the branch code, legal/display identity, business registration, contact and address facts;
reject an active duplicate operator login identifier without exposing whether an unrelated customer identity exists;
create the branch office profile in onboarding state;
create or attach the Supabase operator identity through a dedicated identity provisioning port;
create branch membership and the required parent_hq, hq_admin, and branch_operator SpiceDB relationships;
publish the initial membership-fee policy separately from editable profile facts; and
record command id, actor, reason, revision, and every external side effect so exact replay returns the prior outcome and partial failure is repairable.

The domain feature owns onboarding invariants and vocabulary. Application owns the use case and consumer ports. Adapters implement Supabase and SpiceDB writes. Interfaces authenticate an HQ administrator and validate the public contract. Orchestration composes the multi-system outcome. No adapter or interface imports another adapter or performs business composition.

Durable effect progression

Each provider result is recorded through the exact actor, HQ, idempotency key, command, and branch scope. The store compare-and-swaps both the command state revision and the selected journal effect in one transaction, then returns a snapshot assembled from that committed state. Allowed success transitions are only pending to completed, pending to retrying, retrying to retrying, and retrying to completed. Completed requires a reference and no failure; retrying requires a failure and may preserve a provider reference; a known reference cannot be rewritten.

Before initial finalize, accepted and current result payloads remain jointly null. The latest durable envelope still exposes the current command revision and journal facts, but it is not a non-null currentResultSnapshot. Initial accepted/current persistence, post-acceptance repair, scoped query, and cleanup are separate sequential gates; DB10 through DB13 are now GREEN while provider and actual-actor cleanup remain outside this persistence result.

Post-acceptance durable repair

DB11 reuses the existing sanmopia_record_branch_onboarding_side_effect_transition(..., transition, current) boundary; it does not add a second repair RPC. A repair-pending accepted command may advance exactly one selected journal effect and the full current result in the same transaction. The command row is locked first, then exact five-part execution scope, state revision, effect status/reference CAS, strict public result shape, accepted lineage, and candidate journal/current parity are checked before any mutation.

The accepted payload, actor, HQ, idempotency key, command, branch, prepared identity claim, request/plan facts, audit, branch/office/organization facts, and the four unselected journal effects remain unchanged. Manager-membership completion may also insert the already-defined invited invitation authority row, but never an active membership; every other repair leaves invitation authority unchanged. Stored current always has idempotentReplay=false; it cannot expose manager membership active or invitation accepted, because those states belong to P02. While any effect remains unfinished, the current outcome stays repair_pending with one valid repair envelope and exact inspect_onboarding_repair. When all five effects are complete, current becomes completed, repair becomes null, and the exact P01 profile/configure/resend actions are returned.

The accepted repair envelope remains immutable. While current is repair-pending its repairId remains the same repair lineage; only canonical nullable nextRetryAt may be rescheduled by the coordinator. Strict current validation covers the same 29 Python whitespace characters plus U+FEFF blank boundary used by DB10. The criteria audit found that the provider-neutral _require_result_lineage accepted a changed current repair ID and generated TypeScript/Python missed the canonical JSON Schema’s sent-invitation cross-branch rule. Colocated REDs and minimal fixes closed both gaps before SQL production; the schema was not widened. Invitation delivery remains the final repair.

Malformed submitted current or lineage/candidate-journal mismatch is exact 22023 branch onboarding current result is invalid. Malformed stored current parity is exact XX000 branch onboarding stored current result is invalid. Repair against a completed accepted result is exact 0A000 branch onboarding transition requires repair-pending acceptance; only after that eligibility check, a repair-pending accepted command with null submitted current is exact 0A000 branch onboarding repair requires current result. Pre-acceptance transition with a non-null current remains exact 0A000 branch onboarding transition requires pre-acceptance state. Post-acceptance command and target-effect timestamps use clock_timestamp() and must strictly advance; unrelated timestamps remain byte-identical.

Repair transition delivery is CAS, not a second replay protocol. Repeating a consumed transition with the old revision remains exact 40001; competing valid repairs yield one winner and one exact CAS loser. P01 exact replay is instead proved by retrying the original accepted POST/finalize payload after repair: it returns the immutable repair-pending accepted snapshot with delivery replay true while repaired current, journal rows, revision, and every timestamp remain unchanged.

Scoped current-result read

DB12’s only new public SQL surface is public.sanmopia_get_current_branch_onboarding_result(text,text,text). Application first resolves the authenticated HQ actor, then supplies exact actor ID, HQ branch UUID text, and command ID. The stable SECURITY DEFINER function uses an empty search_path, is executable only by service_role, and returns at most one closed row: actor_id, headquarters_branch_id, command_id, result_payload. It never grants direct access to onboarding tables.

The mutable command row cannot authenticate its own accepted history. DB12 adds the private, FK-free private.sanmopia_branch_onboarding_accepted_results authority. First finalize inserts exactly one command/result receipt in the same transaction and under the same command lock as the accepted/current command update. The table is append-only by trigger, has no Data API table rights, and its assertion/snapshot helpers are not executable by public, anon, authenticated, or service_role. Inspect, start/replay, transition/repair, finalize/replay, and scoped GET all assert null-with-no-receipt before acceptance or byte-equal command/receipt after acceptance before returning or mutating. Missing or divergent history is exact SQLSTATE XX000 branch onboarding accepted result authority is invalid; transition and GET preserve their public fail-closed branch onboarding stored current result is invalid mapping.

Invalid or non-canonical inputs fail with exact SQLSTATE 22023 and branch onboarding result query input is invalid. Missing command, wrong actor, wrong HQ, wrong command ID, and a pre-acceptance command with null current all return the same zero-row result. A match returns current_result_payload, never the immutable accepted POST snapshot. After DB11 repair this means completed current can be returned while the accepted payload remains repair-pending.

Before returning, the function fails closed with exact SQLSTATE XX000 and branch onboarding stored current result is invalid when stored current provenance is not trustworthy: accepted/current must be objects, current replay must be JSON boolean false, row and payload actor/command/branch/fingerprint scope must match, immutable accepted lineage must match, and current sideEffects must equal the canonical five-row journal projection. Full public-contract shape remains revalidated by the existing Layer-first Supabase adapter. The read performs no row lock, insert, update, delete, revision advance, timestamp change, invitation change, or audit append.

Authenticated own-profile query

branch_operations / office_profile exposes an authenticated query whose URL and body contain no authoritative branch id. The server resolves the operator’s active branch membership, checks branch:view, reads the profile, and returns only operator-visible fields and the current revision needed for a later update.

An optional operator-supplied branch id can be a navigation hint for HQ screens, but it is never the scope authority for the own-profile route. A branch operator with zero or multiple active operator memberships fails closed with an audited conflict instead of selecting the first row.

Invitation activation and authorization delivery

P02 starts by activating the P01 invitation through the dedicated branch_operations / branch_manager_invitation_activation feature. branch_manager is retained only as the legacy feature/contract alias; the canonical actor is branch_operator. The command receives no caller-authoritative branch or actor id. It binds the Supabase subject to the invited identity, invitation, expected onboarding revision, and idempotency key, then advances only that invitation and membership.

Activation persistence and external authorization delivery are distinct facts. A successful activation response reports authorizationRelationshipStatus: pending until the queued relationship has been delivered and verified against SpiceDB. The own-profile GET and PATCH fail closed while delivery is pending or failed. A P01-created relationship cannot by itself authorize the invited user before activation; the runtime must close or harden any generic mutation path that could bypass this sequence.

Exact activation replay returns the accepted result without another membership or queue message. A same-key different payload is a typed conflict. Cleanup may delete only explicitly test-owned activation resources after their TTL. It must not delete an existing member profile merely because a test invitation referenced it.

Self-scoped own-profile command

branch_operations / office_profile exposes PATCH /branch/profile. The URL and body contain no authoritative branch profile id or actor id. The server repeats the same session-to-member, exactly-one-active-membership, branch scope, and SpiceDB permission checks used by the own-profile query before every write.

The first P02 command changes only operator-editable display, contact, and structured address facts: display name, contact email, primary phone number, postal code, road address, detail address, and audit reason. It requires Idempotency-Key and expectedRevision. Branch code, legal/business identity, lifecycle, credential, membership, membership fee, raw or purpose-scoped settlement account, and service-area policy are forbidden here and remain separate owned commands.

An applied write returns the full profile projection, new revision, completeness, and exact allowedNextActions. Exact replay returns the same full projection with idempotentReplay: true and no extra revision or audit. Same-key different payload is a typed conflicting replay. Stale revision is typed 409 with latestProjection and a field-level diff. Invalid or forbidden fields are closed typed 422 errors. Every rejection leaves profile and audit counts unchanged.

Boundaries

Contract repository owns public OpenAPI, schemas, and generated clients.
Backend owns domain, application ports, persistence, authorization, and orchestration.
Frontend owns HQ onboarding and branch own-profile screens only after generated clients are available.
Assembly owns stage identity fixtures, four-repository pins, cleanup, browser scenarios, WebP evidence, and this decision lineage.
Backend placement is Layer-first: each layer contains branch_operations/features/<feature>. CQRS folders exist only below the owning application feature when its actual read/write shapes require them; no global commands/queries hierarchy and no direct feature-to-feature internal imports are allowed.
The generic caller-scoped POST /branch-office-profile-updates cannot remain as an activation bypass. It must delegate to the same public own-profile authority or be closed before P02 acceptance.
Raw passwords, access/refresh tokens, unmasked bank accounts, resident identity, and private topology never enter evidence assets or manifests.

Required Evidence

Acceptance does not mean implementation. implementation can advance only after:

HQ authenticated create succeeds from a clean four-repository revision set;
exact command replay returns the same branch and operator outcome;
duplicate login, forbidden actor, stale revision, and partial-side-effect repair paths pass;
the new operator authenticates and the own-profile query returns only that branch without a client-supplied authority id, but only after invitation activation and authorization relationship delivery are both verified;
the operator updates an allowed fact while cross-branch and HQ-only fields remain forbidden; exact replay, same-key conflicting replay, stale revision 409 with latest projection/diff, and closed validation 422 all prove zero rejected mutation;
stage cleanup removes the test Auth profile, operational command/journal/invitation/fee/ office/core-branch rows, membership, and SpiceDB relationships, preserves the public audit plus private accepted-result receipt as the exact retained evidence pair, and verifies zero operational search remainder without treating those two evidence authorities as residue; and
redaction-reviewed desktop/mobile screenshots and a real-transition animated WebP, procedure, hashes, isolated runtime artifact digests, and four immutable repository pins are registered in the canonical visual-evidence registry.

Known Gaps

invitation-activation-delivery: activation may report the queued authorization relationship as pending, but the actual actor path has not yet proved delivery and SpiceDB verification before profile access.
actor-own-branch-resolution: P02 still lacks complete authenticated own-profile actor resolution and six-case actual acceptance. P01 evidence cannot authorize a branch operator’s profile read or mutation.
branch-own-profile-write: the existing generic mutation accepts caller-selected profile scope. Self-scoped atomic CAS/idempotency, typed conflict diff, and closed HQ-only-field rejection remain unproved.
p02-privacy-reaper: retained activation audit still needs a UUID retention or pseudonym policy, and cleanup must prove that test-created identity/profile resources are distinguished from pre-existing profiles.
Actual desktop, mobile, animated WebP, privacy review, cleanup manifest, primary-state manifest, and four-repository P02 pins are pending. No P01 screenshot or run can be reused as P02 evidence.

Consequences

This decision prevents the legacy controller pattern from leaking a caller-owned branch index into modern authorization. It also makes branch creation a named, repairable business outcome instead of an accidental first profile update, and keeps activation delivery distinct from profile mutation authority.

P01 now proves its implementation. P02 remains unproved, so this combined decision stays partial. Safe repository-local Layer-first refactors continue under ADR-029.

Revision History

2026-07-13: proposed from legacy branch add/own-branch mining and the 13-stage actor-chain audit. No implementation authority granted.
2026-07-13: accepted by the workspace owner. Implementation remains not-started until the required cross-repository and stage evidence exists.
2026-07-15: P01 public contract, strict schemas, generated TypeScript client, installable generated Python binding, structured conflict/validation responses, idempotency header, canonical command fingerprint, complete/repair side-effect journal, exact next actions, and six-case plus repair-semantics contract gate completed at contract revision 0e0176db692508f5c88bae0fbc8b32b121eca3bb. Independent counterexample review, Ajv 2020-12 fixtures, Python P01 strict model tests and wheel import, schema meta-validation, and OpenAPI 3.1 validation pass. Backend, frontend, actual actor, cleanup, and visual evidence remain RED, so implementation is only partial.
2026-07-15: backend domain RED tests fixed branch code, initial fee policy, canonical parent_hq/hq_admin/branch_operator vocabulary, typed validation metadata, direct-construction protection, and contract-parity counterexamples. Backend revision 20aae2afd537c39ea0d9f6a76461909041dd6508 passes 57 focused tests, 118 branch-operations domain tests, Ruff, compile, Tach exact/external checks, Vulture confidence 100, and independent re-review. This advances only the domain slice; application and all execution evidence remain RED.
2026-07-15: application acceptance was committed RED at backend revision 61a8cf55030414983ba20f3dad953aee98c74f6b. Three expected missing-module collection errors now pin immutable accepted POST snapshot versus mutable repair projection, server-resolved actor/HQ scope, pre-normalization JCS fingerprint, typed conflict, exact replay, and cleanup inventory criteria. This is a test baseline, not application implementation evidence.
2026-07-15: cleanup inventory counterexamples reopened the contract gate because aggregate operator identity, manager membership, and membership-fee policy ids could differ from their completed side-effect references. TypeScript and Python RED tests now bind all three resources, and resource-parity contract revision 626ad9cb3a6eb75065a0216193c2692aaba9424c passes 431 TypeScript and 35 Python tests.
2026-07-15: backend revision b4eccee8e9847bc91ed72f605eb1aa4dc24f0652 makes the application command/query boundary GREEN after authority-scope, model-copy, typed-error, replay, and whitespace-token counterexamples. The focused application suite passes 51 tests and branch application/domain regression passes 203 tests with Ruff, compile, uv lock, Tach exact/external, and Vulture gates. P01 remains RED until adapters, interfaces, orchestration, frontend, actual actor, primary-state, cleanup, and visual evidence pass.
2026-07-15: a second independent audit rejected provider names and assembly-owned test cleanup procedure from the P01 public operation, and rejected noncanonical or overlong query ids before reader access. Final contract revision 918d797c578df43edc6697a85ab3016409bb75ee uses a generic bearer boundary and keeps cleanup procedure in the actor workflow SSOT. Final application revision 8ac9ed9ca937e1521f984aa7de66bd7c3e64855b passes 57 focused tests and 209 branch application/domain tests. OpenAPI 3.1, full contract, Ruff, compile, uv lock, Tach, and Vulture gates pass; runtime evidence remains RED.
2026-07-15: HQ authority adapter acceptance was committed RED before production. Follow-up counterexamples closed malformed authenticated subjects, malformed Supabase result containers/rows, inherited child-branch HQ permission, and missing root-parent projection fields as typed fail-closed outcomes. Backend revision c4a19418109dd34ce1ba6364c8d1b4040bef9bb7 requires one server-owned HQ profile, one matching HQ membership, explicit root branch identity, and SpiceDB administer_headquarters; 20 focused and 278 branch regression tests pass with Tach exact and Vulture gates. This advances only the authority resolver; P01 remains RED.
2026-07-15: current-result adapter acceptance was committed RED before production. A follow-up counterexample bound actor, HQ root, and command id to both the RPC request and exact response envelope. Backend revision 78781cff20216ebd13a0918be1319e72143b94dc passes 18 focused and 296 branch regression tests with Tach exact, Vulture, and independent P1/P2 re-review. The backing Supabase RPC and persistence remain RED, so P01 remains RED.
2026-07-15: the durable execution port was repeatedly reopened by independent counterexamples before production. The final backend revision 8cf3ffaf9d6e9d184305e198a0c78dbf1713dbce separates invitation namespace claim from identity provisioning, binds the claim to claim id, HQ, idempotency key, command fingerprint, normalized invitation email and created|attached ownership, requires exact returned scope, freezes accepted identity ownership, atomically pairs repair journal/current inputs, preserves real retry references, and rejects P02 active|accepted manager state in P01 snapshots. Focused durable tests pass 55, P01 application tests pass 112, and branch domain/application/adapter regression passes 323, with Ruff, compile, uv lock, Tach exact/interface/external zero diagnostics, and independent P1/P2 re-review. Vulture confidence-100 reports only five required Protocol parameters, verified as false-positive interface declarations. Supabase RPC transactions, claim uniqueness, invitation-only membership storage, Restate compensation, and actor evidence remain RED.
2026-07-15: DB01 ACL and DB02 atomic start are GREEN at backend revision b9e617bed95243073d1b32bb640be6f6f43dd33c. A fresh isolated Supabase replay and catalog lint verify five internal authority tables, service-role-only security-definer RPCs with empty search paths, root-HQ revision initialization, canonical UUID locking, organization CAS, HQ-scoped command identity, one office revision, one append-only audit, and exactly five pending effects. A named duplicate-command constraint is raised after core/office/revision writes and the smoke proves all preceding rows and organization revision roll back. Shared branch/office/fee tables retain existing service_role CRUD because other approved backend features use them; service_role is a trusted backend credential, never an actor credential. P01 public mutation must use the atomic RPC, while the five P01-internal tables remain direct-CRUD closed. Global RPC-only conversion of shared tables requires a separate platform migration of every consumer. DB03 invitation-only transition and every later actor/effect gate remain RED, so P01 remains RED.
2026-07-15: DB03 invitation-only acceptance is pinned RED before production at backend revision d93f7f1b183228ac3e0db599e696c5ea39212c24. The real Supabase gate now requires one service-role-only atomic transition RPC to move only the manager membership effect from pending to completed, advance durable revision, derive one invited row from stored command facts, and leave active membership absent. A duplicate invitation reference must roll the second command back to revision one with a pending journal. The first expected failure is the missing transition RPC; DB08 general CAS and repair semantics remain separate later gates.
2026-07-15: DB03 invitation-only transition and sequential DB04 exact replay are GREEN at backend revision f558b542c39ba8556991cbd8cd19cb4e68d48f1e. The RPC accepts the provider-neutral scope/transition envelope but currently enables only pre-acceptance manager invitation completion; every other effect and non-null current projection fails closed until its own gate. Journal and command revision update before invitation insert so duplicate reference proves transaction rollback. Independent counterexamples closed SQL-null expected-status CAS bypass with required values plus IS DISTINCT FROM, and closed alternate UUID spellings with canonical round-trip checks. Active membership remains absent. Replay returns the latest revision-two snapshot without duplicating any row. DB05 and later persistence, provider, interface, orchestration, UI, and actor evidence remain RED.
2026-07-15: DB05 pre-production gate is pinned RED at backend revision 97562ffea2e83308cb1e6a36097cb72ad433c5c8. Same-HQ/key actor, request, fingerprint, command, and claim mutation cases require the exact idempotency-scope conflict and zero growth across ten business-row categories. Five valid mutations reject correctly, but a claim with omitted identityId currently replays because nullable UUID <> comparison evaluates to SQL null. Production remains unchanged until that counterexample and the full matrix pass atomically.
2026-07-15: DB05 is GREEN at backend production revision a172a8628159fd24b1e6e25522cbdc49dc666849, after the hardened test revision e3dc427946eee398bac673c00dcd3db8848278bc first exposed omitted claim-binding replay. Existing-key checks bind raw claim HQ/key/fingerprint/identity and canonical UUID text to stored facts with null-safe comparisons. Every mismatch preserves ten row counts, the exact latest snapshot, and HQ revision. A fresh missing-identity start fails before its first business write. Fresh Supabase replay, catalog lint, fixture rollback, 207 colocated tests, and two independent blocker-zero audits pass. DB06 claim/identity namespace ownership and all later gates remain RED.
2026-07-15: DB06 is pinned RED before production at backend revision 4a66363d12d844d17a8cb51f3c0ca6c14c390beb. Existing claim_id ownership rejects, but a fresh claim can currently rebind the stored operator identity to another email and disposition. The two namespace aliases, identity ID and normalized invitation email, require individual global uniqueness; a composite pair is insufficient. GREEN requires exact ownership conflicts, no mutation of either owner snapshot or HQ revision, named unique backstops, fixed-order namespace locks, and an actual different-HQ concurrent race with one winner and no partial loser rows. DB07 business conflicts remain separate.
2026-07-15: DB06 is GREEN at production revision f0c60e9878b82bc21d6203c3f63f2a4a71e393ad. Operator identity ID and normalized invitation email have individually named global unique constraints. Fresh requests take claim, identity, then email advisory locks and reject owned namespaces before the first durable write. The serial matrix preserves ten scoped counts, two owner snapshots, two HQ revisions, and candidate absence on exact 22023 conflicts. Test revision 418678accf1cc7aa995c9f22d87e902253aa0e5f closes an adversarial false-GREEN in the initial race harness by requiring both independent backend sessions to commit readiness and wait behind a controller barrier before release. Separate identity and email races each produce one winner, one exact loser, and zero candidate-scoped loser state, including zero invitation, active membership, and fee rows. Fresh replay, catalog lint, serial rollback, disposable-container teardown, 207 colocated tests, and blocker-zero re-review pass. This does not prove DB07 business conflicts, later effect/finalize/repair/query/cleanup gates, provider execution, interfaces, orchestration, UI, or actor evidence; implementation remains partial and P01 remains RED.
2026-07-15: DB07 acceptance is pinned before its executable RED and before any production change. Three independent fresh commands must reject stale organization revision, duplicate global branch code, and duplicate global jurisdiction plus registration number with exact typed 22023 conflicts. Every rejection must preserve both existing branch snapshots, both HQ revisions, and ten authority row counts, with no candidate branch or command. Existing sanmopia_branch_profiles_branch_code_key and sanmopia_branch_office_profiles_business_identity_idx remain the final uniqueness authorities; this decision does not create duplicate constraints. The fixture’s final rollback is not DB13 cleanup evidence, and DB08, provider, interface, UI, and actor evidence remain unopened. Implementation stays partial and P01 stays RED.
2026-07-15: DB07 executable acceptance is RED at backend revision b87e526a7c34828f179c1f48b3182b526d5bbfe5, after criteria revision assembly 361de79e536e70d7e7b688ffe2bcfa2c2e44d9b9. Fresh Supabase replay and catalog lint pass; the stale-revision case returns its exact 22023, then duplicate branch code returns raw 23505 from sanmopia_branch_profiles_branch_code_key instead of the required typed conflict. The test also freezes ten counts, both stored onboarding snapshots, both live branch/office/revision snapshots, both HQ revisions, and candidate absence. The later duplicate-business-identity case has no GREEN evidence because the sequential gate stops at the first product failure. Production is unchanged, implementation stays partial, and DB08 remains unopened.
2026-07-15: an independent adversarial review reopened the DB07 criteria before production. Serial prechecks alone can pass while a different-HQ concurrent duplicate still loses at the unique backstop with raw 23505. DB07 therefore also requires separate branch-code and business-identity races using two proven PostgreSQL backend sessions held behind a readiness barrier. Each race must yield one winner, one exact typed 22023 loser, and zero candidate-scoped loser state. The fixed lock order is claim, identity, normalized email, branch code, then business identity; existing UNIQUE objects remain the final backstop. No production change may precede this race RED. Implementation remains partial.
2026-07-15: DB07 race acceptance is RED at backend revision 6eb6d5e17d32a99acdbdb6240b01a60d5c59ed94 under criteria revision assembly 8476fea9253d18522867e041895afa472ebb577c. Two distinct stored/result backend sessions committed readiness and were released only after ready=2. The branch-code race produced one winner and one raw 23505 loser from the existing branch-code constraint, proving the concurrent typed-conflict gap. The sequential gate stopped before the business-identity race, so no GREEN claim exists for it. The disposable DB was removed; production and DB08 remain RED.
2026-07-15: DB07 is GREEN at final race-proof revision db2a9058edcdd51487f93554fc92bcbda281d04f and production revision e540107db0c1cb75244f91b68b836d1b60d5a3c3. New commands take claim, identity, normalized-email, branch-code, then business-identity locks in that fixed order. Stale organization revision keeps priority. Exact prechecks reject owned branch code and business identity before durable branch writes. The existing branch-code constraint and business-identity partial unique index remain final authorities; only those two named 23505 backstops become the required 22023, while unknown unique violations remain raw. Branch and office inserts share an exception subtransaction, so an office-index loser cannot retain a partial branch.
2026-07-15: the final race harness closes the second false-GREEN counterexample. Two distinct workers must first appear as ungranted ShareLock waiters inside run_candidate. After that wrapper barrier opens, the controller still holds the exact production authority lock and requires both backend PIDs to appear as ungranted ExclusiveLock waiters on it before release. Identity, email, branch-code, and business-identity races all produce one winner, one exact typed loser, and zero loser partial state. The three serial DB07 conflicts preserve two command/live branch snapshots, two HQ revisions, ten authority counts, and candidate absence. Targeted and full fresh replay, lint, rollback, helper teardown, disposable-container absence, 207 colocated tests, Ruff, Tach, and blocker/high/medium/low-zero independent reviews pass. DB08 through DB13, providers, interfaces, orchestration, UI, and actual actor evidence remain RED; implementation stays partial and P01 remains RED.
2026-07-15: DB08 acceptance is pinned before executable RED and before production change. Starting from the first command after DB03 has completed manager membership at state revision two, the remaining identity, authorization, invitation-delivery, and fee-publication effects each move from pending to completed with an exact reference and no failure. The four successful calls advance command revision exactly 2 → 3 → 4 → 5 → 6; each returned snapshot must match the command and one journal row in the same transaction, ending with all five effects completed. Branch, office, HQ revision, audit, invitation, membership, and fee facts stay unchanged. A separate untouched command exercises the remaining valid success shapes: pending to retrying without a reference, retrying while acquiring the claim identity reference, retrying to completed with that same reference, and a different pending effect to retrying with a reference. Its revision advances exactly 1 → 2 → 3 → 4 → 5 and leaves one repairable effect. Accepted/current remain null before finalize. The two lineages prepare later completed and repair-pending outcomes without proving them. DB09 owns stale/rewrite/replay rejection, DB10 finalize, DB11 post-acceptance repair, DB12 scoped GET, and DB13 cleanup. Implementation remains partial and P01 remains RED.
2026-07-15: DB08 executable acceptance is RED at backend revision 5e42e8d58d5377481b39a48ec3933289f146a37a, after criteria revision assembly 034f6da42dadd2d994744bbee3279f6fb4fd68ca. Fresh tracked migration replay and Supabase catalog lint pass, then the first general transition, operator_identity_provisioning pending → completed, returns exact 0A000 with branch onboarding transition is outside the enabled DB03 boundary. The caught transition-call subtransaction leaves the private durable snapshot, complete command and journal rows, both HQ revisions, ten authority counts, branch/office/revision, audit, invitation, membership, and fee facts unchanged before the test re-raises P01-DB-EFFECT-CAS. The ordered eight-case progression also binds non-null identity references to the stored claim identity and uses null-safe comparisons. Independent test audits report no blocker or medium findings, the disposable DB is absent, and production remains unchanged. DB08 therefore remains RED; DB09 through DB13 and all provider/interface/orchestration/UI/actor evidence remain unopened.
2026-07-15: DB08 production candidate a1f26f7ba27afcb43c0914f74e6d8cf29a5ffbaf passed the original ordered eight-case matrix and the full fresh regression gate. This was candidate evidence, not the final GREEN decision.
2026-07-15: independent production audit found that manager-membership pending -> retrying accepted an arbitrary non-UUID reference. Because a known reference cannot later be rewritten and completion requires a canonical UUID, that accepted state is permanently unrecoverable.
2026-07-15: backend test revision b58ee8437cdb297ed8090f1e25c16d1146cc5ec6 pins the counterexample and reproduces P01-DB-EFFECT-CAS accepted poisoned manager retry reference against unchanged production candidate a1f26f7ba27afcb43c0914f74e6d8cf29a5ffbaf. DB08 is reopened as RED. Its final production revision, DB09 through DB13, providers, interfaces, orchestration, UI, and actual actor evidence remain absent; implementation stays partial and P01 remains RED.
2026-07-15: the same audit noted raw JSON non-string coercion and the difference between PostgreSQL space-only btrim and application strip() for tabs/newlines. The pinned sequential boundary assigns malformed-payload rejection to DB09, so these are recorded DB09 criteria inputs, not silently folded into the DB08 fix. They are not executable DB09 RED or GREEN evidence yet.
2026-07-15: DB08 is GREEN at backend production revision b63f8eb61e08dddd65bf8f80139c81931eade8ab. The one-line fix validates every non-null manager-membership reference as a canonical UUID before mutation; null retry references remain allowed, and invitation insertion remains completed-only. Two bounded independent audits report blocker/medium 0.
2026-07-15: the final fresh gate passes tracked Supabase replay, catalog lint error 0, DB01-08 SQL smoke and outer rollback. Identity, email, branch-code, and business-identity races each report winner=1 exact-loser=1 partial=0; helper schemas and the disposable container are absent afterward. The focused P01 suite reports 207 passed; Ruff check/format and Tach exact boundary/interface/external report zero diagnostics. Vulture confidence 100 reports only three Protocol signature parameters, verified as false positives and not deleted.
2026-07-15: this closes only DB08 persistence. DB09 malformed/stale/rewrite rejection through DB13 cleanup, provider effects, interfaces, orchestration, UI, screenshots/WebP, and actual actor evidence remain RED. ADR implementation stays partial and P01 remains RED.
2026-07-15: DB09 acceptance is pinned before executable SQL and before production change. It reuses the DB08 completed command at revision six and repairable command at revision five. Stale command revision has exact 40001 state conflict; stale effect status/reference has exact 40001 effect conflict; rewrite, completed regression, malformed JSON types, and noncanonical text have exact 22023 payload rejection; actor/HQ/key/command/branch scope mismatch has exact 22023 branch onboarding transition scope mismatch. Unknown string enums, pending/reference contradictions, completed reference/failure contradictions, and retrying without failure use the same exact payload rejection and no-change proof. An operator-identity reference different from the stored prepared claim has exact 22023 branch onboarding operator identity reference is invalid and the same whole-row immutability.
2026-07-15: an independent pre-production audit rejected representative-only malformed/canonical cases. DB09 therefore requires all six payload fields against number, boolean, object, and array (24 cases); expected/reference/failure against leading/trailing space, tab, and newline (18 cases); and all five execution-scope fields against the same whitespace/edge matrix (30 cases). Noncanonical scope is exact 22023 branch onboarding transition input is invalid. Test-only reference setup lives inside the rejection exception subtransaction so expectedReferenceId type coercion is independently observable and every setup/success path rolls back.
2026-07-15: every DB09 rejection freezes both private snapshots, every raw command/effect row, and all branch, office, office-revision, HQ-revision, invitation, membership, fee-policy, and audit rows/counts. Unexpected success is rolled back inside an exception subtransaction and then raised as the executable RED, so no later case inherits poisoned state. DB10 accepted/current finalize, DB11 repair, DB12 GET, and DB13 cleanup remain unopened.
2026-07-15: legacy evidence is OfficeManagement.php:399-449 -> Branch_model.php:202-287 and User_model.php:23-39. The PHP path inserts/updates the branch, separately writes a token and current-month fee, ignores both results, and returns true; browser office_detail.js:253-285 redirects or reloads on that boolean. It has no expected revision, idempotency key, durable resume, or manager-invitation call. DB09’s exact fail-closed behavior is an explicit improvement, not a claim that the legacy path already had invitation delivery.
2026-07-15: criteria amendment d051bf1cb82fc566f5050df83e60e624f6d7e49a precedes executable backend RED a14180ade1d71752bf77641650dde3541a7d7194. The 118-case ordered SQL passed fresh schema lint and DB01 through DB08, then current production b63f8eb61e08dddd65bf8f80139c81931eade8ab accepted numeric referenceId through ->> coercion and raised exact sentinel P01-DB-EFFECT-REJECT accepted non-string-reference. The success mutation was rolled back before exact whole-state comparison; the disposable database was removed. Two independent audits report blocker zero and medium zero. This pins DB09 RED only; production, DB10 through DB13, providers, UI, and P01 remain RED.
2026-07-15: a production-candidate audit found that the 18/30 whitespace submatrices covered only representative ASCII whitespace while application _require_canonical_text uses unrestricted Python 3.13 str.strip(). NBSP U+00A0 is a concrete mismatch. DB09 acceptance is therefore amended before any production commit to all 29 Python str.isspace() code points: 174 payload text cases and 290 execution-scope cases, for 534 total rejection cases with the 46 explicit and 24 JSON-type cases. The ASCII-only candidate remains uncommitted and RED until the expanded executable test proves the mismatch and a later candidate passes it without changing DB10 through DB13.
2026-07-15: Unicode criteria revision 568ae08c5e41ae530b4ae67bf9315ddfb881b396 precedes expanded backend RED f3cdf330ad9f44036f21894e0400365be3652153. Fresh schema lint and DB01 through DB08 pass before the ASCII-only candidate accepts a U+001C-leading expected reference and raises exact sentinel P01-DB-EFFECT-REJECT accepted canonical-expected-reference-u001c-leading. Fixture setup and mutation roll back before whole-state comparison; teardown leaves no disposable database. Both independent audits report blocker zero and medium zero. DB09 production and all later phases remain RED.
2026-07-15: DB09 is GREEN at backend production revision 243a674ed5ad4e456e0c8cb55ca50ed9127cbe96. The transition RPC validates all six raw JSON field types before text extraction, applies the exact Python 3.13 str.isspace() 29-code-point boundary to all five scope fields and three nullable payload text fields, and maps canonical cross-scope misses to the exact typed error without weakening command/effect locks, null-safe CAS, SECURITY DEFINER, empty search_path, or service-role-only execution.
2026-07-15: the final fresh tracked Supabase run reports public schema lint zero, DB01 through DB09 including all 534 DB09 cases, outer rollback, and all four authority races at winner=1 exact-loser=1 partial=0; no helper schema or disposable container remains. The same revision passes 207 colocated Python tests, Ruff check/format, and Tach exact dependency/interface/external with zero diagnostics. Tach confirms application depends on domain and adapters depend on application. Vulture confidence 100 reports only three verified Protocol signature false positives, so no deletion was made. Two independent final audits report blocker zero and medium zero.
2026-07-15: this closes only DB09 persistence. DB10 finalize through DB13 cleanup, provider effects, interfaces, orchestration, UI, actual actor execution, and screenshot/WebP evidence remain RED. No custom image was built and no online deployment or visual evidence collection occurred in this DB-only gate. ADR implementation remains partial and P01 remains RED.
2026-07-15: DB10 acceptance is pinned before executable SQL and production change. The legacy PHP success boolean ignores token and fee results and has no durable accepted/current result, revision CAS, or response-loss replay. Atomic initial accepted/current persistence is therefore an explicit modernization improvement, not a legacy behavior claim. DB10 remains a service-role persistence gate; actual HQ allow and branch-manager/mother/caregiver denial remain interface and actor gates.
2026-07-15: one finalize RPC owns exact five-part scope, expected command revision, and one strict result payload. The result is bound to all 25 closed top-level keys, five closed four-key side-effect objects, and nullable closed two-key repair object in contract revision 918d797c578df43edc6697a85ab3016409bb75ee at schemas/branch-operations/branch_onboarding_result.schema.json; missing, extra, raw-type, cardinality, enum, and outcome contradiction cases are generated from that immutable source. Completed revision six and repairable revision five lineages both finalize: accepted/current are written together to the same idempotentReplay=false payload and command revision advances once. The completed lineage becomes revision seven with null repair and exact profile/configure/resend actions; the repairable lineage becomes revision six with exact repair metadata and the singleton inspect action while its retrying/pending effects remain repairable.
2026-07-15: an already accepted exact payload is compared before revision CAS and returned unchanged with delivery-only replay true, so a lost first response can be retried with its original expected revision. Relationship, side-effect, and action arrays are set semantics: finalize normalizes them to one deterministic storage order before durable parity, accepted comparison, and storage, and order-only permutations replay without mutation. A semantically different accepted payload is an exact immutable-result rejection. Stale pre-acceptance revision, all five scope mismatches, malformed raw JSON, replay-bearing storage payload, durable command/plan/claim/audit/effect mismatch, P02 manager-state leakage, and outcome/ repair/action contradiction each require exact typed error plus whole-state and timestamp immutability.
2026-07-15: concurrent identical finalize calls must yield one first delivery and one exact replay with a single revision advance. Concurrent different valid repair payloads use the same durable lineage and differ only by pinned repair ID/time; repair metadata is coordinator-owned finalize input that the first writer freezes, not a DB09-derived authority. They must yield one accepted winner and one immutable loser with no partial drift. Each race owns a committed fixture independent of the smoke rollback, uses a committed target-row-lock readiness/release barrier, and runs in a dedicated cloned disposable database. The trap drops that database and verifies source baseline counts without bypassing append-only audit. DB10’s first executable RED must follow DB01 through DB09 and be exact P01-DB-FINALIZE missing finalize RPC. DB11 repair, DB12 GET, DB13 cleanup, providers, interfaces, UI, actual actors, screenshots, and WebP remain unopened.
2026-07-15: DB10 criteria revision 5ee6aa6b282ef92978edb7ef658e5140985514c7 and contract revision 918d797c578df43edc6697a85ab3016409bb75ee precede executable backend RED 56d87be190fa4897b80884eb382c369c5e1b6a7a. The test-only revision preserves the product migration blob at 5cf6c6a6002e365fb0280fdbe8c7631a7f91d702 and the DB09 SQL prefix SHA-256 at 6b25ce68293f595382962d93205c4c88a9a21c09cf2cc3ae90963317b2b25c06.
2026-07-15: the DB10 serial corpus contains an aggregate-ledger-checked 2,107 cases: 2,094 rejections, one valid nullable-repair case, two first writes, and ten exact or order-only replays. The fresh command passed public schema lint and DB01 through DB09 before stopping at exact ERROR: P01-DB-FINALIZE missing finalize RPC with exit code 3. These DB10 cases and the two finalize races did not run after the sentinel; no race outcome is claimed. A Supabase CLI migration-catalog Tokio warning did not stop reset, lint, or smoke and is not the product RED. Cleanup left zero containers and zero related /tmp artifacts.
2026-07-15: final independent serial/contract and race/harness audits report zero Blocker and zero Medium findings. This validates the RED harness, not production. DB10 production, DB11 through DB13, providers, interfaces, orchestration, UI, actual actors, screenshots, and animated WebP remain RED; implementation remains partial and no online deployment occurred.
2026-07-16: a final schema-hole audit found that PostgreSQL default btrim did not reject U+FEFF in 41 non-null result string paths. Backend RED a7cdbf6d951082530569dc9989903214d5f9a7c4 precedes production d40871109eb156c1f3ac53986f2ae310ddd4b3c9; the fix extends only result-schema whitespace and preserves the DB09 29-code-point execution-scope contract.
2026-07-16: DB10 persistence is GREEN. The final serial ledger is 2,148 cases: 2,135 rejections, one rollback-success, two first writes, and ten exact/order-only replays. Fresh schema lint, DB01 through DB10, outer rollback, same-payload first/replay race, different-payload winner/immutable-loser race, and the four prior authority races all pass with one revision advance and zero partial state. Source baseline, append-only audit, disposable clone, container, and temporary-file cleanup are exact.
2026-07-16: harness cleanup acknowledgment gaps were closed before the final GREEN run at a7b45a22d903f1b6669c1f996d6b2c06a561a9fe. Layer-first package markers for the branch-onboarding feature, commands, and queries were restored at 8a94ad7b6c77aac6e20eb6fed81d33d664558837. Branch-onboarding Python reports 207 passed; Tach reports zero dependency/interface/external diagnostics; focused Vulture reports only three verified Protocol parameter false positives. Clean backend HEAD reports 5,663 passed, 1 failed; the sole failure is a pre-DB10 global Supabase validator that still treats all auth.role() contexts alike and permits only one SECURITY DEFINER, so it remains a separate platform policy/parser gate rather than being weakened here.
2026-07-16: final independent contract and security/race audits both report zero Blocker and zero Medium. No custom image or online deployment was made; the three official Supabase test images were removed afterward. DB11 through DB13, providers, interfaces, orchestration, UI, actual actors, screenshots, and animated WebP remain RED. ADR implementation therefore remains partial and P01 remains RED.
2026-07-16: DB11 criteria are accepted before executable SQL and production change. The existing side-effect transition RPC is the sole persistence boundary for both pre-acceptance progression and post-acceptance repair; no repair-specific public RPC is added. DB10’s repairable revision-six accepted/current pair is the input. Four ordered repairs advance authorization, invited manager authority, fee publication, and finally invitation delivery to revision ten while accepted remains byte-identical. Invitation delivery is last because the public contract cannot represent sent invitation actions while another effect remains repair-pending. Each call atomically changes only one journal effect, current result, command revision, and allowed timestamps, except manager-membership completion also inserts exactly one invited invitation authority and never active membership. Strict result shape, stored and candidate journal parity, stable repair ID with reschedulable next retry time, accepted lineage, P01 manager-state boundary, stale/scope/rewrite rejection, rollback, and a two-session CAS race are required.
2026-07-16: the criteria audit proved the provider-neutral application snapshot still accepts a current repair ID different from accepted. DB11 therefore requires a colocated application counterexample and invariant fix after the first SQL RED is pinned but before SQL production is changed. Nullable nextRetryAt remains mutable.
2026-07-16: the same audit found generated-client drift from the canonical result schema: TypeScript and Python accept repair_pending with a completed/sent invitation and inspect-only action, while JSON Schema correctly rejects that state because sent requires the completed three-action set. Invitation delivery is therefore the final DB11 repair, and generated validators require RED-first parity fixes without widening the schema before persistence production changes.
2026-07-16: DB11 executable RED is pinned at backend 82568de35df5099c429b5261df33bba3befd9ab9 after criteria assembly 3b5baff5e114699438495d35f6bd4bb8149ec97c and baseline-guard amendment 1e67657245042d7a65fa992c81ced479b993a045. Product migration blob ac31182989298d47a8199e5b37a9522562414570 is unchanged. Fresh public schema lint and DB01-10 including all 2,148 DB10 serial cases pass before exact P01-DB-REPAIR complete-retrying-authorization returned 0A000 / branch onboarding transition requires pre-acceptance state. Whole durable state and timestamps remain byte-identical; two independent audits report Blocker zero and Medium zero. This is RED evidence only: contract/application parity fixes, DB11 production/full corpus/race, DB12-13, and all actor/UI evidence remain RED.
2026-07-16: generated-client parity RED 88a0688e68532cf14975b85b90947da351d00987 proves TypeScript returns no problem and Python accepts both sent and accepted delivered invitations while another effect remains unfinished. Product e16c642d39d879fe71b27d2edc52fb1ac281bf1f adds only the repair-pending rejection to both validators; artifact 1f56d28b31a0a5f16045e41bb4555e7eb20e3745 refreshes tracked TypeScript output. Canonical JSON Schema and OpenAPI remain unchanged. Focused tests, all 431 Jest tests, all 37 Python contract tests, layout, lint, TypeScript build, Vulture at 100% confidence, and independent Blocker/Medium-zero audit pass. Application stable-repair-ID remains RED.
2026-07-16: application lineage RED 5d3cc793671e9da547fb3449cffccc7821d559f3 proves a repair-pending current snapshot can replace accepted repairId; the same test pins timestamp and null nextRetryAt rescheduling as valid. Product 60053a89240bbf3a5d4ec7fdad97cd6ce635d2b0 adds one application-layer stable-repair-ID invariant and leaves completed current repair null. Exact and 58 focused tests, all 210 branch-onboarding tests, Ruff, Tach exact/interface/ external with zero diagnostics, and Vulture review pass. Its five 100%-confidence candidates are verified Protocol parameters, not deletion authority. SQL production remains RED.
2026-07-16: repair transition duplicates remain exact stale-state 40001; DB11 does not invent a replay flag on the snapshot-returning transition port. Exact replay is proved after repair by replaying the original DB10 accepted payload and receiving the immutable repair-pending accepted snapshot with delivery replay true and zero current, journal, revision, or timestamp mutation. The first executable RED must observe exact 0A000 branch onboarding transition requires pre-acceptance state from a valid post-acceptance authorization repair and raise exact sentinel P01-DB-REPAIR complete-retrying-authorization returned 0A000 / branch onboarding transition requires pre-acceptance state. DB12 scoped GET and DB13 cleanup remain unopened.
2026-07-16: DB11 race review classifies every sanmopia_branch_memberships row as active P02 authority. A row has no pending status, and direct service_role mutation can otherwise race the DB11 zero-membership invariant without sharing the onboarding command revision. No current production writer owns this table and P02 remains blocked. DB11 therefore revokes all direct table privileges from Data API roles and restores SELECT only to authenticated and service_role before SQL production is committed. This is a deliberate one-table authority boundary, not a blanket revoke for branch profiles, office profiles, or fee policies. P02 must later add a narrow SECURITY DEFINER activation RPC that locks onboarding command then invitation, checks expected onboarding revision and completed current/journal lineage, and atomically records membership, acceptance audit, and SpiceDB outbox. Direct membership DML remains revoked after P02 opens.
2026-07-16: DB11 SQL is GREEN. Test-only backend revisions a49915c, 793891d, c6f8128, 659942c, and 53ff351 precede product c23c5bb5e235e71432a611510d3ce9a785b567d6; accepted membership authority amendment c2d8d70 also precedes product. Supabase CLI reset and public-schema lint zero passed DB10 2,148 plus DB11 1,571, for 3,719 serial cases and outer rollback. The real two-session repair race produced one winner, one exact 40001 CAS loser, revision 6 → 7, atomic current/journal, zero loser partial state, and zero invitation leak. The final fresh canonical gate repeated schema lint, the serial and DB10/DB06/DB11/DB07 race suites, and disposable teardown before returning the full-scope acceptance sentinel. Branch-onboarding Python is 211 passed; Ruff, Tach, and Vulture diagnostics are zero; product and criteria audits report zero Blocker and zero Medium. DB12-13 and all provider/interface/orchestration/UI/actual-actor evidence remain RED, so implementation stays partial and P01 stays RED. No image pull, custom build, or online deploy occurred.
2026-07-16: DB12 criteria are accepted before executable SQL or product change. The existing application query and Supabase adapter define the three-part server-resolved scope and closed four-key row. DB12 owns one service-role-only read RPC, uniform zero-row not-found behavior, current-not-accepted selection, durable provenance checks, exact fail-closed errors, and whole-state immutability. DB13 and downstream actor surfaces remain unopened.
2026-07-16: DB12’s accepted-history authority amendment is accepted after adversarial criteria review and before GREEN evidence promotion. The scoped GET is still the only new public SQL surface. A private append-only, Data-API-inaccessible accepted-result receipt is inserted atomically on first finalize, and inspect/start/transition/finalize/GET must compare every accepted command with that independent receipt before return or mutation. DB13 must delete operational command/journal/invitation/fee/office/core-branch facts while preserving the public audit and private receipt; its zero-search-residue assertion excludes only this exact retained evidence pair.
2026-07-16: DB12 is GREEN at backend 264f1baea39acdbc9982bddbb4bf799ca01de0a6. Criteria assembly f3f7124cf3accad1fe28ec6a97bf74f3015789b2 precedes executable RED 5ca37d81389d24c02308f9149113def690b8680a, 26-case corpus c4b1fdac7b6b89424642c03335b84b5d38b22ab8, initial GET product ef1a97647947e37a46ff958a1933e8d779f8a0c1, adversarial hardening ab386921945868b5a733e3bb00954de0e634fc86, private authority product 3d2cc841ddb0abc06a2e963c67640854eda59996, FEFF contract RED 448c326b9355ee429b00bb45cfd986c74c3d7880, and final application/adapter fix. Fresh Supabase reset and public-schema lint zero pass the serial corpus, outer rollback, DB10 finalize, DB06 ownership, DB11 repair, and DB07 business-conflict races with exact clone/source teardown and the full-scope sentinel. Branch-onboarding Python is 218 passed; Ruff and Tach are clean. Vulture’s three 100%-confidence findings are verified required Protocol parameters, not dead-code deletion authority. Final product audit is Blocker 0, Medium 0; the governance blocker is closed by this amendment. DB13 and all provider, interface, orchestration, frontend, actual-actor, screenshot, and WebP evidence remain RED. No image pull, custom build, online deployment, screenshot, or WebP collection occurred.
2026-07-16: DB13 cleanup criteria reuse the assembly-owned registered stage reaper instead of adding a P01 business or public deletion operation. Only an expired, active batch with explicit test-owned relation/column/value references, matching owner provenance, materialized stage deployment identity, and service_role execution can delete. The DB-only order is command, exact fee policy, office, then core branch in one transaction; command and office cascades remove their owned children, while unexpected dependencies fail closed. The target P01 membership must remain absent. Public audit and private accepted receipt, HQ organization revision, and all unrelated state remain byte-identical. Auth and SpiceDB cleanup stay in the later full stage procedure. Criteria are accepted before executable RED or integration evidence, so DB13 and P01 remain RED.
2026-07-16: DB13 executable RED ee035d91 proves the isolated P01 clone does not materialize the registered reaper authority. The historical reaper migration cannot simply be added because its later half is coupled to reservation add-option tables outside the P01 dependency closure. The accepted minimum is a later dependency-free, idempotent reconciliation of the existing registry, deployment guard, and exact-reference delete RPC plus one P01-specific manifest preparer; it is not a new public/business cleanup API. Stage teardown terminates that test run’s idempotency scope, uses external provider/Restate quiescence, and is resumable rather than batch-atomic. Production remains reaper-disabled. Reaped registry rows are cleanup control-plane evidence, not business residue, and trusted service_role registration is not described as capability isolation.
2026-07-16: DB13 DB and assembly execution boundaries are GREEN. Backend corpus 911f248d precedes product d051b1ed6fdeecef675f9e12067b77fa95c4a810; its fresh selected-migration gate passes the 10-case cleanup ledger, public-schema lint zero, prior finalize/identity/repair/business races, rollback, and exact teardown. Assembly 66ded57d6aaf3f83b8ccea9a529a1efb43f2d063 adds exact P01 manifest validation, lease and revision CAS, partial-delete resume, registered-RPC replay-zero verification, lineage-preserving terminal state, and separate concurrent-skip reporting. Mock PostgREST and policy tests pass 10 of 10 and independent bounded audit reports zero blockers. This does not prove a live stage producer, Auth or SpiceDB deletion, provider/Restate quiescence, actual HQ actor, screenshots, or WebP. P01 therefore remains RED and implementation remains partial.
2026-07-16: the A14 concrete Supabase durable-store adapter is GREEN at backend 54974c2ba4d60db26f71b1313ee3070ff45deb98. Typed RPC error RED/product bd910961/5cf91fa0 precede adapter RED 6cf149a9, adversarial permutation and transition-binding tests ed253f82/b0526eb8, product 7d13d0b4, and SQL-realistic UUID fixture hardening 54974c2b. The adapter binds the exact four DB01-13 RPCs, canonicalizes the three contract set-like arrays before exact comparison, rejects a returned effect or current snapshot that does not match the requested transition, maps only exact SQLSTATE/message pairs, and rejects noncanonical command IDs before durable mutation. Focused branch/platform regression is 294 passed; adapter plus command acceptance is 79 passed; Ruff and Tach dependency/interface/external gates pass; three independent final audits report blocker 0. A post-commit fresh Supabase CLI run again returns public lint [] and the full-scope acceptance sentinel. This is adapter product evidence, not live runtime composition: provider effects, Restate, interfaces, actual actor, screenshot, and WebP remain RED, so ADR implementation stays partial and P01 stays RED.
2026-07-16: P01 is PASS at assembly daec45376021c9df3fb7821c745e21766b32eae8, contract e4534e41c0cd9b06d6193e8850088469f798d162, backend f75548e76866ea10bf36c0f34824262850d0f8aa, and frontend e429d59d31eadc046a2e1920ad29dc088fe15dba. Actual HQ actor acceptance covers all six P01 cases, two cross-HQ race axes with one typed loser and zero partial state, exact replay, and three-lineage cleanup with zero operational/Auth/SpiceDB/session residue while retaining three audit/receipt pairs. The real Astro browser path adds HttpOnly-session submit, same-origin replay, reload resume, stale-conflict no-mutation, desktop/mobile/4-frame WebP, privacy review, and zero process residue. No online deploy occurred. P02 is now RED because actor-own-branch-resolution and own-profile mutation acceptance remain open; combined ADR implementation stays partial.
2026-07-16: P02 workflow-first criteria corrected the legacy lineage: only the detail GET at OfficeManagement.php:374-381 substitutes the session branch; POST OfficeManagement.php:399-448 trusts caller $index; office_detail.js:1-10 is readonly presentation only. The decision now records branch-own-profile-write, canonical branch_operator, invitation activation with pending authorization delivery, self-scoped PATCH /branch/profile, typed replay/revision/validation outcomes, and the retained-audit/reaper boundary. This is RED criteria, not implementation evidence; browser assets and all P02 acceptance manifests remain pending.