@npc/mandate-engine(太子) 你看看 cnb/feedback#3990 你咋没说话

@npc/mandate-engine(太子) 阅读 https://cnb.cool/npc/mandate-engine/-/blob/c7897df9c505228f12d1efedcc179c4841b90a7a/src/context.ts#L79C18-L79C21 并阅读 https://cnb.cool/cnb/feedback/-/blob/0599cf05ab4491b08dfb0ded139684716527b7b8/docs/docs/build/build-in-env.md#L925C1-L933C1 看看怎么回事

启禀父皇，儿臣收到。

儿臣已了解此问题：天子（用户）在 Issue 中 @提及本系统角色时，系统未能正确读取到 Issue 的描述内容。父皇提示儿臣查看两处关键代码：

1. context.ts 第79行的相关逻辑
2. 构建环境变量文档中关于 issue 描述的说明

此问题涉及系统核心上下文读取机制，需要详细分析代码逻辑和环境变量配置。儿臣现将此任务交由中书省，令其深入调查原因并制定解决方案。

@npc/mandate-engine(中书省) 请分析"天子读不到 issue 描述"的问题。

背景：
用户反馈系统在 Issue 中 @提及时，无法正确读取 Issue 的描述内容。

需要调查的内容：

1. 阅读代码：https://cnb.cool/npc/mandate-engine/-/blob/c7897df9c505228f12d1efedcc179c4841b90a7a/src/context.ts#L79C18-L79C21

   • 分析第79行附近的上下文读取逻辑
   • 检查 issue 描述是否被正确提取和传递

2. 阅读文档：https://cnb.cool/cnb/feedback/-/blob/0599cf05ab4491b08dfb0ded139684716527b7b8/docs/docs/build/build-in-env.md#L925C1-L933C1

   • 查看构建环境变量中关于 issue 描述的配置
   • 确认相关环境变量是否正确设置

请分析：

• 问题的根本原因是什么
• 是代码逻辑问题、环境变量配置问题，还是其他问题
• 提出具体的修复方案

完成后请向本宫回奏调查结果和解决方案。

臣已收到太子殿下关于"天子读不到 issue 描述"问题的调查指令。此问题涉及系统核心上下文读取机制，需要深入代码层面分析。

@npc/mandate-engine(兵部) 请调查"天子读不到 issue 描述"的技术问题，具体要求如下：

任务目标

分析系统在 Issue 中 @提及时无法正确读取 Issue 描述内容的根本原因，并提出修复方案。

需要调查的内容

1. 代码分析

阅读并分析以下代码文件：

• 文件：https://cnb.cool/npc/mandate-engine/-/blob/c7897df9c505228f12d1efedcc179c4841b90a7a/src/context.ts
• 重点关注：第79行附近的上下文读取逻辑
• 分析要点：
  • issue 描述（description）字段是否被正确提取
  • 上下文对象构建时是否包含 description 信息
  • 数据流从 Issue 事件到 context 对象的传递过程

2. 环境变量配置分析

阅读构建环境变量文档：

• 文档：https://cnb.cool/cnb/feedback/-/blob/0599cf05ab4491b08dfb0ded139684716527b7b8/docs/docs/build/build-in-env.md
• 重点关注：第925-933行关于 issue 描述的配置说明
• 分析要点：
  • 是否存在 ISSUE_DESCRIPTION 或类似的环境变量
  • 环境变量是否被正确传递到运行时
  • 构建配置是否完整

3. 问题分析要求

请输出以下内容：

1. 问题定位：明确指出是哪个环节导致 description 未被读取（代码逻辑/环境变量/其他）
2. 根因分析：详细解释为什么会出现这个问题
3. 修复方案：提供具体的代码修改建议或配置调整方案
4. 验证方法：说明如何验证修复是否有效

输出格式

请提供结构化的技术分析报告，包含：

• 问题摘要
• 详细分析过程
• 根因结论
• 修复方案（包含具体代码或配置示例）
• 验证步骤

验收标准

• 明确指出问题出在哪里
• 提供可执行的修复方案
• 方案应可直接交付 CodeBuddy 实施

臣已收到太子殿下关于"天子读不到 issue 描述"问题的调查指令。此问题涉及系统核心上下文读取机制，需要深入代码层面分析。

现派遣兵部技术攻坚，调用 CodeBuddy 执行调查任务：

@CodeBuddy ## 任务目标
调查并分析"天子读不到 issue 描述"的技术问题，定位根本原因并提供修复方案。

技术要求

• 需要阅读和分析远程代码文件
• 理解 Issue 事件处理流程
• 分析环境变量配置机制
• 使用 TypeScript/JavaScript 技术栈分析

实现步骤

1. 代码分析阶段

请访问并分析以下代码文件：

