refactor(pressure-test): main context is the main brain; subagents are scoped instruments

README.md

@@ -190,7 +190,7 @@ Greybeard's two flagship slash commands are **`/pressure-test`** and **`/sidenot
 
 ## The `/pressure-test` command
 
-[`commands/pressure-test.md`](./commands/pressure-test.md) is a Claude Code slash command that runs the §5 decision test on demand: pressure-test the approach on the table against **scalable / long-term / efficient** — *whatever is scalable, long term, and cannot be done in a more efficient way* — and get one decisive recommendation, with stale-time-budget shortcuts called out. It fans the grounding out to parallel subagents — one per pillar and per load-bearing claim, each gathering its own evidence in a fresh context that can't inherit the session's anchoring bias — then synthesizes the verdicts into one recommendation. No token-thrift shortcuts: this command exists for crucial decisions, and invoking it is the signal that the stakes warrant the fleet.
+[`commands/pressure-test.md`](./commands/pressure-test.md) is a Claude Code slash command that runs the §5 decision test on demand: pressure-test the approach on the table against **scalable / long-term / efficient** — *whatever is scalable, long term, and cannot be done in a more efficient way* — and get one decisive recommendation, with stale-time-budget shortcuts called out. The main context runs the test and owns the ruling; subagents are scoped instruments, spawned only where a check benefits from being outside the session — challenging a belief the conversation already holds (a fresh context can't inherit its anchoring), or online research and docs verification that parallelize while the main agent keeps reasoning. Never the test wholesale: a main agent that only orchestrates stops being the main brain.
 
 ```bash
 mkdir -p ~/.claude/commands

commands/pressure-test.md

@@ -19,12 +19,12 @@ The governing question for the choice: **whatever is scalable, long term, and ca
 - **But don't optimize away the domain object.** "Reuse the primitive one layer down" is a virtue *until it deletes the thing the feature is actually about*. The trap: fusing a **property the feature requires** (email-binding, single-use, consent) with an **implementation that happens to carry it** (a Supabase magic link, an auth token, a signed URL) — once fused, reuse looks automatically correct, and you end up borrowing an *ephemeral auth artifact* to stand in for a *durable domain record*. Separate the two: name the property, then ask whether the primitive models the property or merely coincides with it today. An auth link is not an invitation; a cache key is not a job; a session is not an audit trail. When the feature needs a **lifecycle** — revoke, resend, expire independently, run several concurrently, record who accepted and when, ask consent before acting — that lifecycle *is* the domain object, and a first-class record (a row + a `requested → active / declined` status) is the correct construct, not gold-plating. Reuse that has no place to hang those states pushes the real cost into fragile edges (24h expiry, single-use collisions, "already registered", silent auto-accept). Adding well-chosen, durable state is sometimes the *efficient* move, not the wasteful one.
 - **A reused state inherits every behavior already attached to it — enumerate them before you adopt it.** The bullet above warns against reuse that *deletes* the domain object; this is its mirror — reuse that silently *inherits* one. When the approach repurposes an existing status / flag / enum / column to mean something new (`trialing` to mean "currency-migration bridge", `pending` to mean "awaiting review", `archived` to mean "soft-deleted"), it doesn't just carry the one property you wanted — it fires *everything* that already reads that value: webhooks, cron jobs, entitlement gates, billing/credit grants, UI branches, cleanup sweeps. Before committing, **grep every consumer of that value** (`grep -rn 'trialing\|is_trial'` across every layer) and list what each one does with it; a behavior you never intended rides along for free. The tell that you skipped this: you validated the *one* behavior you wanted and discovered the others reactively — one bug (or one "wait, why did all of them get free credits?") at a time. The reused state's full behavior set is part of the decision, not a surprise you pay for after. And when you *do* adopt it, verify by diffing the **whole system's response** (side-effect tables, ledgers, related rows) before/after — not just the fields you predicted would change; the inherited behavior only shows up in the diff you didn't expect.
 
-**Fan out the grounding — one subagent per pillar and per load-bearing claim.** If this harness can spawn subagents (Claude Code's Agent/Task tool), don't run every check inside this context — delegate, in parallel:
+**The main context is the main brain — subagents are scoped instruments, not the test.** Run the test itself here: define the pillars, read the code, weigh the tradeoffs, own the ruling. Most of the thinking — and most of the token spend — belongs in this context. Spawn a subagent (where the harness supports it) only for a small, sharply-scoped check that genuinely benefits from being *outside* this context:
 
-- Give each subagent the decision under test plus the *one* pillar or claim it owns, and instruct it to gather its own evidence — grep the repo, read the actual files, pull current docs — and return a verdict: pass/fail, the first thing that breaks, and the evidence it rests on. Verdicts without evidence don't count.
-- **Isolation is the point, parallelism the bonus.** A fresh context has no session priors — it cannot anchor on the subsystem this conversation happens to have been working in, which is exactly the wrong-subsystem trap the sweep bullet above describes. Checks that guard against *this session's* bias (the symptom sweep, the load-bearing claim, per-claim grounding) benefit most from a clean context.
-- **Don't economize on the test itself.** This command exists for crucial infrastructure and product decisions — being invoked *is* the signal that the stakes warrant the fleet. Fan out every pillar and every load-bearing claim; the cost of the subagents is noise against the cost of shipping the wrong architecture. Skip the fan-out only where the harness genuinely can't spawn subagents — then run the full test inline, not a lighter one.
-- **Synthesize here.** Reconcile the verdicts into ONE recommendation in this context. A verdict you can't trace to its evidence is a claim to re-verify, not a vote to count — and conflicting verdicts mean a pillar wasn't defined concretely enough: define it and re-rule, don't average.
+- **Challenging a belief this session already holds.** A load-bearing claim minted in this conversation gets an adversarial check from a fresh context — a clean context cannot inherit the anchoring that produced the belief (the wrong-subsystem trap above). One claim in, refute-or-confirm with evidence out.
+- **A different part of the brain.** Online research, current-docs verification, prior-art sweeps — work that is a different *activity* from ruling, and parallelizes cleanly while you keep reasoning here.
+- **Evidence, not authority.** A subagent's verdict counts only by the evidence it carries — one you can't trace to its evidence is a claim to re-verify, not a vote to count.
+- **Never delegate the test wholesale.** A main agent that fans out every pillar and merely collates becomes a dispatcher — slow, and lazy in the way that matters: no one is actually holding the whole decision. If you catch yourself spawning instead of reasoning, stop and reason.
 
 **Define the three pillars for *this* decision — if they're not already clear.** Before judging, make each concrete for the case at hand: