# Review brief: region HA plan 1b, round 1

You are an independent second reader. Review the implementation plan
`docs/superpowers/plans/2026-10-06-region-ha-1b-claim-readers.md` at the
commit named in the prompt, against the tree at the working directory
(Go, module github.com/carlosframework/platform) and the approved spec
`docs/superpowers/specs/2026-10-04-region-ha-box-placement-design.md`
(rev 5.4; rulings H1–H19 in §0).

## Fixed: do not re-argue

- The spec's rulings H1 to H19, and Paul's approval of rev 5.4.
- The scope rule: plan 1b builds only what needs none of the spec's
  L1–L20 claim/moves changes; everything listed under "Waits for the
  claim" is out of scope. Do not ask 1b to build those.
- The controller rulings recorded in the plan's header.
- Everything stays dormant behind CARLOS_REGION_HA and changes nothing on
  a one-box region.

## What to check

1. Does the code compile and do the tests pass as written? The author
   dry-ran every task on a clean copy of main; a "would not compile"
   finding should quote the line and say exactly what is undefined.
2. Does each test pin the behaviour its name claims, and fail with its
   mechanism removed?
3. Correctness: boxid.Enroll's evidence chain (signature, account,
   region, legacy tofu id, both directions of the roster), termfence's
   binding to the roster's cloud identity and H19 (terminated alone;
   absence never evidence), boxvolumes' records and Discharge (H19 and
   the 2-hour ruling), the edges-file claim reader (§5.4: withholding,
   stamps, caching, read failures), root's update refusal (§5.10's half),
   the bucket policy (would any statement break something that works
   today, especially existing writers under control/).
4. Dormancy: anything that changes behaviour with CARLOS_REGION_HA off,
   or on a one-box region.
5. Task boundaries: a task that cannot be built and tested alone, in
   order.
6. Scope: anything that quietly depends on an L-change, or writes a
   claim.

## Output

Findings ranked P1 (would not compile, a test fails, or unsafe), P2
(wrong or missing), P3 (clarity). Each: 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.