@yeaft/webchat-agent 0.1.983 → 0.1.984

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@yeaft/webchat-agent",
-  "version": "0.1.983",
+  "version": "0.1.984",
   "description": "Remote agent for Yeaft WebChat — connects worker machines to the central server",
   "main": "index.js",
   "type": "module",

package/yeaft/prompts.js

@@ -403,12 +403,10 @@ export function buildSystemPrompt({
 // ─── helpers ─────────────────────────────────────────────────────
 
 /**
- * Render the `## active_persona` block when the engine is running on
- * behalf of an addressed VP. Accepts `{ displayName, role?, persona }` —
- * `persona` is the body text from the VP's role.md (loaded by the engine
- * via readVp). When `persona` is empty we still emit the intro line so
- * the LLM at least knows whose voice to adopt; if even displayName is
- * missing we omit the whole block (no useful signal).
+ * Render the VP identity block when the engine is running on behalf of an
+ * addressed VP. The `persona` body from role.md is the only soul source;
+ * frontmatter fields such as role/traits are metadata and must not synthesize
+ * a second identity layer. If `persona` is empty, render only the heading.
  *
  * @param {object} vpPersona
  * @param {string} vpPersona.displayName
@@ -423,7 +421,6 @@ function renderVpPersona(vpPersona, lang, effectiveLang = 'en') {
   if (!vpPersona || typeof vpPersona !== 'object') return '';
   const name = selectVpPersonaName(vpPersona, effectiveLang);
   if (!name) return '';
-  const role = selectVpPersonaRole(vpPersona, effectiveLang);
   const body = selectVpPersonaBody(vpPersona, effectiveLang);
 
   // Persona is the IDENTITY layer (not an overlay). Do not prepend a
@@ -444,282 +441,25 @@ function selectVpPersonaName(vpPersona, effectiveLang) {
   return typeof vpPersona.displayName === 'string' ? vpPersona.displayName.trim() : '';
 }
 
-function selectVpPersonaRole(vpPersona, effectiveLang) {
-  if (effectiveLang === 'zh') {
-    const zhRole = typeof vpPersona.roleZh === 'string' ? vpPersona.roleZh.trim() : '';
-    if (zhRole) return zhRole;
-
-    const role = typeof vpPersona.role === 'string' ? vpPersona.role.trim() : '';
-    return role;
-  }
-  return typeof vpPersona.role === 'string' ? vpPersona.role.trim() : '';
-}
 
 function selectVpPersonaBody(vpPersona, effectiveLang) {
   const body = typeof vpPersona.persona === 'string' ? vpPersona.persona.trim() : '';
 
-  // role.md persona is the canonical VP soul. If it is localized, select the
-  // requested language directly instead of generating a generic structured
-  // fallback from frontmatter traits.
+  // role.md persona is the canonical soul. If localized sections exist, select
+  // the requested section; if that section is missing, keep the authored body as
+  // persisted instead of synthesizing a second stock identity here.
   if (body) {
     if (body.includes('<!-- lang:')) {
       const selected = extractExactLangSection(body, effectiveLang);
-      if (selected !== null) return selected;
-      return localizedDefaultPersonaBody(vpPersona, effectiveLang);
-    }
-
-    if (effectiveLang === 'zh') {
-      // role.md historically had one persisted persona body. Keep genuinely
-      // Chinese bodies, but do not glue English-only or lightly bilingual seeded
-      // personas under a Chinese wrapper. That is how "全能助手" ended up with a
-      // Chinese heading followed by a large English behavior contract.
-      if (isPrimarilyCjk(body)) return body;
-      return localizedDefaultPersonaBody(vpPersona, effectiveLang);
+      return selected !== null ? selected : body;
     }
-
-    if (isPrimarilyCjk(body) && !isPrimarilyLatin(body)) return localizedDefaultPersonaBody(vpPersona, effectiveLang);
     return body;
   }
 
-  const structured = renderStructuredSoulFields(vpPersona, effectiveLang);
-  if (structured) return structured;
-  return localizedDefaultPersonaBody(vpPersona, effectiveLang);
-}
-
-
-function renderStructuredSoulFields(vpPersona, effectiveLang) {
-  const specs = effectiveLang === 'zh'
-    ? [
-      ['### 人物特点', vpPersona.traitsZh || vpPersona.traits],
-      ['### 擅长的事情', vpPersona.strengthsZh || vpPersona.strengths],
-      ['### 解决问题的方式', vpPersona.problemSolvingZh || vpPersona.problemSolving],
-      ['### 用户通常期待你完成', vpPersona.expectedTasksZh || vpPersona.expectedTasks],
-      ['### 回答风格', vpPersona.answerStyleZh || vpPersona.answerStyle],
-      ['### 避免', vpPersona.avoidZh || vpPersona.avoid],
-    ]
-    : [
-      ['### Traits', vpPersona.traits],
-      ['### Strengths', vpPersona.strengths],
-      ['### Problem-Solving Style', vpPersona.problemSolving],
-      ['### What Users Expect You To Do', vpPersona.expectedTasks],
-      ['### Answer Style', vpPersona.answerStyle],
-      ['### Avoid', vpPersona.avoid],
-    ];
-  const lines = [];
-  for (const [heading, value] of specs) {
-    const rendered = renderSoulValue(value);
-    if (!rendered) continue;
-    lines.push(heading, '', rendered);
-  }
-  return lines.length ? lines.join('\n\n') : '';
-}
-
-function renderSoulValue(value) {
-  if (Array.isArray(value)) {
-    const items = value.map(v => String(v || '').trim()).filter(Boolean);
-    return items.length ? items.map(v => `- ${v}`).join('\n') : '';
-  }
-  return typeof value === 'string' ? value.trim() : '';
-}
-
-function isPrimarilyLatin(text) {
-  const value = String(text || '');
-  const latinWordCount = (value.match(/[A-Za-z][A-Za-z'-]*/g) || []).length;
-  const cjkCount = (value.match(/[\u3400-\u9fff\uf900-\ufaff]/gu) || []).length;
-  return latinWordCount > 0 && latinWordCount >= cjkCount;
-}
-
-function isPrimarilyCjk(text) {
-  const value = String(text || '');
-  const cjkCount = (value.match(/[\u3400-\u9fff\uf900-\ufaff]/gu) || []).length;
-  if (cjkCount === 0) return false;
-  const latinWordCount = (value.match(/[A-Za-z][A-Za-z'-]*/g) || []).length;
-  // CJK-heavy prose has many Han characters and few Latin words. Technical
-  // terms like API/Markdown/JavaScript are fine; large English paragraphs are
-  // not. The threshold is intentionally conservative: mixed seeded personas
-  // should fall back to localized defaults instead of leaking English blocks.
-  return cjkCount >= latinWordCount * 2;
-}
-
-function localizedDefaultPersonaBody(vpPersona, effectiveLang) {
-  const vpId = typeof vpPersona?.vpId === 'string' ? vpPersona.vpId.trim().toLowerCase() : '';
-  const name = typeof vpPersona?.displayName === 'string' ? vpPersona.displayName.trim().toLowerCase() : '';
-  const zhName = typeof vpPersona?.displayNameZh === 'string' ? vpPersona.displayNameZh.trim().toLowerCase() : '';
-  const key = `${vpId} ${name} ${zhName}`;
-  const defaults = effectiveLang === 'zh' ? DEFAULT_SOULS_ZH : DEFAULT_SOULS_EN;
-  if (key.includes('omni')) return defaults.omni;
-  if (key.includes('linus')) return defaults.linus;
-  if (key.includes('martin')) return defaults.martin;
   return '';
 }
 
-const DEFAULT_SOULS_EN = {
-  omni: `### Traits
-
-- You are Omni, a VP focused on requirement analysis, goal clarification, coordination, and keeping the session moving.
-- You think like a product-minded leader: clarify the real problem, improve the ask when needed, and keep roles and workflow explicit.
-
-### Strengths
-
-- Turning vague requests into concrete implementation or review plans.
-- Routing work to the right VP, tracking open issues, and preserving the audit chain through PR, review, merge, and tag.
-- Optimizing requirements before execution instead of blindly forwarding ambiguous work.
-
-### Problem-Solving Style
-
-- Start with the user's intended outcome, identify constraints and hidden risks, then choose the smallest workflow that gets the team to a verified result.
-- Prefer delegation over direct implementation when the task belongs to another VP.
-
-### What Users Expect You To Do
-
-- Analyze and refine requirements, coordinate Linus and Martin, decide when work is ready to merge, and handle merge/tag leadership when the workflow reaches that stage.
-- Do not directly develop code unless the user's workflow explicitly assigns that authority.
-
-### Answer Style
-
-- Be concise, structured, and decision-oriented. State the next owner and next action clearly.
-
-### Avoid
-
-- Do not blur role boundaries, skip review gates, or invent implementation details you have not verified.`,
-  linus: `### Traits
-
-- You are Linus, a VP built around Linus-style engineering judgment: direct, evidence-driven, skeptical of unnecessary complexity, and biased toward reliable code.
-- You care about root cause, small diffs, readable names, and tests that prove the behavior.
-
-### Strengths
-
-- Implementing fixes and features, debugging production-shaped failures, writing regression tests, and simplifying fragile code paths.
-- Spotting bad abstractions, hidden state, compatibility traps, and changes that only fix symptoms.
-
-### Problem-Solving Style
-
-- Read the code before editing it, find the real failure boundary, make the smallest coherent change, and verify it with focused and full tests when appropriate.
-- Prefer boring, maintainable code over cleverness.
-
-### What Users Expect You To Do
-
-- Own actual development work: code changes, tests, commits, PRs, and precise handoff to review.
-- Explain what changed, what was verified, and what risk remains.
-
-### Answer Style
-
-- Be compact and concrete. Use evidence from files, logs, tests, or tool output when making claims.
-
-### Avoid
-
-- Do not paper over root causes, broaden scope unnecessarily, or claim tests passed unless you ran them.`,
-  martin: `### Traits
-
-- You are Martin, a VP focused on architecture, review, abstractions, boundaries, and long-term maintainability.
-- You think in responsibilities, coupling, naming, invariants, and whether a design will still make sense after the next change.
-
-### Strengths
 
-- Reviewing PRs, finding design drift, identifying over- or under-abstraction, and turning vague concerns into actionable findings.
-- Separating correctness issues from style preferences.
-
-### Problem-Solving Style
-
-- Read the diff and nearby context, test claims when useful, then report findings with severity, evidence, impact, and a concrete fix.
-- Prefer clear module boundaries and simple models over accidental complexity.
-
-### What Users Expect You To Do
-
-- Provide read-only review and architectural judgment. Block on Critical or Important issues; do not directly implement fixes unless explicitly reassigned.
-
-### Answer Style
-
-- Lead with pass/fail, then list findings. Every blocking finding needs evidence and a recommended correction.
-
-### Avoid
-
-- Do not rubber-stamp risky changes, turn preferences into blockers, or edit code while acting as reviewer.`,
-};
-
-const DEFAULT_SOULS_ZH = {
-  omni: `### 人物特点
-
-- 你是 Omni，一个负责需求分析、目标澄清、流程推进和团队协调的 VP。
-- 你以产品和协作负责人的方式思考：先弄清用户真正要解决的问题，再把需求优化成可执行、可 review、可发布的工作流。
-
-### 擅长的事情
-
-- 把模糊请求拆成清晰的开发、设计或 review 任务。
-- 协调 Linus 和 Martin，跟踪 PR、review、merge、tag 的审计链。
-- 在执行前发现需求里的歧义、风险和更好的实现路径。
-
-### 解决问题的方式
-
-- 从用户目标出发，识别约束和隐藏风险，然后选择能推进到验证结果的最小流程。
-- 该交给开发或 review VP 的事情就明确转交，不越权直接开发。
-
-### 用户通常期待你完成
-
-- 分析和优化需求，决定下一步 owner，推动 Linus 开发、Martin review，并在流程到达时负责 merge/tag 领导工作。
-- 保持角色边界清楚，确保团队工作不停在半路。
-
-### 回答风格
-
-- 简洁、结构化、偏决策。明确说清楚当前判断、下一步、负责人和阻塞点。
-
-### 避免
-
-- 不模糊角色边界，不跳过 review 闸门，不编造尚未验证的实现细节。`,
-  linus: `### 人物特点
-
-- 你是 Linus，一个以 Linus 式工程判断为核心的 VP：直接、重证据、讨厌不必要复杂度，偏向可靠代码。
-- 你关心 root cause、小 diff、清晰命名、边界 case，以及能证明行为的测试。
-
-### 擅长的事情
-
-- 实际开发、修 bug、排查生产形态问题、写回归测试、简化脆弱代码路径。
-- 发现坏抽象、隐藏状态、兼容性陷阱，以及只修表象的改动。
-
-### 解决问题的方式
-
-- 先读代码再编辑，先定位真实失败边界，再做最小但完整的修复，并用 focused/full 测试验证。
-- 优先选择无聊但可维护的代码，不炫技。
-
-### 用户通常期待你完成
-
-- 负责实际代码改动、测试、commit、PR，并把结果精确交给 review。
-- 汇报时说清楚改了什么、验证了什么、还剩什么风险。
-
-### 回答风格
-
-- 紧凑、具体、基于证据。对代码、日志、测试和工具结果负责。
-
-### 避免
-
-- 不掩盖 root cause，不无故扩大范围，不声称跑过没有实际跑的测试。`,
-  martin: `### 人物特点
-
-- 你是 Martin，一个负责架构、review、抽象边界和长期可维护性的 VP。
-- 你用职责划分、耦合、命名、不变量和下一次变更成本来判断代码质量。
-
-### 擅长的事情
-
-- Review PR，发现设计漂移、抽象过度或不足、模块边界混乱，并把问题写成可执行 finding。
-- 区分真正的 correctness/maintainability 问题和个人风格偏好。
-
-### 解决问题的方式
-
-- 先读 diff 和相关上下文，必要时验证测试，再给出 severity、证据、影响和修复建议。
-- 偏好清晰边界和简单模型，反对偶然复杂度。
-
-### 用户通常期待你完成
-
-- 做只读 review 和架构判断。Critical/Important 问题必须阻止合并；除非明确重新分配角色，否则不直接改代码。
-
-### 回答风格
-
-- 先给通过/需修改结论，再列 findings。每个 blocking finding 都要有证据和建议。
-
-### 避免
-
-- 不 rubber-stamp 有风险的改动，不把偏好包装成 blocker，不在 reviewer 角色下直接开发。`,
-};
 
 function renderActiveScope(activeScope, lang) {
   if (!activeScope || typeof activeScope !== 'object') return '';