# Review brief: region HA plan 1b-next, round 11

You are an independent second reader. This is round 11: first give a disposition table for each round 10 finding in docs/superpowers/plans/CODEX-PLAN-REGION-HA-1BN-R10.md (resolved, partly, or not), judged against the plan's "Rev 11: round 10 dispositions" table, then report only NEW findings. Review the implementation plan
`docs/superpowers/plans/2026-10-07-region-ha-1b-next-relocation.md` at the
commit named in the prompt, against the tree at the working directory
(Go, module github.com/carlosframework/platform, main at 3407d114, which
holds claim Plans 1-8b and 5) and these authorities:

- region HA spec `docs/superpowers/specs/2026-10-04-region-ha-box-placement-design.md`
  (rev 5.4 plus §24; rulings H1-H19 in §0; L1-L20 in §9, all accepted);
- claim spec rev 6.30: `git show origin/design-replica-ownership:docs/superpowers/specs/2026-10-02-host-lifecycle-claim-design.md`;
- claim Plan 6b (not merged): `git show origin/design-replica-ownership:docs/superpowers/plans/2026-10-06-host-lifecycle-claim-6b-box-assembly.md`;
- moves spec on origin/design-moves-any-region (rev 7.22);
- contracts note `docs/superpowers/notes/2026-10-07-region-ha-contracts.md`.

## Fixed: do not re-argue

- Rulings H1-H19, Paul's approval of spec rev 5.4, and claim rev 6.30's
  adoption of L1-L20.
- One implementation per concept, and main's wins: the termination fence is
  written only by `internal/hostfence.TerminationWorker`; the roster is read
  only through `internal/hostactors.Directory`. 1b-next must not add a
  second writer or reader.
- The two-box joint model (L18) is a separate piece of work. This plan only
  gates the merge of relocation on it. Do not ask this plan to write it.
- Tasks 8-10 are marked as gated on unmerged code (6b, moves Plan 2, claim
  Plan 5's app gate). They were not compiled. Review them against the
  interfaces those plans declare, not against main.
- Everything stays dormant behind CARLOS_REGION_HA.

## What to check

1. Tasks 1-7 compile and their tests pass as written. They were dry-run on
   a clean 3407d114. A "would not compile" finding quotes the line and
   names exactly what is undefined.
2. Each test pins what its name claims and fails with its mechanism removed.
3. Correctness against the claim spec: the `relocating` transitions; the
   fence-consuming CASes; `released` coverage (L9); the L11 start guard;
   stop evidence (L10); drain versus failover release; R6 (no warm reuse of
   a local DB); prepared generations and AdmitWriter; executor choice (H4,
   with the SHA-256 tie-break recorded in the create intent); the §5.3 row
   cases; the pin object; `stuck` handling.
4. Races: a crash or a lost response at every step of the worker and
   participants; two workers; a box terminated mid-relocation (nested
   failover); a stale edges file; a late PUT after termination.
5. Dormancy: anything that changes behaviour with CARLOS_REGION_HA off, or
   on a one-box region.
6. Task boundaries and the gated tasks' interface assumptions against 6b's
   and Plan 5's declared interfaces.
7. The author's rulings (in the plan): accept each one, or say why it is wrong.

## Output

Findings ranked P1 (would not compile, a test fails, or unsafe), P2 (wrong
or missing), P3 (clarity). Each gives the task and step, the problem, the
evidence (file:line, or the plan's own line), and a concrete fix. End with a
verdict: ready to build, or not ready.

## Round 2 notes

- Rev 2 adds rulings 14-18 and a "Requests to the claim and moves
  sessions" section (R1-R7). A request listed there is the right answer
  for a missing upstream interface; judge whether each one is necessary and
  sufficient, not whether the plan should have invented it.
- The un-gated tasks are now 1-7; the gated ones are 8a, 8b, 8c, 9 and 10.
- Rev 3 adds rulings 19-22. R3 now has an agent half and a root half; R5
  names the complete retained consequences.
- Rev 4 adds ruling 23 and request R8 (a 6b insertion point between
  OpenProductionClaimAssembly and Build).

## Round 5: two-stage scope (controller ruling 24, fixed)

Claim Plan 6b is unmerged and still changing, so the plan is split:

- **Stage A** (Tasks 1-7 and 9a) is to be built now. Judge it fully: it must
  compile on main, its tests must pin their claims, and it must be correct
  and dormant. Its findings decide "ready to build".
- **Stage B** (8a, 8b, 8c, 9, 10) keeps design and contracts only. Its code
  is rewritten against 6b's real code after 6b merges, and reviewed again
  then. Judge stage B only on its contracts: is each obligation stated,
  is it assigned to this plan or to a named upstream request (R1-R9), and
  is it backed by a named test? Do not report compile-level or
  line-level defects in stage B code. Do check that the "Stage B re-plan"
  step carries every stage B obligation from rounds 1-10.

Verdict: "stage A ready to build" (with stage B contracts complete), or
not ready.
