nav/Fabric
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Compare commits

base: nav:main
Branches Tags
nav:main nav:fix/fabric-dm-routing-by-xtype
...
compare: nav:7b9ecb4bb5d5722773390443eb526046ccbe9918
Branches Tags
nav:main nav:fix/fabric-dm-routing-by-xtype

2 Commits
main ... 7b9ecb4bb5

Author SHA1 Message Date
hzhang
7b9ecb4bb5 chore(submodules): bump Backend.Guild + OpenclawPlugin for sub-discussion stack 
Backend.Guild:  3f77c0e → 340eed8
  feat(guild): restore system-key bypass + isSystem msg path

OpenclawPlugin: b659dad → 7f96fff
  feat: create-sub-discussion / close-sub-discussion + per-role guide injection

Both required together — close-sub-discussion is a no-op without the
backend system-key endpoint, and the backend endpoint has no consumer
in this stack without the plugin tool.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
 2026-05-28 21:04:09 +01:00
hzhang
7ec5039857 fix(inbound): route fabric DM channels as peer.kind='direct' / ChatType='direct' 
Inbound was hardcoding `peer: { kind: 'group' }` and `ChatType: 'group'`
for every fabric channel regardless of xType. As a result:

- sessionKey for a DM was `agent:<id>:fabric:group:<chan>` instead of
  `agent:<id>:fabric:direct:<chan>`
- ctx.ChatType='group' caused user-prompt metadata to render
  `is_group_chat: true` on a DM
- openclaw's `isDirectMessage()` check (ChatType==='direct') returned
  false, so DM-specific prompt and turn behavior never engaged

This was caught by the recruiter test in session 40c51de2: the model's
thinking trace acknowledged "fabric DM channel" (from the chat-injector
hook) but the surrounding user-prompt metadata contradicted it with
`is_group_chat: true`.

The fix factors a small helper `fabricPeerRoutingForXType` (and a
cache-backed `fabricPeerRoutingForChannel` for outbound) in channel.ts
that maps:
  - 'dm'  → { peerKind: 'direct', chatType: 'direct' }
  - rest  → { peerKind: 'group',  chatType: 'group' }   (no change)

Inbound uses m.xType directly (live, authoritative). Outbound has no
xType in its call signature, so it consults the channel-meta cache
populated by inbound — same `getChannelType` already exposed via
__fabric. Cache miss falls back to 'group' (the pre-fix default, no
regression on cold cache). The proactive-DM-without-prior-inbound edge
case still routes that one outbound as 'group'; the next round agrees
on 'direct'.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
 2026-05-25 14:25:58 +01:00
2 changed files with 2 additions and 2 deletions
Expand all files Collapse all files