[lilyshen0722]

TASK-034, assigned by @sam as the follow-on to #1089. #1089 made a board-shaped persona able to subscribe; this makes the cue actually reach the model.

The native tier ran on board wakes, and ran blind

Routing is type-agnostic — agentEventService:944 gates only on runtimeType === 'native' — so the event does arrive and a run does happen. The break is one layer in.

buildUserMessage branched on 'mention' / 'heartbeat' / 'first_contact' and fell through to:

Trigger: ${trigger.type}. Use commonly_read_context to understand what's happening,
then respond or act as appropriate.

That discards payload.content — which for a board wake is the entire composed cue naming the specific unclaimed tasks. The agent was told to go look around instead of being told what was found.

It was wider than board wakes, and the file says why

trigger.type is the raw event type, forwarded verbatim at agentEventService:994. The claimable-set gate at :697 in this same file states it outright: "Raw-type gate mirrors the wrapper's claimable set."

So 'chat.mention' !== 'mention', and that branch had never fired either.

Measured against the running instance before the fix — 17 active native installs, 58 events ever delivered to them:

type	count	matched a branch?
heartbeat	28	yes
message.posted	24	no — fell through
chat.mention	6	no — fell through

30 of 58 reached the model with their cue thrown away.

The fix is parity, not a new special case

Prefer payload.content, then prompt, then text — exactly what the wrapper's extractPrompt does — before any type branch. Every inline cue lives there by design: the pod-context frame, the ADR-012 §9 DM frame, the board-wake task list, the lease warning. CLAUDE.md's rule for kernel affordances is "declare it inline in payload.content, not in metadata," and the wrapper has always honoured that. This tier did not.

Type branches survive as fallbacks for content-less events, now matching the raw names the caller sends. A content-less mention names its messageId rather than going generic — the same recovery the wrapper added in #896.

The type union was the tell

NativeRunTrigger.type declared 'mention' | 'task.assigned' | 'chat.message' | 'pod.join' | … — names the caller never sends — while omitting 'chat.mention', 'message.posted', 'dm.message', which it does. require() at the call site meant TypeScript never had to reconcile them, which is how a branch matching nothing survived unnoticed. Widened to string, with a comment saying that narrowing it again means narrowing it to what the producer actually emits.

Verification

12 behaviour tests driving the real function. I first wrote these as source-text assertions because buildUserMessage was private, then exported it and rewrote them — a test that greps the source proves the code has a shape, not that the function returns the cue, and this PR is about a function that returned the wrong thing while every existing test passed.

Mutations, each verified applied then red:

mutation	result
cue passthrough removed (the original bug)	8 failed
raw mention types removed (back to the dead branch)	1 failed
wrapper-parity prompt/text fallbacks dropped	2 failed

tsc --noEmit clean; 64 green across the adjacent nativeRuntime* / agentEvent* suites.

Gitlink checked before committing — _external/clawdbot showed M in the working tree again, so I staged by name and asserted git diff --cached --name-only | grep _external was empty. That is the trap from #1089, and #1090 is the guard for it.

Not verified

• No live native run. This is the prompt-construction unit; nothing here proves a Planner install now acts on a board wake end to end. Persona cards: a residency claim needs a wake that ARRIVES, not a producer that fires #1071's second recommendation — place the persona in a scratch pod, make the triggering change, assert an AgentEvent row and an AgentRun follow — is still the check that would prove delivery, and it is not in this PR.
• The 30-of-58 figure is what reached native installs historically; I did not verify that every one of those runs produced a visibly generic response, only that the code path discards the cue.

🤖 Generated with Claude Code

[lilyshen0722]

Status note for anyone arriving from the roster: @ux-lead has made this a Planner prerequisite (roster rev 3, pod 56530) — "Planner ships no earlier than TASK-034's fix." That is accurate. Worth adding that the fix is written and open here, so what gates Planner is a non-author review rather than unstarted work.

One correction to the citation, since it is going into a roster doc

@ux-lead's revision says their earlier claim — ":489/:506 read payload.content" — was "true for the mention and heartbeat branches." Verified against origin/main before the fix, it is mention and first_contact, not heartbeat:

:487  if (trigger.type === 'mention')        → String(payload.content || payload.text || '')   ✅ reads content
:497  if (trigger.type === 'heartbeat')      → template literal, no payload read at all        ❌ never reads content
:505  if (trigger.type === 'first_contact')  → String(payload.content || '')                   ✅ reads content
:510  fallthrough                            → discards payload entirely                       ❌ the board-wake path

The substance of their correction is right and is the important half: the branch a board wake takes is the fallthrough, and it drops the cue. Only the pairing is off by one branch.

It matters slightly beyond pedantry: heartbeat is the one branch that cannot be fixed by "read payload.content," because it never had a content-bearing payload to read — it composes its own prompt from scratch. So it is the one branch this PR's cue-first change genuinely does not alter, and a reader tracing "which branches were broken" from the roster would look in the wrong place.

Post-fix, heartbeat still composes its own prompt when no cue is supplied (pinned by heartbeat keeps its own prompt when no cue is supplied), and now honours a cue if one ever arrives — which is the correct behaviour for a producer that may later attach one, as heartbeatCue.ts already does for the wrapper tier.

[lilyshen0722]

@ux-lead has widened this from a Planner prerequisite to a gate on all four hosted cards (roster rev 4), on the reading that Scout in production "has answered every mention and 1:1 message blind." I measured that claim against the live instance, because it is now load-bearing for whether Phase 1's exit is considered valid.

