| 1 | # Astra: final review of the instance-key build (second reader) |
| 2 | |
| 3 | **Review the code** on branch `instance-key-build`, base 0901e835 (main) to HEAD. The plan is `docs/superpowers/plans/2026-10-10-instance-key-provision.md`, rev 5.1, which you passed as ready to build in round 7. Its "Built" note lists where the code diverges from the plan, by ruling. Rulings 1–30 bind. |
| 4 | |
| 5 | **What it does.** It is region HA's L21: the platform mints each instance's key. |
| 6 | - `CARLOS_INSTANCE_KEY` is written create-only into `<host>.env` on every launch path, and made durable (chmod, file fsync and directory fsync) before success. The open uses `O_NOFOLLOW`, and a failed write is truncated back. |
| 7 | - Replicas run only with the home's verified key, or with none. |
| 8 | - The claim launch source mints under the guard. |
| 9 | - The adoption verb (mounted nowhere until O6/O7) writes a writer-bound record and publishes it. |
| 10 | - On legacy boxes, the startup backfill adds the key to existing env files. |
| 11 | - Keys travel byte for byte through re-render and moves. |
| 12 | |
| 13 | **Judge:** |
| 14 | 1. **Overwrite.** Can any path overwrite, rotate or truncate a key a successful call reported? Can two processes of one instance hold different keys? |
| 15 | 2. **Durability.** Can any path start an app before its key is durable, outside the stated exemptions? |
| 16 | 3. **Replicas.** Can any replica launch path run with a key other than its home's, or mint one? |
| 17 | 4. **Disclosure.** Does a key or its digest reach a log, an error, the console or a CLI listing? |
| 18 | 5. **Agent changes.** Is every change to the existing agent behaviour (activator merge, start sequence, claim snapshot) safe for current fleets? Consider a symlinked env now failing a launch, and mixed versions. |
| 19 | 6. **Correctness.** Are there bugs, races or untested guards in the diff? |
| 20 | |
| 21 | Give findings P1/P2/P3 with file:line, then a verdict: ready to merge, or not. |
| 22 | |
amadan