Every failure degrades to silence, and silence is indistinguishable from a decision (8 instances, one defect)

[lilyshen0722]

Every failure in this system degrades to silence, and silence is indistinguishable from a decision

Eight defects found in one session. They look unrelated. They are the same defect.

#	Defect	What a human sees	What it actually was
1	Dead-letter cap (#998)	agent stops answering	events retired to terminal failed after ~45 min
2	POST /api/pg/messages	message posted, 200 OK	enqueueMentions never called — woke nobody
3	Cascade starvation (#1010)	seat stops contributing	refused, acked no_action, invisible to peers
4	fable-lead mute (TASK-028)	agent has nothing to say	wakes, spawns, exits 0, returns NO_REPLY — every health check green
5	Author frame (#1011)	agent ignores a human	human identity arrived as **unknown**
6	NO_REPLY to a mention	agent is broken? deciding?	unknowable from outside
7	classifyTrigger → unknown	—	silently resets a cascade streak
8	Heartbeats enqueue 0	fleet is quiet	boot banner said they run (#986)

In every row, the system did something reasonable-looking and produced nothing. No error, no signal, no trace at the surface a human watches.

Why this is the expensive kind of bug

Silence is the one output that carries no information. A crash names itself. A 500 names itself. A refusal that acks no_action and moves on looks exactly like an agent that considered the message and had nothing to add — which is also a thing we explicitly want agents to do.

So the failure mode and the desired behaviour are the same observable. That is why #4 cost hours: I eliminated message length, session staleness, session bloat, crashes, config, pod routing and CLI version before finding the prompt in argv. Every check came back green because every check measures liveness, and the seat was fully alive.

The principle this should have been designed around

A turn must always produce an observable outcome.

Not "should log" — logs are where silence goes to be invisible. Observable at the surface where the question was asked.

Three consequences:

1. A refusal aimed at a human is an event, not an absence. If a seat declines, is capped, loses a claim, or returns NO_REPLY to a human mention, that is a fact the human should be able to see. A reaction is the cheap carrier — it is bounded, non-recursive, and commonly_react_to_message already exists on both driver classes.
2. Outcomes must be queryable per seat. AgentEvent already acks { outcome, reason }. Nothing surfaces it. "Which seats have produced no output in the last hour, and why" should be one query, not an afternoon of ps and log archaeology.
3. Liveness checks must measure output, not process state. Nine seats were "healthy" — polling, connected, spawning, exiting 0 — while two were starved and one was mute. Counting posts revealed it; nothing else did.

What NOT to do, and this is load-bearing

Do not add a mechanism per row of that table. Cumora's COORDINATION.md names this exactly (anti-pattern 4):

"Don't pile loop-prevention mechanisms when one already exists... Adding a fourth mechanism for a specific observed loop is usually wrong."

We already have three dampeners (self-wake guard, wake-loop dampener, cascade governor) and I was drafting a fourth. The work is consolidation, not accumulation.

Their anti-pattern 8 is this session in one sentence:

"Read the server logs first. If an end-to-end symptom doesn't match any of the in-place defense layers' expected behavior, suspect infra first."

I did the opposite on fable-lead — theorised about session self-imitation, cleared the session, restarted the process, and only then read the prompt. The prompt was in argv the whole time and contained the answer.

Suggested sequence, for challenge rather than adoption

1. fix(auth): every human message reached agents as 'raised by unknown' #1011 — human identity reaches agents (merged or open; it is the smallest and unblocks the rest)
2. Surface no_action outcomes per seat — one query, then a UI affordance
3. Refusal-to-a-human becomes a reaction — needs feat(reactions): notify agents of new acknowledgements #970 resolved first, and feat(reactions): notify agents of new acknowledgements #970 currently types receipts as chat.mention, which is Cumora's anti-pattern 6 (a free bypass that erodes the gate it bypasses)
4. Consolidate the three dampeners into one room-level control — Cumora's per-room framing, not their specific lapping floor: their empirical baseline is counting games and werewolf, where one contribution per participant is the correct shape, and ours is multi-hour technical review where two seats legitimately exchanged 194 posts

Where I have been wrong tonight, since it bears on trusting this synthesis

• Called fix(cli): a directly-addressed seat can answer past the cascade cap #973 a fix; it was a workaround for fix(cli): a seat that loses a claim never reset its cascade streak #1010's mechanism
• Claimed resetMs needs total pod silence; it is process-local, so a capped seat clears every 10 min regardless — an agent caught this
• Predicted the 4-hour outage would dead-letter events; it retired zero, because the circuit stopped seats fetching and the requeue only touches delivered
• Diagnosed fable-lead as session staleness; a fresh session and fresh process both stayed mute
• Claimed the per-spawn prompt was unreadable from outside; it is in argv
• Briefly claimed the unknown author frame proved fix(cli): a seat that loses a claim never reset its cascade streak #1010 was a no-op; that is formatAuthorFrame's username fallback, a different unknown from classifyTrigger's

Six corrections in one session, most caught by measurement or by an agent rather than by reasoning. That is the argument for making outcomes observable: I was only able to correct any of them where the system produced evidence.

[lilyshen0722]

Instance 9, and it is the sharpest one: a wrong model pin is indistinguishable from a thoughtful agent

fable-lead was mute for 19 hours (03:20 → 22:33). Cause: environment.model = 'claude-fable-5' in its attach record. Repinned to claude-opus-5 on an otherwise byte-identical seat and it posted on the very next mention.

It emitted the literal token NO_REPLY. Not an error, not a refusal, not a quota message. One turn ran 10m44s before producing it. The wrapper cannot distinguish that from a considered decision either — an empty return logs empty output, so NO_REPLY specifically means the model chose to say nothing.

Every liveness signal was green throughout: process alive, TCP established, polling, spawning, exit code 0, installation active, messages:write in scope, lastActiveAt current. Nine seats reported healthy while one had been silent for most of a day.

Cost of the ambiguity

Four wrong theories before the right one, each plausible: session staleness (cleared — still mute), session bloat (8.9KB vs 15KB healthy), crashed spawn (exit 0), MCP server (npx -y @commonlyai/mcp@latest vs working seats' local path — repointed, no change). Merge authority had been delegated to this seat, so the PR queue stalled invisibly for an hour before anyone noticed the delegation had gone into a void.

What actually found it

Reading ps -ww -o args= on the live spawn. The full prompt, --model, --allowedTools and --mcp-config are all in argv. I had asserted this was impossible from outside the process because the prompt is materialised per-spawn and deleted — that was wrong, and believing it cost hours. The runtime token is not in argv (routed via env), so reading it is safe.

Why this belongs on this issue

It is the cleanest instance of the thesis. Every other row in the table degrades to silence through some mechanism — a cap, a retired event, an unenqueued mention. This one degrades to silence through the agent's own sanctioned vocabulary for having nothing to say. There is no defect to detect, because the output is valid.

Which means no amount of error handling would have caught it. The only signals that would have are the ones this issue proposes: count output per seat, and make refusal-toward-a-human a visible event rather than an absence.

Two nearby corrections

• The comment at cli/src/commands/agent.js:~260 blames a missing bundled skill for agents that "default to NO_REPLY on a normal question." Our own fleet contradicts it: sprint-review mounts no skill and is the most productive seat in its pod; fable-lead had the skill and said nothing. That comment will mislead the next person during exactly this investigation.
• buildDefaultEnvironment still hands npx -y @commonlyai/mcp@latest to every newly-attached agent. It re-resolves from npm per spawn, so a seat's tool surface can change mid-session with no reviewed diff — it changed under fable-lead today when 0.3.1 published. Same class as the submodule-pin oscillation documented in CLAUDE.md.