[antra-tess]

Problem

A debounced gate wake ([Gate: N events matched]) requests inference with telemetry provenance only, with no channelId. That was deliberate, per the comment this PR replaces. The turn's locus then falls back to defaultPublishChannel, which is the most recent channels/incoming message on any channel. On a locus-mode resident that misrouted DM replies twice in one evening:

1. Ambient after the DM. A DM arrived, and one second later an ambient message landed in a guild channel. The batched wake fired and the DM reply was published into the guild channel. No [routing] notice appeared, because the pin hadn't changed from the previous turn, so the agent had nothing to check.
2. Ambient before the DM. The DM arrived as a push event, which is how Discord DMs arrive. Push events never update defaultPublishChannel, so the reply went to the channel that had last seen channel traffic, minutes earlier.

The direct (non-batched) path already routes to the addressed channel. Batched wakes couldn't, and push events' raw snowflake ids would have made it impossible anyway.

Change

• EventGate resolves each debounced event's registered channel when the event is queued (PendingEvent.routeChannelId), through a new optional resolveRouteChannel(info).
  • Default: a channel-incoming event's own id, and nothing for push events.
  • The framework supplies derivePushEventChannel, the same derivation ingestion uses to register the DM channel on arrival.
  • A resolver that throws never breaks gating.
• wakeProvenance reports routeChannelId only when the chosen event (the newest addressed one) is addressed and resolved. It never falls back to an older addressed event: if the newest one can't be routed, the legacy fallback stands rather than answering the wrong person.
• The gate's requestInference wiring in the framework sets channelId + addressed: true from routeChannelId. The existing turn-start selection (addressed wins) does the rest.
• Batched-wake lines show the registered id (discord:dm:…) instead of the raw snowflake, so the agent sees the same spelling routing notices and send tools use.
• Ambient-only batches are unchanged.

Tests

• test/batched-wake-locus.test.ts: end to end over a new MCPL fixture (wake-locus-mcpl-server.mjs) that sends a Discord-shaped DM push event and channel traffic in one debounce window.
  • DM→ambient, ambient→DM and mention→ambient each reply to the addressed channel. All three fail on main, with the reply published to the ambient channel.
  • Ambient-only keeps the most-recent-inbound fallback.
• test/event-gate.test.ts covers:
  • an addressed batch versus an ambient-only one;
  • the default resolver;
  • a newest-addressed event with no route, which must not guess an older one;
  • a resolver that throws.
• Full suite (merged onto current main): 1226 pass, 4 skipped, 4 fail. All four failures are mcpl-awareness-barrier "startup globally gates …", the known load flake. That file passes 25/25 three times when run alone.

Review fixes (bc21aaa)

All four Greptile findings were valid, and each new test fails when its fix is reverted.

• Older gate wake overrode a newer direct wake. The turn's channel pick now orders by event time (wakeAt, else timestamp), not queue order.
• Route-only addressed push was skipped. wakeProvenance now counts a resolved route as naming a channel.
• Forks bound elsewhere got the route. mayTakeGateRoute gives the route to a fork only for its home channel, and to no other agent when a fork owns that channel.
• Borrowed author. An addressed routing winner is its own provenance and never borrows another request's counterparty. This also fixes the same misattribution for direct addressed pushes on main.

Review fixes, round 2 (3a7a22a)

• Ambient wake lost its attribution. Fixed. Round 1 let an ambient route-only push become the provenance pick, which then carried no telemetry. Now only an addressed event's route makes it a candidate.
• Fork-owned wake still wakes the trunk. Not changed here. main already does this (the gate broadcasts every wake to the trunk with no locus), and conversation routing is being deprecated. See the thread for the follow-up shape.

Notes

• feat(focus): single-channel focus mode with held backlog, autoreply, and expiry #195: its review (finding 1) points out that PendingEvent keeps only the raw push channel id, so the enter-focus purge can't derive it. routeChannelId here is exactly that derived id, if feat(focus): single-channel focus mode with held backlog, autoreply, and expiry #195 wants to reuse it.
• Explicit-mode agents: routing is unaffected, since they have no locus. Their typing indicator now shows on the addressed channel for batched wakes, as it already did for direct wakes.

🤖 Generated with Claude Code

[greptile-apps]

Confidence Score: 4/5

[Medium risk] Fixes message routing for batched wake events.

The PR is not safe to merge while a fork-owned addressed wake can make the trunk publish into an unrelated fallback channel.

Findings

1.  Fork wake misroutes trunk speech ▶
2.  Ambient wake loses attribution ▶

Fix with agent prompt

