| 1 | # Review brief: region HA two-box joint model plan, round 2 |
| 2 | |
| 3 | You are an independent second reader. This is round 2: first give a disposition table for each round 1 finding in docs/superpowers/plans/CODEX-PLAN-REGION-HA-TWO-BOX-R1.md (resolved, partly, or not), judged against the plan's "Rev 4: round 1 dispositions" table and its coverage table, then report only NEW findings. Review the implementation plan |
| 4 | `docs/superpowers/plans/2026-10-07-region-ha-hostlife-two-box.md` at the |
| 5 | commit named in the prompt, against the tree at the working directory |
| 6 | (branch region-ha-hostlife-two-box, based on design-moves-any-region; the |
| 7 | model is `internal/sim/hostlife`). |
| 8 | |
| 9 | The plan extends the joint executable model of the host lifecycle claim and |
| 10 | instance moves from one box per region to one or two. It is region HA's |
| 11 | validation milestone (claim spec rev 6.30 §1.1 activation gate, R18-3, L18): |
| 12 | relocation may not merge until a joint round passes on this model. |
| 13 | |
| 14 | Authorities: |
| 15 | - claim spec rev 6.30: `git show origin/design-replica-ownership:docs/superpowers/specs/2026-10-02-host-lifecycle-claim-design.md` |
| 16 | (search "two boxes per region" for the required cases); |
| 17 | - region HA spec: `git show origin/main:docs/superpowers/specs/2026-10-04-region-ha-box-placement-design.md` |
| 18 | (rulings H1-H19); |
| 19 | - region HA plan 1b-next rev 19, accepted: |
| 20 | `git show origin/plan-region-ha-1b-next:docs/superpowers/plans/2026-10-07-region-ha-1b-next-relocation.md` |
| 21 | (rulings 1-27, L21 open) and its review findings CODEX-PLAN-REGION-HA-1BN-R*.md; |
| 22 | - moves spec rev 7.22 on this branch. |
| 23 | |
| 24 | ## Fixed: do not re-argue |
| 25 | |
| 26 | - Rulings H1-H19, 1b-next's rulings 1-27, and L21 being open (Paul's call). |
| 27 | - The CPU budget: one 3000-seed sweep per revision, serial, nice 19, PAR=2; |
| 28 | deep runs only on Paul's say-so. Do not ask for more seeds. |
| 29 | - Changes are additive: the claim's and moves' rules are not rewritten. |
| 30 | |
| 31 | ## What to check |
| 32 | |
| 33 | 1. Coverage: is every required L18 case a witness or invariant in both a |
| 34 | one-box and a two-box region (create spread, relocation by drain, |
| 35 | termination during serving and every relocation phase, nested failover, |
| 36 | stale edges files, unenrolled references, a volume without |
| 37 | DeleteOnTermination, crashes during installation, late uploads and PUTs |
| 38 | after termination)? |
| 39 | 2. Fidelity: does each modelled guard match the 1b-next rev 19 guard it |
| 40 | names? A model rule stronger or weaker than the code hides bugs. List any |
| 41 | 1b-next guard with no model counterpart. |
| 42 | 3. Mutation strength: does each new guard's mutation fail a seed or a direct |
| 43 | test? Are the "expected misses" justified? |
| 44 | 4. One-box identity: can any change alter one-box behaviour or the existing |
| 45 | expected outcomes? |
| 46 | 5. Task order and compilation: tasks applied in order build and pass. |
| 47 | 6. Are 1b-next's past findings (R1-R19, model F1-F3) each something this |
| 48 | model would catch if reintroduced? Name any it could not. |
| 49 | |
| 50 | ## Output |
| 51 | |
| 52 | Findings ranked P1/P2/P3, each with task and step, the problem, evidence and |
| 53 | a concrete fix. End with a verdict: ready to build, or not ready. |
| 54 | |
| 55 | ## Round 2 notes |
| 56 | |
| 57 | - Rev 4 maps past 1b-next findings either to model rules or to the |
| 58 | 1b-next test that proves them (the coverage table). A mapping to a |
| 59 | 1b-next stage A test is acceptable where claim §11 does not require the |
| 60 | case in the executable model; check each such claim against §11. |
| 61 | - Model rulings 20 (F5) and 21 (F4) are posted to the claim and moves |
| 62 | sessions for an answer; judge them as stated. |
| 63 | |
amadan