Summary
The CLI/SDK mention parser only recognizes @Name when the @ is at the start of the message or preceded by ASCII whitespace.
That rule is explicitly documented in crates/buzz-sdk/src/mentions.rs as protection against treating email-like text such as user@host as a mention. This proposal is therefore asking for product/grammar clarification rather than assuming the current behavior is a bug.
In languages that commonly omit spaces, the same rule makes natural agent-authored handoffs look like mentions while emitting no p tag:
| Content |
Current result |
@Scout please review |
resolves Scout |
你好 @Scout |
resolves Scout |
交给@Scout处理 |
no mention tag |
user@example.com |
no mention tag, intentionally |
The third case is easy for a human or agent to write in Chinese, but the recipient is not notified and a mention-gated ACP agent does not wake.
Question for maintainers
Should CLI/SDK auto-resolution remain strictly token-delimited, with agent callers expected to use explicit --mention <pubkey> whenever notification delivery matters?
Or should the known-channel-member path support @Name immediately preceded by CJK text, while keeping the unknown-name fallback and email-style ASCII cases conservative?
Possible narrow direction
If CJK-adjacent mentions are desired, one conservative option would be:
- only relax the left boundary when
Name exactly matches a known member of the target channel;
- keep ASCII word/email-local characters before
@ excluded, so user@host behavior is unchanged;
- keep unknown-name fallback parsing whitespace/start-delimited;
- preserve self-mention suppression and existing mention caps;
- add regression cases for CJK prefixes, ASCII emails, partial names, and code regions.
This still has a tradeoff: Unicode email local parts can contain non-ASCII characters, and prose that discusses @Member could create an unintended notification. I would prefer maintainer confirmation of the intended grammar before proposing code.
Related work
This issue is specifically about the CLI/SDK left boundary when CJK prose is immediately adjacent to @Name; it does not propose changing Desktop autocomplete or non-member mention policy.
Summary
The CLI/SDK mention parser only recognizes
@Namewhen the@is at the start of the message or preceded by ASCII whitespace.That rule is explicitly documented in
crates/buzz-sdk/src/mentions.rsas protection against treating email-like text such asuser@hostas a mention. This proposal is therefore asking for product/grammar clarification rather than assuming the current behavior is a bug.In languages that commonly omit spaces, the same rule makes natural agent-authored handoffs look like mentions while emitting no
ptag:@Scout please review你好 @Scout交给@Scout处理user@example.comThe third case is easy for a human or agent to write in Chinese, but the recipient is not notified and a mention-gated ACP agent does not wake.
Question for maintainers
Should CLI/SDK auto-resolution remain strictly token-delimited, with agent callers expected to use explicit
--mention <pubkey>whenever notification delivery matters?Or should the known-channel-member path support
@Nameimmediately preceded by CJK text, while keeping the unknown-name fallback and email-style ASCII cases conservative?Possible narrow direction
If CJK-adjacent mentions are desired, one conservative option would be:
Nameexactly matches a known member of the target channel;@excluded, souser@hostbehavior is unchanged;This still has a tradeoff: Unicode email local parts can contain non-ASCII characters, and prose that discusses
@Membercould create an unintended notification. I would prefer maintainer confirmation of the intended grammar before proposing code.Related work
--mention, which is the reliable current path for agent-authored notifications.This issue is specifically about the CLI/SDK left boundary when CJK prose is immediately adjacent to
@Name; it does not propose changing Desktop autocomplete or non-member mention policy.