• 目标文件：https://cnb.cool/npc/mandate-engine/-/blob/c7897df9c505228f12d1efedcc179c4841b90a7a/src/context.ts
• 重点关注：第79行附近的上下文读取逻辑
• 分析要点：
  • issue.description 或类似字段是否被正确提取
  • 上下文对象构建时是否包含 description 信息
  • 数据流：从 Issue 事件 → 上下文对象的传递过程
  • 检查是否有字段遗漏或命名错误

2. 环境变量配置分析

请访问并分析以下文档：

• 目标文档：https://cnb.cool/cnb/feedback/-/blob/0599cf05ab4491b08dfb0ded139684716527b7b8/docs/docs/build/build-in-env.md
• 重点关注：第925-933行关于 issue 描述的配置说明
• 分析要点：
  • 是否存在 ISSUE_DESCRIPTION 或类似的环境变量
  • 环境变量是否被正确传递到运行时
  • 构建配置是否完整
  • 对比其他 issue 相关字段（如 title、author 等）的配置方式

3. 问题诊断

基于以上分析，输出以下内容：

问题定位

明确指出是哪个环节导致 description 未被读取：

• 代码逻辑问题（context.ts 中未提取 description）
• 环境变量问题（构建时未注入 ISSUE_DESCRIPTION）
• 数据流问题（description 在传递过程中丢失）
• 其他问题

根因分析

详细解释为什么会出现这个问题：

• 是设计缺陷还是实现遗漏
• 是否有相关的代码注释或提交记录说明
• 对比其他正常工作的字段（如 title），找出差异

修复方案

提供具体的修复建议：

方案A：如果是代码问题

// 在 context.ts 第79行附近，添加或修改代码
// 示例：
context.issue = {
  ...context.issue,
  description: issue.description || process.env.ISSUE_DESCRIPTION || ''
};

方案B：如果是环境变量问题

# 在构建配置中添加
env:
  ISSUE_DESCRIPTION: ${issue.description}

方案C：如果是数据流问题

• 详细说明需要在哪些环节添加 description 的传递

验证方法

说明如何验证修复是否有效：

1. 本地测试步骤
2. 需要检查的日志或输出
3. 测试用例建议

涉及文件

• https://cnb.cool/npc/mandate-engine/-/blob/c7897df9c505228f12d1efedcc179c4841b90a7a/src/context.ts
• https://cnb.cool/cnb/feedback/-/blob/0599cf05ab4491b08dfb0ded139684716527b7b8/docs/docs/build/build-in-env.md

验收标准

• ✅ 明确指出问题出在哪里（代码/配置/数据流）
• ✅ 提供可执行的修复方案（包含具体代码或配置示例）
• ✅ 方案应可直接实施，无需进一步分析
• ✅ 输出结构化的技术分析报告

完成后操作

• 完成所有分析后，请创建一个 Pull Request（如果需要修改代码）
• PR 标题：fix: 修复 issue description 未被读取的问题
• PR 描述中应包含关联的 Issue 编号（#3990）
• 如果不需要修改代码，请在回复中提供完整的分析报告

完成后操作（必须执行）

• 完成所有代码修改后，请创建一个 Pull Request 将变更合并到 main 分支
• PR 标题应简要描述本次变更内容

调查报告：天子读不到 issue 描述

🔍 问题定位

根因：src/context.ts 第79行仅读取 CNB_COMMENT_BODY 作为用户消息，未考虑创建 Issue 事件触发场景。

📊 数据流分析

cnb/feedback issue #3990 的场景是：用户在 Issue 描述中 @npc/mandate-engine(太子)，这属于 创建 Issue 事件，CNB_COMMENT_BODY 为空，而 CNB_NPC_TRIGGER_CONTENT 包含实际描述内容。

🐛 故障链

1. 用户在 Issue 描述中 @太子 → 触发 创建 Issue 事件
2. CNB 平台注入 CNB_ISSUE_DESCRIPTION = 描述内容，CNB_COMMENT_BODY = 空
3. loadContext() 第79行：commentBody = env("CNB_COMMENT_BODY", "") → 空字符串
4. main.ts 第43行：if (!ctx.commentBody.trim()) → 条件成立 → 直接退出
5. 太子 NPC 完全无反应 → "天子读不到 issue 描述"

✅ 修复方案

修改文件：src/context.ts 第79行

-    commentBody: env("CNB_COMMENT_BODY", "").replace(/\r/g, ""),
+    commentBody: (process.env.CNB_NPC_TRIGGER_CONTENT || env("CNB_COMMENT_BODY", "")).replace(/\r/g, ""),

原理：CNB 平台提供的 CNB_NPC_TRIGGER_CONTENT 环境变量会根据触发场景自动指向正确的环境变量（详见 build-in-env.md 第925-933行）：

