pressure-test

Run the decision test on $ARGUMENTS — or, if that's empty, on the approach currently on the table in this conversation.

The governing question for the choice: whatever is scalable, long term, and cannot be done in a more efficient way.

Ground it first — don't judge from priors. A prior isn't only stale training data — it's also a conclusion you minted this session from neighboring code. The second kind is more dangerous: it feels freshly earned, so it rides on the credibility of everything else you verified. Verify before ruling.

• 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.
• Look down the stack, not just sideways. Before designing any new state — config keys, DB columns, env vars, endpoints, files — search the framework / platform / library you build on (and the rest of this repo) for a native primitive that already models this concern. The leanest correct option is frequently one that already exists one layer down; reinventing what the host exposes is the most common efficiency miss. Verify it against the dependency's actual source, not its docs alone.
• 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 enumeration is not the verdict — price each behavior: wanted (a feature you'd otherwise build yourself — an approval gate on a doc that needs approval, search over a doc worth finding), neutralizable (name the exact switch that turns it off), or harmful. Reuse loses only if a harmful behavior survives neutralization; a list where most behaviors are wanted is an argument for reuse. The tell you skipped pricing: "none fatal alone, but together they say no" — a count of behaviors standing in for a judgment of them, which quietly biases every ruling toward building new state, the exact miss the efficiency pillar exists to catch. 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.