项目待办管理器（project-backlog）

核心原则：文档即状态，不依赖 AI 记忆。 任何输入先存文档；执行状态写在文档里；进程中断后可从文档恢复，不丢失。

---

认知根

认知根：_内部总控/认知结构/L1_系统性文档/系统架构思维维度/Skill体系设计原则_v1.0.md 关联：「文档即状态」是本 Skill 的核心执行范式。

---

待办文档规范（项目待办.md）

位置：项目群/[项目名]/产品经理/项目待办.md （优先用 project-config.md 中的 PATH_待办 字段覆盖）

标准格式：

# 项目待办

> 所有类型的输入先到这里。说「处理项目待办」可触发自动处理流程。

| ID | 类型 | 内容摘要 | 来源日期 | 优先级 | 状态 |
|----|------|---------|---------|--------|------|
| B-01 | Bug | [描述] | YYYY-MM-DD | P0/P1/P2 | 🔲 |
| F-01 | Feature | [描述] | YYYY-MM-DD | — | 🔲 |
| U-01 | UX | [描述] | YYYY-MM-DD | P1 | 🔲 |
| P-01 | 原则 | [描述] | YYYY-MM-DD | — | 🔲 |
| R-01 | 规范偏差 | [描述] | YYYY-MM-DD | — | 🔲 |
| D-01 | 设计建议 | [描述] | YYYY-MM-DD | — | 🔲 |

状态标记：🔲 待处理 / 🔄 处理中 / ✅ 已完成 / ❌ 执行失败 / ⏸️ 搁置（待决策）/ 📬 已移交

ID 前缀：B=Bug / F=Feature / U=UX / P=原则 / R=规范偏差 / D=设计建议 + 两位流水号

架构层标签（B-xx Bug 可选，AI 平台项目推荐填写）： L0=部署模型 / L1=状态管理 / L2=并发模型 / L3=LLM调用 / L4=数据隔离 / L5=Agent框架 / L6=可观测 / L7=安全 / L8=性能 / L9=扩展 / FE=前端 示例：B-01 | Bug | [L1] 更新认知显示构建中 | ...

---

知识导航表（执行前读取）

层级	文档	读取目的
D0	.cursor/project-config.md（若存在）	获取 PATH_待办 和 PATH_技术追踪台
①	_内部总控/元项目导航.md	project-config 不存在时确认当前活跃项目

---

可用 Skill 速查表（P-2 生成激活命令时的唯一参考）

⚠️ 生成激活命令时必须参考此表，不得凭记忆猜测触发词

待办类型	触发词（【X】格式）	对应 Skill	该 Skill 处理什么	前置条件
P-xx 原则类	【立原则】：[原则描述]	engineering-principle-recorder	新工程/执行原则录入到 Rule/Role Skill 执行层，并审计现有违规	无
B-xx P0/P1 Bug（需立即修复）	【修复循环】	bug-fix-loop-coordinator	读技术追踪台，P0→P1 循环 TDD 修复，直至清零。⚠️ 需要 Bug 已在追踪台中（P-2-1 写入追踪台后再激活）	技术追踪台已有条目
B-xx P2 Bug（仅记录）	【记录问题】[Bug描述]	issue-tracker	拆分并记录到产品/技术追踪台，不立即修复	无
F-xx Feature（新功能需求）	【协调者】：[需求描述 + 用户决策]	role-产品开发协调者	判断任务类型并编排完整产品开发流水线（PM→关卡A→架构师→关卡B→开发→关卡C→DevOps）	无
U-xx UX 问题（体验问题）	【协调者】：[UX问题 + 用户决策]	role-产品开发协调者	同上，协调者判断走产品修复还是前端/UI修复	无
R-xx 规范偏差（已有规范被违反）	【规范修复】：[规范偏差描述]	project-convention-resolver	接收–分类–路由–验证；已知规范的偏差修复（与「立原则」的区别：这里处理已有规范的违反，不是立新规范）	无
D-xx 设计建议（纳入迭代）	【协调者】：评估设计建议：[描述]	role-产品开发协调者	产品/技术层面评估并纳入开发计划	无
D-xx 设计建议（仅存档）	无需激活 Skill，project-backlog 直接写入	—	直接追加到技术架构.md「设计建议存档」节	技术架构.md 已存在