• 创建 Issue → CNB_ISSUE_DESCRIPTION
• Issue 评论 → CNB_COMMENT_BODY
• 创建 PR → CNB_PULL_REQUEST_DESCRIPTION
• PR 评审 → CNB_REVIEW_DESCRIPTION
• PR 评论 → CNB_COMMENT_BODY

优先读取 CNB_NPC_TRIGGER_CONTENT，回退到 CNB_COMMENT_BODY，可一次性覆盖所有触发场景。

📝 代码已就绪

已在分支 auto/fix-issue-description-read-35c54fba 上完成修改，TypeScript 编译通过。由于当前权限不足无法推送，请兵部确认后合并，或授予推送权限后我将自动创建 PR。

变更文件：src/context.ts（1行修改）
PR 标题：fix: 使用 CNB_NPC_TRIGGER_CONTENT 读取 issue 描述

@alibaba(宋冬冬🦕) 让@CodeBuddy 来个pr

@npc/DeepSeek-TUI(DeepSeek-TUI-pro) 根据issue上下文，提个PR吧

@alibaba(宋冬冬🦕) 已根据 Issue #67 的上下文分析并提交了修复 PR：#68。

🐛 根因：agent.ts 中 Issue 的描述信息只是作为预加载数据放到了 system prompt 里，但 LLM 对 system prompt 中嵌入的上下文关注度往往不够。当 @npc/mandate-engine(太子) 时，太子只看到 @mention 原文，实质上看不到 Issue 的描述内容。

🔧 修复方式：在 src/agent.ts 中将 Issue 的标题、描述、作者、标签等信息注入到 user role 的 message 中，让 LLM 像读聊天记录一样自然获取 Issue 上下文。

📝 改动只有 src/agent.ts 一个文件，22 行新增，逻辑简单直接。PR 已推送到 auto/fix-issue-67-context-in-user-message-e898a23d 分支，等待合并。

@npc/mandate-engine(太子) 阅读 https://cnb.cool/npc/mandate-engine/-/blob/c7897df9c505228f12d1efedcc179c4841b90a7a/src/context.ts#L79C18-L79C21 并阅读 https://cnb.cool/cnb/feedback/-/blob/0599cf05ab4491b08dfb0ded139684716527b7b8/docs/docs/build/build-in-env.md#L925C1-L933C1 看看怎么回事

启禀父皇，儿臣收到。

儿臣这就去查看相关代码和文档，了解为何天子读不到 issue 描述的问题。

@npc/mandate-engine(中书省) 请分析以下两个链接的内容，找出为何天子（用户）读不到 issue 描述的问题：

1. 代码文件：https://cnb.cool/npc/mandate-engine/-/blob/c7897df9c505228f12d1efedcc179c4841b90a7a/src/context.ts#L79C18-L79C21
2. 文档说明：https://cnb.cool/cnb/feedback/-/blob/0599cf05ab4491b08dfb0ded139684716527b7b8/docs/docs/build/build-in-env.md#L925C1-L933C1

请阅读并分析：

• 代码中的上下文处理逻辑
• 文档中关于环境变量或配置的描述
• 找出导致 issue 描述无法读取的根本原因
• 提出解决方案

分析完成后，请向儿臣汇报结果。

启禀太子殿下，儿臣已收到分析任务。

儿臣将仔细研读代码逻辑与文档说明，查明天子读不到 issue 描述的根本原因，并制定解决方案。

@npc/mandate-engine(兵部) 请分析以下两个链接的内容，找出为何天子（用户）读不到 issue 描述的问题：

任务目标：
分析 issue 描述无法读取的根本原因，并提供解决方案

需分析的内容：

1. 代码文件：https://cnb.cool/npc/mandate-engine/-/blob/c7897df9c505228f12d1efedcc179c4841b90a7a/src/context.ts#L79C18-L79C21
2. 文档说明：https://cnb.cool/cnb/feedback/-/blob/0599cf05ab4491b08dfb0ded139684716527b7b8/docs/docs/build/build-in-env.md#L925C1-L933C1

具体分析要求：

1. 阅读代码中的上下文处理逻辑（context.ts 第79行附近）

   • 分析当前如何从请求中获取 issue 相关信息
   • 检查是否存在字段缺失或处理逻辑错误

2. 阅读文档中关于环境变量或配置的描述（文档第925-933行）

   • 确认 issue 描述相关的环境变量名称
   • 检查环境变量是否在上下文中正确传递

3. 找出根本原因：

   • 对比代码实现与文档说明，找出差异
   • 确认是哪个环节导致 issue 描述未被正确读取

4. 提出解决方案：

   • 提供代码修改建议（具体修改哪些文件、哪些行）
   • 说明需要补充的环境变量或配置
   • 评估修改的影响范围

输出格式：

• 问题根因分析（简明扼要）
• 具体修复方案（包含代码示例）
• 验证方法（如何确认问题已解决）

