| 1 | Reviewed HEAD `a21e8225200504cc3ce504172594e83e54f7a6e4`. Five findings: |
| 2 | |
| 3 | 1. **P1 — Configured-key presence still bypasses the missing-key refusal.** [Plan:184](/home/paulca/amadan.net/carlos/platform/.claude/worktrees/instance-key-provision/docs/superpowers/plans/2026-10-10-instance-key-provision.md:184) |
| 4 | Source (c) accepts an app whose configuration supplies key A while `InstanceKey(own)` selects an unpublished app-owned key B. Relocation restores the database without B. This is round 1 finding 1 through another supported source; documenting it as a residual does not close it. Require evidence of adoption for configured keys too, and test this exact refusal. |
| 5 | |
| 6 | 2. **P1 — Configuration evidence neither identifies nor pins the recovered key.** [Plan:3039](/home/paulca/amadan.net/carlos/platform/.claude/worktrees/instance-key-provision/docs/superpowers/plans/2026-10-10-instance-key-provision.md:3039) |
| 7 | `ConfiguredInstanceKey` reads current configuration, discards its versions, and returns only a boolean. A source can still be running with A when configuration changes to B and the box dies. The pinner accepts B; the target renders B over data sealed with A. Configuration can also change between pinning and installation. Even an app that correctly adopts configuration needs evidence identifying its actual key, plus retention or verification that delivers that same key on recovery. Add both transition tests. |
| 8 | |
| 9 | 3. **P1 — An adoption record outlives the writer it describes.** [Plan:683](/home/paulca/amadan.net/carlos/platform/.claude/worktrees/instance-key-provision/docs/superpowers/plans/2026-10-10-instance-key-provision.md:683) |
| 10 | The record contains only version, variable name and key digest. After one release adopts platform key A, another release can select its own key B; step 1 sends no notification and nothing invalidates A’s record. If B is absent from the manifest, O2′ still accepts A. A failed deployment followed by rollback can likewise leave adoption evidence behind. Bind evidence to the relevant installation and writer/release, define invalidation and continuity across transitions, and test stale-record rejection. The endpoint currently receives no generation identity or write fence. |
| 11 | |
| 12 | 4. **P2 — First adoption has no specified publication path during the running session.** [Plan:196](/home/paulca/amadan.net/carlos/platform/.claude/worktrees/instance-key-provision/docs/superpowers/plans/2026-10-10-instance-key-provision.md:196) |
| 13 | `Establish` publishes before the process starts; the helper creates the adoption record afterward. O5 publishes on orderly release, but neither obligation publishes this new platform item during normal execution. A first adopting process can therefore run indefinitely with locally acknowledged adoption that failover cannot see. Add publication through the session’s publisher and test adoption followed by box loss without another admission or release. O6 also needs to gate this capability: claim launches currently have no socket, yet the HA rollout checklist omits O6. |
| 14 | |
| 15 | 5. **P2 — Deferring adoption-record retirement breaks later installation on the source box.** [Plan:3106](/home/paulca/amadan.net/carlos/platform/.claude/worktrees/instance-key-provision/docs/superpowers/plans/2026-10-10-instance-key-provision.md:3106) |
| 16 | Moves leave the new host-named record outside their retirement lists. `EmptyInstallationCensus.CheckLocal` refuses such leftovers, so a completed move can prevent that host from being installed there again. Include the record in the journalled artifact lifecycle before shipping its writer; test move-away followed by return or reinstallation. |
| 17 | |
| 18 | The adoption record **is tenant-forgeable**: the tenant holds the bearer and key, and the nested record lives in tenant-writable storage. Authentication fixes the HTTP request to the listener’s host; it does not prove which key seals the database. This can be a trusted-helper assertion, but it is not independent platform evidence. Host/incarnation provenance from the enclosing manifest does not resolve the stale-writer problem above. |
| 19 | |
| 20 | Round 1 disposition: |
| 21 | |
| 22 | - **2, 3, 4, 7 and 8:** addressed by the proposed implementation and tests. |
| 23 | - **1:** remains open. **5:** configured keys are now accepted, but recovery identity remains unsafe. |
| 24 | - **6:** I verified that the installed CLI supports `-squash`; I withdraw the unsupported-option claim. The conflicting AGENTS.md workflow still needs reconciliation before landing. |
| 25 | - **9:** specified as a provider integration obligation, not yet demonstrated here. |
| 26 | - **10:** acceptable stated limitation while legacy boxes cannot relocate. |
| 27 | |
| 28 | The unguarded fsync is acceptable as described: it changes no logical file content, mode or ownership; chmod remains guarded. The missing claim socket is safe only as an explicit recovery refusal, not as completed platform-key HA support. |
| 29 | |
| 30 | This was static review of the plan and referenced code. I did not independently compile or execute the snippets in this read-only workspace. |
| 31 | |
| 32 | --- |
| 33 | |
| 34 | **FIRST PROMPT:** |
| 35 | Review the instance-key provisioning plan at HEAD using the round 2 brief. |
| 36 | |
| 37 | **WHAT:** |
| 38 | Assess whether the revised plan is ready to implement. |
| 39 | |
| 40 | **STATUS:** |
| 41 | Review complete; five findings. No files changed. |
| 42 | |
| 43 | **NEEDED:** |
| 44 | Nothing for this review. |
| 45 | |
| 46 | **RECOMMENDED:** |
| 47 | Resolve recovery evidence, adoption publication and artifact retirement before implementation. |
| 48 | |
| 49 | **SESSION:** |
| 50 | Safe to close; no background processes or scratch files created. |
| 51 | |
| 52 | **Verdict: not ready to build.** |
amadan