Part C/D: gate built + proven live (v0.280.0), defaults fixed, floor 0.280.0; decision 46 outcome; 01 §5 who may reach an app; R-707 narrowed, R-708/R-709/R-712 closed, R-713 filed

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0159rPz1ZhFKsS53msqPYxtS

documentation/architecture/01-topology-and-trust.md

@@ -124,6 +124,18 @@ a trust boundary too: a default password, or a "first visitor creates the admin"
 household acts. Rule and per-app status: `09` §3 decision 45 and `app-catalog-felhom.eu/FIRST-ADMIN.md` (the audit
 of all 53 apps, 2026-09-28).
 
+**Who may reach an app, and through what (recorded 2026-09-29 — no document said it before; spike finding F1).**
+Every app is reached only through the box's traefik (no catalog app publishes a host port except crafty-controller's
+game ports; none uses host networking — read from the catalog 2026-09-29). traefik routes by host name: the tunnel's
+`*.domain` and the LAN both land there. The dashboard (`felhom.<domain>`) has its own password; its session cookie is
+**host-only** and never reaches an app host. An app answers anyone who reaches its host, with the app's own login —
+**except while its setup gate is closed** (`09` §3 decision 46, controller ≥ 0.280.0): then traefik asks the
+controller first (`forwardAuth`), and only a browser holding a gate cookie for that one host gets through. The cookie
+is minted after a valid dashboard session vouched for the browser (a 60-second, one-use token bound to the host, on
+the dashboard's own `/__gate/start`). The controller is in an app's request path ONLY while its gate is closed; once
+open, the gate's traefik router is removed and the app is reached exactly as without it. The gate decides who creates
+the first admin; it does not decide who may sign up afterwards (R-711).
+
 ---
 
 ## 6. Enrollment & identity

documentation/architecture/09-update-architecture.md

@@ -502,7 +502,15 @@ R-636's louder repeated alarm.
     app is not yet set up, the box lets only a person logged in to the household's dashboard reach it; the gate opens
     when the app's own status says an admin exists, or when the household presses "Done, I set it up". Option B: one
     fix per app (route (b), R-707). A is built only if the spike passes its exit test in writing; otherwise B continues
-    and the spike's result is the recorded reason. Outcome: *(filled in by the 2026-09-29 session)*.
+    and the spike's result is the recorded reason. **Outcome (2026-09-29): the spike PASSED** (`audits/login-gate-2026-09-29/
+    B/B-VERDICT.md`, written before any build): on 9202 a stranger never reached a first-setup screen (~530 polls during
+    two installs, 0 app answers), the household passed with its dashboard session in 0.2 s, both probes flipped on the
+    setup, immich's phone-app API worked unchanged once the gate's router was removed, and the dashboard cookie was never
+    widened (a redirect handshake mints a 60-second, one-use token per app host instead). **Built in controller v0.280.0**
+    and proven live on immich, n8n, audiobookshelf (probe) and uptime-kuma (button). Costs, stated: ~2 ms per gated
+    request; a gated app answers 500 while the controller is down (closed, not open); a phone app cannot reach a gated
+    app; an app with no probe waits for the household's press, and the press trusts the household. Not covered by the
+    gate: open sign-up after the setup (R-711). Design record: `01-topology-and-trust.md` §5.
     Same day, operator: CC changes the admin passwords of demo-hp's installed bookstack and calibre-web and stores them
     in the operator's credentials file (not in any repo).