Assess whether a proposed implementation change will require a database reset, and guide batching decisions to avoid wasting optimization runs.

## When to use this command

Run `/planChange` before starting any task that touches:
- The composite scoring formula (`config.py:composite_score()`)
- The trailing stop simulation logic
- The data export pipeline (new signals added, columns renamed, normalization changed)
- `calculate_metrics()` return values
- `generate_signals()` output structure

## Steps

1. **Summarize the proposed change** in 1–2 sentences and identify which of these categories it falls into:
   - **DB-invalidating**: scoring formula, trailing stop sim, data export column changes → requires `reset_results.py --apply`
   - **DB-safe**: new weight param added (only affects new runs, old runs stay valid), UI changes, documentation, tooling
   - **Uncertain**: ask the user to clarify before proceeding

2. If the change is **DB-invalidating**, show this message:

   > ⚠️ **This change will require a database reset.**
   >
   > Proceeding without a reset means old DB rows were scored under different rules and will bias the sweep dashboard, sign-stability analysis, and Optuna sampling. Winner files from before the reset will also be stale.
   >
   > **Before implementing**, consider:
   > - Are there other pending DB-invalidating changes in the backlog that could be batched into this reset? (Check `docs/backlog.md` for items tagged `[DB-invalidating]` or involving scoring/data changes.)
   > - How many hours of optimization data will be lost? Run: `python3 mine_sweep_db.py` to see current row counts.
   > - Is now a good time to reset, or should this change wait until after a planned long optimization run completes?
   >
   > When ready to proceed:
   > ```
   > python3 tools/reset_results.py          # dry run — shows what will be deleted
   > python3 tools/reset_results.py --apply  # actually delete
   > ```

3. If the change is **DB-safe**, confirm:
   > ✅ This change does not require a database reset. Old optimization results remain valid.

4. Ask the user: "Would you like to proceed with this change, batch it with other pending changes, or defer it?"

5. Only begin implementation after the user confirms.

## Checklist before any DB-invalidating implementation

- [ ] Checked backlog for other pending DB-invalidating changes to batch
- [ ] Checked current DB row counts (`python3 mine_sweep_db.py`)
- [ ] User has confirmed this is a good time to reset
- [ ] `reset_results.py --apply` will be run immediately before implementing (or immediately after, before any new optimization starts)