Force a written plan before Claude Code touches a multi-file feature

Before touching any file, produce a complete plan for this feature and wait for explicit approval. Do not create, edit, or delete a file, and do not run any command that changes repository state, until the plan below has been written in full and approved — reading files and searching the codebase during planning is expected and encouraged.

FEATURE
Add a saved-searches feature: users can save their current filter combination on the /reports page under a name and reload it later from a dropdown, with saved searches persisting across sessions.

DEFINITION OF DONE
A saved search survives a full page reload and a new login session, appears in the dropdown ordered by most recently used, and reloading one restores every filter exactly as it was saved.

EXISTING PATTERNS TO REUSE, NOT REINVENT
Reuse the existing FilterState type in lib/reports/filters.ts rather than inventing a parallel shape; store saved searches in the existing user_preferences JSON column rather than adding a new table, unless it genuinely cannot hold the data.

ROLLBACK EXPECTATIONS
This should be revertible with a single commit revert; no data migration should be required to undo it, since the column already exists.

WRITE THE PLAN IN THIS EXACT STRUCTURE
1. Restated understanding — the feature in two or three sentences, including any ambiguity in the request being resolved a specific way, and how, so a disagreement surfaces now rather than after the code is written.
2. Files touched — every file expected to be created or modified, grouped as new versus existing, each with a one-line reason it needs to change.
3. Build sequence — the order changes will be made in, and why that order; name any two steps that could happen in parallel versus any step that genuinely depends on a prior one finishing first.
4. Interfaces and contracts — every function signature, exported type, API shape, or database column this feature adds or changes, written out in full before any implementation, since this is the actual coordination surface between files that a plan is supposed to catch problems in before they exist as bugs.
5. Risk points — the two or three places most likely to break something outside this feature's obvious scope, and specifically what will be checked, and how, to confirm they did not.
6. Explicitly out of scope — anything a reasonable person might expect this feature to include that this plan is deliberately not doing, stated so it cannot be silently assumed later to have been forgotten rather than excluded on purpose.

End the plan with the exact sentence: 'Waiting for approval before making any changes.' Do not proceed past that line under any circumstance, including a case where the plan seems obviously correct and re-confirming it feels redundant — the point of the stop is that 'obviously correct' is exactly the judgment a plan review exists to check, not to skip.

IF THE PLAN CHANGES MID-IMPLEMENTATION
If, while implementing an approved plan, a genuine reason emerges to deviate from what was approved — a file needs a change that was not listed, or an interface needs a different shape than planned — stop, state exactly what changed and why, and wait for approval on the delta before continuing, rather than quietly implementing the deviation and mentioning it only in a final summary.