B-xx P0/P1 Bug 的两步流程说明：

P-2-1 生成激活命令时，Bug 条目额外执行两步（在生成【修复循环】命令之前）：
  Step A: Read [PATH_技术追踪台]（默认：技术架构师/技术问题追踪台.md）
  Step B: StrReplace 追加 issue 条目：
          | [日期] | [Bug描述] | P0/P1 | [复现步骤/文件] | 🔲 待修复 |
          （若追踪台不存在则先创建）
然后生成激活命令：【修复循环】

---

激活后：判断操作模式

⚠️ 首先判断触发的是哪种模式

收集模式信号：
  消息含「待办」+「记录/存/先放着」等延迟动词
  「加到项目待办」「先存到待办文档」「记录这些待办」
  含编号列表 + 延迟信号词 → 收集模式

处理模式信号：
  「处理项目待办」「按待办文档逐条」「处理待办文档里的」
  → 处理模式

⚠️ 必须含「待办」关键词才触发本 Skill（防止与 issue-tracker / bug-fix-loop 冲突）
⚠️ 两种模式同时出现（「记到待办然后马上处理」）→ 先完整执行收集（C-0~C-3），再询问是否立即处理
⚠️ 不确定时 → 问用户：「您是要先记录到待办文档，还是立即开始处理？」

---

收集模式（COLLECT）

Step C-0  【确认待办文档路径】
          ① Read: .cursor/project-config.md（若存在）→ 读 PATH_待办
          ② 若无 config → Read: _内部总控/元项目导航.md → 识别当前项目
          ③ 若仍不确定 → 问用户：「当前操作哪个项目？」
          ⚠️ 禁止用 IDE 打开的文件推断项目（ide-context-guard 规则）

          默认路径：项目群/[项目名]/产品经理/项目待办.md
          若文件不存在 → 创建文件，写入标准表头（见上方规范）

Step C-1  【解析输入为结构化条目】
          逐条扫描用户消息中的独立意图：
          对每个独立意图提炼：
            - 摘要：一句话（≤40字，说清「什么东西 + 什么问题」）
            - 类型（参考可用Skill速查表）：
              Bug     = 有明确错误行为（系统报错/功能失效/数据错误）
              Feature = 新功能需求
              UX      = 体验/交互问题（不是 Bug，但影响使用感受）
              原则    = 「以后都要」「这是原则」「系统应该怎样运行」
              规范偏差= 「这不符合规范」「这违反了规范」（已有规范被违反）
              设计建议= 架构思路/技术方向/产品建议（非强制需求）
            - 优先级（仅 Bug 类）：P0=阻塞 / P1=影响核心流 / P2=次要

          ⚠️ 若解析出 0 条独立意图 → 不执行 C-2，输出：
             「未识别到独立条目，请分条列出（如用编号或换行分隔）」→ 等待用户重新输入

          宁多勿少：有疑问时保留条目；重复的意图合并为一条

Step C-2  【追加到待办文档】
          Read: [PATH_待办]（先读，获取当前最大 ID 编号，确认表格完整）
          ⚠️ 若表格格式异常（缺表头/非标准列）→ 告知用户并先修复表头，不追加
          StrReplace 在表格末尾追加新行（每条一行，ID 继续编号）

Step C-3  【确认输出】
          输出格式：
          「✅ 已记录 N 条待办：
          [B-01/P1] 更新认知时显示「正在构建中」
          [P-01]    LLM 调用不截断上下文（原则）
          [B-02/P0] 对话历史消失
          [R-01]    日志截断违反不截断原则（规范偏差）
          [F-01]    实时显示AI思考过程（新功能）
          [D-01]    状态管理按生命周期分层（设计建议）
          ...
          文档路径：[PATH_待办]
          说「处理项目待办」可触发自动处理流程。」

