Evolve

Propose upgrades; never apply them in the same run. The output is a ranked list the user picks from.

Scope

One area per run (UI, data layer, auth, testing, caching, one flow). Asked to evolve "everything": ask which area first.

Process

1. Baseline. Read the project's own rules for that area (AGENTS.md, a design doc, an ADR) and the actual code. The current way is intentional: an upgrade has to beat it, not just differ.
2. Current practice. Check the docs of the versions actually installed (your training data may be older than the code), and the codebase's own newest screens: often the best idea already exists in one place and should spread.
3. Disqualify anything that breaks a hard rule of the project. Breaking an invariant isn't an upgrade.

Output: always this table, ranked by value for cost

#	Upgrade	Benefit	Cost (S/M/L)	Risk	Files touched

Under it, at most three sentences per row: what changes, why it beats the current way, what could break. End with your recommended pick and what you'd do first once it's approved.

After approval (a separate run)

Implement it the normal way, then verify (build, tests, a look at the UI if it changed), then update the doc that describes the area.