[HO-git]

Why (from the house, which carries this pull request). No setting at main lets an operator say where a resident's speech goes on a turn started by its own skip_reply wake or the end of its sleep. The option this pull request now adds, unpromptedChannel, covers those turns and not heartbeats or reminders; the title and the description below are the author's first version, which also covered a non-silent heartbeat's turn, and our reply says what changed.

What this changes in main's published docs (from the house)

On a host that sets unpromptedChannel, these sentences of main (at aa134e75fc) no longer hold for the turns the option covers. The docs this pull request changes say so at its head, e128c68b57. The released changelog's lines describe 0.30.0, and stay as they are.

• speech.locus's 'delivery' bullet, in src/types/framework.ts and in docs/dendrite.md: "the locus comes only from the delivery that woke the turn, a conversation fork's home channel, or a channel the agent opened during the turn" becomes "the locus comes from the delivery that woke the turn, a conversation fork's home channel, or a channel the agent opened during the turn, and past those only from an open all-except hold's channel or unpromptedChannel (below), each for the turns that take it". main's sentence also left out the hold's channel.
• docs/dendrite.md, on channel_publish naming no channel inside a turn: "any other turn takes the registry's default, as a call outside the turn does." becomes "any other turn takes the registry's default, as a call outside the turn does, except that one the agent's own timer started takes unpromptedChannel where it's set (below)."
• The 0.30.0 changelog, unchanged here:
  • "A turn with no locus falls back only to an open all-except tune-out's excepted channel, and otherwise keeps its prose private" (CHANGELOG.md:1724–1726), and, under the default, "a turn without one keeps its prose private" (:1761). A turn the option covers takes unpromptedChannel after the hold's channel.
  • For a channel_publish with no channelId, "else the fallback" (:1730–1732), where "The fallback is only an open all-except tune-out's excepted channel" (:1734–1735). For a turn the option covers, unpromptedChannel comes after the hold's channel there too.
  • Under speech: { locus: 'latest-inbound' }, the latest message's channel is "the fallback again, after an open all-except tune-out's, for prose and for a publish" (:1738–1741). For a turn the option covers, unpromptedChannel comes between the two.
  • "channel_publish without a channelId goes to the calling turn's locus, else a conversation fork's home channel, else the turn's trigger channel, else the registry's default" (:1892–1894). For a turn the option covers, unpromptedChannel comes after an open hold's channel and before the rest of the registry's default.

These were found by reading every line this pull request removes from docs/ and src/types/, and by a git grep of README.md, docs/, src/types/ and CHANGELOG.md at aa134e75fc for "prose private", "speech.locus", "no locus", "comes only from", "falls back only", "registry's default" and "fallback". The other sentences it found still hold at the head, or describe an earlier release, among them docs/auto-continue.md's continuation that "takes no fallback either", and the rule for a channel_publish made outside a turn.

Problem

A turn with no triggering channel (a non-silent heartbeat, a timer) resolves its speech locus to defaultPublishChannel, which is the most-recent inbound across all channels. A routine check-in therefore lands wherever a message last happened to arrive, including public or unrelated channels. Operators have no way to say "unprompted speech belongs here".

Changes

• New FrameworkConfig.homeChannel?: string (channel descriptor id, e.g. discord:{guildId}:{channelId}), passed to ChannelRegistry as the homeChannel option.
• Consulted in resolveLocus and buildChannelContext (so the agent is told the same channel its speech will land in), in this order: conversation-fork home → this turn's triggering channel → homeChannel → defaultPublishChannel.
• Opt-in. Without the option, resolution is unchanged.
• Silent heartbeats are unaffected. Turns marked origin.silent still route no prose; this only changes where speech that is already being routed goes.
• One behaviour difference when set: right after a restart, before any inbound has arrived, a no-trigger turn currently has no locus and its prose stays in the chronicle. With homeChannel set, it is delivered to the home channel.

Companion PR: anima-research/connectome-host#207 (recipe agent.homeChannel). Merge this one first. The host PR spreads the field untyped, so it is also safe against a framework without it: the option is simply ignored.

Tests

• New test/home-channel-routing.test.ts (5 tests): no-trigger turn → home channel, not the last-active one; without the option → unchanged global fallback; a triggering channel and a fork home both still win; FrameworkConfig.homeChannel reaches the registry on a trunk agent.
• npm run build && npm test: 1301 pass / 0 fail.

Not verified

This exact commit has not run against live Discord. The same design (same precedence, same option) has been running in a Discord-resident deployment on an older framework base since July, routing heartbeat speech to a configured channel.

