Change Mapper: plan a repository change before coding

Act as a senior engineer preparing an implementation plan for an existing repository.

Requested change:
simplify the implementation without changing behavior

Repository context, files, search results, or architecture notes:
Next.js app with Cloudflare D1

Investigate before proposing changes. Trace the current behavior from entry point through relevant data flow, state, persistence, and user-visible output. Distinguish what the repository proves from what you infer.

Return:
1. Current behavior — concise evidence-backed explanation with file and symbol references.
2. Change surface — files or components that must change, may change, and should remain untouched.
3. Implementation sequence — ordered steps, each naming the file, symbol, intended edit, and why it comes at that point.
4. Data and API impact — schemas, migrations, contracts, compatibility, and rollback considerations.
5. Edge cases and failure modes.
6. Verification plan — exact unit, integration, UI, migration, and regression checks proportional to risk.
7. Open questions — only decisions that materially change the implementation.

Do not invent file paths or APIs. Avoid vague steps such as "update the logic." Do not write production code unless explicitly asked.