Control path: safety-critical changes (watchdog disable / max_temp_c) apply silently — rollback checks liveness, not thermal protection

[VijitSingh97]

Context

The control path (#236) applies a staged change, then rolls it back if the miner doesn't come back to a live hashrate — the terminal status is rolled_back with reason "miner did not return to a live hashrate." That liveness gate protects against a change that stops mining.

The concern

The rollback gate checks hashrate liveness only — not thermal safety. But the writable allowlist includes watchdog and max_temp_c, which are the rig's thermal protection. So:

• POST /apply {"watchdog": "disabled"} disables the thermal cutoff. The miner keeps hashing → liveness check passes → the change is recorded applied, not rolled back. A safety mechanism was removed and the system reports success.
• POST /apply {"max_temp_c": 999} raises the ceiling past anything real — same story: mining continues, so it "succeeds."

Because Pithead now exposes these as one-click edits from the dashboard (pithead#185), a fat-finger or a compromised control channel can silently strip a rig's thermal protection, and neither RigForge nor Pithead treats it as anything but a normal successful apply.

The ask (your call on the mechanism — flagging the safety gap)

Give safety-relevant changes special handling on the RigForge side, e.g. one or more of:

1. Refuse to fully disable thermal protection via the control path — allow tuning max_temp_c within a sane band, but reject watchdog: disabled / an absurd max_temp_c from the remote control path (local rigforge.sh on the box can still do it deliberately). Cleanest: the control path is for tuning, not for removing safety.
2. Or flag it loudly in the /status result (e.g. a warnings: ["thermal protection disabled"] field) so the consumer can surface a prominent confirmation, and keep an audit trail.
3. Or extend the post-apply verification to also confirm the watchdog is still armed / temps are within ceiling, and roll back / warn if a change left the rig thermally unprotected.

We don't need a specific one — this issue is to make a deliberate decision so "disable the thermal cutoff" isn't silently a successful remote apply.

Recommended default (Pithead's ask — implement this unless you have a reason not to)

Pithead is happy to dictate the safe default so this isn't a blocking "decide" — do Option 1 +
Option 2 together:

1. Refuse to remove thermal protection via the remote control path. In the control receiver's
   validation (util/control-server.py, alongside the WRITABLE allowlist check) and/or the applier's
   parse_config gate (rigforge.sh:456-472), reject a staged change that:
   • sets watchdog to a disabled value (disabled/false/off/none/""), or
   • sets max_temp_c to empty/absent (no cutoff) or outside the existing safe band 40–110 °C
     (parse_config already enforces 40–110 for a set value — the new rule is that the remote path
     may not unset it or disable the watchdog).
     Return 400 with a clear reason (e.g. "watchdog/max_temp_c cannot be disabled via the remote control path; change it locally on the rig with rigforge.sh if intended"). A local rigforge.sh apply on the box keeps full control — the operator is physically present and deliberate; only the
     remote, one-click path is constrained.
2. Also surface it in /status (defense-in-depth + audit). When a change touches watchdog or
   max_temp_c at all, add a warnings: ["thermal protection changed: …"] field to the status.json
   _control_status writes (rigforge.sh:3646), so even an allowed tightening is visible to the
   operator and Pithead can show a confirmation. (This also gives Pithead a signal to require an extra
   confirm on the dashboard side.)

This keeps the control path a tuning channel, not a safety-removal channel, while leaving the
local CLI fully capable. If you choose a different mechanism, the acceptance criteria below still stand.

Acceptance criteria

• A deliberate decision on how the control path treats safety-critical changes (watchdog disable, out-of-band max_temp_c).
• At minimum, such a change is either refused via the remote control path or clearly flagged in the /status outcome (not silently applied).

Reference

Surfaced by the pithead#185 security review. Producer: #236 (control path) + the apply/rollback logic in rigforge.sh.