diff --git a/docs/micromate_protocol_reference.md b/docs/micromate_protocol_reference.md
index 112015f..fb280af 100644
--- a/docs/micromate_protocol_reference.md
+++ b/docs/micromate_protocol_reference.md
@@ -1546,9 +1546,52 @@ Action codes, so far:
 | `0` | **Auto Call Home** |
 | `3` | **Start monitoring, with setup** |
 
-⚠ `[6]` is the one field still unidentified — `2` on the start entry, `16` on the
-Auto Call Home entry.  It is not the name length and not the time.  A capture
-that changes only the **Repeat** checkbox, or switches Day↔Week, would isolate it.
+### The Repeat flag is folded into `Action` (2026-09-25)
+
+A capture that changed **only** the *Repeat Daily* checkbox — schedule pulled,
+repeat disabled, schedule pushed — moved **exactly one byte in the whole
+session**:
+
+```
+record @0   Action  0x03 → 0x02        (repeat ON → repeat OFF)
+```
+
+Nothing else moved.  Record 2 unchanged, `[6]` unchanged, and `0xDA`, `0x68`,
+`0x82`, `0x71`, `0x94`, `0x8D` all byte-identical.
+
+⚠ So **`[6]` is NOT the repeat flag** — the field predicted for that test is still
+unidentified.  And the earlier label on `[0]` was too simple: it is not a plain
+action index, it carries the repeat behaviour too.
+
+**Leading hypothesis** — `2` and `3` are the two *setup-bearing start* actions the
+firmware names, and repeat selects between them:
+
+| value | action | why |
+|---|---|---|
+| `0` | `DUTYCYCLE_CALLHOME` | the 19:30 entry, no setup name |
+| `2` | `DUTYCYCLE_START_MONITOR_WITH_SETUP` | repeat **off** |
+| `3` | `DUTYCYCLE_START_MONITOR_WITH_SETUP_STOP_COMPLETE` | repeat **on** |
+
+That reading is supported by the THOR manual's description of what a *repeating*
+schedule does on hitting a Start Monitoring event while already monitoring:
+
+> *"the unit will stop the current monitoring session, run any Auto Call Home
+> actions, load the compliance setup and continue monitoring."*
+
+Which is precisely what a name ending `_STOP_COMPLETE` would mean: a repeating
+start has to terminate the in-progress session first, a one-shot start does not.
+The firmware action name, the manual's behaviour, and the single byte that moved
+all agree.
+
+⚠ **The enum's ordering is NOT known.**  The action names were recovered with
+`strings | sort`, so their source order is lost — do **not** infer that `1` is
+`DUTYCYCLE_START_MONITOR` merely because it sits between the two known values,
+tempting as that is.  Three of six codes are observed (`0`, `2`, `3`); the
+remaining three need entries that use those actions.
+
+⚠ Note also that Thor re-pushed the **entire 2,090-byte config block** for a
+one-byte schedule change — a third instance of the coupling described in
+*The schedule↔config coupling is Thor's, not the protocol's*.
 
 ⚠ Also still unknown: whether the file can hold more than the records in use
 (both captures had every used record contiguous from offset 0), and the remaining