---

处理模式（PROCESS）

Step P-0  【读取待办文档 + 构建执行队列】
          Read: [PATH_待办]（全文读取，不截断；若文件不存在 → 告知「待办文档不存在」→ 停止）
          
          解析所有 🔲 条目（按 | 分隔的表格行）：
          ⚠️ 若解析失败（格式混乱）→ 输出原文片段，告知用户修复格式或重新用收集模式录入
          ⚠️ 若无 🔲 条目 → 告知「当前没有待处理条目」→ 停止

          按以下规则排序（数字小的先执行）：

          第一轴：类型（最高优先）
            1. P-xx 原则类         — 影响所有后续修复方向，必须最先处理
            2. B-xx Bug 类         — 技术问题，按第二轴（架构层）细化排序
            3. U-xx UX / F-xx Feature — 功能/体验问题，按架构层或产品决策排序
            4. D-xx 设计建议       — 最低优先，通常只存档

          第二轴（仅 B-xx Bug 类内部）：架构层（AI 平台项目）
            若条目 ID 含架构层标签（如 [L1]）：
              L1（状态管理）> L2（并发）> L3（LLM调用）> L4（数据隔离）> L5（Agent框架）> FE（前端）
            若无层标签：按 P0 > P1 > P2 排序（传统方式，兜底）

          第三轴（同层内）：AI 确定/不确定
            AI 确定（唯一明确修法）先执行
            AI 不确定（需设计决策）在 P-1 前置决策中收集

          同优先级按 ID 编号顺序

Step P-1  【前置决策收集（Feature/UX/设计建议类）】
          扫描队列，找出需要用户判断的项：
            - F-xx Feature 类：有多种实现方案 → 询问方案选择
            - U-xx UX 类：设计方向不明 → 询问期望体验
            - D-xx 设计建议 → 询问「纳入当前迭代 / 下个迭代 / 仅存档」

          ⚠️ 一次性集中提问，不分散：
          「处理前需确认 N 个决策点：
          [F-01] 实时显示AI思考过程
                 → A: SSE 推送节点状态  B: 前端轮询
          [D-01] 状态管理分层重构
                 → 纳入当前迭代 / 仅存档
          请依次回答（如「A, 存档」）」

          用户回答 → 记录决策到对话上下文 → 进入 P-2
          某条用户说「跳过」或不回答 → 该条标记 ⏸️ 搁置，激活队列中排除
          若全部为 A 类（原则/Bug，无需决策）→ 跳过 P-1 直接进 P-2

