Anything that takes long enough to watch — an update, a pin, a rebuild —
becomes an **action** rather than an async function behind a route. A
module declares the handler; core owns the row, the ordering and the
clock. That split is what lets the scheduler fire an action from a
process that restarted twice since the schedule was written: the row
holds `(module, action, args)`, never a closure.

The decisions that shape it, and why they are not defaults:

- Identity is `module + action + target`, at most one live run per
  triple, and `onSelfConflict` is REQUIRED. A schedule firing over its
  own previous run has no safe default, and `drop` still writes a
  `skipped` row — a silently discarded click is how you get bug reports
  saying nothing happened.
- Ordering and exclusion are one primitive: gates. They are evaluated
  against the TABLE, anchored by a persisted `gate_anchor_ms`. The
  event-driven version is the one that comes naturally and it is wrong,
  because a completion that happened while the process was down has to
  count exactly once.
- `interrupted` is terminal. There is one process and no workers, and a
  `docker compose` child dies with its parent, so a system claiming a run
  will eventually happen anyway is lying. Core records where the run was
  left and stops; whether re-running is safe is the module's judgement,
  expressed as a new run linked `retry_of`.
- Secrecy is per field and defaults to withheld. An action lists what a
  non-admin may see (`expose`), and a run reports what was stripped
  (`withheld`). A whole-run boolean had already leaked once — step errors
  and checkpoints were added and nobody updated the single place that
  decided what was secret — so the cost of forgetting is now an empty
  pane, not a host command line in somebody's browser.
- One authorised way in. `startRun` is the mechanism and trusts its
  caller; everything originating from a browser goes through
  `startAsUser`, so the console opt-in and the role check exist once.
  Stated three times, the copies drifted: the HTTP route accepted an
  `args` body for actions whose entire contract is that a generic client
  cannot compose one.
- A schedule's key is built by `scheduleKey(module, name)` and nowhere
  else. The module-facing API takes the module-local name, so the
  "already prefixed?" guess that produced `docker:docker:updates` cannot
  be written.

Gate evaluation is serialized through one chain: two interleaved
evaluations would both see a free lock, which is exactly the "checked the
mutex and never took it" bug the design exists to make unwriteable.

Live topics `core:tasks` and `core:task:<id>` are retained — a subscriber
gets the current state plus everything after it from one source, so there
is no REST baseline to reconcile and no timer to notice it drifted.
Resumption carries an `epoch`, because a `tseq` only means anything
within the generation that issued it and a restart must not splice new
deltas onto a stale snapshot.

@@ -389,3 +340,1 @@
-  const job = new JobFollow(feed, {
-    wants: () => true,
-    onFinish: () => {
+  // this modal follows whichever run it was pointed at, stack-wide or not

@@ -0,0 +306,4 @@
+      `SELECT ${RUN_COLUMNS} FROM task_runs
+       ${sql}
+       ORDER BY COALESCE(finished_at_ms, updated_at_ms) DESC, id DESC
+       LIMIT ${limit} OFFSET ${offset}`,