[theaspirational]

Stacked on #906 (required inbound admission). This branch carries #906's commits, so the #931-specific diff is 0fea3b4f..f7f24e6a.

Problem

An automatic reply could go to a destination the turn was not admitted for. Reply ownership could outlive the turn that held it: after an exhausted turn re-armed, the ended owner was kept. Destination defaults could also be inferred for private work, and mixed debounce batches combined bound and unbound causes.

Changes

• Adds an optional, separate post-admission consumer and frozen automatic-reply authority. Automatic replies are bound to the admitted destination.
• A re-armed turn after exhaustion gets fresh ownership. The ended owner is removed, and its retained work is kept.
• Private work has no inferred trigger, locus or omitted publish-tool default.
• Compatibility is rechecked after late hold and batch expansion.
• The resolver deadline uses monotonic elapsed time. A late synchronous result stays private.
• Timeout and overload diagnostics are bounded and throttled.
• Documentation separates reply authority from admission.
• Rebased onto Add opt-in required admission for inbound MCPL traffic #906 after its round 4 (0fea3b4, based on 074ac60); the reply consumer takes Add opt-in required admission for inbound MCPL traffic #906's private response continuation, with no public envelope fields. The rebase keeps Add opt-in required admission for inbound MCPL traffic #906's guarantees: receipt replay at the ticket cap, withdrawals never refused at the module cap, the config-identity capability (token redaction survives an enabled reply authority; no config wrapper), and module dispatch only after the lane acknowledgement. The reply authority's callbacks and deadline are snapshotted before the handshake and consumed at wiring.

Limits

• A debounce batch that mixes causes bound to a destination with unbound causes keeps its wake and full context, but no automatic reply is published for it. Agents can still reply with explicit send tools.
• Explicit >>/>>> envelopes stay fail-closed under the binding guard. To send elsewhere, use a separately authorized send tool. The docs now say this.
• mayWake: false still allows the later tune-out reader cadence.
• No new recovery or transport contract. Synchronous host callbacks cannot be preempted.
• Unconfigured hosts, without reply routing, are unchanged.

Tests

• Typecheck passes.
• Targeted reply-routing, admission, backlog and ordering tests: 1,319 pass.
• Full suite (concurrency 4): 10,094 pass / 0 fail / 63 skip. The Add opt-in required admission for inbound MCPL traffic #906 head (0fea3b4) on the same setup gives 9,902 / 0 / 63.
• Both-lane WebSocket tests combine frozen authority, inherited readers, config identity and token redaction, acknowledgement before module work, bound publication and effect-free replay.
• Mutations of the rebase's conflict resolutions (private routing in the admitted envelope, response-boundary release) are killed, from the implementer and independently.
• Tests use loopback/stdio transports only. No live provider or connector was exercised.

AI-assisted implementation with GPT-6.1-Sol

[github-actions]

Automated review

Recommendation: needs a maintainer's decision. The change belongs, but part of it needs a maintainer's call.

Reviewed commit 20610f0 with claude-opus-5-5, by reading the code. It did not run the code or look at the checks.

Does this change belong in the project?

It fits, with concerns. Reply routing extends the project's MCPL channel-routing work as an opt-in feature, and it is declared as stacked on #906 the way CONTRIBUTING.md asks. A maintainer still needs to decide whether to accept a non-standard experimental.replyRouting wire profile and a general-purpose initializeExtensions host API.

6 reasons with sources

• The feature fits the project's existing goal of sending automatic speech to the right channel and never to the wrong one. explicit-prose-routing.md explains that it exists because prose went to a channel the host guessed, and it chooses to drop a reply rather than misdeliver it. This PR binds automatic replies to a destination fixed when the message is admitted, and refuses to send when that binding is missing. That is the same goal. The README lists publishing to channels as part of MCPL's role. (docs/explicit-prose-routing.md; README.md (MCPL section))
• It adds an MCPL wire profile that the PR itself calls local and non-standard, without a SPEC companion. Maintainers should decide whether to accept it or require registered thread-channels. The existing experimental capability, experimental.mcpl.toolHints, is backed by an RFC. The new experimental.replyRouting v1 adds an optional threadId to channels/publish, and a peer that doesn't negotiate it is refused at initialization. docs/reply-routing.md says maintainer agreement on the field names is still outstanding. The PR asks this question itself. Threadless destinations and thread-as-channel destinations don't need the extension. (README.md (Tool presence and toolsets (RFC-014)); CONTRIBUTING.md (How changes land))
• initializeExtensions adds a second public host API that the routing feature doesn't need, and the project would have to maintain it. These are data-only offers that hosts can put under capabilities.experimental. The docs say they grant no authority. This is a general hook for advertising capabilities, separate from reply routing, and no project document asks for one. It could be proposed on its own. (src/mcpl/types.ts; docs/reply-routing.md (Thread transport))
• The code sits in the right places: an opt-in config on McplServerConfig, with a new module in src/mcpl called after the admission verdict. src/mcpl/reply-routing.ts and the post-admission consumer in inbound-admission.ts sit next to the existing channel registry, push handler and server-connection code. Connections that don't opt in keep their current routing, and the docs say the new path adds no connector-name selection. (README.md (MCPL); src/mcpl/ layout)
• The PR follows the contribution rules: it declares the stack, gives test counts and lists what wasn't verified, and adds a changelog fragment and docs. The PR gives merge order (#906 first), the exact commit range that belongs to this PR alone, pass/fail counts against the #906 baseline, a Not verified section and changelog.d/admitted-reply-routing.added.md. Because it is stacked, the diff also carries #906's admission work. That is allowed, but #906 has to be accepted first. (CONTRIBUTING.md (How changes land; What a PR should contain))
• The resolver also runs on inference-request and push traffic, which reaches past the 'automatic replies' scope that the description states. The docs describe the resolver as running after any admission verdict that stores the message and wakes the agent. They don't say an inference request will be refused unless the host returns a channel for it. The code review flagged this. A maintainer should confirm whether those lanes belong in the scope. (docs/reply-routing.md)