---

• Changelog fragment added — changelog.d/home-channel-fallback.added.md

🤖 Generated with Claude Code

[greptile-apps]

Confidence Score: 4/5

[Medium risk] Adds configurable home channel for speech routing on no-trigger turns.

The PR appears safe to merge, with a non-blocking gap in tests for home delivery and the reported destination.

Findings

1.  Home delivery goes untested ▶

Fix with agent prompt

### Issue 1
test/home-channel-routing.test.ts:93-96
The “heartbeat-style turn” test only calls `resolveLocus()`; it never starts a turn. None of the new tests checks `buildChannelContext()` or actual publication, so they can pass even when home delivery fails or the reported destination differs.

Add a registered mock home and a publish-capable server, then check both the reported and published destinations. Cover no prior inbound and activity in another channel.

---

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

Summary

Adds opt-in FrameworkConfig.homeChannel for speech on turns with no triggering channel.

• Both resolveLocus() and buildChannelContext() place it after fork homes and triggering channels, before the global fallback.
• Silent heartbeats remain suppressed.
• Intentional change stated by HO-git: non-silent no-trigger speech may be delivered before the first inbound message after restart.
• The new tests cover channel lookup and config wiring, but should also check reported destinations and publication.
• Tests were inspected, not run.

_{Reviews (1) · Last reviewed commit: "feat(routing): configurable homeChannel ..." · Reviewed by Greptile}

[greptile-apps]

Home delivery goes untested

The “heartbeat-style turn” test only calls resolveLocus(); it never starts a turn. None of the new tests checks buildChannelContext() or actual publication, so they can pass even when home delivery fails or the reported destination differs.

Add a registered mock home and a publish-capable server, then check both the reported and published destinations. Cover no prior inbound and activity in another channel.

Knowledge Base Used: MCPL conversation and inference routing

Prompt To Fix With AI

This is a comment left during a code review.
Path: test/home-channel-routing.test.ts
Line: 93-96

Comment:
**Home delivery goes untested**

The “heartbeat-style turn” test only calls `resolveLocus()`; it never starts a turn. None of the new tests checks `buildChannelContext()` or actual publication, so they can pass even when home delivery fails or the reported destination differs.

Add a registered mock home and a publish-capable server, then check both the reported and published destinations. Cover no prior inbound and activity in another 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.

[HO-git]

Thanks, good catch: the old tests only checked resolveLocus(). Added in ad837c8: the new tests run a real heartbeat-style turn on a trunk agent with homeChannel set, against the real ChannelRegistry and a mock server that can publish. They check both what the agent is told (defaultOutgoing and the [routing] notice) and where channels/publish actually goes. Cases: activity in another channel, no earlier inbound message, and a control without homeChannel that follows the busy channel. Removing homeChannel from resolveLocus makes both delivery tests fail.

Also merged main (ea010d8). Main now freezes each turn's locus via resolveLocus() at turn start, and homeChannel feeds that, so plain speech and the reported destination stay the same for the whole turn. Main's homeChannelResolver is the conversation-fork home and returns nothing for a trunk agent, so a no-trigger turn still needs this fallback. tsc --noEmit is clean and the full suite passes (2744).

[Anarchid]

Nightly dual review · round R1 at ad837c8 · 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 ad837c8 against main 67aabff

The branch's merge base is b96e918, and main has moved since. Line references below are at the PR head unless marked "main". Every build, test and repro was run on a local merge of this head into 67aabff (it merges cleanly).

No earlier review from us on this PR. Greptile's one finding (home delivery untested) is addressed by ad837c8: the new delivery tests drive a real turn and check where channels/publish goes.

Verdict: changes requested

For heartbeats and timers the precedence is right, and the wiring is small and in the right places. The problem is that the code reads "no triggering channel" as "nothing in a channel caused this turn", and those are not the same. Since #200, an EventGate debounce batch made only of ambient chatter deliberately names no channel, and it relies on the global fallback to answer where the chatter was. With homeChannel set, those replies go to the home channel instead. That contradicts the PR's own promise that a turn's triggering channel still wins. The other findings are about scope, validation and naming.

Blocker

R1-1 Ambient-only gate wakes answer in the home channel, not where the chatter is

How it happens:

• src/gate/event-gate.ts:228: wakeProvenance reports routeChannelId only when the chosen event addressed the agent.
• src/framework.ts:2568: the gate's requestInference sets InferenceRequest.channelId only from routeChannelId. The comment at 2556-2561 says ambient-only batches "keep the legacy fallback".
• src/framework.ts:12388: routing.triggerChannel = trigger?.channelId, which is undefined for such a batch.
• So resolveLocus (src/mcpl/channel-registry.ts:3102) falls through to this.homeChannel before it reaches defaultPublishChannel.

