@yeaft/webchat-agent 0.1.1003 → 0.1.1005

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@yeaft/webchat-agent",
3
- "version": "0.1.1003",
3
+ "version": "0.1.1005",
4
4
  "description": "Remote agent for Yeaft WebChat — connects worker machines to the central server",
5
5
  "main": "index.js",
6
6
  "type": "module",
package/yeaft/prompts.js CHANGED
@@ -197,6 +197,7 @@ const PROMPTS = {
197
197
  tools: (names) => `Available tools: ${names}`,
198
198
  // DESIGN-PROMPT §3 ④ — Active Scope header
199
199
  activeScopeHeader: '## active_scope',
200
+ multiVpRoutingHeader: '## multi_vp_routing',
200
201
  sessionAnnouncementHeader: '[Session Announcement]',
201
202
  // Project-doc (CLAUDE.md / AGENTS.md) header + one-liner intro. Both
202
203
  // filenames are recognized: CLAUDE.md is this project's convention,
@@ -212,6 +213,7 @@ const PROMPTS = {
212
213
  tools: (names) => `可用工具:${names}`,
213
214
  // DESIGN-PROMPT §3 ④ — Active Scope header
214
215
  activeScopeHeader: '## active_scope',
216
+ multiVpRoutingHeader: '## multi_vp_routing',
215
217
  sessionAnnouncementHeader: '[会话公告]',
216
218
  // 项目文档块:CLAUDE.md / AGENTS.md(与 Codex 通用命名兼容)。
217
219
  projectDocHeader: '[项目文档]',
@@ -393,6 +395,9 @@ export function buildSystemPrompt({
393
395
  const activeScopeBlock = renderActiveScope(activeScope, lang);
394
396
  if (activeScopeBlock) parts.push(activeScopeBlock);
395
397
 
398
+ const multiVpRoutingBlock = renderMultiVpRouting(activeScope, lang);
399
+ if (multiVpRoutingBlock) parts.push(multiVpRoutingBlock);
400
+
396
401
  return parts.join('\n\n');
397
402
  }
398
403
 
@@ -490,7 +495,11 @@ function firstNonEmptyString(...values) {
490
495
  }
491
496
 
492
497
  function renderSessionMembersLine(members) {
493
- if (!Array.isArray(members)) return '';
498
+ return normalizeSessionMemberIds(members).join(', ');
499
+ }
500
+
501
+ function normalizeSessionMemberIds(members) {
502
+ if (!Array.isArray(members)) return [];
494
503
  const clean = [];
495
504
  const seen = new Set();
496
505
  for (const member of members) {
@@ -500,7 +509,38 @@ function renderSessionMembersLine(members) {
500
509
  seen.add(id);
501
510
  clean.push(id);
502
511
  }
503
- return clean.join(', ');
512
+ return clean;
513
+ }
514
+
515
+ function renderMultiVpRouting(activeScope, lang) {
516
+ if (!activeScope || typeof activeScope !== 'object') return '';
517
+ const ownId = firstNonEmptyString(activeScope.sessionMember, activeScope.vpId);
518
+ const members = normalizeSessionMemberIds(activeScope.sessionMembers || activeScope.members);
519
+ const peers = ownId ? members.filter((member) => member !== ownId) : members;
520
+ if (peers.length === 0) return '';
521
+
522
+ const header = lang.multiVpRoutingHeader || '## multi_vp_routing';
523
+ if (lang === PROMPTS.zh) {
524
+ return [
525
+ header,
526
+ `当前 VP: ${ownId || 'unknown'}`,
527
+ `可转发 VP: ${peers.join(', ')}`,
528
+ '- 多 VP session 中,先主动感知这些 VP 的职责;不要假装只有你一个人在场。',
529
+ '- 当用户点名其他 VP、任务明显属于其他 VP、需要并行协作,或你需要另一个 VP 继续处理时,必须调用 `route_forward`。',
530
+ '- VP 自己写 @mention 不会触发路由;只有 `route_forward` 工具会真正把任务交给目标 VP。',
531
+ '- 如果要多人一起处理,调用 `route_forward`,`to` 可填目标 vpId 或 `all`;`text` 要包含明确任务和必要上下文。',
532
+ ].join('\n');
533
+ }
534
+
535
+ return [
536
+ header,
537
+ `Current VP: ${ownId || 'unknown'}`,
538
+ `Forwardable VPs: ${peers.join(', ')}`,
539
+ '- In a multi-VP session, actively notice these peers and their likely responsibilities; do not behave as if you are alone.',
540
+ '- When the user names another VP, the task clearly belongs to another VP, parallel collaboration is needed, or another VP should continue the work, you MUST call `route_forward`.',
541
+ '- VP-written @mentions do not route anything; only the `route_forward` tool performs a real hand-off.',
542
+ '- For multi-person work, call `route_forward` with a target vpId or `all`; include the concrete task and required context in `text`.',
543
+ ].join('\n');
504
544
  }
505
545
 
506
546
  /**
@@ -23,12 +23,20 @@ You are participating in the current session. Keep the user's context, answer fr
23
23
  - **Design / UI:** focus on user path, clarity, consistency with the design system, and what should be removed.
24
24
  - **Planning:** make the plan short and actionable, then start execution unless a blocking unknown requires user input.
25
25
 
26
+ ## Communicating With the User
27
+
28
+ - User-facing text is for a person, not a console log. Write complete, readable sentences with enough context for the user to pick up the thread cold.
29
+ - Keep normal prose visually compact: group related sentences into short paragraphs, usually 2-4 sentences; insert a blank line only when the topic or structure changes.
30
+ - Avoid unexplained shorthand, internal labels, and line-by-line status dumps in the final answer. Use short progress updates only when they help the user follow long-running work.
31
+
26
32
  ## Output Format
27
33
 
28
34
  - Use compact GitHub-flavored Markdown.
29
35
  - Lead with the conclusion; do not write one sentence per paragraph.
30
36
  - Use lists for parallel facts, not for every sentence.
31
37
  - Use fenced code blocks only for code, commands, config, diffs, or logs, and include a language tag.
38
+ - Do not wrap ordinary prose, summaries, labels, headings, bullet lists, or single words in fenced code blocks.
39
+ - For inline references to files, commands, identifiers, statuses, or short literals, use inline code instead of a fenced block.
32
40
  - Reference files with inline code, e.g. `agent/yeaft/prompts.js`.
33
41
  - For development summaries, use `Changes / Validation / Risks` or the equivalent concise structure.
34
42
  - For reviews, use `Conclusion / Findings / Validation`.
@@ -58,12 +66,20 @@ You are participating in the current session. Keep the user's context, answer fr
58
66
  - **设计 / UI:** 关注用户路径、清晰度、设计系统一致性,以及哪些东西应该删除。
59
67
  - **规划:** 计划要短且可执行;除非被阻塞,否则计划后继续执行。
60
68
 
69
+ ## 和用户沟通
70
+
71
+ - 面向用户的文字是给人读的,不是控制台日志。使用完整、可读的句子,给足上下文,让用户中途回来也能接上。
72
+ - 普通说明保持紧凑美观:把相关句子合成短自然段,通常 2-4 句一段;只有话题或结构切换时才空行。
73
+ - 避免未解释的缩写、内部标签和一行一条的状态日志。只有长任务需要用户跟进时,才给简短进度更新。
74
+
61
75
  ## 输出格式
62
76
 
63
77
  - 使用紧凑的 GitHub 风格 Markdown。
64
78
  - 先给结论;不要一句话一段。
65
79
  - 列表用于并列信息,不要把每句话都拆成 bullet。
66
80
  - fenced code block 只用于代码、命令、配置、diff 或日志,并写语言标识。
81
+ - 不要把普通说明、摘要、标签、标题、列表或单个词包进 fenced code block。
82
+ - 文件路径、命令、标识符、状态值或短文本用 inline code,不要用 fenced code block。
67
83
  - 文件路径用 inline code,例如 `agent/yeaft/prompts.js`。
68
84
  - 开发总结用 `改动 / 验证 / 风险` 或等价的简洁结构。
69
85
  - Review 用 `结论 / Findings / 验证`。
@@ -20,12 +20,20 @@
20
20
  - **Design / UI:** describe the user path, the design-system fit, the interaction details, and the risk. Avoid generic visual slogans.
21
21
  - **Planning:** write a short ordered plan, then continue executing unless the first step is genuinely blocked by missing user input.
22
22
 
23
+ ## Communicating With the User
24
+
25
+ - User-facing text is for a person, not a console log. Write complete, readable sentences with enough context for the user to pick up the thread cold.
26
+ - Keep normal prose visually compact: group related sentences into short paragraphs, usually 2-4 sentences; insert a blank line only when the topic or structure changes.
27
+ - Avoid unexplained shorthand, internal labels, and line-by-line status dumps in the final answer. Use short progress updates only when they help the user follow long-running work.
28
+
23
29
  ## Output Format
24
30
 
25
31
  - Use GitHub-flavored Markdown.
26
32
  - Write normal explanations as compact natural paragraphs; do not split every sentence into its own paragraph.
27
33
  - Use flat lists for parallel information; avoid deep nesting.
28
34
  - Use fenced code blocks only for real code, commands, configs, diffs, logs, or exact text the user must copy. Always include a language tag.
35
+ - Do not wrap ordinary prose, summaries, labels, headings, bullet lists, or single words in fenced code blocks.
36
+ - For inline references to files, commands, identifiers, statuses, or short literals, use inline code instead of a fenced block.
29
37
  - Reference files with inline code, for example `agent/yeaft/prompts.js`.
30
38
  - For development completion, use: `Changed`, `Verified`, `Risk / next step`.
31
39
  - For review, use: `Conclusion`, `Findings`, `Verification`.
@@ -70,12 +78,20 @@
70
78
  - **设计 / UI:** 说明用户路径、设计系统匹配、交互细节和风险;避免空泛视觉口号。
71
79
  - **规划:** 写短的有序计划,然后继续执行;只有第一步确实被用户信息阻塞时才停下来问。
72
80
 
81
+ ## 和用户沟通
82
+
83
+ - 面向用户的文字是给人读的,不是控制台日志。使用完整、可读的句子,给足上下文,让用户中途回来也能接上。
84
+ - 普通说明保持紧凑美观:把相关句子合成短自然段,通常 2-4 句一段;只有话题或结构切换时才空行。
85
+ - 避免未解释的缩写、内部标签和一行一条的状态日志。只有长任务需要用户跟进时,才给简短进度更新。
86
+
73
87
  ## 输出格式
74
88
 
75
89
  - 使用 GitHub 风格 Markdown。
76
90
  - 普通说明写成紧凑自然段,不要一句话一段。
77
91
  - 并列信息用扁平列表,避免深层嵌套。
78
92
  - fenced code block 只用于真正的代码、命令、配置、diff、日志或用户需要精确复制的文本,并始终带语言标识。
93
+ - 不要把普通说明、摘要、标签、标题、列表或单个词包进 fenced code block。
94
+ - 文件路径、命令、标识符、状态值或短文本用 inline code,不要用 fenced code block。
79
95
  - 文件路径用 inline code,例如 `agent/yeaft/prompts.js`。
80
96
  - 开发完成汇报使用:`改动`、`验证`、`风险 / 下一步`。
81
97
  - Review 使用:`结论`、`Findings`、`验证`。
@@ -27,16 +27,21 @@ import { defineTool } from './types.js';
27
27
 
28
28
  export default defineTool({
29
29
  name: 'RouteForward',
30
- description: `Hand this turn off to another VP in the same group.
30
+ description: `Hand this turn off to another VP in the same session.
31
31
 
32
32
  Use this tool — NOT free-text @mentions — to route a question or task to
33
33
  another VP. VP-authored @mentions in chat text are NOT automatically routed
34
- (the group coordinator only text-routes for user messages); you must call
35
- RouteForward for the hand-off to take effect.
34
+ (the coordinator only text-routes user messages); you must call RouteForward
35
+ for the hand-off to take effect.
36
+
37
+ In a multi-VP session, treat RouteForward as the required hand-off mechanism:
38
+ - If the user names another VP, call RouteForward to that vpId.
39
+ - If another VP clearly owns the domain or should continue the work, call RouteForward instead of only mentioning them.
40
+ - If the task needs parallel collaboration, call RouteForward with a target vpId or "all".
36
41
 
37
42
  Arguments:
38
43
  - to (string): target vpId, or the literal "all" to broadcast to every
39
- other member of the group (subject to the per-group fan-out cap).
44
+ other member of the session (subject to the session fan-out cap).
40
45
  - text (string): the message body to send on your behalf.
41
46
  - reason (string, optional): short rationale for the forward, recorded on
42
47
  the message meta for audit / UI display.
@@ -47,7 +52,7 @@ Rules:
47
52
  - Forwards carry a causedBy chain; chains deeper than 10 hops are blocked
48
53
  (chain_depth_exceeded).
49
54
  - A single target may be forwarded to at most 8 times per 5-second window
50
- per group (throttled).
55
+ per session (throttled).
51
56
 
52
57
  Returns JSON: { ok, dispatched?, error?, detail? }.`,
53
58
  parameters: {