# 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.