Worktree context injection should include minion session routing rules so spawned agents don't land in wrong channels

[chubes4]

Bug

Agents repeatedly spawn minion sessions in per-repo project channels instead of the canonical agent channel defined in RULES.md. This has happened multiple times across sessions.

Example: intelligence-chubes4 has this rule in RULES.md:

All minion sessions for this agent go in the #intelligence-chubes4 Discord channel (channel id 1493345787894038649). Never spawn sessions in per-repo project channels.

Despite having this loaded in context, the agent spawned a session into a newly-created #homeboy-extensions channel because kimaki project add auto-creates a channel and the agent reached for that channel ID instead of the canonical one.

Root cause

The dm-context-filter.ts plugin (shipped with wp-coding-agents) strips ## cross-project commands from kimaki's system prompt. Good — that removes the explicit "send to other project channels" examples.

But it does NOT inject any positive routing instruction. After the strip, the agent has:

• ✅ "starting new sessions from CLI" examples using ${channelId} (correct — the current channel)
• ✅ No cross-project examples
• ❌ No instruction saying "ALWAYS use this channel, even when you discover other channels via kimaki project add"
• ❌ No instruction saying "NEVER send sessions to per-repo project channels"

When the agent runs kimaki project add /path/to/repo and gets back a new channel ID, nothing in the system prompt says not to use it. The RULES.md instruction exists but competes with the model's tendency to use the most recently discovered information.

Fix — inject routing instruction into system prompt

In dm-context-filter.ts, after stripping ## cross-project commands, inject a minion routing section:

// Inject minion routing rule — all sessions go in this channel.
result = result.replace(
  "## starting new sessions from CLI",
  `## Minion Session Routing\n\nAll minion sessions for this agent go in THIS channel (the one you're currently in, channel ID ${channelId}). NEVER route sessions to per-repo project channels created by \`kimaki project add\`. When working on external repos, use \`--cwd\` to point the session at the repo directory while keeping the session in this channel.\n\n## starting new sessions from CLI`
);

Wait — the plugin doesn't have access to channelId at transform time. Let me check... Actually looking at the plugin signature, it operates on the system prompt string, not the structured context. The channelId is available in getOpencodeSystemMessage in kimaki's source but not passed to plugins.

Alternative approach — inject via AGENTS.md compose:

Since DM's dm-agent-sync.ts already calls wp datamachine agent compose before each session, and AGENTS.md is loaded as the primary instruction file, the fix could go in SectionRegistry instead: compose the RULES.md minion routing section into AGENTS.md.

Simplest approach — just make the existing strip more thorough:

Actually the simplest fix is to also strip the kimaki project add / kimaki project list instructions from the system prompt, since DM-managed agents don't need to discover other project channels. That removes the discovery path entirely:

// Already stripped:
result = stripSection(result, "## cross-project commands");

// Also strip project discovery (kimaki project list/add):
// These create new channels that agents mistakenly route sessions to.
// DM-managed agents should always route sessions to their canonical channel.
result = stripProjectDiscovery(result);

Where stripProjectDiscovery removes the kimaki project list / kimaki project add / kimaki send --channel <channel_id> / kimaki send --project examples from the remaining sections.

Recommended approach

1. Strip kimaki project add/list examples from system prompt in dm-context-filter.ts — removes the discovery path
2. Add RULES.md to worktree context injection — ensures spawned agents carry routing rules
3. File kimaki issue for a proper fix: kimaki send should accept a config-level default_channel that plugins or opencode.json can set, so the routing is enforced at the infrastructure level rather than relying on prompt engineering

Files

• wp-coding-agents/kimaki/plugins/dm-context-filter.ts — the plugin that strips sections from kimaki's system prompt. Already strips cross-project commands. Needs to also strip project discovery or inject positive routing.
• wp-coding-agents/kimaki/plugins/dm-agent-sync.ts — syncs DM agents into OpenCode's agent switcher. Calls wp datamachine agent compose before each session.
• wp-coding-agents/runtimes/opencode.sh — runtime setup that installs the plugins.

AI assistance

• AI assistance: Yes
• Tool(s): Claude Code
• Used for: Tracing the root cause through kimaki's system prompt source, wp-coding-agents plugins, and DM's SectionRegistry. Chris identified the likely pollution source and pointed at the wp-coding-agents plugins.