amadan
Region HA plan 1b-next: Astra review brief, round 19
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
1 file changed,
+115
−0
docs/superpowers/plans/CODEX-PLAN-REGION-HA-1BN-BRIEF-19.md+115 −0
CI cancelled — superseded by a newer push — run details
diff --git a/docs/superpowers/plans/CODEX-PLAN-REGION-HA-1BN-BRIEF-19.md b/docs/superpowers/plans/CODEX-PLAN-REGION-HA-1BN-BRIEF-19.md| new file mode 100644 |
| index 000000000..b4f584450 |
| --- /dev/null |
| +++ b/docs/superpowers/plans/CODEX-PLAN-REGION-HA-1BN-BRIEF-19.md |
| @@ -0,0 +1,115 @@ |
| +# Review brief: region HA plan 1b-next, round 19 |
| + |
| +You are an independent second reader. This is round 19: first give a disposition table for each round 18 finding in docs/superpowers/plans/CODEX-PLAN-REGION-HA-1BN-R18.md (resolved, partly, or not), judged against the plan's "Rev 19: round 18 dispositions" table, then report only NEW findings. Review the implementation plan |
| +`docs/superpowers/plans/2026-10-07-region-ha-1b-next-relocation.md` at the |
| +commit named in the prompt, against the tree at the working directory |
| +(Go, module github.com/carlosframework/platform, main at 3407d114, which |
| +holds claim Plans 1-8b and 5) and these authorities: |
| + |
| +- region HA spec `docs/superpowers/specs/2026-10-04-region-ha-box-placement-design.md` |
| + (rev 5.4 plus §24; rulings H1-H19 in §0; L1-L20 in §9, all accepted); |
| +- claim spec rev 6.30: `git show origin/design-replica-ownership:docs/superpowers/specs/2026-10-02-host-lifecycle-claim-design.md`; |
| +- claim Plan 6b (not merged): `git show origin/design-replica-ownership:docs/superpowers/plans/2026-10-06-host-lifecycle-claim-6b-box-assembly.md`; |
| +- moves spec on origin/design-moves-any-region (rev 7.22); |
| +- contracts note `docs/superpowers/notes/2026-10-07-region-ha-contracts.md`. |
| + |
| +## Fixed: do not re-argue |
| + |
| +- Rulings H1-H19, Paul's approval of spec rev 5.4, and claim rev 6.30's |
| + adoption of L1-L20. |
| +- One implementation per concept, and main's wins: the termination fence is |
| + written only by `internal/hostfence.TerminationWorker`; the roster is read |
| + only through `internal/hostactors.Directory`. 1b-next must not add a |
| + second writer or reader. |
| +- The two-box joint model (L18) is a separate piece of work. This plan only |
| + gates the merge of relocation on it. Do not ask this plan to write it. |
| +- Tasks 8-10 are marked as gated on unmerged code (6b, moves Plan 2, claim |
| + Plan 5's app gate). They were not compiled. Review them against the |
| + interfaces those plans declare, not against main. |
| +- Everything stays dormant behind CARLOS_REGION_HA. |
| + |
| +## What to check |
| + |
| +1. Tasks 1-7 compile and their tests pass as written. They were dry-run on |
| + a clean 3407d114. A "would not compile" finding quotes the line and |
| + names exactly what is undefined. |
| +2. Each test pins what its name claims and fails with its mechanism removed. |
| +3. Correctness against the claim spec: the `relocating` transitions; the |
| + fence-consuming CASes; `released` coverage (L9); the L11 start guard; |
| + stop evidence (L10); drain versus failover release; R6 (no warm reuse of |
| + a local DB); prepared generations and AdmitWriter; executor choice (H4, |
| + with the SHA-256 tie-break recorded in the create intent); the §5.3 row |
| + cases; the pin object; `stuck` handling. |
| +4. Races: a crash or a lost response at every step of the worker and |
| + participants; two workers; a box terminated mid-relocation (nested |
| + failover); a stale edges file; a late PUT after termination. |
| +5. Dormancy: anything that changes behaviour with CARLOS_REGION_HA off, or |
| + on a one-box region. |
| +6. Task boundaries and the gated tasks' interface assumptions against 6b's |
| + and Plan 5's declared interfaces. |
| +7. The author's rulings (in the plan): accept each one, or say why it is wrong. |
| + |
| +## Output |
| + |
| +Findings ranked P1 (would not compile, a test fails, or unsafe), P2 (wrong |
| +or missing), P3 (clarity). Each gives the task and step, the problem, the |
| +evidence (file:line, or the plan's own line), and a concrete fix. End with a |
| +verdict: ready to build, or not ready. |
| + |
| +## Round 2 notes |
| + |
| +- Rev 2 adds rulings 14-18 and a "Requests to the claim and moves |
| + sessions" section (R1-R7). A request listed there is the right answer |
| + for a missing upstream interface; judge whether each one is necessary and |
| + sufficient, not whether the plan should have invented it. |
| +- The un-gated tasks are now 1-7; the gated ones are 8a, 8b, 8c, 9 and 10. |
| +- Rev 3 adds rulings 19-22. R3 now has an agent half and a root half; R5 |
| + names the complete retained consequences. |
| +- Rev 4 adds ruling 23 and request R8 (a 6b insertion point between |
| + OpenProductionClaimAssembly and Build). |
| + |
| +## Round 5: two-stage scope (controller ruling 24, fixed) |
| + |
| +Claim Plan 6b is unmerged and still changing, so the plan is split: |
| + |
| +- **Stage A** (Tasks 1-7 and 9a) is to be built now. Judge it fully: it must |
| + compile on main, its tests must pin their claims, and it must be correct |
| + and dormant. Its findings decide "ready to build". |
| +- **Stage B** (8a, 8b, 8c, 9, 10) keeps design and contracts only. Its code |
| + is rewritten against 6b's real code after 6b merges, and reviewed again |
| + then. Judge stage B only on its contracts: is each obligation stated, |
| + is it assigned to this plan or to a named upstream request (R1-R9), and |
| + is it backed by a named test? Do not report compile-level or |
| + line-level defects in stage B code. Do check that the "Stage B re-plan" |
| + step carries every stage B obligation from rounds 1-18. |
| + |
| +Verdict: "stage A ready to build" (with stage B contracts complete), or |
| +not ready. |
| + |
| +## Round 14 note |
| + |
| +Rev 14 adds a seeded property test over the real hostexec controllers |
| +(Task 7), asserting five lifecycle invariants after every step. Judge |
| +whether its event set and invariants cover the controller lifecycle |
| +(acknowledge, lease loss, recovery, finish, sweep, successor handover, |
| +restart). A controller interleaving it could not generate is a finding |
| +against the test, not only against the code. |
| + |
| +## Round 17: findings from the two-box joint model |
| + |
| +After round 16 accepted rev 16, the two-box joint model |
| +(`git show origin/region-ha-hostlife-two-box:docs/superpowers/plans/2026-10-07-region-ha-hostlife-two-box.md`, |
| +findings F1-F3, model rulings 14, 16, 17) reproduced three gaps. Rev 17 |
| +answers them with rulings 25 (F2, empty pin needs positive evidence), 26 |
| +(F1, failed probe with no spare goes stuck) and 27 (F3, unopened P parked |
| +at completion). Judge whether each ruling closes its gap without opening |
| +another, and say plainly if a ruling hides something the spec should fix |
| +instead (especially 25's window between the app minting instance.key and |
| +its first manifest, and 26's leaving a drained host unserved). |
| + |
| +## Round 18 note |
| + |
| +Rev 18 records L21 (the window between the app minting instance.key and |
| +its first manifest) as an open request for Paul, with recovery failing |
| +safe (stuck) meanwhile. Do not ask the plan to choose L21's fix; judge |
| +only that recovery cannot install a database without its key. |