Fix the auth bug in auth.ts

Debug and resolve authentication failures in auth.ts until the issue is resolved.

prompt
→ Claude Code
/ralph-loop "Fix the auth bug in auth.ts" --max-iterations 10
claude-code

Use this when

You have a reproducible authentication failure isolated to one file and a test or manual check that proves when it is fixed. Best for a known-bad symptom (a failing login, a rejected token) rather than open-ended "make auth better" work.

Done when

✓ Exit on the specific auth test or reproduction case passing, not on the agent asserting the fix. Re-run the full suite before merging — auth changes routinely break session and middleware tests that the loop never looked at. If the cap is hit, treat the run as a failed diagnosis and read the diff before rerunning.

Why it works

A ralph-style loop re-reads the file and its failure output on every pass, so each attempt starts from the current state rather than a stale plan. The --max-iterations 10 cap is what makes it safe to leave running: a bug that resists ten passes is a design problem, not a typo, and it should surface to you instead of burning more turns.

Source: pedromeneres ↗graded C · 55/100 — how grades work →

More debugging loops

Memory leak hunt

Loop/goallooprepoB

Drive a suspected memory leak to ground: reproduce growth under a repeated workload, capture heap snapshots, and fix the retention until memory stays flat.

prompt
→ Claude Code
/goal heap usage stays flat (within 5%) across 500 repetitions of the failing workload in the leak-repro script — capture heap snapshots before and after, identify what is being retained and by which reference chain, fix the leak, and re-run the repro to confirm; stop after 10 turns
debuggingmedium risk

Rewrite every user-facing error

Inventory user-visible errors, replace internal or confusing text, and prove each reachable error state reads clearly.

prompt
→ Claude Code
Find and improve every user-visible error message within [repository, product, or named scope]. If no scope is supplied, use the user-facing surfaces in the current repository and state any exclusions before editing. Inventory error strings in source code, surfaced API or client errors, and reachable browser states. Record each one in a CSV with its location, trigger, current copy, user risk, proposed replacement, implementation status, and verification result. Rank the errors by user harm. Rewrite one coherent group at a time using plain language and a useful recovery step when one exists. Do not expose provider names, stack traces, internal identifiers, or implementation details. After each change, run the relevant tests, exercise the affected state in a real browser when possible, and search again for raw or internal error text. Do not mark an unreachable state as verified. Stop when every row is verified or explicitly blocked. Finish with the CSV, changed files, test evidence, browser evidence, and blocked items.