Project Modernization Executor

You are executing a project modernization. This prompt has two modes: PLAN and EXECUTE. Start in PLAN mode. Only switch to EXECUTE when the user approves the plan.

═══ MODE 1: PLAN ═══

Read the project and any existing audit outputs (tech debt reports, documentation reviews, architecture maps, repository clean reports). If none exist, perform a quick reconnaissance first.

Produce a modernization plan as a markdown file at `MODERNIZATION_PLAN.md` in the project root. The plan must contain:

1. CURRENT STATE BASELINE
- Run the test suite and record: total tests, pass count, skip count, fail count
- Run dependency audit (`npm audit` / `pip audit` / equivalent) and record vulnerability count
- Run typecheck and record error count
- Run linter and record warning count
- Record current dependency count and how many are outdated

2. PROPOSED CHANGES (organized into waves)
For each wave, list every change with:
| # | Change | File(s) | Risk | Effort | Rationale |

Wave 1 — Quick Wins (< 30 min each, low risk)
Wave 2 — Dependency Updates (minor/patch first, then majors)
Wave 3 — Code Quality (dead code, convention violations, type safety)
Wave 4 — Architecture (structural improvements, boundary fixes)
Wave 5 — Testing & Documentation (coverage gaps, stale docs)

3. WHAT WILL NOT BE CHANGED (and why)
Explicitly list things you considered but decided against. This builds trust.

4. ROLLBACK STRATEGY
How to revert if something goes wrong (branch strategy, commit granularity).

5. ESTIMATED IMPACT
| Metric | Before | Projected After |
- Test count, pass rate, vulnerability count, type errors, linter warnings

STOP HERE. Output the plan and wait for the user to review. Do not execute anything until the user says to proceed.

═══ MODE 2: EXECUTE ═══

Once the user approves (they may modify the plan first), execute each wave:

For every change:
1. Make the change
2. Run typecheck — must pass
3. Run tests — must pass (or document why a test legitimately needs updating)
4. Commit with a descriptive message using conventional prefixes: fix:, feat:, refactor:, deps:, test:, docs:, ci:, perf:

Rules:
- ONE logical change per commit. If you can't describe it in one sentence, split it.
- GREEN-TO-GREEN commits only. Every commit must leave the project in a working state.
- THREE-STRIKE RULE: If a change breaks tests and three fix attempts fail, `git revert` to the last green state, log the failure, and move on.
- Never force-push. Never drop database tables. Never delete data.
- After every 3-5 changes, update `MODERNIZATION_PLAN.md` with progress (check off completed items).

After all waves complete, produce a FINAL REPORT at the bottom of `MODERNIZATION_PLAN.md`:
| Metric | Before | After | Delta |
- Test count, pass rate, vulnerabilities, type errors, linter warnings
- List of completed changes with commit hashes
- List of skipped changes with reasons
- Recommended next steps

CONSTRAINTS:
- Always plan before executing. The plan is the contract.
- The user must approve the plan before any code changes.
- Every change must be verified (typecheck + tests) before committing.
- Prefer the smallest change that achieves the goal.
- Do not refactor code that isn't in the plan. Scope discipline.

PROJECT TO MODERNIZE:
{{Paste the project path or describe what needs modernization}}