Practice — Case Study: Shipping a Fix with Claude Code, End to End (11 questions)

In the case study, the ledger-events monorepo has a working test runner (pnpm test --filter <package>) that lets Claude write a failing regression test before implementing the pagination fix, and later confirm the fix with a real, re-runnable check.

Now suppose you're debugging the identical symptom — CSV exports intermittently missing rows — in a codebase with no automated test suite at all. There's no test runner to write a failing test against, and no CI to catch a regression later.

1. Rework Phase 2 (Exploration): does the plan still make sense to propose, and does it change shape without a test suite to design verification around?
2. Rework Phase 3 (the wrong turn): without a failing test to prove the timezone hypothesis wrong, how would you actually discover that it didn't fix the bug? Be concrete about what evidence you'd look for.
3. Rework Phase 4 (Implementation): what does "give Claude a way to verify its work" mean when there's no test framework to write tests in? Name at least two concrete substitutes.

In the case study, the first hypothesis — a timezone-based day boundary filter was excluding rows — turned out to be wrong. Claude implemented it, wrote a test, the test still failed, and the session rewound to a clean checkpoint before pursuing the real cause (a pagination cursor race).

Now imagine an alternate universe where the timezone hypothesis had been correct — the fix in Phase 3 actually resolved the bug, full stop, no pagination race involved.

1. In that universe, was any of the work done in Phase 2 "wasted"? Be specific about what would and wouldn't have been used.
2. Was plan mode still worth the overhead it added in that universe, given that the very first hypothesis panned out? Argue both sides, then give your actual answer.
3. What would Phase 5 (generalizing the fix) look like in that universe — would there still be a reason to run a workflow afterward, or does a confirmed, correct fix remove the need?

After the timezone hypothesis is ruled out in the case study, what turns out to actually be causing rows to go missing from the CSV export?

The covering-index migration for the pagination fix used CREATE INDEX CONCURRENTLY instead of a plain CREATE INDEX.

Why did that matter for this specific table?

The session in the case study was running in accept-edits mode, which normally waves through routine file edits without asking. The engineer still reviewed the migration file by hand before approving it.

Why, given that accept-edits was already active?