scalable: sweep the whole repo for the symptom before hypothesising where it lives

commands/scalable.md

@@ -11,6 +11,7 @@ The governing question for the choice: **whatever is scalable, long term, and ca
 
 - For this **infra/tech decision**, research how established services and competitors solved the same problem — engineering blogs, postmortems, talks, and case studies are fair game here. Prior art is signal.
 - Verify any **fact** you lean on — an API, a limit, a price, current behavior — against a primary source (official docs, the actual source code), not a remembered version or a random blog. When a docs-retrieval tool is available — Context7, a `find-docs` skill, an MCP docs server — use it to pull the latest docs instead of recalling them.
+- **Sweep the whole repo for the symptom before you hypothesise where it lives.** Before deciding *which* subsystem owns the problem, grep/semantic-search the entire codebase for the reported symptom itself — the user's literal words, the error string, the observable behaviour (e.g. every place that can emit "not available / not ready / refused", every `status`/guard early-return on this entity). Enumerate *all* the sites that could produce it across *every* layer, with no assumption about which one is at fault, then rule per site. Anchoring on the subsystem you happen to have been working in is the most common way a careful, well-grounded ruling lands on the wrong code — and the volume of grounding you did there makes the wrong-subsystem conclusion *feel* solid. Narrow to the load-bearing claim only after the sweep.
 - Read the actual code and architecture this touches before ruling — locally correct but architecturally wrong is still wrong. That means the exact file the change runs through, not only its neighbors — reading everything *around* the target and inferring the target by analogy is the most seductive way to skip this.
 - **Ground per claim, not per session.** Verifying four neighboring things doesn't transfer to the one load-bearing claim. The volume of grounding you've done makes the unverified claim *feel* as solid as the rest — it isn't. Isolate the single claim the ruling rests on and verify *that* one directly: "the thing this touches is built like its neighbors" is not evidence about the thing it touches.
 - **Do the cheapest decisive check yourself — don't defer it.** If one file (a `wrangler.jsonc`, an entrypoint, a config) would settle the load-bearing claim, open it. Ending your turn by asking the human to confirm what a file you could have read answers is the same deferral repeating one turn later.