Thermal recipe v2 (sun-only sun matrix); land the stranded #40

[kastnerp]

What

Two commits:

1. feat(recipes): see the campaign one recipe at a time; the thermal phases are stages #40, cherry-picked onto main. PR feat(recipes): see the campaign one recipe at a time; the thermal phases are stages #40 (recipe views, thermal stages, docs/thermal.md, scripts/admit_thermal.py) was merged into feat(recipes): the campaign names what a worker that declares no recipes may take #39's stacked branch claude/recipe-fence seven seconds after feat(recipes): the campaign names what a worker that declares no recipes may take #39 was squash-merged to main, so it never reached main or production (/healthz reports 0.23.0 @ 2b2492b7). The cherry-pick applies cleanly: feat(recipes): the campaign names what a worker that declares no recipes may take #39's squash commit has the same tree as 697715f.
2. The thermal recipe is surf-1008/rad6R0P2-fft-v2; v1 is withdrawn. Version 0.24.1.

Why v2

Eddy3D PR #960 adds -d to the thermal sun matrix (gendaymtx -5 0.533 -m 4 -O1 -d). Without it, every sun also carried the whole Perez sky, so the direct term re-counted about 2.6 % of each sensor's diffuse sky. That is about 1.1 % of total irradiance on open ground and about 30 % of "direct" on a north wall. irradiance.npy and t_surface.npy change. By the contract in docs/thermal.md, that makes a new recipe version, never an edit.

Changes

• docs/thermal.md
  • The recipe is v2 in the table and in the spec.
  • A new Sky row names the three gendaymtx matrices.
  • The telemetry and manifest include radiance.gendaymtx: {sky, sun, direct_sky}, as the Eddy3D v2 node records them.
  • A new Versions section says why v1 is withdrawn and that there was nothing to retire.
• scripts/admit_thermal.py
  • Posts v2.
  • WITHDRAWN names v1.
  • --post refuses while a case of a withdrawn version is still pending or leased, so an old-build node never archives v1 while v2 is being admitted.
• Tests
  • THERMAL is now v2 in test_node_releases.py and test_recipe_views.py.
  • New: a lease never crosses thermal versions, in either direction.
  • New: withdrawn_in_flight counts only pending and leased cases.
  • New: main() refuses with a leased v1 case and proceeds with a done one; the done case is the control.
  • With the guard disabled, the refusal test goes red.
• DOMAIN.md: a recipe's version is part of its name.
• CHANGELOG: v2 is under 0.24.1; feat(recipes): see the campaign one recipe at a time; the thermal phases are stages #40's own entry stays as 0.24.0.

What production held (read-only query, 2026-09-29)

• No case of any surf-* recipe in any state, and no thermal events.
• No worker has ever declared a thermal recipe. Every fleet build predates the Eddy3D thermal runner (5f6dc824, 2026-09-27).
• So v1 needs no retire-or-re-admit decision. The v2 pilot is admitted fresh.

Before merging

• Merging deploys, as Render builds from main. This ships feat(recipes): see the campaign one recipe at a time; the thermal phases are stages #40's dashboard and stages for the first time.
• Version clash: feat(fields): the broker holds the pedestrian wind field itself, per direction #41 (pedestrian fields) also claims 0.24.0. Whichever lands second needs its version bumped.
• Don't lease v2 yet. Wait until:
  • the Eddy3D v2 change is on dev, and
  • the fleet runs a build containing it. Current fleet builds have no thermal runner at all, and the releases table is empty, so the first rollout is manual.
• Set undeclared_recipes first. Set it to the wind recipes before admit_thermal.py --post. It is unset in production, and the script refuses to post until it is set.

Tests

uv run --with pytest --with httpx python -m pytest tests/ --ignore=tests/test_db_postgres.py -q: 826 passed, 0 skipped. After the final CHANGELOG amend, the version tests and the touched files were re-run: 69 passed.

🤖 Generated with Claude Code