**Review:** `docs/superpowers/plans/2026-10-10-instance-key-provision.md` rev 3 (3947e1d9) on `instance-key-build`. The "Rev 3: round 2 dispositions" table answers your round 2 (`CODEX-PLAN-INSTANCE-KEY-R2.md`). Rulings 19–24 are binding decisions:
4
- **19, threat model.** The adoption record is a trusted-helper assertion that prevents accidental loss. A tenant who forges it only risks their own data.
5
- **20, evidence.** There are two sources:
6
- (a) `instance.key` in the pinned manifest;
7
- (b′) an adoption record bound to the pinned writer session, whose SHA-256 equals the digest of the exact key the target delivers. That key is pinned at pin time and verified again at install. Source (c), the configured key on presence, is dropped.
8
- **21:** the record is published continuously on the running session.
9
- **22:** the helper reports on every process start, with `source` taken from `$CARLOS_INSTANCE_KEY_SOURCE`.
10
- **23:** O6 (a control socket on claim launches) gates platform-key relocation. Until then the refusal is explicit.
11
- **24:** the move lifecycle includes the record (O7).
12
13
The report is `INSTANCE-KEY-PLAN-REPORT-R3.md`.
14
15
**Judge:**
16
1. Is each round 2 finding closed?
17
2. Can (b′) accept a key the pinned data isn't sealed with, under:
18
- stale sessions;
19
- rollbacks;
20
- a configuration change between pin and install;
21
- a lost first report;
22
- replicas?
23
3. Is the agent's check of `source` against its own launch state sound?
24
4. Does a record for a configured key, which publishes the SHA-256 of a configured secret, need hashing with a per-host salt? Or is a P3 note enough?
25
5. Anything new?
26
27
Give findings P1/P2/P3 with file:line, then a verdict: ready to build, or not.
amadan