Answer A-195: the runner's pipeline wait

Claude-Session: https://claude.ai/code/session_01NcbgfGKaxw984XyAPfLm4h
2026-11-12 09:41:28 +01:00
parent 19a1d9342e
commit 2188dfaffe
1 changed files with 6 additions and 0 deletions
@@ -62,3 +62,9 @@ the principle that settles it, cited as "design 47 G A-n".
 - **A-194** (principle 4; §64) The indexer's state `runs` and its run candidates get tools as every kept thing does:
  `indexer_runs` reads them and `indexer_run_drop` drops one by hand (its hand act written first); a run id is
  `run-` and the runner's random 12-hex id, which the indexer's wider pattern accepts.
+- **A-195** (§65, §266, §276, §534, §19, A-77, A-149; principles 2, 3 and 7) The runner's `pipeline` wait is a field on
+  each held pipeline's record (`held`: since, and the fingerprint awaited), no new state. A take-in changes the runner
+  when its own module's entry (its own name, A-149) gets a new fingerprint; every pipeline started after that take-in
+  is held. The pipelines' records are on the bus, so whichever runner holds the seat when the wait ends starts them:
+  the wait ends on the node-engine seat's `running` for the runner's module at the awaited fingerprint with `healthy`
+  true, on any node; its 30 minutes are a bound key, whose expiry starts the held pipelines and writes a finding.