From ebcc55e2ecc0ffd4046b038aed0b4162b1075641 Mon Sep 17 00:00:00 2001 From: serversdown Date: Thu, 24 Sep 2026 19:46:09 -0400 Subject: [PATCH] docs(series4): the schedule<->config coupling is Thor's, not the protocol's In Thor, a schedule entry that starts monitoring forces you to attach a setup, and sending the schedule pushes that setup too, overwriting anything with the same name. The protocol requires none of it. Evidence from the scheduler capture: * The two writes are separate operations, not one transaction. The config write ends at frame 18, Thor sends a fresh POLL preamble, and only then opens the schedule at frame 20. Different commands, different paths: config 0xDA -> 0x68/0x73 -> 0x82/0x83 -> 0x71/0x72 schedule 0x8D -> 0x8E * The schedule stores a length-prefixed NAME, not a config blob. It is a reference, and a reference does not require rewriting its referent. * The config Thor pushed was already on the unit unchanged -- its 2,090-byte 0x71 payload is byte-identical to the previous capture's, zero differences. Thor spent a whole block write re-sending a setup the device already had. So SFM can, with today's protocol: enumerate setups with 0x3F/0x40, write ONLY the schedule when the referenced setup already exists, and push a config only when it is genuinely missing or deliberately edited. Common case drops from 524 + 2090 bytes to 524, and the write disappears entirely. It also removes a real hazard. Because the reference is by name, and a same-name write overwrites silently with an indistinguishable ack, Thor's pattern means scheduling something can quietly rewrite a setup that other schedules or the operator's own work depend on. Validating the reference instead of rewriting the referent avoids the class of problem. Co-Authored-By: Claude Opus 5 Claude-Session: https://claude.ai/code/session_01Ru8Lg9HkkYvX9VWWo65SmL --- docs/micromate_protocol_reference.md | 49 ++++++++++++++++++++++++++++ 1 file changed, 49 insertions(+) diff --git a/docs/micromate_protocol_reference.md b/docs/micromate_protocol_reference.md index 55cf545..a0d9c53 100644 --- a/docs/micromate_protocol_reference.md +++ b/docs/micromate_protocol_reference.md @@ -1322,6 +1322,55 @@ checked whether the unit cares." | Greys out send-to-unit while monitoring | **Thor policy** | The *reason* is real — a push to the active setup overwrites silently. But "the button is grey and you figure it out" is a UX choice, not the only answer. SFM could offer stop → push → restart as one operation, which is what an operator actually wants. | | Names the target with `0xDA` before a config write | **almost certainly required** | The unit has to know which file to write. Closest thing here to a genuine protocol requirement. | +### The schedule↔config coupling is Thor's, not the protocol's + +In Thor, putting "start monitoring" in a schedule forces you to attach a setup, +and sending the schedule pushes that setup at the same time — overwriting +whatever already has that name. **The protocol does not require any of this.** + +The evidence, from the scheduler capture: + +- **The two writes are separate operations**, not one transaction. The config + write ends at frame 18 (`0x72`), then Thor sends a fresh `POLL` preamble, and + only then opens the schedule for writing at frame 20. Different commands, + different paths, no shared state: + + ``` + config 0xDA → 0x68/0x73 → 0x82/0x83 → 0x71/0x72 + schedule 0x8D → 0x8E + ``` + +- **The schedule stores a NAME, not a config.** A length-prefixed filename is + all an entry carries. It is a *reference*, and references do not require the + referent to be rewritten. + +- **The config Thor pushed was already on the unit, unchanged.** Its 2,090-byte + `0x71` payload is **byte-identical** to the previous capture's — zero + differences. Thor spent a full block write re-sending a setup the device + already had, purely to satisfy its own coupling. + +So the sequencing is a Thor UI decision, and a costly one. + +**What SFM can do instead, with today's protocol and nothing new:** + +1. Enumerate the unit's setups with `0x3F` / `0x40` — cheap, read-only, and it + yields the exact names a schedule may legally reference. +2. Write **only** the schedule (`0x8D` / `0x8E`) when the referenced setup is + already present. +3. Push a config only when it is actually missing, or when the operator + deliberately edited it — and say so explicitly rather than silently. + +That removes the write entirely from the common case: scheduling against a setup +that already exists becomes a 524-byte schedule write instead of 524 bytes plus +a 2,090-byte config overwrite. + +⚠ **And it removes a real hazard.** Because the reference is by name, and +because a same-name write overwrites silently with an indistinguishable ack, +Thor's pattern means *scheduling* something can quietly rewrite a setup that +other schedules — or the operator's own saved work — depend on. Nothing in the +protocol or the ack reports that this happened. Validating the reference +instead of rewriting the referent avoids the whole class of problem. + ### What this implies for the build order The read path is fully known and needs no Thor-shaped decisions, so a read-only