carlos / platform Public
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 CARLOSREGIONHA 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:
Dischargevalidates every stored record of the enrollment before using it (version, a state carrying mappings, a non-empty mapping, volume ids and devices); new testTestDischargeRefusesStoredRecordsThatAreNotEvidence. - 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;edgesLoopStateadds a pass every 30 seconds while claim reads are due, replacing the loop's direct use ofedgesFileSchedule; three new host tests and one newinternal/edgetest. - Task 7: participation and marker failures are recorded as
deferred(notrefused); new testTestApplyDeferredForParticipationAppliesOnceItEnds. - Task 8: the tofu test compares each statement whole; Steps 2 and 4 keep the module initialized until validation has run.
What to check
- 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?
- Then only new findings, in the changed parts above or anything the changes break elsewhere. In particular: -
edgesLoopState: with CARLOSREGIONHA 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? - Thedeferredoutcome: does anything in the agent's leg or root's apply treat a repeated deferral badly (log volume, the replay watermark inseen.json, the rolled-back stickiness)? -Discharge's validation: could it refuse a recordWriteproduces 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? - 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.