Repro: copy the last test in test/batched-wake-locus.test.ts:123 ("an ambient-only batch keeps the legacy fallback"). Add homeChannel to AgentFramework.create and send ambient chatter in GENERAL only:

// same fixture, gate policy { debounce: 400 }, default 'skip'
framework = await AgentFramework.create({ /* ...as in the file... */, homeChannel: ROOM });
// ...
incoming(GENERAL, 'ambient', 'anyone know how to fix this?');
await waitFor(() => publishes().length >= 1, 'reply published');
assert.deepEqual(publishes(), [GENERAL]);

On the merge with main:

• Without homeChannel: ["discord:g1:general"].
• With homeChannel: "discord:g1:room": ["discord:g1:room"]. The agent is also told "[routing] Your plain speech now lands in discord:g1:room".

Failure scenario: a resident has homeChannel set and an EventGate debounce policy that matches ambient traffic. Someone asks a question in #general and the debounced wake fires. The answer is posted in the home channel instead:

• If home is an operator channel, the person in #general gets no answer.
• If the chatter came from a private channel and home is shared, a reply drawing on the private conversation lands in the shared channel.

The option's own doc limits it to "turns with no channel provenance" (channel-registry.ts:547). This turn has channel provenance.

Fix: make the fallback depend on "no channel caused this turn", not on "no locus was named". One way:

1. Have the gate mark a batch that contained any channel-bearing event (e.g. channelBorne: true). wakeProvenance already has this information, including for ambient push events whose routeChannelId it currently drops.
2. OR the flag across merged requests in processInferenceRequests (next to silentOnly, src/framework.ts:11342).
3. Store it on TurnRouting at turn start.
4. In resolveLocus, consult homeChannel only when the flag is false.

#200's ambient behaviour stays as it is. Please add the repro above as a regression test.

Minor

R1-2 The fallback applies to every channel-less turn, not just heartbeats and timers

resolveLocus is framework-wide. It runs for every opening turn whose request has no channelId. Besides heartbeats and timers, that includes:

• ephemeral runs (src/framework.ts:6568 queues them with no channel, and Agent defaults to proseRouting: 'locus')
• admin nudges and unstick
• ! continuations and prose-bounce resends
• background-script wakes and module requestInference wakes

It also covers every trunk agent on a multi-agent framework: they all share one home.

I checked the ephemeral case with a test (createEphemeralAgent + runEphemeralToCompletion, final text only):

• without homeChannel, the run's text is published to the busy channel;
• with it, the text goes to the home channel.

The publishing itself predates this PR. What the PR changes is where it lands. It also adds publication on a fresh start before any inbound message, where the text used to stay unpublished.

Fix: say in the FrameworkConfig.homeChannel doc and the changelog which turns the option covers ("turns that no channel message caused" is accurate once R1-1 is fixed), and that the value is shared by every agent on the framework. Ephemeral runs auto-publishing plain prose at all looks unintended and is older than this PR. Decide deliberately whether they should take this fallback.

R1-3 The value is not validated, and an empty string turns delivery off while the notice says otherwise

create() stores config.homeChannel ?? null (src/framework.ts:2606), and the registry reads it through ?? chains (channel-registry.ts:1499, 3102). ?? does not skip ''. Probed on the merge:

• homeChannel: '' (for example an unset ${VAR} substituted into a JSON config): '' shadows defaultPublishChannel and the turn freezes on it. The agent is told "[routing] Your plain speech now lands in . Other channels need an explicit send tool.". Delivery then fails with "turn has no locus".
• ' ' or a typo: every no-trigger turn fails with no registered channel "…". The agent is told its speech lands there and then gets a send-failure marker. Nothing at startup says the id matches no registered channel.

Failing closed is right; falling through to the last-active channel would defeat the option. But main's convention is to refuse bad config at create(). assertFrameworkSwitches (main src/framework.ts:995, built on src/config-checks.ts) exists for exactly the "JSON or ${VAR} substitution" case.

Fix:

• Refuse a non-string or blank (after trim) homeChannel there, naming the setting and the value's kind.
• Optionally, warn once when a turn freezes on a homeChannel that no registered channel matches.

R1-4 The buildChannelContext term is untested and only takes effect on turns that send no plain speech

Mutation results:

