--- name: appcheck-enforce-reminder description: "App Check enforcement is DONE — no pending action. Kept for the enforce-early reasoning, the standing caveat, and the staging incident that produced the localhost-only debug-guard rule." metadata: node_type: project originSessionId: appcheck-enforce-reminder --- # ✅ ENFORCEMENT IS DONE — do not surface this as a queued or parked item Owner-confirmed. *"unpin app check, I thought I already enforced it"* — he had. There is no flip to perform and nothing here is a precondition for other work. *Corrected 2026-07-20: this file spent weeks telling every session App Check was on MONITORING and to flip it at ~90% verified. That instruction, the verified-percentage figures, a reCAPTCHA site key, version/cache revisions and a commit ref are all removed. **Enforcement state is a console fact, never a memory fact.** The file was not wrong when written — it simply never learned the work had happened, and nothing in the system was ever going to tell it.* **A debug token was stored in this file in plaintext and has been stripped.** Rotating it is a 2.9.0 queue item that also gates museum publication — `QUEUE.md` owns the detail and the gating. Do not restate it here. The only rule this file keeps: **never write a debug token into a memory file again.** ## The decision and why (durable) Enforcement was flipped **while the verified percentage still looked low**, deliberately. The trailing verified-% average was dominated by **stale clients still open and auto-polling with an old key** — instances the owner does not control, which drain only as those users reload on their own timeline. Waiting for the number to climb meant waiting on strangers. The owner and his brother were both already verifying cleanly, and unverified clients **fail open on cloud features only**, so enforcing early cost those stale users nothing but cloud sync until they refreshed, and cost the owner nothing. **Standing caveat:** do NOT generalise this. If the owner has said he wants zero disruption to other users, don't enforce early. The call above was his, made knowing the tradeoff. ## The incident that explains the localhost scoping Enforcing App Check **broke the staging build's cloud** ("cloud network failure"). Cause: the dev debug-token guard was scoped to localhost *and* the preview-deploy domain, so every browser hitting staging needed its own debug token registered — unmanageable. **Fix, and the rule it leaves behind: the debug-token guard is scoped to LOCALHOST ONLY.** Staging must authenticate the same way production does, so staging genuinely exercises the production path instead of a bypass. **Do not widen the debug guard beyond localhost** — a debug path that reaches any deployed origin is both a test-fidelity hole and a security hole. ## Passive watch (not a task) If the owner or his brother ever report cloud-save or sign-in failures, **enforcement is reversible** from the Firebase console — set back to Unenforced, then diagnose. Nothing here needs doing until that happens. Related: [[dev-branch-workflow]].