/bl —— 全部产品工作项 → 优先级与排期

把所有相关产品工作项放进同一个比较集合，核对真实状态，形成产品经理可一次决策的排序和排期方案。 默认只读；未获确认不批量修改 Meegle。

输入

• Meegle 中全部相关产品工作项，而不只是当前迭代
• 项目业务目标、阶段目标和关键里程碑
• 现有优先级枚举、状态流转与迭代规则
• 产品、研发、测试 owner 与团队可用容量
• 工作项依赖、截止时间、复杂度、风险和不确定性
• SPEC、分支、commit、MR、测试和发布证据（存在时）

装了飞书项目 CLI 就直接读取；没装就使用用户提供的导出或列表，并在输出开头说明覆盖范围。 无法确认是全量数据时，不得声称完成了全量排序。

工作流

1. 建立覆盖范围

报告查询范围、过滤条件、工作项总数、状态分布、最早与最后更新时间，以及缺失的字段或系统。

2. 归一化工作项

为每个工作项整理：编号、标题、产品目标、状态、优先级、迭代、owner、创建与更新时间、父子关系、 依赖、阻塞、复杂度、截止时间、SPEC / MR / 测试关联。

3. 核对真实状态

Meegle 状态必须与交付证据交叉核对。例如：

• 写着开发中，但没有 SPEC、分支或 commit
• 写着待测试，但没有 MR 或可验证版本
• MR 已合入，工作项仍停在开发中
• 长期阻塞，但没有依赖项、原因或 owner

同时识别重复、失效、范围重叠、过大、信息不完整和长时间不动的工作项。

4. 形成相对优先级

优先使用项目已有的优先级定义；没有定义就报告缺口，不自造精确分数。

比较时至少考虑：

• 业务价值与阶段目标匹配度
• 用户影响范围和证据强度
• 时间紧迫性与延迟成本
• 对其他工作项的解锁作用
• 风险、合规或线上问题影响
• 研发复杂度、团队容量和不确定性

优先级是工作项之间的相对选择，不是给每项单独贴“高”标签。复杂度和技术风险由研发补充， 场景与质量风险由测试补充，产品经理做最终排序。

5. 形成排期方案

按依赖、团队容量、里程碑和在制品上限安排迭代：

• 先排能解锁其他工作的前置项
• 不让同一 owner 在同一时段承担不可并行的工作
• 不为容量未知的团队编造精确日期
• 无法进入近期迭代的项目明确放入 Later / 待定，而不是全部塞进 Next

6. 确认后回写

一次性展示状态修正、优先级和排期建议。产品经理确认具体调整项后，才批量更新 Meegle； 未被确认的项目保持不变。回写后重新读取受影响工作项，核对状态、优先级和迭代是否生效。

输出顺序

1. 数据覆盖范围与缺口
2. 工作项全景表
3. 状态不一致、重复、阻塞和过大项
4. 优先级建议及相对理由
5. 迭代排期、容量与依赖说明
6. 待产品经理确认的批量调整清单
7. 回写结果（仅确认后）

规则

• 默认只读。 未获产品经理明确确认，不修改优先级、状态、迭代或关闭工作项。
• 不只看当前迭代。 排序必须有完整或明确限定的比较集合。
• 不替产品经理做最终排序。 Agent 提供证据、冲突和方案。
• 不重写产品需求。 定义不清或范围过大的工作项返回 /pd。
• 不进入研发实现。 被排入迭代的工作项再运行 /s。
• 不处理产品验收。 已完成项只核对状态与证据，不执行验收。

Red Flags

• 数据只覆盖局部，却声称完成全量治理
• 所有工作项都被排成最高优先级
• 只按提出人级别、创建时间或声音大小排序
• 排期不看依赖、owner 和团队容量
• Meegle 状态与 MR / 代码证据冲突却未指出
• 未经确认批量修改工作项