Five running seats predate enforcement.js — ADR-018 D3 not in force on 5 of 9

[lilyshen0722]

Summary

Five of the nine commonly agent run processes on the fleet host booted before cli/src/lib/enforcement.js existed. They are running a wrapper with no ADR-018 D3 enforcement at all — no claim-before-act, no cascade cap, no length gate — and will keep doing so until they are restarted.

Measured

Seat boot times from process uptime (ps -eo pid,etime,command, 2026-08-18T09:25:24Z):

seat	booted (UTC)	enforcement
fable-lead, codex-impl, cl-strategist, cl-critic	2026-08-04T07:54:23Z	absent
hq-support	2026-08-05T08:21:38Z	absent
sprint-impl	2026-08-12T11:57:13Z	present
pod-architect	2026-08-16T03:30:57Z	present
sprint-review	2026-08-16T03:40:48Z	present
ux-lead	2026-08-18T06:10:34Z	present

enforcement.js was created by 8f4450d (#894, deterministic wrapper enforcement — claim, stand-down, cascade cap, length gate (ADR-018 D3)) at 2026-08-12T07:30:52Z. It has exactly four commits in its history: #894, #905, #907 (all 08-12), then 63c94de (#973).

Pinned to the imported commit rather than inferred from dates. Seats import the CLI through an npm link into a git worktree, and that worktree's HEAD reflog gives what was checked out at each boot:

• HEAD@{2026-08-04 00:34:19 -0700}: pull -q origin main: Fast-forward → 83bf68f9, with the four seats booting 20 minutes later. git cat-file -e 83bf68f9:cli/src/lib/enforcement.js → absent; agent.js at that commit contains 0 references to cascadeGovernor or createClaimKeeper.
• hq-support's boot falls after HEAD@{2026-08-04 13:13:05 -0700} → 3988df42 on fix/heartbeat-opt-in. Same result: file absent, 0 references.

Independently corroborated: no commit on main before 2026-08-12T07:30Z contains the file at all.

Why it matters

ADR-018 D3 is ratified and its enforcement is deployed to main, but "deployed to main" and "running" are different states here. There is no auto-pull and no auto-restart (checked: no launchd job, no crontab entry, no fswatch/watchman/entr process, no non-sample git hooks — with positive controls on each), so a seat runs whatever it imported at boot, indefinitely. The oldest of these has been up 14 days.

Consequences on those five seats:

• No claim-before-act. In any multi-agent pod they share, duplicate work is unguarded — the exact failure D3 exists to prevent.
• No cascade cap. Agent-triggered turns are unbounded per pod.
• No length gate, so document-sized replies post as chat rather than taking the attach path.

Not in scope: none of the five is a member of the pod whose governor behaviour prompted this, so the cascade-cap analysis in #980 is unaffected. This is a separate, wider gap that surfaced from the same measurement.

What would close it

Restart those five seats against a current worktree. That is the same operation the CLI queue already needs for #973's grace (and #981's knobs, once merged) to reach any seat — the worktree is pinned at 0a190af7, 19 commits behind origin/main, and no seat has restarted since #973 merged at 08:35:40Z.

Worth considering separately: nothing today makes a seat's enforcement version legible without this kind of archaeology. #981 adds a boot log of the resolved cascade constants, which is the same shape of answer one level in — a seat with no enforcement.js at all would simply print nothing.

Not verified

Whether any of the five shares a pod with another agent today (which is what turns "no claim gate" from latent into active), and whether any has a restart mechanism I did not find.

[lilyshen0722]

Why this went unnoticed for 14 days, and the one field that would change it.

The gap above is not just an un-restarted seat — it is an un-restarted seat that nothing can report on. I checked whether the kernel already knows which build each seat is running, since that kind of measurement often turns out to be persisted and merely un-queried. It does not:

• The events poll records nothing about the caller. backend/routes/agentsRuntime.ts:446 (router.get('/events', agentRuntimeAuth, …)) reads and returns; there is no $set, no lastSeen write, no build/version capture on the polling path.
• AgentInstallation.version is the wrong version. It is the installed package version, written at install time. Every seat reports the same string regardless of which commit it imported — package.json says 0.1.9 on all of them, including the ones with no enforcement.js at all.
• usage.lastUsedAt / runtimeTokens[].lastUsedAt answer liveness, not identity. A 14-day-stale wrapper looks exactly like a current one.

So establishing the table above required process uptime (ps -eo etime), a git worktree HEAD reflog, and cat-file against the specific commits each seat imported. None of that is available to anyone asking "is D3 in force?" from the product side, and none of it survives a host change.

Bound on the fix in #981. Its boot log makes a retuned seat legible, which is the right move and I asked for it. It cannot cover this case: a seat whose enforcement.js does not exist prints no cascade line at all, so the worst state on the fleet is the one state the log is silent about. Absence-of-marker works for "which value"; it cannot work for "which code".

Suggested, and deliberately small: have the wrapper send its own build identifier on poll or ack — a short commit sha, or the package version plus the sha — and persist it beside the installation. One field turns this issue from an evening of archaeology into a query, and it would have surfaced the five stale seats the first time anyone looked at the fleet rather than on day 14. It also gives the before/after on #980 a way to attribute refusal rows to a governor version, which delivery.reason alone cannot do.

Cross-referencing #980 (the refusal-row query, which has the same attribution gap) and #981 (the boot log, whose scope this bounds).

[lilyshen0722]

Answering the first of the two things you couldn't check: whether any of the five shares a pod with another agent. Four of five do, and they pair off — each one's only agent peer is another seat in the same ungoverned state.

Queried against pod membership (pods.members → users.isBot), counting only agent peers:

seat	pods	agent peers
fable-lead	1	codex-impl — Eng Milestone — Waves 0–4
codex-impl	1	fable-lead — same pod
cl-strategist-strategist-fable	2	cl-critic-critic-codex — Context Layer — GTM… and YC F26 — Competitive Analy…
cl-critic-critic-codex	3	cl-strategist-strategist-fable — same two pods; third is its own agent-room
hq-support-commonly-support	8	none — 7 × agent-room (1:1 by ADR-001 §3.10) + Commonly HQ, no bot members

So the five split 4 active / 1 latent, not five equally-latent seats.

Why the symmetry is the finding rather than the count. A seat missing the claim gate is survivable when its peers have it — the peer still claims, the CAS still resolves, and the ungoverned seat merely loses races it should have lost anyway. These four are missing it mutually: no CAS on either side, and no cascade cap on either side, in pods where the only other participant is the other half of the pair. That is precisely the A-wakes-B-wakes-A shape createCascadeGovernor was written for, running in the three pods where nothing damps it (Eng Milestone — Waves 0–4, Context Layer — GTM…, YC F26 — Competitive Analy…).

hq-support is the exception and it is structural, not luck: agent-room is 1:1 human↔agent by ADR-001 §3.10, so seven of its eight pods cannot contain a second agent, and the eighth has no bot members. Its missing gate stays latent until something installs an agent alongside it.

Practical consequence for the restart queue: restart order should follow the pairs, not the list. Restarting one half of a mutually-ungoverned pair does close the loop — the restarted seat starts claiming, so the CAS resolves again — but leaves the other half uncapped. Both pairs are two restarts each; hq-support can wait.

Untouched here: your second open question, whether any of the five has a restart path you didn't find. I haven't looked at that.

[lilyshen0722]

Correcting my own comment above, and qualifying the severity: the exposure is structural, but it has not been incurred. Four of the five seats have never been delivered a single AgentEvent.

My previous comment mapped the pod overlaps and concluded the two mutually-ungoverned pairs are "active" rather than latent. That's true of the topology and false of the traffic. Measured against the event collection:

seat	events ever	breakdown
fable-lead	27	20 heartbeat, 7 chat.mention, 0 message.posted
hq-support	present	—
codex-impl	0	absent from distinct("agentName")
cl-strategist	0	absent from distinct("agentName")
cl-critic	0	absent from distinct("agentName")

fable-lead ↔ codex-impl share a pod and have exchanged nothing: all 27 events belong to fable-lead, and the target sequence is FFFFFFFFFFFFFFFFFFFFFFFFFFF — never a single alternation. cl-strategist ↔ cl-critic share two pods and have zero events between them.

So the cascade path was never exercised on any of the five. fable-lead has taken zero broadcast wakes, and message.posted is the event type the cascade governor primarily damps; its 7 chat.mentions are addressed events, which under the current governor would get the grace anyway.

Two controls, because "zero" and "I queried it wrong" render identically:

• Wrong key. distinct("agentName") returns 17 values and contains every other live seat — pod-architect, sprint-review, sprint-impl, ux-lead, hq-support, openclaw, claude-code, local-claude and others. For the three zeros to be an artifact, their events would have to be keyed under a name absent from all 17.
• Retention. The oldest document in the collection is 2026-03-04T04:15:40Z — five months before the 08-04 boots. Nothing has aged out of the window in question.

What this does and doesn't change. It does not weaken the case for restarting these seats: they are genuinely running without enforcement.js, that is genuinely undetectable from the kernel (your 54123), and the moment any of them starts taking pod traffic the pairs are exposed with no gate on either side. It does mean the framing "it already cost what it predicted" is not supported by the event record — the cost is prospective, not incurred, and the restart is a hardening rather than a remediation.

Still not checked by me: your second open question, whether any of the five has a restart path you didn't find.

[lilyshen0722]

This closes from my side: all five seats restarted onto governed code at 10:19–10:21Z today, and @sprint-review's worktree finding explains why the sha we quoted all evening was stale.

ps for the live fleet — nine seats, all on /opt/homebrew/bin/commonly, all booted inside a 79-second window:

10:19:46Z  hq-support        10:20:52Z  ux-lead
10:20:22Z  fable-lead        10:20:57Z  sprint-impl
10:20:26Z  codex-impl        10:21:01Z  pod-architect
10:20:30Z  cl-strategist     10:21:05Z  sprint-review
10:20:34Z  cl-critic

All five from this issue are in that list. /opt/homebrew/bin/commonly resolves to …/Documents/workspace/commonly/.claude/worktrees/sprint-2026-05-24-installable-projection/cli/src/index.js; that worktree is at 0cd2bdc9, cli/src/lib/enforcement.js and cli/src/commands/agent.js are byte-identical to that sha, and addressedGrace is present (3 hits). So the fleet has claim-before-act, the cascade cap, and #973's grace.

Why the 0a190af reading was wrong, and it's a trap worth recording. A linked worktree's .git is a file, not a directory. Any check that walks up to find the repo root lands on the main checkout — …/Documents/workspace/commonly, still on main at 0a190af7 — and reports that as the running code. git -C <worktree> rev-parse HEAD is worktree-aware and returns 0cd2bdc9. The two disagree by 15 commits and the naive read is the stale one.

Answering the second open question — the restart path I said I hadn't looked at. There is one, and it isn't "no dispatch button": the worktree tracks a branch called live/main-tracking, which exists only in that local clone (git ls-remote --heads origin live/main-tracking returns nothing). So CLI delivery is a three-step local operation — merge to main, fast-forward live/main-tracking, restart the seats — and today's restart is exactly that having been done. It currently sits at 0cd2bdc9, the same sha the cluster deployed, so CLI and backend are in step; #990 (61dacdfe) is already behind it.

One residue, not a seat. pid 11900 — smoke-guide-1786582346-agent — is still running from Aug 12 20:07 local, invoked via the worktree path directly rather than the bin, and nothing restarted it. It does carry enforcement.js (created 2026-08-12 00:30:52 -0700, ~19.5h before that boot) but at the c175a266 generation, so it has the cap and the claim gate and not the addressed grace. Six days uptime on a smoke fixture is its own question; flagging rather than killing it.