# Brief: review the P7 edge-door plan

Review `docs/superpowers/plans/2026-09-28-instance-moves-p7-edge-door.md`
against the code in this checkout (branch `instance-moves-p7`, based on
`main` with P0 merged) before anyone builds it.

The design it implements is on branch `docs-instance-moves-design`:
`git show origin/docs-instance-moves-design:docs/superpowers/specs/2026-09-24-instance-moves-for-every-app-design.md`.
Read §0 (Paul's rulings, fixed: do not re-argue them), §8 and §10. Your own
recommendations that became those rulings are in
`CODEX-RULINGS-INSTANCE-MOVES.md` beside it.

## What was decided while planning, and why

- **The credential is a console-minted random key whose SHA-256 sits in a
  record under `control/door-keys/<account>/<app>.json`, signed with the
  deployment's root release key.** Boxes verify it against
  `CARLOS_RELEASE_PUBKEY`, which the edge already holds (`e.staticPub`).
  Rejected: the relay's HKDF-per-box-master pattern (a master staged by hand
  on every box, an infra change per box), and an unsigned hash record (any
  bucket writer could add a key, discussion #171).
- **Remote ownership comes from new `account`/`app` fields in each box's
  edges file**, so the request path never reads the bucket (the edge's rule).
  A host whose publisher predates the fields is refused.
- **The door calls the ordinary `Edge.ServeHTTP`** after authenticating,
  stripping the key and the hop headers, checking ownership, and setting a
  context mark. The mark widens X-Forwarded-For trust in `setForwarded` and
  `clientIP` only; the backhaul one-hop refusal still reads `hopVerified`.
- **Dormant:** no socket unless `CARLOS_EDGE_DOOR` names a path.

## What to look for

1. **Authorization holes.** Any request a door caller can shape that reaches
   an instance of another app, or the tunnel host, the store door, the
   steering probe, or any other `ServeHTTP` branch that runs before the route
   lookup. Specifically check the login POST, which `ServeHTTP` re-resolves by
   its `next` parameter (edge.go around 1400-1446), not by `r.URL.Path`, while
   the door checks ownership by `r.URL.Path`.
2. **Trust leaks.** Whether rewriting `RemoteAddr` from the caller's
   X-Forwarded-For, or the `forwardedTrusted` widening, lets a door caller
   spoof anything the edge or the gate relies on beyond the visitor address.
3. **The signing choice.** Is signing door-key records with the root release
   key (the key that moves `stable`) acceptable, or does it need a scoped
   grant (`internal/release/grant.go`)? Does any existing verifier accept a
   root-signed wrapper of a different kind, so that a door-key record could be
   replayed as something else, or vice versa?
4. **Revocation and failure behaviour.** The 30 s mirror; dropping records
   that fail verification but keeping the last map on a list failure; what a
   console with no signing key does.
5. **Plan quality.** Tasks whose interfaces don't line up, steps that name
   helpers or fixture fields that don't exist (check each against the code),
   tests that would pass without the change, and anything the rulings require
   that no task builds.

Cite code as `path:line` and check each citation. Findings first, ranked
P1 (must fix before building) / P2 (should fix) / P3 (note), each with the
failure scenario and a suggested fix. Then one line on whether the plan is
ready to build once the P1s are fixed. Keep it under about 2,000 words.