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

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). Your round 1 findings are in
`CODEX-PLAN-REGION-HA-1B-R1.md`; the author's answers are the table
"Astra plan round 1: dispositions" at the end of the plan.

## 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 (six, unchanged
  this round).
- Everything stays dormant behind CARLOS_REGION_HA and changes nothing on
  a one-box region.
- Round 1 findings the dispositions table marks fixed are not to be
  raised again unless the fix itself is wrong; say which, and why.

## What changed since round 1

- Task 5: `Discharge` validates every stored record of the enrollment
  before using it (version, a state carrying mappings, a non-empty
  mapping, volume ids and devices); new test
  `TestDischargeRefusesStoredRecordsThatAreNotEvidence`.
- Task 6: aliases and served catch-alls take their primary's stamp (two
  new replacements in `edgesfile.go`); entries track the last attempt
  separately from the last decision; `edgesLoopState` adds a pass every
  30 seconds while claim reads are due, replacing the loop's direct use of
  `edgesFileSchedule`; three new host tests and one new `internal/edge`
  test.
- Task 7: participation and marker failures are recorded as `deferred`
  (not `refused`); new test
  `TestApplyDeferredForParticipationAppliesOnceItEnds`.
- Task 8: the tofu test compares each statement whole; Steps 2 and 4 keep
  the module initialized until validation has run.

## What to check

1. The dispositions table first: for each of R1-1 to R1-7, is the finding
   resolved, partly resolved (say what is left), or not resolved?
2. Then only new findings, in the changed parts above or anything the
   changes break elsewhere. In particular:
   - `edgesLoopState`: with CARLOS_REGION_HA off, is the loop's behaviour
     identical to before (passes, `timed`, retry backoff, headroom
     refresh)? With it on, can the 30-second passes interfere with the
     schedule's change detection or backoff?
   - The `deferred` outcome: does anything in the agent's leg or root's
     apply treat a repeated deferral badly (log volume, the replay
     watermark in `seen.json`, the rolled-back stickiness)?
   - `Discharge`'s validation: could it refuse a record `Write` produces
     today from a real describe (for example a box mid-`stopping`)?
   - Alias stamps: with the flag on, can an alias of a withheld primary
     or a non-relocatable primary ever be published with a stale stamp?
3. As in round 1: does the code compile and do the tests pass as written,
   does each new test fail with its mechanism removed, and do task
   boundaries still build in order?

## 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. Start
with the round 1 table, then new findings only. End with a verdict:
ready to build, or not ready.