Step P-2  【生成激活队列并输出（不自行执行，交由专业 Skill）】

          ⚠️ 核心设计原则：project-backlog 只负责「收集」和「排队」，不执行具体任务。
             每条待办必须由对应的专业 Skill 正式激活后执行，才能保证：
             - D0 认知根读取（产品定义/技术架构等前置文档）
             - 完整的流程门控（关卡/测试/文档同步）
             - 正确的角色视角（后端开发 ≠ 测试工程师 ≠ 产品经理）
          ⚠️ project-backlog 自行执行 = 绕过所有规范 = 等于没有规范

          Step P-2-1  为每条 🔲 条目生成对应的激活命令
                      （⚠️ 必须参照上方「可用 Skill 速查表」，不得凭记忆）：

                      [P-xx 原则类]
                        → 激活命令：「【立原则】：[原则精确描述]」

                      [B-xx P0/P1 Bug]（⚠️ 两步，先写追踪台再生成命令）
                        Step A: Read [PATH_技术追踪台]（不存在则 Write 创建）
                        Step B: StrReplace 追加 issue 行到追踪台
                        → 激活命令：「【修复循环】」
                        （bug-fix-loop-coordinator 会读追踪台，追踪台必须先有条目）

                      [B-xx P2 Bug]
                        → 激活命令：「【记录问题】：[Bug描述]」
                        （issue-tracker 仅写入追踪台，不触发修复）

                      [F-xx Feature]
                        → 激活命令：「【协调者】：[需求描述 + P-1中用户决策]」
                        （role-产品开发协调者 编排完整产品开发流水线）

                      [U-xx UX 问题]
                        → 激活命令：「【协调者】：[UX问题描述 + 用户决策]」
                        （同上，协调者判断走产品修复还是前端/UI修复路线）

                      [R-xx 规范偏差]
                        → 激活命令：「【规范修复】：[规范偏差描述]」
                        （project-convention-resolver 分类路由验证已有规范的违反）

                      [D-xx 设计建议（用户决策：纳入迭代）]
                        → 激活命令：「【协调者】：评估设计建议：[描述]」

                      [D-xx 设计建议（用户决策：仅存档）]
                        → 无需激活其他 Skill
                        → 直接：StrReplace 追加到技术架构.md「设计建议存档」节
                        → 状态直接改为 ✅（已存档）

          Step P-2-2  输出执行计划（仅展示，立即进入 P-2-3 执行）：
                      「📋 开始按优先级逐条执行（N 条）：
                      1. [P-01] 原则 → 激活 engineering-principle-recorder
                      2. [B-01/P0, B-02/P1] Bug → 写入追踪台 → 激活 bug-fix-loop-coordinator
                      3. [F-01] Feature → 激活 role-产品开发协调者
                      ...
                      ⏸️ [D-01] 搁置（等待您决策）
                      ──────────────────」

          Step P-2-3  逐条完整执行（无需用户确认，自动推进）：

                      ⚠️ 「完整执行」的定义（与 v1.0 的「按其步骤执行」本质不同）：
                         Read [目标 SKILL.md]
                         → 切换为对应角色视角
                         → 执行「激活后立即执行」序列中的 EVERY step，包括：
                            · D0 认知根读取（所有 Read 操作，不跳过）
                            · 知识导航表中列出的所有前置文档读取
                            · 每个 Step 的所有工具调用（Write/StrReplace/Shell/浏览器等）
                         → 不简化、不跳步
                         → 与用户直接说「【X】：[内容]」触发的效果完全等同

                      对每条 🔲 条目，按排序顺序：

                      ── P-xx 原则类 ──
                      StrReplace 状态 → 🔄
                      Read: .cursor/skills/engineering-principle-recorder/SKILL.md
                      完整执行其所有 Step（含 Step 0 读元项目导航、Step 1 分类、Step 2-B/C/D 写入、Step 3 报告）
                      完成 → StrReplace 状态 → ✅

                      ── B-xx P0/P1 Bug ──
                      StrReplace 状态 → 🔄
                      Read [PATH_技术追踪台]（不存在则 Write 创建）
                      StrReplace 追加 issue 条目到追踪台
                      Read: .cursor/skills/bug-fix-loop-coordinator/SKILL.md
                      完整执行其所有 Step（含 Step 0 读追踪台、Step 1.5 读产品定义、循环修复等）
                      
                      ⚠️ Bug 修复完成后必须执行关卡C（不等用户，自动推进）：
                      Read: .cursor/skills/role-测试工程师/SKILL.md
                      完整执行其所有 Step（含 D0、Step 0.4 基线建立、五类测试、Step 6.4 覆盖门禁、Step 6.6 写凭证）
                      关卡C通过 → StrReplace 状态 → ✅
                      关卡C发现新 Bug → 写入追踪台 → 继续修复循环（不标 ✅，标 🔄 继续中）

                      ── B-xx P2 Bug ──
                      StrReplace 状态 → 🔄
                      Read: .cursor/skills/issue-tracker/SKILL.md
                      完整执行其所有 Step（澄清现象、分类、写入追踪台）
                      完成 → StrReplace 状态 → ✅（已记录）

                      ── F-xx Feature / U-xx UX ──
                      StrReplace 状态 → 🔄
                      Read: .cursor/skills/role-产品开发协调者/SKILL.md
                      完整执行其所有 Step（含任务类型判断、briefing生成、编排后续角色）
                      完成（协调者完成其briefing输出）→ StrReplace 状态 → 📬 已移交

                      ── R-xx 规范偏差 ──
                      StrReplace 状态 → 🔄
                      Read: .cursor/skills/project-convention-resolver/SKILL.md
                      完整执行其所有 Step（接收-分类-路由-验证）
                      完成 → StrReplace 状态 → ✅

                      ── D-xx 仅存档 ──
                      StrReplace 状态 → 🔄
                      Read: [项目路径]/技术架构师/技术架构.md（若存在）
                      StrReplace 追加到「设计建议存档」节
                      StrReplace 状态 → ✅（已存档）

                      每条完成后输出进度：「✅ [ID] 已完成（N/Total）」→ 继续下一条
                      若某条执行失败 → StrReplace 状态 → ❌（原因）→ 继续下一条，不中止

