Add Formula Data Analysis-style charts to the F1 predictor dashboard and validate how much FP analysis helps predictions. Requested by Elmar from Telegram. Scope: 1. Dashboard...
StateDoneNext ActionClosedOwnerLuciRuntimeClosedAge5d ago
Ticket is done; runtime is closed.·profile claude_opus_1m_medium
Description
MC-4824
Add Formula Data Analysis-style charts to the F1 predictor dashboard and validate how much FP analysis helps predictions.
Requested by Elmar from Telegram.
Scope:
1. Dashboard charts:
- Add visual charts for FP analysis where data exists: weighted FP pace, ideal lap, long-run pace, tyre degradation, corner speed, load factor/lateral grip, aero/PU triangulation.
- Dashboard should handle FastF1 deep data vs OpenF1 fallback gracefully: show richer telemetry charts only when rows exist; show explanatory fallback text otherwise.
- Keep tables if useful, but add chart visuals rather than table-only views.
2. Confirm model integration:
- Verify/document that FP/F1DataAnalysis-style signals are consumed in prediction scoring, especially pipeline/run.py -> signals/fp_pace.json/aero_pu.json -> pipeline/05_model.py.
- Add/adjust tests if needed so these signals cannot silently stop affecting scoring.
3. Actual race telemetry validation:
- For Monaco first, compare free-practice analysis signals against actual race telemetry/results.
- Measure whether FP signals were directionally on target: FP pace vs race pace, ideal/corner/load/aero signals vs actual race performance where telemetry permits.
- Summarize misses and recommended weighting adjustments.
4. Season backfill plan with FastF1 rate-limit safety:
- Do not query the whole season in one run.
- Add a rate-limited/backoff-capable script or documented workflow to backfill one race at a time, preferably using cached existing data first.
- Propose which completed races to run next after Monaco.
Acceptance criteria:
- Tests pass.
- Dashboard verified locally or via available route.
- At least Monaco validation report produced.
- Clear answer to Elmar on whether current FP analysis changed predictions and whether weights need adjustment.
Expected check-in: today after first implementation/validation pass.
Activity
done
INTERACTIVE
Luci is working...
Details —
Done
· High
· Luci
▼
SState
Done
Closed
PPeople
TTiming / Details▼
api (human)
Mission Control
5d ago
5d ago
Advanced / Operator evidence
RRouting owner
ROperator console
Ticket is done; runtime is closed.MC is visibility-only. Hermes Luci launches and gates work outside MC, then mirrors evidence/status here.
WWorkflow
Start Dev Review + QA ▾
Select phases to include:
Agents
Review Gates
Decision
WAT routing: choose an agent, review gate, or decision. Buttons use the live runtime when one is attached.
[visibility-only] Queued message recorded for Hermes Luci. MC did not claim the ticket or spawn a runtime.
luci-board-manager5d ago
[visibility-only controller] Routed this Luci-owned technical ticket to internal Hermes Kanban card t_3bfdc3b5 (assignee codexbuilder) in isolated worktree /home/lucienne/workspace/state/kanban-worktrees/mc-4824-f1-analysis-charts. MC remains the human-facing ledger; no MC runtime/pickup was launched. I will mirror the worker evidence back here when the card completes.
luci-board-manager5d ago
[visibility-only controller] Internal Kanban card t_3bfdc3b5 was blocked after a read-only investigation. I added a continuation instruction, unblocked the same card (no duplicate), and dispatched codexbuilder again. Verified active run 138 with worker PID 2082933 in isolated cwd /home/lucienne/workspace/state/kanban-worktrees/mc-4824-f1-analysis-charts. MC remains waiting on kanban_active:t_3bfdc3b5; no MC runtime/pickup endpoint was used.
luci-board-manager5d ago
[visibility-only controller gate] I independently reviewed the completed Kanban output and did not close this ticket. Blocker: the new FP signal guard fails open when `signals/fp_pace.json` has no `_metadata`, so `/api/fp-analysis/:race` can report global/unknown signals as usable for unrelated races. I created and dispatched follow-up internal Kanban card t_65d16bf8 in the same isolated worktree to make the guard fail closed, add tests for missing/mismatched/matching metadata, rerun validation, and push the branch. MC remains waiting on `kanban_active:t_65d16bf8`; no MC runtime/pickup endpoint was used.
luci-board-manager5d ago
[visibility-only controller gate] Closed MC-4824 after controller verification and landing. The internal Kanban follow-up t_65d16bf8 was blocked on a push-auth claim, but a controller dry-run/real push succeeded. Evidence: commit 992751d10506689440f26826539745ef7cd985f6 (`fix: fail closed stale FP signals`) is now pushed to `origin/master` of conrelma/f1-predictor; `origin/master` contains the prior dashboard/telemetry work and this fail-closed guard. Verification rerun from isolated worktree `/home/lucienne/workspace/state/kanban-worktrees/mc-4824-f1-analysis-charts`: `node --check dashboard/server.js`, `node tests/test_dashboard_fp_api.js`, and `HOME=/home/lucienne PYTHONDONTWRITEBYTECODE=1 uv run --with pytest pytest -q -p no:cacheprovider` => 84 passed. Local dashboard smoke: `/` returned HTTP 200 and `/api/fp-analysis/japan-2026` returned HTTP 200; Monaco validation/backfill report exists at `docs/monaco-2026-fp-telemetry-validation.md`. No MC runtime, pickup, send, claim, harvest, switch, or retry endpoint was used.
luci-board-manager5d ago
[visibility-only controller correction] I reopened MC-4824 after a stricter acceptance check: the pushed dashboard/scoring work and fail-closed guard are landed, but the Elmar-facing acceptance answer still needs the final Monaco backfill/API proof and explicit FP-impact/weighting recommendation. Created and dispatched internal Kanban card t_1d067e62 to codexbuilder in isolated cwd `/home/lucienne/workspace/state/kanban-worktrees/mc-4824-f1-analysis-charts`; verified worker PID 2121594 is running in that cwd. MC remains visibility-only and waiting on `kanban_active:t_1d067e62`; no MC runtime/pickup endpoint was used.
luci-board-manager5d ago
[visibility-only controller gate] Closed MC-4824 after independent verification of the final internal Kanban follow-up t_1d067e62. Evidence checked by controller: origin/master contains 7dc7cc05b94202367da99be8d579298dbbc77ba7 and prior guard commit 992751d10506689440f26826539745ef7cd985f6; isolated worktree was clean; `node --check dashboard/server.js`, `node tests/test_dashboard_fp_api.js`, and `PYTHONDONTWRITEBYTECODE=1 PYTHONPATH=. python3 -m pytest -q tests/test_fastf1_cache_bypass.py tests/test_openf1_fp_summary.py tests/test_next_race_fp_quality.py` passed (17 pytest tests plus node checks); live local API smoke `GET /api/fp-analysis/monaco-2026` returned HTTP 200 with summary, FP1/FP2/FP3 sessions, and fail-closed signals_status usable=false. Elmar-facing answer verified at `docs/monaco-2026-fp-impact-answer.md`: FP backfill did not change prediction/scoring, Monaco score remains 8.0/22.5, and no immediate FP weight adjustment is recommended from this single validation sample. No MC runtime/pickup/send/claim/harvest endpoint was used.