| name | heater-appb-manager-rec-review |
| description | Use when assessing whether ANY HEATER recommendation output (lineup/start-sit, trades, free agents, streaming, draft) actually makes sense to enact as the manager of Team Hickey in the FourzynBurn league — "does this rec make sense?", "should I trust this?", "review the optimizer's answer", or before acting on any surface's advice. The harness the per-surface review skills plug into. |
Manager's Recommendation Review — the assessment harness
Purpose: judge a feature's OUTPUT (not its code) the way a competent fantasy manager would — legal under league rules, consistent with all available data, consistent with the engine's own diagnostics, and worth enacting. Per-surface checklists: heater-appb-lineup-rec-review, heater-appb-trade-rec-review.
League truth (FourzynBurn — assess against THIS, from code not memory)
| Rule | Value | Source |
|---|
| Format | 12-team Yahoo H2H Categories, 26 weeks, playoffs top-4 | LeagueConfig (src/valuation.py); _PLAYOFF_SPOTS=4 |
| Categories | R/HR/RBI/SB/AVG/OBP + W/L/SV/K/ERA/WHIP; inverse = {L, ERA, WHIP} | LeagueConfig — never a hardcoded list |
| Roster | C/1B/2B/3B/SS/3×OF/2×Util/2×SP/2×RP/4×P/6×BN/4×IL (28) | league settings (Yahoo, 24h-TTL cache) |
| Transactions | 10 adds+trades combined per matchup week, FCFS | src/league_rules.py:15 WEEKLY_TRANSACTION_LIMIT |
| Can't-drop | rounds 1–3 picks — restricts DROPS only, trades are legal | league_rules undroppables |
| Weekly IP | minimum 20.0, target ≈53.85 | src/ip_tracker.py:16,20 |
| Days/weeks | Eastern time, Yahoo Mon–Sun weeks | src/et_today.py |
"Use all data available" means, concretely
- The full payload — recs ship their own diagnostics (grades, warnings, reasons, components,
adds_remaining_this_week). Read every field before judging.
- Freshness first:
get_refresh_log_snapshot() / freshness_minutes — was the rec computed on degraded inputs (Marcel-only projections day, stale rosters, missing Statcast)? A faithful rec on bad data is a DATA verdict, not a bug.
- Pool row for every named player: projections + YTD + L14 + Statcast +
percent_owned + status (load_player_pool()), keyed by mlb_id.
- Context: standings + category gaps + live matchup state (which cats we're winning/losing), probables/schedule for the scope dates (ET), IL/news.
- Live Yahoo verification (standing owner rule): before endorsing any pickup, live-fetch FA availability — never assume a list is current. Same for "partner rosters still contain the players".
- One independent recomputation per assessment — recompute a load-bearing number by hand (e.g. staff ERA = Σer·9/Σip from the payload's own lines). Rate stats aggregate WEIGHTED (heater-appb-fantasy-math-invariants).
Fetch paths: live API with a Clerk JWT (browser console: await window.Clerk.session.getToken(); the scripts/diag_matchup_truth.py pattern) or local uvicorn api.main:create_app --factory --port 8000 against a synced DB, or call the service in a REPL.
Verdict protocol
Per recommendation, a check table (check | pass/fail/unknown | evidence), then ONE verdict:
- ENACT — legal, internally consistent, data-supported.
- ENACT-WITH-CAVEATS — sound but flag the specifics (e.g. acceptance longshot, thin sample).
- DO-NOT-ENACT — a check failed; name it (illegal slot, grade↔surplus contradiction, capturable-without-trading).
- DATA-DEGRADED — the rec is faithful to bad inputs; route to heater-appb-debugging / live-data-honesty, don't enact.
No editorializing (standing owner rule): verdicts are rule- and data-grounded findings, never taste ("this violates the 10-move budget", not "I wouldn't do this"). The final call is always the manager's.
Triage when a rec looks wrong
Wrong given its own inputs → engine/service bug (heater-appb-debugging, note a guard test). Right given degraded inputs → data problem. Conflicts with a league rule → bug + missing guard. Merely debatable → present both sides' evidence and stop. Before filing anything, check heater-appb-known-non-bugs.
When NOT to apply
Not a code-review skill (that's the review pair in heater-appb-workflow) and not for building features. Draft-season surfaces share the harness but their checklists aren't written yet — extend, don't improvise silently.
