# Astra: final review of the instance-key build (second reader)

**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.

**What it does.** It is region HA's L21: the platform mints each instance's key.
- `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.
- Replicas run only with the home's verified key, or with none.
- The claim launch source mints under the guard.
- The adoption verb (mounted nowhere until O6/O7) writes a writer-bound record and publishes it.
- On legacy boxes, the startup backfill adds the key to existing env files.
- Keys travel byte for byte through re-render and moves.

**Judge:**
1. **Overwrite.** Can any path overwrite, rotate or truncate a key a successful call reported? Can two processes of one instance hold different keys?
2. **Durability.** Can any path start an app before its key is durable, outside the stated exemptions?
3. **Replicas.** Can any replica launch path run with a key other than its home's, or mint one?
4. **Disclosure.** Does a key or its digest reach a log, an error, the console or a CLI listing?
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.
6. **Correctness.** Are there bugs, races or untested guards in the diff?

Give findings P1/P2/P3 with file:line, then a verdict: ready to merge, or not.