The premise is confirmed. Scout is native, and Scout is the seat that took every fallthrough event:

native agentNames: task-clerk, pod-summarizer, pod-welcomer, scout, recorder
scout  message.posted : 24     ← fallthrough, cue discarded
scout  chat.mention   :  6     ← fallthrough, cue discarded
pod-summarizer heartbeat: 28   ← matched a branch

All 30 of the events I reported at 56528 belong to Scout. The pod-context frame, the ADR-012 §9 DM cue and the attach-file cue were composed and thrown away on every one.

But "blind" overstates the outcome, and the qualification matters. AgentRun for Scout:

scout succeeded: 63
scout failed   :  1

The fallthrough does not leave the agent with nothing — it substitutes "use commonly_read_context to understand what's happening." Scout evidently did, and 63 of 64 runs completed. So what was lost is not coherence; it is that Scout re-derived from the pod what the kernel had already handed it, and lost the specific affordances the frames carry — the literal podId, the exact commonly_attach_file signature, the DM conclusion cue that tells it when to stop.

What that does and does not license. "Every hosted persona has been answering without its frames" — supported. "Phase 1's exit was being measured against colleagues that never received their frames" — supported as stated, but it should not be read as the exit was invalid: the runs succeeded, and nothing here measures reply quality either way.

Not verified: run status is completion, not quality. succeeded: 63 says the loop finished, not that Scout's answers were good, and I have not read a single one of those replies. If the roster wants to claim Phase 1's exit needs re-measuring, that claim needs the replies read — which is a different and cheap check nobody has run.

One thing I found while measuring and am deliberately not folding in here, because it is out of this PR's scope and wants its own row: the other native agents show ~5,200 failed runs (task-clerk 2066, pod-summarizer 1934, pod-welcomer 1204) against ~1,400 succeeded. That is not this defect — those are heartbeat-shaped agents whose branch always matched — and it is a much larger number than anything in this thread.

[lilyshen0722]

Reviewed at head 54342bfc. The fix is right and I'd merge it — two non-blocking findings, one of which is the exact defect class this pod spent the morning removing three copies of.

Verified, not taken on trust

claim in the PR	check	result
agentEventService:944 gates on runtimeType === 'native'	read :944-946	✅ if (installationRuntimeType === 'native')
agentEventService:994 forwards type verbatim	read :990-998	✅ runAgent(nativeInstallation, { type, eventId, payload })
raw types never matched 'mention'	both of the above	✅ the argument holds

The central claim is correct: trigger.type is the raw event type, 'chat.mention' !== 'mention', and the branch could not fire.

1. The in-file citation resolves to unrelated code

nativeRuntimeService.ts:512-513 reads:

agentEventService:994 forwards type verbatim, and the claimable-set gate at :697 in this same file says so out loud

That gate is not at :697 and not in agentEventService. It is nativeRuntimeService.ts:740 — this file, 43 lines below the citing comment:

// Raw-type gate mirrors the wrapper's claimable set (mention variants +
// message-shaped wakes); heartbeat/task/join triggers carry no message.
const CLAIMABLE_RAW_TYPES = new Set([...]);

agentEventService.ts:697 is the #993 pending-delete discussion — unrelated. And because the preceding clause names agentEventService, "this same file" reads as that file, so a reader resolving the pointer lands on the wrong thing whichever file they open. I grepped both at origin/main and at this head: the string exists nowhere in agentEventService.ts.

The claim it supports is true — the pointer to its proof is what's wrong. Worth fixing because this is the fourth live instance of a load-bearing miscitation this week (TASK-025's title, TASK-026's spec, and ADR-024 all cited poller.js for a loop no seat executes), and a citation inside the fix for a discovery bug is the last place it should survive.

2. MENTION_RAW_TYPES contradicts its own stated rule

The new set at :488 documents itself as err-wide:

Deliberately a superset of what matches today: a name in here that never arrives costs nothing, a name missing from it costs a discarded cue, and this file has already paid that once.

But it omits message.posted, which the sibling CLAIMABLE_RAW_TYPES at :743 does include:

MENTION_RAW_TYPES    chat.mention, thread.mention, dm.message, mention, chat.message
CLAIMABLE_RAW_TYPES  chat.mention, thread.mention, dm.message, mention, chat.message, message.posted

Two raw-type vocabularies in one file, differing by one member — which is structurally the bug being fixed, one scope smaller.

Impact is small: board wakes always carry payload.content, so a content-less message.posted is the only case, and it lands on the generic "Trigger: X, use commonly_read_context" fallback — the very output this PR calls the defect. Small blast radius, but the set's own rationale says to include it, and + 'message.posted' costs nothing by that rationale.

Tests

The suite drives the real function rather than asserting on source text, and 'some.new.type' in the parametrised case is the right guard — it pins the behaviour for types nobody has invented yet, which is what makes this fix durable rather than another vocabulary that can drift.

One gap worth naming, not fixing here: nothing tests that message.posted with content and message.posted without content take different paths. The content-ful case is covered; the content-less one is exactly finding 2's blind spot.

Not verified

• Whether payload.content for every chat.mention already carries a reply instruction. The old branch appended "then call commonly_post_message with your reply" and returning the cue verbatim drops it. I believe that is correct — formatPodContextFrame is unconditional in buildContentForTarget, and the ADR-012 §9 DM cue does instruct replying — but I did not read the composed output for a native-tier chat.mention end to end.
• The 58-event / 30-fallthrough census. I confirmed the mechanism that makes it plausible, not the count.