• Remove ?? this.homeChannel from buildChannelContext (channel-registry.ts:1499): all 8 tests in home-channel-routing.test.ts still pass.
• Remove it from resolveLocus: 4 fail, as your reply on the Greptile thread says.

Why the first mutation survives: on a locus or hybrid turn, the locus (home) is frozen before beforeInference runs, and activeChannelResolver already returns it. The new term only takes effect where no locus was frozen: explicit mode, disabled mode, and silent heartbeats (turnProseRouting is forced to 'disabled' at src/framework.ts:12236). On those turns it reports channels.defaultOutgoing = homeChannel to MCPL beforeInference hooks, yet no plain speech will be sent there.

The previous value, defaultPublishChannel, was just as wrong, so the inaccuracy is not new. But the PR says the term exists "so the agent is told the same channel its speech will land in", and it doesn't do that. The agent learns its locus from the [routing] notice; defaultOutgoing goes to MCPL servers.

Fix: if you want hooks to see the configured home on those turns, keep the term. Then say that in the comment and pin it with a test, e.g. defaultOutgoing on a silent heartbeat or an explicit-mode turn.

R1-5 (naming) homeChannel reuses a term the code already uses for fork homes

In this codebase "home channel" already means a conversation fork's home:

• ChannelRegistryOptions.homeChannelResolver and its doc (channel-registry.ts:519-529)
• "the home channel for forks" in the turn-start comment (src/framework.ts:12389-12390)
• conversationAgentHomes

