Setting Disconnected Not Missing

1. "Make X dynamic" often isn't missing a setting — it's a disconnected one. Check the consumer before you build the producer. A dial wired to nothing looks identical to a working one until you trace the wire. 2. Follow the value to its point of use. A config value's bug almost always lives where it's read (or should be), not where it's defined. 3. When code doesn't set a field, something else does — a default or a trigger. "Absence of an assignment" is itself a clue, not a dead end. 4. Prove the gap with live data. 340 vs. the default made an abstract worry concrete in one request. Reasoning tells you where to look; a query tells you you're right. 5. Shared invariants belong at the convergence point. Two clients, one database → the rule goes in the database.

Signals: 1 concept captured → concepts/setting-disconnected-not-missing (the methodology + the 5 transferable lessons + the meta-lesson about iOS↔Supabase seams + the architectural principle of pushing invariants down), 0 entities, 0 facts. Captured silently per WRITES SILENTLY preference. The user's framing — "the method matters more than the specific fix" — is the canonical reference; the page documents the methodology so future sessions can apply the pattern to other "make X dynamic" requests.

The architectural principle: push shared invariants DOWN to the layer where all paths meet. The trigger is in the database — same database that both clients write to. If the rule were in the iOS client, the web client would still be broken. If the rule were in a single Edge Function, the direct-to-DB admin path would still be broken. The database is the only layer both paths converge through.