Construction

season_outlook is published: weeks 2-14, 1720.5 pts. Built in the enricher on the data side, which is a producer step -- the page still only reads it.

recommendations published on 17 weeks, 25 start/sit moves carrying their own arithmetic. Pregame weeks only; a finished week gets none.

provider_comparisons available on all 14 fantasy weeks. The same-rules join is ours against Yahoo's own weekly capture; neither is an outcome.

Yahoo column populated on every player and every TOTAL row across the 14 fantasy weeks. Weeks 15-18 have no Yahoo projection because the fantasy season ends at 14.

§9's dangerous half was already satisfied -- no invented zero -- and the label half now is: the week chip reads Upcoming for every pregame week. The separate 'Upcoming matchup' banner was removed at Sean's request; the chip and the scoreboard already said it.

NOT A BUG — verified. Week 1 is correctly labelled 'Older capture' because the fresh roster capture covers weeks 2-18 only; the generation declares this in its own issue log. The page is reporting a true roster-scope fact.

The rail now reads 'NFL only' on weeks 15-18 and draws them dashed, so the horizon is disclosed even on mobile where the chip label is hidden. The data already distinguished them; the renderer did not.

lineup_alternative published on the 3 actionable weeks. Scenarios are limited to that horizon on purpose -- publishing all 18 put the payload at 19.2 MB and the app aborts its fetch at 15s.

app.js polls /data/maintenance-health-live.json every 60s; it was never shipped, so the poll failed silently. Codex's envelope has max_age_seconds=180 — built for the loopback server that regenerates per request, so it cannot work on static hosting. Replaced with a liveness badge that reads the manifest on the same cadence.

player_week holds no kicker and no defense rows at all. Those positions are scored in kicker_scored (initial and surname, 'E.Pineiro') and defense_scored (no name at all, only the team abbreviation), and Yahoo files a defense under its nickname alone. Two blank cells withheld the starter total for all ten players, because a sum is withheld unless every row has a value. Now: week 1 starters projection 139.81, actual 127.20, Yahoo 143.93, and every TOTAL row on all 18 weeks populates.

forecast-refresh is running its first cycle. Watch for a new generation_id on Maintenance, then confirm deploy-generation ships it and the customer page swaps without a reload.

Every piece is now scheduled but no NEW generation has been produced and shipped yet. Until one is, this is wiring, not a working loop.

Read the nine-desk operating model in full, then sequence it. Not started -- the plumbing comes first.

Sean, 19 Sept: the system Codex defined is the plan of record.

research/playgrain/ -- play-grain warehouse, transition simulator, air-gapped loop. Built 18-19 Sept. Parked until the POR is moving.

Run in parallel, measured against the POR. Adopted only where it demonstrably beats it.

The league feed records no playoff schedule and will not until standings finalise -- fp_league_matchup holds week 1 and nothing else. PLAYOFF_WEEKS in bin/enrich-generation.py is a declared setting sourced to Sean, which is correct for now. A forecast would project the remaining schedule to a seeding and name a likely opponent per playoff week, and it must ship as a forecast with its own scope -- never as a saved matchup. Blocked on nothing; deferred behind the basics.

Sean, 2026-09-19: 'maybe they can be forecasted playoffs based on our projections, but that is low priority right now until the basics are working.' PARKED ON PURPOSE -- recorded so it is not lost, not so it gets built next.

BLOCKED, not skipped. aar_attribution holds 2024 and 2025 and nothing for 2026, and `pw aar --season 2026` refuses with EmptyComparison: no player-week carries a forecast from all seven legacy sources, so there is no common sample. Its own message is the right instinct -- 'an empty result is not agreement'. Unblocking it means filing 2026 forecasts from more than one source into aar_forecasts, which is institute work through the review path, not an edit here.

Sean asked for 'the AAR items that were dropped'. The 20%-from-Yahoo table on the Season Plan answers the substance -- ours, Yahoo's, the gap and the stat line behind it -- but the real AAR is richer: aar_attribution splits an error into variance, regime, volume, share and conversion.

DELIBERATELY NOT BUILT TONIGHT. The inputs exist -- spreads and moneylines for every remaining game now that odds_quote carries prices -- but a Monte Carlo playoff simulation is a MODEL, not arithmetic over saved products, and NFL seeding needs real tiebreaker logic (division winners seed 1-4). Guessing a seed puts a wrong number on a page whose whole claim is that it does not imply a forecast. standings_week also has no 2026 rows, so even the 'actual standings' half shows 2025 -- correctly labelled historical. Wants a decision on method before code.

The Playoffs page is entirely 'Seed forecast pending' / 'Awaiting simulation'.

Customer site: Codex's 60s manifest poll now has a supply. Monitor: polls state.json every 30s and reloads only when generated_at changes, so it never throws away your scroll position to show the same page.

Sean: 'do both urls update without me needing to hit refresh?' The customer app already polled; nothing produced anything new to find, and the monitor had no script at all.

bin/deploy-generation.sh ships whatever `active` points at, with a no-op guard so an unchanged generation is not re-uploaded every 10 minutes, and it writes the 15 legacy .html keys the edge still had cached.

publish_delivery.py builds a release and flips a symlink. Nothing ships it to Cloudflare, so a fresh generation never reaches the site.

Loaded in dependency order: institute.forecast-refresh (4h), ingest-refresh (1h, the job that pulls actuals), deploy-generation (10m), buildsite (10m). publish.sh deliberately left UNLOADED -- it ends in a site-pwa deploy that would revert the Codex site.

34 of 38 launchd agents are on disk and not loaded. Ingest works when run by hand; nothing runs it.

Codex renderer deployed to Cloudflare. app.js and styles.css byte-identical to the chatgpt.site original. Old 15-page site replaced on every route, including the cached ones.

playerweek-build.pages.dev. Same design system, one tab per desk, generated from measurement at render time.

pw refresh ingested Thursday's game. player_week 2026 went from 920 rows in 1 week to 1,705 rows across 2.

Was published as 'not published'. Every ingredient was on disk -- pred_2026_wNN covers 642 players a week, yahoo_proj covers all ten rosters for all fourteen weeks, week 1 is scored -- and only the join was missing. All ten ranked on one basis (our model, Yahoo for K/DST). Mine #2 at 1995.57, 18.26 behind; the optimum's +99.43 clears it, so the page reads FINISH 2nd current / 1st optimised.

Rendered an empty state because plan_moves/teams/plan_weekly had no producer. Five sections now: every start/sit change week by week, the ten-team projected finish, plan by week, and every forecast 20%+ AND 2pts+ from Yahoo with the stat line behind it. The headline splits forced bye swaps (+68.78 across 6) from genuine judgement (+30.68) -- counting bye replacements as insight would have been a lie.

Owner and record were captured nowhere; scrape_yahoo_standings.py now lands them and the page reads 'Sean · 0-1 · 8th'. Every one of the ten league logos was ALSO wrong -- team 10 held Sean's own, team 6 held the Yahoo nav icon -- because the original build keyed off ordering. Logos are now downloaded from the same standings row that yields the record, and all ten hash-match on the live site.

bin/validate-payload.py asks the warehouse whether every blank cell could have been filled (28,554 cells, 0 gaps). bin/verify-live.py asserts the renderer contract against the bytes Cloudflare serves. bin/smoke-page.py loads the page in a real browser and requires five views to render. Each was written after a defect that the previous layer could not see, and each was confirmed against a known-bad input before being trusted.