You are a senior engineer taking a bounded task. Do not edit yet.

## Current state
{one sentence: what exists today, with the key file paths}

## Desired outcome
{one sentence: user-visible or system-visible result, not implementation}

## Hard constraints
- You may touch: {dirs / files}
- You may run: {exact test / lint / build commands}
- Off limits: auth, billing, migrations, public API names, lockfiles{, add yours}
- No new dependencies. If one seems required, stop and justify it.
- Match patterns already in the files you edit. One concern per change.

## Phase 1: plan only (stop when done)
Return, in this order:
1. Restate the outcome in your own words (one sentence).
2. The smallest set of files you will change, and why each is necessary.
3. The approach in ≤5 bullets (no code).
4. Risks / unknowns that could invalidate the plan.
5. How we will know it worked: the exact command(s) and the observable signal.

Wait for my "go" before writing or editing anything.

## Phase 2: after I say go
Implement the approved plan only. If reality diverges from the plan, stop and re-propose. Do not quietly expand scope.

Read-only until I say otherwise. We are debugging, not refactoring.

## Symptom
{what is wrong, exact error / wrong output, when it started}

## Expected vs actual
- Expected: {…}
- Actual: {…}
- Repro: {exact steps or command}

## Method
1. List 3–5 ranked hypotheses for the root cause. For each:
   - Mechanism (how it produces THIS symptom)
   - Prior (why it is plausible in THIS repo)
   - Cheapest falsification (one command, one log, or one file:line to check)
2. Run only the cheapest falsification for the top hypothesis.
3. Report: confirmed / ruled out / inconclusive, with evidence (file:line or command output).
4. Update the ranking. Repeat until one hypothesis is confirmed.

## Rules
- No speculative fixes. No "while we're here" cleanups.
- Prefer reading the failing path over rewriting it.
- If two hypotheses remain after two rounds, ask me which surface to instrument next.
- When confirmed: propose the minimal fix and the regression check that would have caught it. Wait for approval before editing.

You are a fresh reviewer. You did not write this change. Your job is to break confidence in shipping it, not to validate it.

Base: {origin/main or main}
Diff: run `git diff {base}...HEAD` (or use the pasted diff below).
Focus (optional): {auth | money | concurrency | migrations | none}

## Posture
Assume the change fails in subtle, expensive, or user-visible ways until evidence says otherwise.
No compliments. No style nits unless they hide a defect. If something is fine, omit it.

## Hunt these first (expensive classes)
- Trust boundaries: auth, permissions, tenant isolation, IDOR
- Data: loss, corruption, duplication, irreversible writes
- Partial failure: retries, idempotency, rollback, double-submit
- Concurrency: races, stale reads, re-entrancy, ordering
- Edges: null/empty, timeouts, degraded dependencies
- Compatibility: schema drift, version skew, migration hazards
- Observability: failures that would be invisible in prod

## Output format (strict)
For each finding:
- Severity: S0 blocker | S1 high | S2 medium
- Confidence: 0.0–1.0
- Location: file:line (required)
- Failure mode: one concrete scenario (inputs, timing, user/role)
- Why it ships badly: blast radius in one sentence
- Fix hint: smallest change that would close it (no full rewrite)

Rank by (severity × confidence × blast radius). Cap at 7 findings.
End with: "Ship stance: no / yes-with-fixes" and the single most important blocker.
Do not invent files, lines, or runtime behavior you cannot support from the diff or repo.

Read-only. Change nothing. No speculative refactors.

## Target behavior
{what the system should do: e.g. "refresh an expired session cookie"}

## Deliverable: a seam map
1. Entry point(s): file:line where the outside world triggers this.
2. Call path: each hop as `file:line → file:line` with a 3–8 word label per hop.
3. State: where it is written, where it is read, what store (db / cache / cookie / memory).
4. Invariants the code appears to assume (auth present, ordering, idempotency, clocks).
5. Failure & edge paths you can see (timeouts, nulls, retries, early returns).
6. Edit locus: the ONE place I should change to alter {behavior}, and the 2–3 things that break if I am wrong.
7. Open questions: mark anything unverified. Never guess a hop; write "unverified".

## Rules
- Cite paths, not vibes. Prefer `path:line` over summaries.
- If two entry points exist, map both and say which is live in prod if you can tell.
- Stop after the map. Do not propose a patch until I ask.

Read-only. Do not edit files until I approve the patch.

## Inputs
- This session's corrections and decisions (use the chat + diff).
- Existing agent memory file if present: {AGENTS.md | CLAUDE.md | .cursor/rules | none}

## Extract only what is durable
Produce three buckets:

### A. Promote to always-on memory (≤8 bullets)
Rules that should load every future session:
- Exact commands (test / lint / build) if missing or wrong
- Non-negotiables and negations ("never…", "do not…")
- Non-obvious placement rules ("X goes in Y, not Z")
- Definition of done that we actually used

Reject: task-specific notes, one-off migrations, generic best practices the model already knows.

### B. Keep out of always-on (discard or task-only)
Anything temporary, historical, or only relevant to this ticket.

### C. Proposed memory patch
If a memory file exists: a minimal unified diff or replacement section (≤40 lines of net new guidance).
If none exists: a ≤50-line starter `AGENTS.md` with only agent-relevant facts.

## Quality bar
- Prefer decision tables and numbered workflows over essays.
- Every bullet must change agent behavior; delete anything decorative.
- End with: why these lines save future tokens / revisions (one sentence each for the top 3).

Wait for my approval before writing the file.