Review brief: region HA spec 1 rev 5.2, round 3

You are an independent second reader. Review docs/superpowers/specs/2026-10-04-region-ha-box-placement-design.md at the commit named in the prompt, in the repository at the working directory (Go; carlos platform).

What changed and why

Rev 5.2 answers your rev 5 round 2 findings (CODEX-FINDINGS-REGION-HA-REV5-2.md, B2-1 to B2-6) and the round 1 items you marked partly resolved (B1-2, B1-3, B1-4, B1-8). §21 is the disposition table. The mechanisms changed:

• §6 volume guard (B2-1): the SCP also denies CreateReplaceRootVolumeTask, CreateSnapshot(s) and CreateImage on platform boxes and their volumes; the carlos:role tag is protected on volumes as well as instances; a replaced root volume shows as removed.
• §6 service-linked roles (B2-3): the attestation reads every service-linked role's managed policy at its default version and maps each disk or tag action to an initiating API the SCP denies (for Auto Scaling: refresh, group create and update, warm pools, attach), and is invalidated by a policy version change.
• §5.9 hold release (B2-2): the hold names its instance and the change role's exemption is limited to it; release revokes the role's earlier sessions, waits for in-flight disk tasks and the signature-age bound, then needs a validating record after that barrier.
• §5.6, §5.8 files pin (B2-4): the files manifest is pinned from the newest admitted generation, independently of the database baseline; a files live set protects it.
• §5.8 local install receipt (B2-5): bound to op.journal.install_stamp; never remade after the first admission.
• §5.1 H17 emptiness (B2-6): the cross-region confirmer requires a positive terminated read for every remaining enrollment in the region, in the same pass; it is not a fence.

Paul's rulings H17 and H18 (2026-10-06) are fixed text, and §11 is empty.

Fixed: do not re-argue

Rulings H1 to H18 in §0, and the claim's own ruled text (R6 in particular: no warm reuse of a local database). Report only mechanisms that fail to honour them, are unsafe, or are missing.

Sources to check against

• Claim spec: git show origin/design-replica-ownership:docs/superpowers/specs/2026-10-02-host-lifecycle-claim-design.md (§2, §4, §5.1, §5.9 PROPOSED, §6.4, §6.4a, §6.6 PROPOSED, §7, §8, §10.1 PROPOSED).
• Claim code on main: internal/hostclaim, internal/hostguard, internal/stopevidence, internal/park, internal/genselect.
• Moves spec: /home/paulca/amadan.net/carlos/platform-moves-design/docs/superpowers/specs/2026-10-02-move-any-app-design.md (latest committed rev on that worktree's branch).
• Plan 1a's code on main, for §18 and §19's claims about it.

Focus

1. First, a disposition table for B2-1 to B2-6 and for B1-2, B1-3, B1-4 and B1-8: resolved, partly resolved (say what remains) or not resolved, each with the section that answers it.
2. Then only new findings. Do not re-raise anything resolved in any earlier round (rounds 1 to 6 of rev 4.x, and rev 5 rounds 1 and 2) unless this revision broke it; if it did, say which change broke it. Look hardest at the mechanisms listed above and their neighbours: the hold, revoke and release order against the fence and the 2-hour bound; the attestation's service-role table against Auto Scaling's real behaviour; the files pin and live set against PublishGeneration's parks and the at-rest sweep; the receipt against replacements and crashes; the emptied-region check against H17's single cross-region use.

Output

The disposition table, then new findings ranked P1 (unsafe or blocks a plan), P2 (wrong or missing), P3 (clarity). Each: section, the problem, a concrete failing sequence, and a suggested fix. End with a verdict: ready for plan, or not ready.