DIME
Get the picksJoin

FEEDBACK · findings note

do not let scope creep turn a small task into a deep refactor

Stop and check in when an "add X" task starts cascading into multi-file refactors. The user has rejected this twice in one session.

← All findingssource · memory/feedback_scope_creep.md

When the user asks for "add WNBA support," do not propose:

  • Refactoring NBA into a plugins/basketball/ shared core (rejected 2026-05-08 — service is plugin-per-sport by design).
  • Renaming three_pm → threes and removing three_pa/ftm/fta from prop_prediction_generator.py under the same PR (cascades through 14 test files, models, defensive rankings — user pulled the brake).

Why: The user explicitly rejected my "Refactor to shared basketball core" idea after I'd already started planning around it, and pulled the brake again when "wire NBA/WNBA/MLB to sportlib" started touching prop_prediction_generator.py. Cascading refactors under a different PR's banner = regression risk + scope confusion + unreviewable diff.

How to apply: When the user says "add a feature for new league/sport," the safe scope is:

  1. Register in contract / ACTIVE_LEAGUES
  2. Plugin scaffold + sport-data-service client
  3. Wire to sportlib for prop_types/active_months
  4. Stop. Don't touch existing leagues' prediction logic.

Bigger refactors (renaming stat keys, removing deprecated fields, extracting shared cores) are their own focused PRs with proper test baselines. When I notice scope creeping, surface it explicitly with a "stop here vs. push through" question rather than charging ahead. The user values that callout — they pulled the brake both times when I did.

Particularly avoid charging ahead after the user has answered "push through" — they may not yet see the cascade scope I'm about to surface. Surface the scope first, let them re-decide.