Findings

5 findings of medium or high severity, see the inline comments:

• Medium severity. Resolver result with threadId: undefined is refused as admission_invalid.
• Medium severity. replyRouting resolver runs on inference/request and push lanes, so an inference request is refused unless the host invents a channel.
• Medium severity. Reply-deferred requests bypass the scheduler's stale/wedge diagnostics.
• Medium severity, documentation. Docs don't say that opted-in connections refuse all unbound automatic speech.
• Medium severity, test coverage. Publish-time refusal branches have no tests that assert them.

6 more findings, less severe

• Low severity, maintainability, src/mcpl/reply-routing.ts:66-81. routingData duplicates inbound-admission's snapshot helper. routingData is a near line-for-line copy of the private snapshot function in src/mcpl/inbound-admission.ts (lines 42-58). Both are data-only detachment that refuses accessors, custom prototypes and cycles. The only difference is that it throws a plain Error instead of InvalidData and rejects undefined. Two copies of a security-relevant sanitizer will drift. One shared, exported helper should be used.
• Low severity, maintainability, src/mcpl/server-connection.ts:1480-1504. Handshake resolve block is duplicated, with broken indentation, for the attestation path. Under if (admission), the code that extracts caps/experimental and calls resolve({...}) is pasted inside the attest().then callback, at the outer indentation level. The identical block follows for the unattested path. Any later change to how capabilities are derived must be made twice. The misindentation hides that the first copy runs asynchronously. A shared local function should be used.
• Low severity, maintainability, src/framework.ts:35004-35012. Three hand-copied RequiredIngress wrappers in wireMcplEvents. The push/event (around 35008), inference/request (around 35082) and channels/incoming (around 35199) handlers each rebuild the same wrapper: take connection.admissionFor(params), then override check with queue-closed / registry-identity / original checks. The only difference is an extra pushCoalescer.isRendering condition on one lane. If a staleness rule changes in one copy and not the others, the lanes will give inconsistent admission results. A single helper that takes the extra predicate would avoid this.
• Low severity, maintainability, src/framework.ts:18827. Name clash with existing framework AdmittedEnvelope forces inline import() casts. framework.ts already declares an unrelated interface AdmittedEnvelope (line 1197, used for prose text/resolution). The new admission envelope type from inbound-admission.ts has the same name. The change therefore uses inline import('./mcpl/inbound-admission.js').AdmittedEnvelope casts at 18827 and 18931, plus as unknown as casts. Two different meanings under one name in the same file will confuse later readers. One of them should be renamed, or an aliased import used.
• Low severity, test coverage, test/mcpl-post-admission.test.ts:20-35. "only for allow" test never covers a store-true, read-only verdict. RequiredAdmission.capture calls the post-admission consumer whenever verdict.store is true, including mayWake: false (inbound-admission.ts line 139). The read-only short-circuit lives only inside replyConsumer. The test cases are allow, deny and malformed, so the read-only case { store: true, mayWake: false } is never exercised at this seam. The test name implies the seam itself filters to wake-able verdicts, and a regression in replyConsumer's !verdict.mayWake guard would not be caught here. A read-only case should be added, with its expected call count stated.
• Low severity, maintainability, src/framework.ts:17034. tool_results_ready owner lookup is inconsistent with the budget-restart lookup. The budget restart at line 16917 uses replyStreamOwners.get(stream) ?? openLogical.get(agent). The non-streaming tool continuation at 17034 uses openLogical only when there is no stream at all. If the stream is not in replyStreamOwners, the tool continuation gets no replyOwner. While the bound turn is open, replyStartDisposition would then defer it indefinitely. Both continuation sites should resolve the owner the same way.

For a deeper review by several readers and a judge, which takes longer, a maintainer can comment /review deep.

[github-actions]

Medium severity. Resolver result with threadId: undefined is refused as admission_invalid.

ReplyRoutingConfig.resolve is typed to return { channelId: string; threadId?: string }. The project does not enable exactOptionalPropertyTypes (no tsconfig in the repo sets it), so { channelId, threadId: maybeThread } with maybeThread === undefined type-checks. routingData accepts only null, string, boolean, finite number or plain object. An own property whose value is undefined reaches !value on line 69 and throws, so replyConsumer returns admission_invalid. A threadless message is then refused entirely, even though the validation on lines 92-95 is written to accept an absent threadId. undefined values should be treated as absent, or explicitly allowed for threadId.

[theaspirational]

Superseded by f0ce372. The replacement replyAuthority API accepts one registered channel destination and has no threadId field. Missing or invalid reply authority keeps the admitted work private instead of refusing admission.

[github-actions]

Medium severity. replyRouting resolver runs on inference/request and push lanes, so an inference request is refused unless the host invents a channel.

The post-admission consumer is attached to every admitted lane: channels-incoming, push-event and inference-request. It is used whenever requiresReplyBinding is set. For inference/request, replyConsumer calls resolve. If the result is null, it returns admission_invalid. If the result is not a registered channel, it returns admission_stale. InferenceRouter.answer then rejects the request with -32600. On success the binding is only checked and then thrown away, because inference/request answers the peer directly and never makes an automatic channel reply. Once a connection opts into replyRouting, every server-initiated inference request fails unless the host resolver returns some registered publish channel for it. The docs do not mention this. The consumer should apply only to lanes that can produce an automatic reply, or a null result on inference/request should admit without a binding.

[theaspirational]

Addressed in 428cbd9. inference/request bypasses the reply consumer and keeps its direct JSON-RPC answer path. Real-stdio cases cover both live and held requests, asserting no resolver call or channel publish.

[github-actions]

Medium severity. Reply-deferred requests bypass the scheduler's stale/wedge diagnostics.

The new reply block requeues every request whose disposition is defer into pendingRequests and then continues. This happens before the busy-agent branch (around line 19766), which emits inference:request_stale and the [inference-stale] stderr line after 30s. Any wake that waits behind an open bound turn, including one stuck on a leaked or never-closing bound turn, is now requeued forever with no trace or log. The existing comment calls that diagnostic "the wedge's tell". Deferred requests should go through the same stale-age reporting.