Step P-3  【所有条目处理完成后的总结报告】
          ⚠️ 此步骤在激活队列全部为非🔲状态时执行

          Read: [PATH_待办]（读取最终状态）
          输出格式：
          「📊 待办处理完成
          ──────────────────────────────────────
          ✅ 已完成：N 条
          📬 已移交：M 条（等待对应 Skill 后续处理）
          ⏸️ 已搁置：K 条（需后续决策）
          ──────────────────────────────────────
          详细记录见：[PATH_待办]」

---

常见失败模式

失败1：触发词「有几个问题」被 A1 产品开发域抢占
  → 根因：消息含「问题/bug」特征被路由到协调者，本 Skill 不被激活
  → 预防：用户需使用含「待办」的触发词；session-bootstrap 排除条件中已加「项目待办/待办文档」

失败2：执行目标 Skill 时走捷径（跳过 D0 读取或知识导航表）
  → 根因：AI 认为「我已经知道这个 Skill 做什么了」，省略了 Read 步骤
  → 预防：P-2-3 明确「完整执行」定义——EVERY step，包括所有 Read 操作；看到跳步立即重新执行

失败3：处理模式中途停止（P-3 未执行）
  → 根因：某条引导过程中断，AI 以为任务结束
  → 预防：P-3 是强制步骤；队列中有 🔲 条目时不能输出 P-3

失败3：Feature 移交后标 ✅（错误）
  → 根因：Feature 设计流程未完成，仅移交给协调者
  → 预防：Feature/UX 移交后标 📬 已移交，不标 ✅

失败4：零条可解析时写入空行
  → 预防：C-1 后若 N=0，不执行 C-2，输出提示请用户分条列出

失败5：内部触发子 Skill 变成伪造用户消息（导致嵌套触发）
  → 根因：AI 发新用户消息包含触发词，再次命中 A1 路由
  → 预防：P-2 明确「内部 dispatch：Read SKILL.md 按其步骤执行，禁止伪造用户触发句」

---

注意事项

• 收集不执行：收集模式只写文档，不触发任何修复或设计流程
• 文档是状态：所有状态写在 项目待办.md，AI 进程中断可从文档恢复
• P2 Bug 只记录：写入追踪台但不修复，控制批次执行范围
• Feature 只移交：Feature/UX 移交协调者后标 📬，等待协调者完整处理
• 触发词必须含「待办」：防止与 issue-tracker / bug-fix-loop 的触发词冲突

---

变更记录

v1.3 — 2026-03-25 — P-2 改为自动逐条完整执行（移除手动确认流程）

根因：v1.1/v1.2 的「输出激活命令 → 等用户复制发送」设计过于保守，用户需要手动 复制粘贴每一条命令，体验极差。用户的正确预期是：一句「处理项目待办」→ 系统自动完整执行。

关键洞察：

• v1.0 的问题是「完整执行」指令不明确，AI 走捷径跳步骤
• 解决方案不是「让用户手动触发每条」，而是「给出足够明确的完整执行指令」
• P-2-3 新增「完整执行」精确定义：EVERY step + 所有 Read 操作 + 所有工具调用 + 不跳步

修改内容：

