| 1 | # Astra round 1 brief: instance key provision (L21), plan rev 1 |
| 2 | |
| 3 | **Review:** `docs/superpowers/plans/2026-10-10-instance-key-provision.md` on branch `instance-key-provision`, cut from main at 0d338c14. |
| 4 | |
| 5 | **What it decides.** Paul's decision of 2026-10-09: the platform creates each instance's key before the app's first start. The plan has the agent mint `CARLOS_INSTANCE_KEY` (32 CSPRNG bytes, base64) create-only into `<host>.env`, the file that already carries `CARLOS_ADMIN_TOKEN`. The framework contract is rastrillo's `carlos.InstanceKey`, on rastrillo main e3ea08d. Its order is: |
| 6 | 1. the app's own key wins; |
| 7 | 2. otherwise `$CARLOS_INSTANCE_KEY`, verbatim; |
| 8 | 3. on CARLOS without a key, the app refuses to start; |
| 9 | 4. off CARLOS, nothing changes. |
| 10 | |
| 11 | Rollout: the key is written on every box, existing instances included, before any app adopts the helper. |
| 12 | |
| 13 | **Why it matters.** Region HA (docs/superpowers/specs/2026-10-04-region-ha-box-placement-design.md, H6 and §5.6) restores a dead box's instance from the replicated database and the files backup. A key minted after start and never backed up leaves sealed data unrecoverable. |
| 14 | |
| 15 | **Context.** The planner's report is in `docs/superpowers/plans/INSTANCE-KEY-PLAN-REPORT-R0.md`. Its main concern: nothing on main backs up `<host>.env` yet. Durability before the first start depends on the claim C8 files provider, which moves is building, and that obligation is recorded as O1. |
| 16 | |
| 17 | **Judge:** |
| 18 | 1. **Create-only.** Is it airtight on every path, given the plan's ruling-8 table? The paths: create, backfill, retries, re-render, hibernation restore, move, relocation install and layout move. Can any path overwrite or rotate a key, or leave two processes of one instance holding different keys? |
| 19 | 2. **Durability before first start.** Is the argument sound on legacy boxes and on claim boxes? Is O1 the right obligation, and is it enough? |
| 20 | 3. **The backfill.** Is it safe, idempotent and complete? Is anything missed: hibernated instances, landing paths, nested layouts? |
| 21 | 4. **Secrecy.** Logs, errors, file modes, the console, CLI listings, move reports. |
| 22 | 5. **Concurrency.** Minting under `adminTokenMu` across `seedChild`, `spawnChildFrom`, nested `prepareAt` and `EnsureClaimAdminToken`. |
| 23 | 6. **Tests.** Does the code compile against main? Are the tests real, so that each fails without its guard? |
| 24 | 7. **The planner's five open questions.** Replicas, a key set in configuration, `report.token`, workers and sidecars, and restarts inside a claim session. Say which ones block the build. |
| 25 | |
| 26 | Give findings P1/P2/P3 with file:line. End with a verdict: ready to build, or not. |
| 27 | |