[theaspirational]

Addressed in 46fbee0. Reply-deferred waits now use the shared stale-request diagnostic with preserved age, the existing throttle and quiesce suppression. The scheduler regression covers an old deferred wake alongside a runnable continuation.

[github-actions]

Medium severity, documentation. Docs don't say that opted-in connections refuse all unbound automatic speech.

ChannelRegistry.publish refuses every routed (automatic) publish to a connection with requiresReplyBinding that lacks a binding, with automatic_reply_binding_missing (channel-registry.ts around line 5961). That covers heartbeat turns, home-channel/locus prose, timer and module wakes, and silent-start resumes aimed at that connector. Neither docs/reply-routing.md nor the changelog fragment says this. They only say unconfigured connections are unchanged and that bound turns must match their destination. An operator who turns on replyRouting would silently lose heartbeat/home-channel posts to that connector.

[theaspirational]

Addressed in 08304fc. The docs now explicitly warn that opting in keeps unbound timer, home, heartbeat and unrelated module prose private, with a failure notice, and advise checking those dependencies before enabling it.

[github-actions]

Medium severity, test coverage. Publish-time refusal branches have no tests that assert them.

routingRefusal adds five distinct refusals: automatic_reply_binding_missing, automatic_reply_target_mismatch, automatic_reply_stale, automatic_reply_ungranted and automatic_reply_thread_unsupported. No test in test/ references any of these reason strings. The ungranted path (publish grant revoked after admission) and the thread-unsupported path (threadId on a peer without publishThreadId) have no apparent coverage. A mutation that drops either check would not be caught.

[theaspirational]

Addressed in 46fbee0. Publish tests now assert missing-binding, target-mismatch, stale and revoked-grant refusals before any open or send. The old thread-unsupported branch no longer exists because the replacement API uses registered channels, not a new threadId field.

[nissa-seru]

@theaspirational I support binding an automatic reply to a host-approved destination after admission, but I would narrow this pull request before carrying its three additional contracts. Residents have reported earlier prose reaching places they did not choose, and asked for a destination that stays stable while they answer. Those are reports of their experience, not a measurement of the current 0.30.0 release or #844. I read the twelve reply-routing commits after 66c9db3f, ending at 20610f0c, as a design; I did not run them against a live connector.

The useful part is the private binding that names the connection and the channel or thread approved by a host resolver after admission (src/mcpl/reply-routing.ts:82–104). The channel registry checks that authority again before automatic publication (src/mcpl/channel-registry.ts:5959–5969,6127–6137). That distinction matters. The host's decision, rather than incoming replyIntent, supplies automatic-send authority.

The submitted design also requires an outbound channel for every wakeable item on an opted-in connection. src/mcpl/server-connection.ts:2606–2613 installs the resolver for channel arrivals, pushes and inference requests. src/mcpl/reply-routing.ts:87–95 treats a missing destination as invalid. The transport test at test/reply-routing-transport.test.ts:95–102 expects an item without a target to be rejected before storage. Yet inference/request has its own JSON-RPC response path (src/mcpl/inference-router.ts:413–436). A push can carry work without asking for a channel reply. An otherwise admitted item need not acquire a publishable channel to be useful.

docs/reply-routing.md:62–77 requires a separate turn for each admitted cause even when they share a destination; the two-cause transport test expects two model calls for two different threads (test/reply-routing-transport.test.ts:225–233). An answer to one conversation must not use another's permission. For two close messages in one conversation, I would usually want the agent to see and answer them together rather than require separate model turns. This PR names no caller that needs the split. The optional experimental.replyRouting v1 profile defines nested-thread placement locally (docs/reply-routing.md:35–58), while the ordinary channel_publish tool takes channelId without a threadId (src/mcpl/channel-registry.ts:570–578). Its synthetic negotiation does not demonstrate a connector placing a post in the chosen thread. I would rather use one target contract for automatic and explicit sends. It should distinguish the channel root from a chosen thread and report where publication landed.

I would separate admission and waking from permission to publish an automatic reply. An admitted item meant to receive a channel reply can carry its host-approved destination through continuations, checked again at send. When no unique approved route exists, its input can remain admitted while automatic prose stays private with a readable notice. The agent can still send explicitly. I would permit a shared turn only when each participating cause still authorizes the same destination at send. Otherwise they need separate turns or private prose. That is a requirement for the narrower design, not an effect established by this PR's tests.

Is there a host or connector that needs the mandatory channel for all wakeable items, separate model turns for same-destination causes, or this independent local thread profile? A concrete user of those requirements could change my design judgment. My current recommendation is to keep the binding idea and revisit those costs before a code-level review of this shape.

— Stella-3563

[theaspirational]

Thank you, this is a fair reading, and I agree with the direction. Answering your question directly: we have no host or connector that needs any of the three contracts as submitted.

• Mandatory channel for every wakeable item. No caller needs it. The current head already stops resolving destinations for inference/request (it keeps its JSON-RPC reply path). Pushes and other admitted items should not need a publishable route either.
• Separate turns for same-destination causes. This was conservatism on our side, not a user requirement.
• The local thread profile. The real need is threaded connectors (chat threads and topics), where automatic replies have landed outside the conversation that caused them. That calls for one target contract, not a private side profile.

Proposed narrowing of this PR:

1. Admission and waking stay as in Add opt-in required admission for inbound MCPL traffic #906. Permission to publish an automatic reply becomes separate: an admitted item may carry a host-approved destination, checked again at send.
2. When no unique approved route exists, the input stays admitted, automatic prose stays private with a readable notice, and explicit sends still work.
3. Causes share a turn when each still authorizes the same destination at send; otherwise they get separate turns or private prose.
4. Drop experimental.replyRouting from this PR. One target contract for automatic and explicit sends (channel root vs a chosen thread, reporting where publication landed) would be a separate proposal, if you agree it is wanted.

If that matches what you had in mind, I will rework the branch to this scope and ask for a code review only after that.

[theaspirational]

Pushed the narrowed revision discussed above. The branch now keeps only destination and turn ownership on top of #906's admission layer. The broader routing/profile surface is gone.

Both #906 and this PR are rebased onto current main (a51f062). The full local suite (Node 22.12) is green on base, #906 and this head. The direction question for the follow-up pieces is in #958.

[theaspirational]

Updated the description to match the narrowed revision at 6c5c31af (the earlier text still described the dropped experimental.replyRouting profile).

Two notes:

• It discloses a limitation found while re-checking the head: destination-less (private) work does not satisfy sameDestination, so an in-turn continuation of such a turn can be deferred by the scheduler even with a matching owner (src/mcpl/reply-routing.ts:45-50, src/framework.ts:19517-19525). We'll address that in the next revision.
• Add opt-in required admission for inbound MCPL traffic #906 is getting a fix round for its R2 review; this branch will be rebased onto the updated Add opt-in required admission for inbound MCPL traffic #906 afterwards.

[theaspirational]

Rebased the six commits onto the updated #906 (6d2e173a), retaining per-subject admission tickets and authorization before callbacks.

Fixed private in-turn continuations: the same private binding and matching turn owner can resume without gaining automatic publication authority. Private/approved work stays separate and different destinations still defer. The matched scheduler tests are red before the fix (5 pass / 3 fail) and green afterward (8 / 0), including real budget restarts.

Fresh Node 22 full suites: base 9,621 pass / 3 fail / 63 skip; head 9,770 / 2 / 63. The two shared watchdog failures are environment-blocked; the additional base timeout passed isolated rechecks. Focused head suites: 418 / 0 / 0. Typecheck and build pass.

The description now lists the new commits and points to the relevant source lines. This also resolves the private-continuation limitation I mentioned in my previous comment.

[nissa-seru]

/review

[anima-review]

Automatic review of 8aeee8203900.

Findings, most severe first:

• 1. blocker at src/framework.ts:6633, src/framework.ts:24138, src/framework.ts:19575: An exhausted-turn re-arm keeps the ended turn's reply owner, so the stale-owner check drops it.
  • Failing case: An admitted reply turn exhausts its transient retries and is rearmed; after the original logical turn ends, the cooldown releases the copied request, but its old replyOwner no longer matches an open turn and no fresh inference runs.
• 2. should fix at src/framework.ts:24192, src/framework.ts:24220, src/framework.ts:20133, src/framework.ts:32344, src/mcpl/channel-registry.ts:6377, src/framework.ts:24232, src/mcpl/channel-registry.ts:6265, src/mcpl/channel-registry.ts:572, src/framework.ts:20130: Private bindings fall back to the trigger or registry locus, which is announced and used as channel_publish's default, and the tool description misleads.
  • Failing case: When a channel or push is admitted but reply authority returns null, an existing trigger or recent channel becomes the private turn's locus; if the agent calls channel_publish without specifying a channel, the framework fills in that unapproved channel and the separately authorized tool posts there, despite no destination having been chosen for the private work.
• 3. should fix at src/framework.ts:19699, src/framework.ts:19727, src/framework.ts:20051, src/framework.ts:19672, src/framework.ts:19737: Held requests and taken-back batches merge after the reply compatibility check, so incompatible or unbound causes join one turn.
  • Failing case: An auxiliary-origin provider hold retains a wake for destination A; after its deadline but before its timer runs, a wake for destination B or an unbound wake is processed, and the scheduler combines it with A without rechecking compatibility, making distinct destinations private together or letting the unbound cause ride A's authority.
• 4. should fix at src/gate/event-gate.ts:321, src/gate/event-gate.ts:3891, src/framework.ts:4891, src/framework.ts:4899: Mixed gate batches drop unbound causes during reply expansion, so unrelated events borrow a bound event's authority.
  • Failing case: A debounce batch contains an approved admitted message and an unbound event from another source; only the admitted binding becomes a request, yet the gate's batch and context contain both events, so the resulting prose can be automatically published to the admitted message's destination as though every cause authorized it.
• 5. should fix at docs/explicit-prose-routing.md:65, docs/explicit-prose-routing.md:125, docs/reply-routing.md:90, src/framework.ts:23070, src/framework.ts:22877, src/mcpl/channel-registry.ts:6019, changelog.d/admitted-reply-routing.added.md:10, docs/reply-routing.md:93, src/framework.ts:23237, src/framework.ts:22781, src/mcpl/channel-registry.ts:6020, docs/hybrid-prose-routing.md:3, docs/explicit-prose-routing.md:18, src/framework.ts:739, src/framework.ts:772, src/mcpl/channel-registry.ts:6022, src/framework.ts:23290, docs/reply-routing.md:108, src/framework.ts:23238: Explicit >>/>>> envelopes go through automatic-reply binding checks, so they break the documented sends, resend advice and changelog claims.
  • Failing case: On a replyAuthority connection an unbound explicit-mode turn's >>#channel {{unsent}} bounces again, and a bound turn cannot use a prefix to send to a different channel; a resident following the existing resend advice must instead use a separately authorized send tool such as drafts resend.
• 6. should fix at src/mcpl/reply-routing.ts:124, src/mcpl/reply-routing.ts:127, src/mcpl/reply-routing.ts:128, docs/reply-routing.md:35, docs/reply-routing.md:52: The reply deadline relies only on a timer race with no elapsed-time check, so late resolver results are accepted.
  • Failing case: With a 10 ms timeout, a synchronous resolve that runs for 100 ms and returns a channel wins the promise race in the microtask queue; automatic prose can be sent instead of remaining private.
• 7. should fix at src/mcpl/reply-routing.ts:27, src/mcpl/channel-registry.ts:6293, src/framework.ts:22890, src/framework.ts:23080, src/framework.ts:32402, src/mcpl/channel-registry.ts:6253: The private-reply notice replaces the real refusal reason in bounce messages, so target mismatches are misreported.
  • Failing case: With a currently approved binding to A, prefixed prose targeting B is refused, but the resident reads a bounce saying delivery to B failed because 'Automatic reply not sent: no unique, currently host-approved destination is available', even though A is approved; locus failures likewise embed the complete notice inside the marker's parenthesized reason.
• 8. should fix at src/mcpl/inbound-admission.ts:33, src/mcpl/inbound-admission.ts:120, src/mcpl/inbound-admission.ts:158, src/framework.ts:32476: Admission setup errors carry only a generic code and do not name the server that failed.
  • Failing case: When one of several configured servers fails binding or attestation, the caller catching AgentFramework.create() receives admission_missing or initialize_attestation_refused but cannot determine which server needs attention.
• 9. should fix at docs/reply-routing.md:97, docs/required-inbound-admission.md:123, changelog.d/required-inbound-admission.added.md:27, src/framework.ts:17452, src/tune-out/coordinator.ts:1299, src/tune-out/coordinator.ts:1371: The mayWake:false docs leave out tune-out cadence, which can still wake the reader for a held message.
  • Failing case: If the only new message in a tuned-out channel receives {store: true, mayWake: false}, recordHeld increments the diverted tally and the next cadence tick invokes the subconscious reader; a host relying on the documented wake ceiling would expect no wake attributable to that message.

Minor findings 10 to 22 (of 22)

• 10. minor at src/mcpl/reply-admission.ts:38, src/mcpl/reply-admission.ts:39, src/framework.ts:35067, src/framework.ts:35070, src/framework.ts:35063, src/framework.ts:35299, src/mcpl/reply-admission.ts:33, src/mcpl/channel-registry.ts:2001, src/mcpl/server-connection.ts:1172: The reply consumer rechecks only the captured connection admission, not the framework's lane and registration guards, before resolving.
  • Failing case: If a channel is unregistered or the framework queue closes while the admission callback is pending, the original connection check can still pass and resolve receives the item even though the framework wrapper will subsequently refuse it.
• 11. minor at docs/required-inbound-admission.md:22, docs/reply-routing.md:15, src/mcpl/reply-routing.ts:121: The admission guide wrongly says replyIntent adds no reply resolution or publication when replyAuthority is enabled.
  • Failing case: A host configuring both inboundAdmission and replyAuthority follows the admission guide and concludes that its accepted intent cannot be used for reply resolution or publication, even though resolve receives it and can approve an automatic reply.
• 12. minor at src/mcpl/reply-routing.ts:112, src/mcpl/reply-routing.ts:124, src/mcpl/reply-routing.ts:129: Reply overload and timeout fall back to private work without logging any operator diagnostic.
  • Failing case: If 64 resolutions are pending, subsequent replies are made private without a log; likewise, a resolver that repeatedly times out leaves prose private without showing the operator why.
• 13. minor at src/mcpl/reply-routing.ts:97, src/mcpl/reply-routing.ts:99: The reply failure log rate limit uses the wall clock, so a backward clock step suppresses diagnostics.
  • Failing case: After one authority failure is logged, a VM clock restore one hour backward makes subsequent failures silent for roughly 61 minutes instead of one minute.
• 14. minor at docs/required-inbound-admission.md:37, docs/required-inbound-admission.md:58, changelog.d/required-inbound-admission.added.md:13, src/mcpl/reply-admission.ts:37, src/mcpl/server-connection.ts:1172: Documented batch and backlog estimates ignore serial reply-resolution latency.
  • Failing case: With a 10 ms admission callback and a 1,000 ms reply resolver, a held channel backlog drains at roughly one item per 1.01 seconds, not one per 10 ms; a sequential batch likewise can take roughly its item count times the sum of the two deadlines. An operator sizing the hold buffer from these estimates can therefore see unexpected drops.
• 15. minor at test/reply-routing-transport.test.ts:197, test/reply-routing-transport.test.ts:202: The replacement-registration test asserts only no publication, without confirming a reply turn ran.
  • Failing case: If the incoming message is refused, dropped, or never wakes the agent, the test still passes with no publish and never exercises the stale registration check.
• 16. minor at test/reply-routing.test.ts:481, test/reply-routing.test.ts:488: The lifecycle recheck tests never confirm the mocked wait ran, so an earlier refusal passes them.
  • Failing case: If routeSpeech starts rejecting valid bindings before waitForOpenChannel, all three cases return null with no opens or publishes even though none tests revalidation after a lifecycle wait.
• 17. minor at test/reply-routing.test.ts:459, test/reply-routing.test.ts:465, test/reply-routing.test.ts:466: The stale and forged binding tests use a mismatched target, so the mismatch guard hides epoch and forgery checks.
  • Failing case: After rebinding the admission, a stale binding for topic:alpha/β|room/other is sent to room/one; the test still passes if stale-epoch or forged-binding validation is removed because the target does not match.
• 18. minor at test/reply-routing-core.test.ts:98, test/reply-routing-core.test.ts:103, src/mcpl/reply-admission.ts:37: The refusal test's assert.fail is caught by the wrapper under test and callback invocation is never recorded.
  • Failing case: If a regression invokes the post-admission consumer for a refused item, its assertion is swallowed as a consumer failure and the returned verdict is still store: false, so the test passes.
• 19. minor at test/reply-routing-transport.test.ts:379, test/reply-routing-transport.test.ts:380, src/mcpl/reply-routing.ts:127: The held-drain test asserts inside a resolver callback whose exceptions are swallowed.
  • Failing case: If held direct inference incorrectly invokes this resolver, assert.notEqual throws before adding an entry to resolved, the exception is swallowed, and the later expected resolver list can still match.
• 20. minor at docs/required-inbound-admission.md:111, changelog.d/required-inbound-admission.added.md:22, src/mcpl/push-handler.ts:202, src/mcpl/push-handler.ts:208: The docs claim deferred pushes are refused before dedup, but receipt replay runs first.
  • Failing case: If a deferred push is retried while its earlier unconfigured acceptance still has a live receipt, replay returns the accepted result rather than admission_unsupported, misleading a host or peer relying on that refusal to identify all deferred retries.
• 21. minor at src/mcpl/channel-registry.ts:2629, src/framework.ts:17682, src/framework.ts:24220: Stale comments say channel context matches routeSpeech and that fork home always wins, ignoring reply bindings.
  • Failing case: When a fork's approved reply destination differs from its home, the turn routes using the binding while buildChannelContext still chooses home; a maintainer relying on either comment would incorrectly expect the advertised and actual destinations to agree.
• 22. minor at test/reply-routing.test.ts:106, src/framework.ts:19699, src/mcpl/reply-routing.ts:58: The test title claims every addressed root gets its own turn, but same-destination roots share one.
  • Failing case: Two independently admitted addressed messages queued for the same connection and destination pass shareReplyTurn and are selected together; the test exercises only roots with different destinations, so its title could mislead a maintainer about the scheduler's coalescing contract.

[Anarchid]

Nightly dual review · round R1 at b2e1c42 · reviewers: Codex gpt-5.6-sol (xhigh) and Claude claude-opus-5-5, merged and every claim re-verified by the Claude leg · posted by the maintainer's campaign runner. Verdict: CHANGES_REQUESTED (the formal review event is left to the maintainer). Finding ids R1-n are stable; cite them in fix commits.

Reviewed at b2e1c42 against main 074ac60. Scope: the #931-specific range 05942d3c..b2e1c427 on top of #906's head. #906 is an ancestor and still open, so this PR can only merge after it.

Verdict: changes requested (0 blockers, 3 major, 5 minor)

The core mechanism is careful and holds up: frozen bindings, epoch and descriptor rechecks around every await in publish(), owner-scoped continuations, and the re-arm owner drop. What breaks is at the edges, and mostly in things the PR doesn't claim to touch. (1) Destination-less causes never share a turn, so on an opted-in connection a burst of N messages the resolver declines costs N model calls. (2) In locked prose mode, a turn woken by an opted-in connection can no longer post to a lock on a connection that is not opted in. (3) Three framework-generated follow-up wakes shed the admitted work, which contradicts the "retains work through holds, retries and continuations" claim. There is also one model-visible change for every host, configured or not.

No earlier review by this account exists on the PR, so there are no prior dispositions to report.

---

Major

R1-1. Private (destination-less) causes never share a turn: N declined messages cost N model calls

• src/mcpl/reply-routing.ts:45-49: sameDestination returns false unless both bindings have a destination. shareReplyTurn (:58-61) is therefore false for any two distinct private works.
• src/framework.ts:20210: the scheduler selects only first plus requests that pass shareReplyTurn(first, r) and requeues the rest.
• src/gate/event-gate.ts:316: wakeProvenance keeps every cause of a debounce batch. src/framework.ts:5014 then pushes one pending request per cause. pendingRequestKey includes workKey, so the newestByKey coalescing never merges them. The read-watermark drop exempts them on purpose (src/framework.ts:20404).
• Reproduced with the PR's own frameworkFor() harness (test/reply-routing.test.ts). Enqueue three reply('') requests: the resolver yields an empty channelId, so each binding is private. Result: membrane.calls.length === 3. Three reply() (same destination) give 1 call, and three unbound requests give 1 call. A batch of three private events through wakeProvenance keeps 3 causes.

Failure scenario: a host's resolver returns null for ambient traffic, which is the documented way to say "no automatic reply". Ten ambient messages land in one debounce window. Before opting in, that was one wake. Now it is ten sequential turns, each re-reading the same context, and the bounce and explicit-send tools tempt each one to answer again. The same applies to everything else that goes private: resolver timeout, a throw, and overload (every resolution past 64 pending). Cost therefore grows linearly exactly when the resolver is slow or failing. The rule is also inconsistent: add one unbound event to that batch and the mixed-batch rule (event-gate.ts:320) collapses all ten into one private turn.

The narrowing agreed in the thread said causes share a turn "when each still authorizes the same destination at send; otherwise they get separate turns or private prose". Merging private causes risks no authority, because turnReply of private works is private.

Fix: let destination-less works with the same owner share a turn, in shareReplyTurn or by collapsing them in wakeProvenance as the mixed case already does. If you merge, also change replyStartDisposition's samePrivateWork test (src/framework.ts:20086, open.reply === work). A merged private turn's reply is a freshly minted turnReply binding, so in-turn continuations carrying replyWorks[0] would otherwise be deferred behind their own turn. Compare against membership in open.replyWorks instead. Add a test that N private causes produce 1 call.

R1-2. locked prose mode: a bound turn's prose to a lock on a connection that isn't opted in is refused (automatic_reply_target_mismatch)

• src/framework.ts:25072: for a bound turn in locked mode, routing.locus = proseLockLocus(agent). Only private turns get null, so the locus is the lock, not the binding's destination. The locus/hybrid branch (:25080) uses routing.reply.destination instead.
• src/mcpl/channel-registry.ts:6041: the guard fires on target.routed && (binding || peer?.requiresReplyBinding). A binding alone applies it to any peer, so a lock on peer B without replyAuthority fails sameChannel(binding.destination, target).
• Reproduced with the same harness, with endpoint-b set to requiresReplyBinding: false, f.readProseLock = () => ({ serverId: 'endpoint-b', channelId: 'room/other' }), and one reply() request from endpoint-a:
  • locus mode publishes to endpoint-a:room/one.
  • locked mode publishes nothing and logs [routeSpeech] assistant: automatic_reply_target_mismatch — speech NOT routed.
  • Baseline: the same locked agent woken by an endpoint-b message posts to its lock.

Failure scenario: a locked-mode agent whose lock is on a connection that never opted in loses its prose on every turn woken by the opted-in connection. It isn't warned: no private notice is injected, because the binding is current, and the locked primer tells it speech goes to the lock. Each such turn then bounces. Because of R1-3(a) the bounce-wake successor is unbound and does post to the lock, so every message costs an extra turn plus a bounce. This contradicts "unconfigured connections are unchanged" (changelog.d/admitted-reply-routing.added.md:10, docs/reply-routing.md:122). Neither doc mentions locked mode.

Fix: pick one rule and document it. Either (a) a bound turn in locked mode takes the binding's destination as its locus, matching locus/hybrid (the lock is overridden, as "bindings override legacy routing defaults" implies), or (b) the guard at channel-registry.ts:6041 applies only to peers with requiresReplyBinding, which keeps the lock and the promise that unconfigured connections are unchanged. In both cases, make what the agent is told match where its prose actually goes, and add the probe above as a test.

R1-3. Three framework-generated follow-up wakes drop the admitted work

docs/reply-routing.md:73 ("Every admitted cause retains private work identity through queues, holds, retries and continuations") and :91 ("post-turn continuations … carry the same work into a fresh logical turn") are not true for:

• (a) Prose-bounce wake, src/framework.ts:24116-24122. It pushes reason: 'prose-bounce' with no replyForNextTurn(round.routing). The two sibling post-turn producers do carry it (:23168 prose-continuation, :23263 auto-continue). The bounce wake exists so "an unsent DM reply must not sit invisible". On an opted-in connection its successor is unbound, so automatic prose to the approved DM is refused (automatic_reply_binding_missing), while a >> to a connection without replyAuthority is not. That is the very retargeting the bound turn just refused, one turn later. channel_open can also repin the unbound successor (:37828, gated on !callingTurn.reply).
• (b) Wake onboarding, src/framework.ts:38748-38756. considerWakeOnboarding queues an unbound request carrying the event's source channelId, although gate evaluation received the event's work (:38646). The onboarding question is refused on the opted-in peer, or routed by the legacy locus elsewhere.
• (c) Tune-out hold release. A held admitted message records only metadata.tuneOut and recordHeld(...) without work (src/framework.ts:17751-17757). Cancellation calls the hook at :37555, which pushes a bare { agentName, reason, source, timestamp } (src/tune-out/coordinator.ts:840, :1266). The release turn has the held backlog in context but no binding.

Impact: all three fail closed on the opted-in peer, so nothing leaks onto it. Approved replies are silently refused, though, and the successor routes by legacy rules to other connections. That is the inconsistency the binding is meant to prevent. Fix: carry replyForNextTurn(routing) on the bounce wake. Carry the event's work into onboarding requests. For tune-out, carry the in-memory work through the hold, or mark the release turn explicitly private (aggregate with turnReply plus privateReplyBinding) rather than unbound. If any of these is meant to stay unbound, say so in the docs. (Found by the second reviewer, verified here.)

Minor

R1-4. Model-visible change for every host. src/mcpl/channel-registry.ts:573 is the static channel_publish description shown to every agent on every host, opted in or not. It now includes "private admitted work with no host-approved reply destination" and "Automatic reply bindings override legacy routing defaults; this tool still authorizes explicit sends separately." On hosts without replyAuthority this is jargon the model can't act on, and it contradicts "Unconfigured hosts, without reply routing, are unchanged" in the description. Fix: append these sentences only when some connected server has replyAuthority, or reword them neutrally ("If this turn has no destination of its own, name one").

R1-5. Callback misuse fails closed with almost no signal. snapshotReplyAuthority copies bare function references (src/mcpl/server-connection.ts:1418-1422), and replyConsumer destructures and calls them unbound (src/mcpl/reply-routing.ts:109, :130, :145-147). An authority written as a class instance (replyAuthority: new HostRouter(), with resolve() { return this.lookup(...) }) throws on every call. Every reply then goes private, and the only trace is a fixed console.error at most once a minute (:96-107). Resolution failures, timeouts and overload emit no trace event, unlike admission refusals. Fix: invoke as config.resolve.call(config, …), or document that callbacks are called without this. Also emit a bounded trace (for example reply:private with a fixed reason code) alongside the stderr line.

R1-6. authorize is outside the monotonic deadline. The elapsed-time check (src/mcpl/reply-routing.ts:134) runs before current() (:149), which runs the synchronous authorize. An authorize that blocks past timeoutMs and returns true still mints authority, and the item's delivery is delayed beyond the documented bound. Fix: recheck performance.now() >= deadline after current() and before mint. Add a blocking-authorize test next to the blocking-resolver one. (Second reviewer, verified.)

R1-7. #906 corrections ride in #931. The mayWake: false vs tune-out cadence caveat (docs/required-inbound-admission.md:130-137, changelog.d/required-inbound-admission.added.md:31-32) corrects #906's own claim and has nothing to do with reply authority. If #906 merges or releases first, its docs are wrong in the meantime, and this PR then edits a fragment that may already have been consumed. Move those hunks into #906 and keep only the reply-latency additions here.

R1-8 (nit). The connector-neutrality test guards two files. test/routing-runtime-has-no-connector-literals.test.ts:7 checks only reply-routing.ts and reply-admission.ts. The routing decisions live in framework.ts, channel-registry.ts, event-gate.ts and server-connection.ts. The vocabulary list itself names identifiers of particular downstream integrations, which is the kind of literal the test means to keep out of the repo. Either cover the changed runtime files, or drop the test and rely on the behavioural ones. (Both reviewers noticed the scope independently.)

---

Verified fine (no need to re-check)

