# Brief: P7 edge-door plan, review round 3

Rounds 1 and 2 are `CODEX-FINDINGS-P7-EDGE-DOOR.md` and `-R2.md` beside the
plan. The plan is now revision 3. It opens with a disposition table for
round 2 and a new **Security model** section.

Revision 3 changes the approach instead of adding machinery. Its claim is
that **the door grants exactly one privilege over the public door: the
caller's claim of the visitor's address is believed.** Everything else a door
request can do, an internet request to the same URL can already do. Given
that, it drops the door-scoped hop and the box-side revision persistence, and
accepts a set of residuals that each cost at most misattribution.

1. **Try to falsify the claim first.** Look for anything a door request can reach or cause that an internet request to the same host and path cannot:
   - any handler, header, context mark or address the edge, the activator, the gate, the cache, the purge path, the sidecar marker or analytics treats differently;
   - anything an app behind the edge could reasonably rely on, such as an app that trusts `X-Forwarded-For` for authorization;
   - what the door does to `RemoteAddr` and the forwarded headers on a local serve and on a backhaul.

   If the claim is false, say exactly where. That is the most important finding this round could produce.
2. **If the claim holds, judge the residuals table.** Is each bound stated correctly? Is any residual worse than misattribution?
3. **Disposition table** for round 2's seven findings: closed / partly / not closed / correctly superseded.
4. **Then only new findings,** ranked P1/P2/P3. Look hardest at the publication protocol in Task 2 (mutex, the CAS retry, the revision advance) and at `Owner` returning the dial target.
5. The rulings in the design record's §0 are fixed. Check every `path:line` you cite.

End with one line saying whether the plan is ready to build. Keep it under about 1,500 words.