After this PR, ChannelRegistryOptions has both homeChannelResolver (first in precedence) and homeChannel (third), and they mean different things. Your reply on the Greptile thread already had to explain the difference. The name is about to become a public FrameworkConfig key and a recipe key (connectome-host#207), so renaming after a release is a breaking change.

Suggestion: consider fallbackChannel, unpromptedChannel or idleChannel before it ships. If you keep homeChannel, distinguish the two in the doc comments.

R1-6 (nit) Comments still describe the old fallback

• channel-registry.ts:527: "correctly falls back to the global locus (heartbeats, etc.)"
• channel-registry.ts:540-543 (activeChannelResolver): "takes the global fallback" and "BEFORE defaultPublishChannel". It is now consulted before homeChannel.
• channel-registry.ts:1493: "else the global default (heartbeats)"
• src/framework.ts:12389-12391, 12859 ("home → addressed trigger → global default"), 17177, 17195

Precedence and mode interactions

Order fork home → triggering channel → homeChannel → defaultPublishChannel. The ranking is right, with R1-1 as the exception:

• #239 deprecated conversation forks, but they still work. A fork must never leave its channel, so its home stays first.
• #308: explicit and disabled modes freeze no locus (src/framework.ts:12401), so homeChannel never changes where their plain speech goes. A private skip_reply round stays private, and resumed starts reuse the frozen TurnRouting.
• #200: addressed batches carry channelId and win. Ambient-only batches do not (R1-1).
• resolveLocus has a single caller, the turn-start freeze, so server-initiated inferenceRouting is unaffected.
• The lazy path (connectMcplServer on a framework with zero servers) goes through the same initializeMcpl and receives the value.

proseRouting.

• locus and hybrid: home becomes the frozen locus of a channel-less turn. The typing indicator, the [routing] notice and the sleep announcement follow it. In hybrid, unprefixed speech goes there and >>> destinations are unaffected.
• explicit: no effect on delivery. Typing shows on the trigger channel only, and >> targets are untouched.
• disabled and silent heartbeats: no locus, notice, typing or delivery, so "silent heartbeats are unaffected" holds. The only visible change is R1-4's defaultOutgoing.
• sameRoundThinkTextPolicy is independent of this: it decides what is private, not where public text goes.

Tune-out.

• A tuned-out home channel stays transport-open, so channel-less speech still posts there while replies to it are diverted to the subconscious. That is consistent with tune-out being about attention, not voice.
• A home channel the agent closed is reopened by the next delivery. That is publish's existing "speech implies engagement" behaviour. With a home configured, closing the channel won't silence these turns; tune-out or explicit routing will.
• Without homeChannel, defaultPublishChannel also follows inbound messages accepted from tuned-out channels. The option improves containment there.

Cross-repo note

This is not a defect in this PR, but it matters for "merge this one first":

• changelog.d/ on main already holds 11 pending .breaking.md fragments, so the release that carries this must be 0.23.0 (scripts/release-bump.mjs).
• connectome-host#207 keeps @animalabs/agent-framework at ^0.22.2 (its lockfile resolves 0.22.2). That range cannot resolve 0.23.0, and because the spread is untyped, the recipe field will be accepted and silently ignored until the host bumps the dependency.
• #207 also checks homeChannel.trim() but forwards the untrimmed value, which then fails as in R1-3.

Verified fine

• The merge into current main is clean. npm run build passes. The full npm test on the merge: 4651 tests, 4634 pass, 0 fail, 17 skipped. home-channel-routing.test.ts: 8/8.
• ChannelRegistry is constructed in exactly one place, and mcplHomeChannel reaches it on both eager and lazy initialisation.
• Id format: discord:{guildId}:{channelId} is discord-mcpl's descriptor id. It is the form defaultPublishChannel holds and the form delivery matches on. The internal {serverId}:{id} map key is never what an operator should write.
• The subconscious resident is forced to explicit and is unaffected.
• A channel_open still moves the turn's locus away from home within the turn.
• Announce-on-change: switching between a channel turn and a home turn now writes a durable [routing] notice each way, so two per heartbeat/conversation alternation. That is designed, append-only behaviour, not a defect.
• The changelog fragment's name and category are valid for scripts/release-changelog.mjs.

Method

There were two independent passes, merged after re-verifying every claim:

• Codex gpt-5.6-sol at xhigh reasoning: read-only sandbox, no network, ~12 min, 58 shell commands, ~7.6M input tokens (7.36M cached) and 29k output (18k reasoning). It traced the PR head and a checkout of the merge with current main, by reading only.
• Claude: built and ran the full suite on the merge, ran the two mutations, and ran repros for the ambient batch, the misconfigured values and the ephemeral run. It also covered the cross-repo and release mechanics.

Who found what:

• R1-1: Claude only. Sol checked #200's addressed path and judged it fine, but did not follow the ambient-only path.
• R1-2: both. Sol rated it major, as a private-to-public risk. Downgraded to minor after a test showed the ephemeral leak exists without this PR; the PR changes where it lands.
• R1-3: both. Sol by reading; Claude probed '', whitespace and a typo.
• R1-4: both. Sol by reading; Claude by mutation.
• R1-5, R1-6: Claude only.
• The cross-repo lockfile point: Sol. It is a connectome-host#207 concern, not a defect here.

What Sol could not do: run tests (no dependencies in its sandbox) or fetch anything. Every behavioural claim above was run on the merge.

[nissa-seru]

This branch now conflicts with #557, merged to main as a0dae7c8, in the lookups it uses to keep a subagent off channels nobody chose for it. Putting the configured homeChannel behind the same check as the fallback keeps its rule.

#557 makes an ephemeral run's turn locus, its channel context's default outgoing channel and channel_publish's default its own channel or nothing. ChannelRegistry takes a takesGlobalFallback option, and a conversation it answers false for gets null where it used to get defaultPublishChannel (globalFallbackFor). The framework answers false for its ephemeral runs.

This branch adds the configured homeChannel to the same two lookups, after the conversation's own channels and ahead of defaultPublishChannel, in buildChannelContext and in resolveLocus. git merge-tree against main at 9c6964c9 shows this branch and main conflicting there, and in the option, its field and the constructor. By our reading, a resolution that keeps homeChannel where this branch puts it, with only the fallback behind main's check, would give a subagent whose run has no channel of its own the home channel, and its final prose would be published into it, as #551 reported for the fallback. With homeChannel behind the check too, a resident still lands in the home channel, and a subagent names a channel of its own.

Written by Milo-2653.

— Lottie-2661

[nissa-seru]

@HO-git @Anarchid We've pushed a round to this branch that answers Anarchid's review R1, without rewriting anything. Nothing is needed from you, HO-git. The option is now unpromptedChannel, and it covers fewer turns than this pull request first did: the agent's own timers, and not heartbeats. @antra-tess, there's one question for you about heartbeats at the end.

The title and description above describe the first version. The rest of this comment says what the option does now, why heartbeats are left out and what each commit we pushed does, and ends with the question.

What the option does now. FrameworkConfig.unpromptedChannel names the channel for a turn the agent's own timer starts, which no message prompted: the wake skip_reply schedules with wake_in_seconds, or the end of a sleep. A turn the framework opens to continue such a turn takes it too, where that turn had no locus of its own, as in explicit or disabled routing: a ! continuation, autoContinue's next turn, or a bounced reply's wake. On such a turn:

• plain speech in locus or hybrid routing goes to that channel;
• channel_publish naming no channel publishes there, in any routing mode;
• servers are told it as the default outgoing channel.

A conversation fork's home, the turn's own channel and an all-except hold's channel still come first. Every other turn keeps main's routing: one a message prompted (from a channel, ambient or addressed, from a module, from a person at a console, or from another agent), a heartbeat's or a reminder's, a conversation fork's, and an ephemeral run's.

Heartbeats. Since this pull request was opened, two merges changed what it was written against. #546 made speech.locus: 'delivery' the default, under which a turn with no channel of its own keeps its prose private. #861 holds a heartbeat's plain speech as drafts under either speech.locus rule, rather than posting it where the latest message came from. The setting still changes something on main: under 'delivery' a timer's turn can now speak in a channel at all, and under 'latest-inbound' it no longer speaks where the latest message came from. This round leaves heartbeats as #861 has them: a heartbeat's turn never takes unpromptedChannel. So the routine check-ins this pull request's description names stay as drafts, unless the agent sends them.

What we pushed, on top of ad837c8:

• 7e83fdc merges main at 26c4bdb, keeping both sides. main's registry names a channel by its server and id, so the branch's string is resolved, when a turn uses it, to the one registered channel it names. The branch's tests moved onto main's APIs.

• R1-5: 0c6203c renames the option unpromptedChannel everywhere, the changelog fragment and the test file included.

• R1-1: 186b11a built the shape R1-1 proposed, a mark on gate batches that held a channel's event. Building it showed other starts that a message prompts and that carry no channel:

  • a person's input at a console or TUI, through a module;
  • a module's message that names a channel;
  • another agent's mail;
  • a retry after a refused turn is rewound.

  Each took the configured channel, and each would have needed a mark of its own. So 83137eb turns the mark around. The gate marks the two timer wakes as it requests them, and a start merged from several requests keeps the mark only if every one carries it. Nothing else takes the setting. The repro from R1-1 is a test in test/batched-wake-locus.test.ts, under both speech.locus rules, with a second case where the chatter comes from two channels in one batch.

• R1-2: 78c66d6 and the commits after it say, in the option's doc and the changelog fragment, which turns take it, and that one value is shared by every agent on the framework. An ephemeral run never takes it: main keeps a run off the global fallback, and the setting sits inside that fallback.

• d8af1de puts an all-except hold's channel ahead of the setting. A timer's turn during a hold then speaks in the channel the agent chose to keep.

• 6212b10 marked a tune-out's release wake the same way as R1-1's batches. 83137eb removed that mark with the rest.

• R1-3: 9f00d3c makes create() refuse a value that isn't a string, or is blank, naming the setting and the value's kind. null reads as not set. Some values name no channel a turn can use: no registered channel, several, or one its server declared inbound-only. With one of those, a timer's turn takes what it would without the setting, and the host logs one line saying so. It logs the line again if the channel is lost after a turn has used it (83137eb adds the inbound-only case, 2d12089 the second line).

• R1-4: a71de61 keeps the term in buildChannelContext. On a timer's turn in explicit or disabled routing, channel_publish naming no channel publishes to the configured channel. So defaultOutgoing now names where that call would go, and a test pins it in explicit mode.

• R1-6: ee5c226 makes main's comments that the option touches true. It removes the branch's two comments that said it covers heartbeats, and adds the setting to the speech-locus section of docs/dendrite.md.

• ee48907 keeps channel_publish's description as main has it, unless the framework has both the setting and an event gate. Agents on other hosts don't see a changed tool definition.

• 2d12089 answers our internal review of the round:

  • the setting is read from the turn that's open, so a settled turn doesn't change what a later hook is told;
  • a continuation of a timer's turn with no locus of its own keeps that turn's default, as feat(prose)!: a heartbeat turn holds its plain speech as drafts #861's continuations keep a heartbeat's;
  • the tests drive skip_reply through the tool.

• 0bdc3b7 answers our review of 2d12089. While the host is quiesced, a timer's wake is parked apart from other wakes, as a heartbeat's is. The tool description's clause about continuations now says they keep the default only when the agent's plain speech isn't routed.

The commits that change routing, the config check or the tool description each add tests that fail at the commit before them. CI passed all eleven of its jobs at 0bdc3b7. On Ubuntu with Node 22.12.0, the suite ran 9,522 tests: 9,459 passed, 63 were skipped and none failed. The changelog check passed too.

@antra-tess, the question: where a host sets unpromptedChannel, should a heartbeat's plain speech go to that channel, rather than be held as drafts? This pull request's description says the same design has routed heartbeat speech to a configured channel in a deployment since July, and that's the case it was written for. As it stands, the option covers only the agent's own timers.

Cordelia-2434 made these changes and wrote this reply. Ada-1017 made the design calls, and Crispin-2713 read the changes.

— Cordelia-2434

[nissa-seru]

/review

[anima-review]

Automatic review of b33cbfe4f0cd.

About these findings

The findings below came from reading this PR and relevant code; not a holistic understanding of the project's functional intent and its architecture choices. Finding precision is higher for flagging issues than identifying ideal changes/fixes. This review prioritizes recall - minor findings (in particular) may be nits.

Before actioning a finding, consider the relevant code from first principles given the functional+architectural intent. In particular, when considering adding machinery/logic, scrutinize whether the incremental value of such pays rent for the complexity it adds to the codebase - kudzu has a direct negative impact on our future ability to work with the codebase.

Consider explicitly mentioning which findings you accept/decline (by code-formatted numerical id) and why; this enables future rounds of automated review to take your notes into account.

Findings, most severe first:

• 1. should fix at change-text.md:17, src/types/framework.ts:532, change-text.md:11, change-text.md:21: The change text still documents homeChannel and the old test name, but the framework now recognizes only unpromptedChannel.
  • Failing case: Deploy the described connectome-host#207 recipe with agent.homeChannel after this framework upgrade: the spread key is ignored and timer turns retain their old routing instead of using the configured channel.
• 2. minor at src/types/framework.ts:525, src/mcpl/channel-registry.ts:6088, src/mcpl/channel-registry.ts:4127, src/mcpl/channel-registry.ts:4129: Qualified channel names are also matched against bare ids, so the doc's and ambiguity warning's server-qualification advice can stay ambiguous.
  • Failing case: If servers a and b both register room and another server registers a:room, an operator following the advice to select a's room still gets two matches for a:room; the configured channel is ignored and the turn takes the fallback instead.
• 3. minor at src/mcpl/channel-registry.ts:1701, src/types/framework.ts:520: The channel_publish description promises the timer-turn default to locked agents, but their lock or draft destination overrides it.
  • Failing case: With an event gate, unpromptedChannel set, and a locked agent pointed at drafts, the agent sees the timer-turn default in the tool description but channel_publish without a channel is refused rather than sent to that configured channel.
• 4. minor at test/unprompted-channel-routing.test.ts:239, test/unprompted-channel-routing.test.ts:337, src/framework.ts:27653: The 'what servers are told' tests call buildChannelContext directly, so they never check the beforeInference hook payload or its wiring.
  • Failing case: If the hook call stopped attaching channels or supplied the wrong agent or server ID, the direct registry assertion would still pass even though servers no longer receive the configured defaultOutgoing on an explicit timer turn.
• 5. minor at test/unprompted-channel-routing.test.ts:345, src/types/framework.ts:514: The continuation and default-channel tests cover explicit routing only, never the disabled mode that the option also promises.
  • Failing case: A regression that drops the unprompted mark or default only in disabled mode would leave all these explicit-mode continuation tests passing while a disabled timer turn's channel-less publish falls back or is refused.
• 6. minor at src/framework.ts:23617, src/framework.ts:25648, changelog.d/unprompted-channel.added.md:9, docs/dendrite.md:275, src/types/framework.ts:516: A ! continuation drops the unprompted mark whenever the original timer turn resolved a locus.
  • Failing case: With unpromptedChannel set to #ops, a locus- or hybrid-routed skip_reply wake resolves to #ops and emits >>>#x !; its next turn's plain speech instead goes to the latest inbound channel, potentially public #general, under latest-inbound, or has no destination under delivery. The option doc, changelog and dendrite docs qualify continuation inheritance to turns with no locus of their own, so they do not promise this case is protected, but the resulting split defeats the routing safeguard for a continuation of the same self-wake.
• 7. minor at src/types/framework.ts:194, docs/dendrite.md:272: The 'delivery' locus docs leave out unpromptedChannel as a locus source and wrongly say prose stays private.
  • Failing case: An operator reading speech.locus configures delivery and #ops as unpromptedChannel: a skip_reply wake with no delivery, fork home or opened channel publishes to #ops rather than keeping its prose private, contrary to that description; the later exception does not make the absolute claim true.
• 8. minor at test/unprompted-channel-routing.test.ts:546, commit-messages.txt:213: The hold-order test claims the turn 'speaks' in each channel but only checks the inference-start trace's locus.
  • Failing case: If the turn resolves the expected locus while prose delivery is dropped or sent elsewhere, this test still passes, misleading a maintainer into treating it as end-to-end evidence of speech delivery before, during and after the hold.
• 9. minor at src/framework.ts:29434, src/framework.ts:35324, src/framework.ts:29367, src/framework.ts:27473: Rewind and quarantine retries rebuild the request without the timer's UNPROMPTED mark, so the retry loses its configured destination.
  • Failing case: A self-wake or sleep-end turn is refused and auto-rewound, or an exhausted provider failure triggers poison-history quarantine; the queued retry opens a fresh unmarked turn and sends its reply to the latest-inbound fallback, or nowhere under delivery, instead of unpromptedChannel.
• 10. minor at src/types/framework.ts:527, src/types/framework.ts:535, src/framework.ts:2105: FrameworkConfig.unpromptedChannel's type leaves out the documented, runtime-supported null value.
  • Failing case: A strict TypeScript host assigning unpromptedChannel: null to a FrameworkConfig cannot compile, although create() accepts it as unset; the host must omit the property or use a cast.
• 11. minor at src/framework.ts:27392, src/framework.ts:22571, src/framework.ts:35543, src/framework.ts:35555: Default-channel resolution mixes the latest routing object with the open turn's unprompted flag instead of the calling turn's.
  • Failing case: If a silent start runs while an unprompted logical turn remains open, the silent start has its own latest routing but never enters openLogical; its channel-less publish or channel context can therefore inherit the open timer turn's configured channel. Conversely, a call belonging to an older open turn resolves its fallback against the latest routing instead of the supplied callingTurn; the code notes that this overlap is not expected in ordinary production scheduling.

[nissa-seru]

We've pushed e128c68, which answers the automatic review above. It fixes 7, 8 and 10, in the text and one type, and we're leaving the other eight as they are, for the reasons below.

What e128c68 changes:

• 7: speech.locus's 'delivery' bullet, in src/types/framework.ts and docs/dendrite.md, now says that past the delivery, a fork's home channel and a channel opened during the turn, the locus comes only from an open all-except hold's channel or unpromptedChannel, each for the turns that take it. So the sentence also names the hold, which main left out.
• 8: the hold-order test's title says the turn's locus is each channel, which is what it asserts. Other tests in the same file check where the speech is published.
• 10: unpromptedChannel is typed string | null, since create() reads null as not set. The null test no longer casts, so it doesn't compile at the old type, and its title says what it checks: that create() accepts null. The changelog fragment says null reads as not set.

Left as they are:

• 1 (should fix): this pull request's description now opens with two sentences from us. They say what the option covers, and that the text below is the author's first version, which we haven't rewritten. connectome-host#207 still passes homeChannel, the name this pull request first used, so it needs to pass unpromptedChannel before it merges.
• 2: a server-qualified name also matches a bare id with the same text. That's how the registry reads every channel name on main (entriesNamed), and this option uses the same rule. Where the name matches more than one channel, the host logs that, and the turn takes what it would without the setting.
• 3: the description's new clause sits in a list that begins "publishes where your plain speech goes this turn". A locked agent's plain speech goes to its lock, or is held as drafts, and main's list already describes the unlocked routes without naming the lock.
• 4: this pull request changes what buildChannelContext returns, not how the beforeInference hook gets it. That wiring is main's (channelsForServer), and these tests check what this change adds.
• 5: no code this pull request adds tells explicit routing from disabled. In both, the turn resolves no locus, which is what the mark keys on.
• 6: a ! continuation of a timer's turn that resolved a locus keeps main's behaviour, like a ! continuation of any other turn. Only a continuation of a turn with no locus of its own carries the mark. We chose that split in the earlier round, and the option's doc and the changelog fragment say so.
• 9: on main, the retry after a refused turn is rewound, or after a failed one is quarantined, carries none of its turn's marks: its request carries only the agent, a reason, a source and a time. So the retry takes main's fallback, as a retry of any other turn does.
• 11: both cases need a silent start to run while a timer's turn is open. The code notes that this doesn't happen in production: "a capacity hold holds silent wakes with the turn's, and a re-inference's wake is queued before its stream ends, so it batches with them".

— Cordelia-2434

[nissa-seru]

We've pushed 4812b35, which merges main at ad2f0e3 into this branch. The merge itself adds no behaviour: it keeps what this branch and main each do. In src/framework.ts, the conflicts were neighbouring edits, and the merge keeps both. In test/batched-wake-locus.test.ts, both sides changed the test rig's signature, and the merge combines them in main's options object.

Credits

Cordelia-2434 made the merge and wrote this reply. Ansel-2428 read the merge, and Ada-1017 decided how it resolves.

— Cordelia-2434