• 移除 P-2-4/P-2-5（手动确认和逐条引导流程）
• P-2-2 改为展示执行计划（立即开始，无需确认）
• P-2-3 改为「逐条完整执行」，含对每类 Skill 的精确执行指令

备份路径：history/SKILL_v1.0_20260325_before_dispatch-fix.md

---

v1.2 — 2026-03-25 — 可用Skill速查表 + 规范偏差类型 + P-2-1 精确路由

根因：v1.1 的 P-2-1 激活命令映射基于推断，未核实真实 Skill 触发词和处理范围； 缺少规范偏差（R-xx）类型；B-xx Bug 未考虑「需先写追踪台再激活修复循环」的前置步骤。

修改内容：

• 新增：「可用 Skill 速查表」章节（基于读取全部真实 SKILL.md 文件后整理）
• 新增：R-xx 规范偏差类型（→ 【规范修复】/ project-convention-resolver）
• 更新：C-1 类型分类加入「规范偏差」和更准确的类型描述
• 更新：P-2-1 路由为两步流程（B-xx P0/P1 先写追踪台，再生成【修复循环】命令）
• 更新：D-xx 纳入迭代 → 【协调者】（原为【架构师】，协调者才是入口）

数据来源：逐一读取 role-产品开发协调者/issue-tracker/bug-fix-loop-coordinator/ engineering-principle-recorder/role-测试工程师/role-产品经理/role-技术架构师/ role-前端开发/role-后端开发/role-AI工程师/role-DevOps/fixer/project-convention-resolver 的 SKILL.md 原始文件

备份路径：history/SKILL_v1.0_20260325_before_dispatch-fix.md

---

v1.1 — 2026-03-25 — P-2 重构：内部dispatch → 激活队列输出

根因：v1.0 的 P-2「内部 dispatch」= AI 自己模仿 Skill 行为，跳过了 D0 读取、 文档守门、关卡等所有规范步骤，导致任何被「内部调用」的 Skill 实际上没有被真正执行。 Bug 修复没有读产品文档、功能需求没有走关卡、原则录入没有搜索违规——完全不符合规范。

设计原则更新：

• project-backlog 只负责「收集」和「排队」，不执行具体任务
• 所有任务必须通过「激活队列 → 用户显式触发 → A0.5 正式激活对应 Skill」完成
• 这样每个 Skill 都能完整走 D0 读取 + 完整流程步骤

修改内容：

• P-1：保留前置决策收集逻辑
• P-2：完全重写为「生成激活队列 + 输出 + 引导逐条执行」
• P-3：改为「队列全清空后的总结报告」
• 新增失败模式：AI 自行执行而非生成队列

配套说明： 通用设计原则（对所有 Skill 有效）： 「任何 Skill 不应尝试内部执行另一个 Skill，应输出显式激活命令交给 A0.5 处理」

备份路径：history/SKILL_v1.0_20260325_before_dispatch-fix.md

---

v1.0 — 2026-03-24 — 初始创建（关卡A/B 修复后版本）

根因：缺少前置收集层，混合输入被立即路由，意图遗漏且无法积累待办。

关卡A 修复：

• P-1 标题修正为「Feature/UX/设计建议类」（非「B类」）
• P-2「等待完成」改为「Read SKILL.md 按其步骤执行，完成后更新状态」
• Feature/UX 状态改为 📬 已移交（不标 ✅）
• C-1 零条解析时不写文件
• 触发词新增「待办」作为必要关键词，与 issue-tracker 区分

关卡B 修复：

• 触发词改为「处理项目待办/按待办文档逐条」（含「待办」强绑定，与 bug-fix-loop 区分）
• 模式判断段明确「必须含待办关键词才激活」
• P-2 明确「内部 dispatch，禁止伪造用户触发句」
• role-menu + session-bootstrap 已在部署步骤中更新（见下方）

产品定义草稿：.cursor/skills/skill-designer/draft-project-backlog.md Level 3 集成型：依赖 engineering-principle-recorder / bug-fix-loop-coordinator / role-产品开发协调者