@telora/daemon 0.24.40 → 0.24.42

package/docs/runbook-tower.md

@@ -153,6 +153,25 @@ that is no longer armed. A pass that throws for one product is logged and never
 stops another product's pass; admission fails open on that product's foci at
 once (see the fail-open rule).
 
+The head-of-pass run is not the only one. A focus armed or re-armed AFTER the
+poll's pass read the armed set -- most often with a stage directive queued for
+it in the same poll, which the pending-spawn pass acts on later in that poll --
+has no verdict for its current arm. Both spawn passes, ready and pending, admit
+through one rule (`admitThroughTower`, `tower/tower-admission.ts`): when the
+product's pass is standing and no pass of this daemon has computed a verdict for
+the focus under its current `agent_assigned_at`, admission runs that product's
+pass on the spot (`computeTowerVerdictForAdmission`, `tower/tower-pass.ts`;
+the focus counted as wanting a team), writes the product's changed verdicts,
+and admits against the verdict it just computed. So a just-armed focus is held
+from its first poll, whichever pass reaches it, and every re-arm gets its own
+verdict before it can spawn. The daemon logs `[tower] "<focus>": no verdict
+computed for its current arm yet -- computing it before admission`. Pinned by
+`tower/tower-arm-admission.test.ts` (the 2026-10-26 sequence, and each hold
+reason through both paths), `tower/tower-depends-on-admission.test.ts` (an
+unlanded depends_on predecessor, through the production tower read, graph judge
+and git LANDED check, holding both paths until it lands) and
+`tower/tower-entrypoints.test.ts`.
+
 ## The three modes: `TELORA_TOWER_MODE`
 
 Declared in `@telora/daemon-core` `env-config.ts`; default **`observe`**.
@@ -171,14 +190,23 @@ most recent pass for the product succeeded, within the freshness bound. When the
 product's pass fails -- or has not yet succeeded since the daemon started --
 every verdict of that product is unobeyed AT ONCE, however fresh, and the daemon
 logs `[tower] "<focus>": its product's tower pass failed -- failing open`.
-Another product's holds are untouched. A verdict that is
-
-- missing,
+Another product's holds are untouched -- and this includes a pass admission ran
+itself for a just-armed focus: if that computation fails, the product's pass is
+failed and the focus spawns.
+
+A verdict that is NOT YET COMPUTED -- missing, or computed under an earlier arm
+(its `armedAt` is not the focus's current `agent_assigned_at`), while the
+product's pass stands and no pass of this daemon has seen the current arm -- is
+not a failure of the tower, so admission does not fail open on it: it computes
+the verdict first (see the slot rule above) and admits against that. Only once
+the tower has had its chance is a verdict that is
+
+- missing (the pass computed none for this arm, e.g. its inputs could not be judged),
 - unreadable,
 - older than the bounded age (`TOWER_VERDICT_MAX_AGE_MS`, 5 minutes), or
-- computed under an earlier arm (its `armedAt` is not the focus's current `agent_assigned_at`)
+- computed under an earlier arm although a pass has seen the current one (a read that raced the write)
 
-is NO verdict: the focus spawns exactly as it would with the tower off, the
+NO verdict: the focus spawns exactly as it would with the tower off, the
 daemon logs `[tower] "<focus>": tower verdict unavailable (<why>) -- failing
 open`, and the dashboard names it ("Tower verdict unavailable (stale) --
 spawns as with the tower off"). A tower that stops writing therefore releases

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@telora/daemon",
-  "version": "0.24.40",
+  "version": "0.24.42",
   "description": "Agent orchestration daemon for Telora - spawns and manages Claude Code instances",
   "type": "module",
   "bin": {
@@ -41,7 +41,7 @@
   "//testRunner": "Uses Node.js built-in test runner (node:test) via tsx for TypeScript support. The root package uses Vitest; this is a deliberate choice for the daemon package to avoid framework dependencies. Test files live beside the modules they exercise (owner-directory layout); the runner discovers them recursively.",
   "dependencies": {
     "@telora/daemon-core": "^0.3.2",
-    "@telora/mcp-products": "^0.23.18",
+    "@telora/mcp-products": "^0.23.19",
     "commander": "^14.0.3",
     "yaml": "^2.4.0",
     "zod": "^4.3.6"