| 1 | # Review brief: region HA plan 1a (foundations), round 1 |
| 2 | |
| 3 | You are an independent second reader. Review the implementation plan |
| 4 | `docs/superpowers/plans/2026-10-05-region-ha-1a-foundations.md` at the |
| 5 | commit named in the prompt, against the tree at the working directory |
| 6 | (Go, module `github.com/carlosframework/platform`) and the spec |
| 7 | `docs/superpowers/specs/2026-10-04-region-ha-box-placement-design.md`. |
| 8 | |
| 9 | ## Fixed: do not re-argue |
| 10 | |
| 11 | - The spec's rulings H1 to H9. |
| 12 | - The split into 1a (no claim dependency, this plan) and 1b (after |
| 13 | `internal/claim` lands). Do not ask 1a to wire anything into create, |
| 14 | reconcile, the activator's restore path or relocation. |
| 15 | - The three departures the plan states at its top (content hash in place |
| 16 | of S3 version ids; the base64 RSA identity signature; `snapshot` as a |
| 17 | periodic full publish). Report only if one fails to keep the spec's |
| 18 | property. |
| 19 | |
| 20 | ## What to check |
| 21 | |
| 22 | 1. **Does the code compile and do the tests pass as written?** Read each |
| 23 | task's code against the real tree: every identifier, signature, |
| 24 | import and file path it uses from existing code (`release.Store`, |
| 25 | `registry.Timer`, `registry.Route`, `edgesFile`, `foldHomes`, |
| 26 | `edgesFilePlacementView`, `views`, `markStale`, `testKeyFP`, |
| 27 | `provision.InstanceID`, the ec2 SDK types, `unix.Inotify*`). Name the |
| 28 | exact line that would not compile or the test that would fail, and why. |
| 29 | 2. **Does each test actually pin the behaviour its name claims?** A test |
| 30 | that passes for the wrong reason, or passes before the change. |
| 31 | 3. **Correctness of the mechanisms**: the manifest's ordering under |
| 32 | concurrent or late writes; `readStable` and symlink races; the inotify |
| 33 | watcher (event parsing, lost events, new directories, close); |
| 34 | `dialBeats` against every pre-existing home-map rule; `Verify` in |
| 35 | `boxid` and `termfence`; the bucket policy statements (would any |
| 36 | statement deny something that works today, especially lease releases |
| 37 | or existing writers under `control/`?); the EventBridge and SQS tofu. |
| 38 | 4. **Additivity**: anything that changes behaviour on a one-box region |
| 39 | or breaks a reader of an existing wire shape. |
| 40 | 5. **The Review Focus list**: is each of the five pinned by a test in |
| 41 | the task that owns it? |
| 42 | 6. **Task boundaries**: a task that cannot be built and tested alone, in |
| 43 | order, with only the earlier tasks present. |
| 44 | |
| 45 | ## Output |
| 46 | |
| 47 | Findings ranked P1 (would not compile, a test fails, or unsafe), P2 |
| 48 | (wrong or missing), P3 (clarity). Each: task and step, the problem, the |
| 49 | exact evidence (file:line in the tree, or the plan's own line), and a |
| 50 | concrete fix. End with a verdict: ready to build, or not ready. |
| 51 | |
amadan