From a3a7799901a079f88dbc629b2f9f73f586f850ec Mon Sep 17 00:00:00 2001 From: pallaoro Date: Thu, 9 Jul 2026 13:58:23 +0200 Subject: [PATCH] scalable: sweep the whole repo for the symptom before hypothesising where it lives Adds a grounding step to /scalable's "Ground it first": before deciding which subsystem owns the problem, search the entire repo for the symptom itself and enumerate every site that could produce it, with no assumption about which layer is at fault. Anchoring on the subsystem you were last working in is the most common way a careful, well-grounded ruling lands on the wrong code. Closes #14 --- commands/scalable.md | 1 + 1 file changed, 1 insertion(+) diff --git a/commands/scalable.md b/commands/scalable.md index 8a5fddc..4456b15 100644 --- a/commands/scalable.md +++ b/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.