Establish cold-safe Jump Jet dragon-core foundation

[danielbrownjr]

Summary

Establishes the current cold-safe Jump Jet product foundation on ESP-IDF for the actual ESP32-S3 target and integrates current main.

The production image remains heater-incapable: no heater GPIO, placeholder heater pin, fan GPIO, PWM hardware, ADC, thermistor conversion, fake board constant, or MOSFET actuation path exists. Logical demand and thermal-management state may be modeled, but delivered physical output is always zero/unavailable.

Product contract

The authoritative contract is now docs/PRODUCT_SAFETY_CONTRACT.md.

• Exactly OFF / MANUAL / AUTOMATIC
• Boot/reset always OFF; mode is not persisted
• OFF removes heat demand without erasing retained configuration; cooldown/fault fan activity may continue
• Retained MANUAL target: 30–50 °C inclusive, default 45 °C, reject rather than clamp
• Read-only dc_prusa; its existing 15-second freshness result is authoritative
• No second Jump Jet freshness timer
• Only exact PRINTING is AUTOMATIC-eligible; all other known/future states fail cold
• Bed-target → chamber-target production policy is TBD, so AUTOMATIC heating remains unavailable/fail-cold
• Watchdog/panic/brownout and suspected stuck-on recovery requirements are mandatory pre-actuation gates
• Browser/API is never the safety boundary

dragon-core

All selected components are pinned to dragon-core v0.32.0 at 4e041d864763d468a50e9649807827dd83dd54bc. This supersedes the earlier PR #51-era commit. Jump Jet consumes dc_prusa's freshness-qualified snapshot directly.

Hardware evidence

Current main is integrated, including docs/hardware/cz4060-characterization.md.

Confirmed standalone facts:

• design basis: 24 V / 200 W / 8.33 A
• sustained: about 189 W / 7.89 A
• no high-current cold inrush
• heater/PTC region about 130 °C steady
• chassis about 74–75 °C steady

Still unvalidated: the complete Q1/F2/PCB copper/connectors/wiring path, installed behavior, and final GPIO/ADC/thermistor/protection/cooldown/recovery values. The authoritative .kicad_pcb is missing. Sanyo Denki 9GA0424P3J001 remains a prototype fan candidate, not BOM-final. Uncharacterized provisional thermal and AUTOMATIC constants were removed.

OTA, diagnostics, and capabilities

OTA is rejected while heating or active thermal management is required. The authoritative guard is rerun immediately before boot selection, followed by image-identity validation.

Diagnostics follow: mode/controller → source/temperature → target → requested → allowed → delivered → dominant constraint → health/degraded/fault.

Capabilities do not advertise unavailable heater/fan control.

Verification

Local:

• host interlock tests, -Wall -Wextra -Werror: pass
• UBSan: pass
• API/product contract: pass
• OTA/status contract: pass
• actuation allowlist: pass
• GPIO/ADC/thermistor compile-out: pass
• cppcheck warning/performance/portability analysis: pass
• whitespace check: pass
• identity/CMake contract: CI (CMake unavailable in the local runner)

CI also builds ESP-IDF v5.3 for esp32s3.

Remaining pre-actuation blockers

Before any actuator is added: authoritative PCB source, complete power-path review/validation, final hardware assignments and thresholds, persistent recovery implementation, physical sensing/fan proof, and bench/HIL fault-injection evidence.

[danielbrownjr]

Two follow-up design questions from the interlock audit. I don't consider either of these merge blockers for the Phase-0 foundation, but I do want them explicitly carried forward rather than becoming accidental policy.

1. Fan-proof semantics

fan_proven == false now latches JJ_FAULT_FAN and denies heat. That is fail-cold and likely the right abstract safety direction, but it also commits us to fan proof -> heater permission before the physical proof mechanism and sequencing are finalized.

We still need to decide what "proven" means on release-intent hardware (tach/RPM threshold, airflow/current sensing, etc.) and how spin-up/proof timing works. I lean toward keeping the prerequisite in the interlock so a future heater path cannot bypass airflow proof, but this should be an explicit design decision rather than an incidental consequence of fixing an unused input.

2. Cooldown behavior during sensor faults

blocked() only commands cooldown fan when sensors_ok() is true, and sensors_ok() requires all required sensors to be valid. Therefore one failed sensor can suppress cooling even if another valid sensor still reports residual heat.

Example: chamber sensor open, outlet/case sensors valid and hot -> heater correctly blocked, but fan output can remain 0 because sensors_ok() is false.

I don't think we should change that casually without defining the fault policy, but I do think we should explicitly decide whether sensor uncertainty should bias toward continued cooling when remaining valid sensors indicate heat.

Again, neither is a Phase-0 merge blocker because the application remains uncommissioned/OFF and has no actuator driver. These are product-safety contract questions to settle before Phase-1 fan/heater implementation.

[danielbrownjr]

Tracked the two non-blocking follow-up safety questions as issues so they survive PR #1:

• Define fan/airflow proof semantics and heater authorization sequence #3 — Define fan/airflow proof semantics and heater authorization sequence
• Define conservative cooldown behavior during sensor faults #4 — Define conservative cooldown behavior during sensor faults

These remain important design/safety work, but are not being treated as Phase-0 merge blockers.