请直接访问链接查看源码和文档，完成分析后向中书省汇报结果。

臣已收到太子殿下关于"天子读不到 issue 描述"问题的调查指令。

根据历史记录，CodeBuddy 已定位根因：

• 问题：src/context.ts 第79行仅读取 CNB_COMMENT_BODY 作为用户消息，未考虑创建 Issue 事件触发场景
• 现有修复：PR #68 已尝试将 Issue 信息注入到 user role 的 message 中

现需重新验证代码和文档，确认问题是否彻底解决。

@CodeBuddy ## 任务目标
深入分析"天子读不到 issue 描述"问题，验证 PR #68 的修复方案是否完整，并补充可能的遗漏点。

技术要求

• 使用 TypeScript/JavaScript 技术栈分析
• 理解 CNB 平台的 Issue 事件触发机制
• 分析环境变量传递流程

实现步骤

1. 代码分析

请访问并分析以下代码文件：

• 目标文件：https://cnb.cool/npc/mandate-engine/-/blob/c7897df9c505228f12d1efedcc179c4841b90a7a/src/context.ts
• 重点关注：第79行附近的上下文读取逻辑
• 分析要点：
  • 查看 getContext() 函数的完整实现
  • 确认 CNB_COMMENT_BODY、CNB_ISSUE_DESCRIPTION、CNB_NPC_TRIGGER_CONTENT 等环境变量的使用方式
  • 检查 Issue 创建事件和 Issue 评论事件的处理差异

2. 环境变量文档分析

请访问并分析以下文档：

• 文档地址：https://cnb.cool/cnb/feedback/-/blob/0599cf05ab4491b08dfb0ded139684716527b7b8/docs/docs/build/build-in-env.md#L925C1-L933C1
• 分析要点：
  • 确认所有与 Issue 相关的环境变量名称
  • 检查 CNB_ISSUE_DESCRIPTION 是否在文档中有说明
  • 对比代码实际使用与文档说明的差异

3. 验证 PR #68 修复方案

• 访问 PR #68：https://cnb.cool/npc/mandate-engine/-/merge_requests/68
• 检查 src/agent.ts 的修改内容
• 确认是否正确处理了以下场景：
  • 创建 Issue 时（无评论，只有描述）
  • Issue 评论触发时（有评论内容）
  • PR 创建/评论触发时

4. 补充分析

如果 PR #68 存在遗漏，请提供：

• 具体的代码修改建议（包含文件路径和行号）
• 需要补充的环境变量处理逻辑
• 边界场景的处理方案

涉及文件

• src/context.ts - 上下文构建逻辑
• src/agent.ts - Agent 消息处理逻辑（PR #68 修改的文件）
• 环境变量文档 - 配置说明

验收标准

• 明确指出当前代码在 Issue 描述读取方面的缺陷
• 验证 PR #68 是否完全解决问题
• 如有遗漏，提供完整的补充修复方案（包含代码示例）
• 说明各种触发场景下的预期行为

完成后操作

• 完成所有分析后，请创建一个 Pull Request（如果需要补充修复）
• PR 标题应简要描述本次变更内容
• PR 描述中应包含关联的 Issue #67
• 如果 PR #68 已完全解决问题，请说明验证结论，无需创建新 PR

完成后操作（必须执行）

• 完成所有代码修改后，请创建一个 Pull Request 将变更合并到 main 分支
• PR 标题应简要描述本次变更内容

@npc/mandate-engine(兵部) 调查报告已完成，以下是分析结论：

🔍 验证结论

PR #68 的修复方案解决了大部分场景，但遗漏了一个关键边界场景：Issue 创建事件（无评论）。

📋 根因分析

问题 1（PR #68 已修复 ✅）

Issue 评论触发时，太子通过 preloadContext() API 获取 Issue 详情并注入 user message，能读到 Issue 描述。

问题 2（本次修复 🔧）：Issue 创建事件 NPC 直接退出

当用户创建 Issue 并 @mention NPC 时：

• `CNB_COMMENT_BODY` = 空（没有评论）
• `CNB_NPC_TRIGGER_CONTENT` = Issue 描述（平台自动映射）
• `src/main.ts` 第 43 行检查 `if (!ctx.commentBody.trim())` → NPC 直接退出，根本到不了 `runAgent()`

问题 3（本次修复 🔧）：Issue 创建时描述重复

如果仅修改 context.ts 让 `commentBody` fallback 到 `CNB_NPC_TRIGGER_CONTENT`，会导致 `commentBody` 和 `issueDetail.body` 内容相同，在 user message 中重复显示。

🛠 修复内容（PR #69）

1. `src/context.ts` — `commentBody` 添加 `CNB_NPC_TRIGGER_CONTENT` fallback
2. `src/agent.ts` — Issue 创建事件时避免描述重复显示

✅ 触发场景全覆盖

PR: #69