### Issue 1
src/framework.ts:1589-1592
When an addressed batched wake belongs to a conversation fork, this guard withholds the channel from the trunk but still queues the trunk for inference. If ambient traffic has made another channel the global fallback, the trunk can publish its response there instead of in the addressed channel.

### Issue 2
src/gate/event-gate.ts:211
An ambient push with only a registered channel ID and no author now qualifies as the batch’s newest provenance event. Because its route is reported only for addressed events, the wake carries neither channel nor counterparty telemetry, even if an earlier event supplied both. This leaves the host unable to attribute that ambient wake.

```suggestion
    if (!e.channelId && !e.authorId && !(e.addressed && e.routeChannelId)) continue;
```

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

Summary

This PR routes addressed debounced wakes to their registered channel and updates turn selection to prefer the newest addressed event.

• Adds push-channel resolution and batched-wake routing coverage.
• The fork route guard still permits a non-owning trunk to answer through an unrelated fallback channel; route-only ambient pushes can lose wake attribution.

_{Reviews (2) · Last reviewed commit: "fix(gate): batched-wake routing review f..."}

[antra-tess]

@greptileai

[greptile-apps]

Fork wake misroutes trunk speech When an addressed batched wake belongs to a conversation fork, this guard withholds the channel from the trunk but still queues the trunk for inference. If ambient traffic has made another channel the global fallback, the trunk can publish its response there instead of in the addressed channel.

Knowledge Base Used: MCPL conversation and inference routing

Prompt To Fix With AI

This is a comment left during a code review.
Path: src/framework.ts
Line: 1589-1592

Comment:
**Fork wake misroutes trunk speech** When an addressed batched wake belongs to a conversation fork, this guard withholds the channel from the trunk but still queues the trunk for inference. If ambient traffic has made another channel the global fallback, the trunk can publish its response there instead of in the addressed channel.

**Knowledge Base Used:** [MCPL conversation and inference routing](https://app.greptile.com/anima-labs/-/custom-context/knowledge-base/anima-research/agent-framework/-/docs/mcpl-conversation-and-inference.md)

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

[antra-tess]

Not fixing this here. It already happens on main. There, getAgentNames broadcasts every gate wake to the trunk, and requestInference sets no locus, so a fork-owned addressed batch already wakes the trunk onto the most-recent-inbound fallback. The guard leaves the trunk exactly where main has it. Before the guard, the trunk would have answered inside the fork's own channel, a second reply next to the fork's.

The real fix is per-agent wake provenance: work out each agent's provenance only from events it owns, and skip agents that own none. That changes gate broadcast semantics. Conversation routing is also being deprecated (chore/deprecate-conversation-routing), and no deployed config enables it. That makes it a follow-up at most, not part of this PR.

[greptile-apps]

That’s fair. Given the current broadcast semantics, mayTakeGateRoute prevents the trunk from producing a second reply in the fork’s channel while preserving the existing main behavior for the trunk (waking it on the legacy fallback). Fixing that remaining misroute requires per-agent provenance and changing which agents receive or act on a gate wake, which is separate from this PR—especially with conversation routing being deprecated and disabled in deployed configurations. I’ll treat the earlier finding as non-blocking and withdraw it for this change.

[greptile-apps]

Ambient wake loses attribution An ambient push with only a registered channel ID and no author now qualifies as the batch’s newest provenance event. Because its route is reported only for addressed events, the wake carries neither channel nor counterparty telemetry, even if an earlier event supplied both. This leaves the host unable to attribute that ambient wake.

Suggested change

	if (!e.channelId && !e.authorId && !e.routeChannelId) continue;
	if (!e.channelId && !e.authorId && !(e.addressed && e.routeChannelId)) continue;

Knowledge Base Used: Event gate pipeline

Prompt To Fix With AI

This is a comment left during a code review.
Path: src/gate/event-gate.ts
Line: 211

Comment:
**Ambient wake loses attribution** An ambient push with only a registered channel ID and no author now qualifies as the batch’s newest provenance event. Because its route is reported only for addressed events, the wake carries neither channel nor counterparty telemetry, even if an earlier event supplied both. This leaves the host unable to attribute that ambient wake.

```suggestion
    if (!e.channelId && !e.authorId && !(e.addressed && e.routeChannelId)) continue;
```

**Knowledge Base Used:** [Event gate pipeline](https://app.greptile.com/anima-labs/-/custom-context/knowledge-base/anima-research/agent-framework/-/docs/event-gates.md)

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

[antra-tess]

Valid. My previous round introduced it. Fixed in 3a7a22a with your suggested condition: only an ADDRESSED event's route makes it a provenance candidate. Test: event-gate › "a newer AMBIENT route-only push does not hide an earlier event's channel and author", which fails without the fix.