Found during review of #144 (round 2; both reviewers, root cause on main).
ChannelRegistry.handleIncoming calls the EventGate, and a debounce policy queues the event as a side effect of evaluate (event-gate.ts ~1093) BEFORE handleMcplChannelIncoming consults TuneOutCoordinator.onIncoming (framework.ts ~4924-4941). Nothing removes the queued event, so deliverEvents still wakes the primary with a "[Gate: N events matched] … messages in " line. The tune-out suites never configure a debounce policy, so it is untested.
Proposed fix: consult tune-out state before evaluating (or filter the batch at flush against getTuneOutState), plus an integration regression covering debounce + diversion. #144 no longer sets a speech locus from gate wakes, so this leak has no routing consequence there — but the spurious wake itself remains. Relates to #77.
Found during review of #144 (round 2; both reviewers, root cause on
main).ChannelRegistry.handleIncomingcalls the EventGate, and a debounce policy queues the event as a side effect ofevaluate(event-gate.ts~1093) BEFOREhandleMcplChannelIncomingconsultsTuneOutCoordinator.onIncoming(framework.ts~4924-4941). Nothing removes the queued event, sodeliverEventsstill wakes the primary with a "[Gate: N events matched] … messages in " line. The tune-out suites never configure a debounce policy, so it is untested.Proposed fix: consult tune-out state before evaluating (or filter the batch at flush against
getTuneOutState), plus an integration regression covering debounce + diversion. #144 no longer sets a speech locus from gate wakes, so this leak has no routing consequence there — but the spurious wake itself remains. Relates to #77.