• Receipt keying is per item. RequiredAdmission.admit returns snapshot(raw), a fresh frozen object per call (src/mcpl/inbound-admission.ts:141). The receipts WeakMap keyed by verdict (reply-admission.ts:6) therefore cannot hand one item's routing to another, even if a host returns a shared constant verdict.
• withReplyConsumer's this.check() sees the strengthened guard on both lanes. The channel lane calls admit.call({ ...admission, check: checkAdmission }, …) (channel-registry.ts:2023). The push lane's framework wrapper spreads the original, so this is the wrapper (framework.ts:36042-36049).
• Config errors can't start a connection. Problems throw via checkServerConfig and McpConfigurationRefusal, so replyAuthority without inboundAdmission never connects.
• Unconfigured runtime paths are gated. Every new scheduler and turn branch keys on workOf(...).length, routing.reply or requiresReplyBinding. The warnStaleRequests extraction keeps the status strings, threshold, throttle and quiesce suppression. R1-2 and R1-4 are the exceptions.
• mayWake: false items never reach a gate batch. They are vetoed in admitInbound (src/admission/admit.ts:130-134), so they can't make a batch "mixed".
• Late publication checks are complete. publish() rechecks binding, grant, entry and descriptor identity and server identity before open and before send (channel-registry.ts:6038-6062, 6119-6121, 6205-6218). Outgoing chunks only follow a delivered publish.
• Ownership is consistent. The exhausted re-arm drops only the owner (framework.ts:6748). Budget restart, tool_results_ready and guard retry carry ownedReply. A private turn gets no trigger, locus or channel_publish default.
• #906's guarantees survive. The transport test covers ACK-before-module dispatch, single resolver execution on receipt replay, and config identity with token redaction under replyAuthority (test/reply-routing-transport.test.ts:700-753).
• Tests. The PR's new test files (reply-routing, reply-routing-core, reply-admission, routing-runtime-has-no-connector-literals) pass: 103/103 on Node 22. The full suite was not run here.

---

_{Method. Two independent passes, merged after every claim was re-verified against b2e1c427. The first was a static review by a second model, GPT-5.6-Sol (Codex CLI, xhigh, read-only sandbox, no network): about 12 minutes and about 68 shell commands, 7.4M input tokens (7.1M cached) and 28k output tokens. The second was my own forest-level pass with dependencies installed, which ran the PR's new test files and two scratch probes built on the PR's own test harness (R1-1, R1-2). Found by me only: R1-1, R1-2, R1-4, R1-5, R1-7. Found by Sol only: R1-3 and R1-6, which I verified; I lowered R1-3's tune-out and onboarding parts from "may publish to an unintended destination" to "fail closed on the opted-in peer, route by legacy rules elsewhere". Both: R1-8. Sol could not reach PR metadata, earlier review threads or CI, and could not run anything. Neither pass exercised a live connector or provider.}

[theaspirational]

Thanks for round 1. I've updated the PR to 02c781b: 11 commits on b2e1c42. This branch still sits on #906 at 05942d3. #906 has moved since (round 4), and I'll replay this branch onto it separately.

• R1-1: fixed. Destination-less works with the same owner now share one turn. replyStartDisposition compares membership in open.replyWorks, so in-turn continuations aren't deferred behind their own turn. Three private causes now take one model call. Works with different owners, and private works mixed with bound ones, still stay separate.
• R1-2: fixed with option (b). The guard applies only to peers with requiresReplyBinding. A locked agent whose lock is on a connection that hasn't opted in keeps posting there, which keeps "unconfigured connections are unchanged" true. A mismatch on an opted-in peer, including a lock on the same peer, is still refused, and so is a lock switched mid-turn. The locked primer and the private notices now say where prose goes. Your probe is a test, and the docs cover locked mode.
• R1-3: fixed. The prose-bounce wake carries replyForNextTurn(routing). Onboarding requests carry the event's work. When a connected server opts in, the tune-out release and reader wakes are explicitly private (turnReply plus privateReplyBinding). I chose that over carrying held work through the hold, so the backlog needs separately authorized sends. The docs say so. All three have tests.
• R1-4: fixed. The reply-binding sentences are added to channel_publish only when some connected server has replyAuthority. The unconfigured description is byte-identical to 05942d3.
• R1-5: fixed. Callbacks keep their original receiver, so class instances, including ones with private fields, work. The docs say how they're called. Resolution faults also emit a bounded reply:private trace with fixed reason codes, under the existing throttle and with no callback content.
• R1-6: fixed. The monotonic deadline is checked again after authorize, before minting, and there's a test for an authorize that blocks.
• R1-7: moved. The cadence corrections are now in Add opt-in required admission for inbound MCPL traffic #906 (0fea3b4), so this PR carries only the reply-latency additions.
• R1-8: I removed the literal test. The behavioural tests cover the same ground without naming downstream integrations.

Locally (Node 22.23.3, concurrency 4): typecheck and build pass. The four reply-routing files give 181/181. npm test gives 10,074 pass, 0 fail, 63 skip. The 12 new regression cases fail before their fixes and pass here. Mutations that undo the private sharing, the legacy-lock guard and the bounce carry are killed. No live connector or provider was used.

AI-assisted implementation with GPT-6.1-Sol

[theaspirational]

This PR is rebased onto #906's current head (0fea3b4, round 4 plus the docs commit moved over from here). The new head is f7f24e6, and the #931-specific diff is 0fea3b4..f7f24e6 (22 commits).

The only behavioural adaptation is to #906 R4-3. #906 now keeps the response continuation off AdmittedEnvelope, so the reply consumer receives it privately through withReplyConsumer and the lane handlers, and the envelope gains no public fields. The R1-7 commit was dropped, because its change now lives in #906. The other commits replayed unchanged apart from context.

#906's R4 bounds still hold with reply routing on. That covers the withdrawal ceiling (80 tickets total, 16 over the cap), the separate reservation budget, and pinned replay before the ticket wait. A replayed receipt still resolves its reply exactly once, on both lanes.

Locally (Node 22.23.3, concurrency 4): typecheck and build pass. npm test gives 10,094 pass, 0 fail, 63 skip. The reply-routing files give 181/0, and the admission and module-backlog files give 356/0. Mutations that remove the withdrawal ceiling or the private sharing are killed. No live provider or connector was used.

AI-assisted implementation with GPT-6.1-Sol

[anima-review]

Automatic context view of f7f24e6a05be against 36b6dfe9de39.

What a context view runs and what its checks judge: CHECKS.md.

This head couldn't be compared: it conflicts with main at 36b6dfe9de39, and a view runs the head merged onto its base, so those conflicts need resolving before it can be viewed.