sprint-closeout

name	sprint-closeout
description	为当前项目执行迭代收尾——核对已完成需求、按严重程度列出未关闭缺陷、标记低于覆盖率门槛的测试套件，并产出结转报告与下一迭代建议。

何时使用

在每个迭代结束时使用：当用户要求迭代收尾、迭代总结、结转复盘，或 「遗留事项与下一迭代建议」报告时。

输入

• projectId（可选）：缺省取当前选中项目。
• coverageFloor（可选）：覆盖率门槛百分比，缺省 70。

任务清单

先用 manage_todo 创建清单（下面六个步骤一项一条），执行中逐步更新状态。 轮次预算：清单更新必须与该步骤的其他工具调用合并在同一轮发出——不要为 单纯更新清单消耗一整轮（每次 manage_todo 调用都占一轮轮次预算）。收尾前 先把在途条目按实际结果结算（成功标 completed，失败保持 in-progress 并 说明），最后再 clear。

步骤

1. 确认上下文。 调用 list_projects 确认当前项目（缺省取当前选中项）， 再调用 list_sprints 找到进行中 / 即将结束的迭代——不要拿更早迭代里 已完成（Completed）的。记录它的时间窗、已燃尽与承诺的故事点、进度。

2. 拉取数据。 一次性批量调用该项目的 list_requirements、list_bugs 和 list_test_suites。

3. 需求完成核对。 列出状态为 Done 的需求，逐条对照证据（关联缺陷已 关闭、覆盖它的测试套件通过、无未关闭缺陷），确认没有「假完成」。反过来， 标记那些看起来已完成——缺陷已 Fixed、相关套件通过——但仍是 In Progress 的需求，建议与负责人确认后翻转为 Done。所有 In Progress / Todo 的需求连同故事点一并计入结转清单。

4. 未关闭缺陷。 过滤状态为 Open 的缺陷，按严重程度排序： Critical → Major → Minor。列出 ID、标题、严重程度、模块、负责人与 创建日期。单独标注已 Fixed 但未 Closed 的缺陷——结转前需要 回归验证。

5. 测试覆盖。 标记覆盖率低于 coverageFloor（缺省 70%）的套件。 覆盖率达标但仍有失败的套件也要标注（不稳定 / 回归风险），并给出整体 平均覆盖率。

6. 渲染收尾 surface（报告版式；以下结构为固定骨架，每次输出逐项必填， 数据为 0 也要展示对应卡片）： a. 开头一段总结（一段话说清数据口径与总体结论）。 b. 顶部 5 张指标卡：一个 Grid（columns: 'auto'）一排摆开，每格用 Card（或 Stack）包一个 Metric。五张卡的标题与取值固定为—— 「完成需求」value=Done 数/需求总数、change=已完成故事点； 「结转规模」value=结转故事点总数、change=结转需求条数； 「未关闭缺陷」value=Open+Fixed 未关闭总数、change=其中 Critical 个数； 「平均测试覆盖率」value=平均覆盖率、change=门槛值； 「失败测试套件」value=有失败用例的套件数。 配色走 palette 语义（有风险用 rose/amber，正常用 emerald），不写死颜色。 c. 中部三张 Table：需求完成核对表、未关闭缺陷表（按严重程度排序）、 测试覆盖核查表（含门槛结论）。 d. 末尾 2 张卡片：一个 Split（ratio: '1:1'），左卡「结转遗留事项」、 右卡「下一迭代建议」，各用一张带 palette 的 Card。两卡都是事项清单： 左卡每条一行列出结转需求（ID 标题（故事点）· 状态 · 阻塞原因或备注）， 右卡给带序号的建议列表。两卡内部都不要用 Table——Split 半栏宽度 放不下多列表格，会被挤压截断。 聊天里只做一两句解说，不要复述原始数据——surface 才是交付物。

约束

• surface 只是报告：不要修改需求或缺陷的状态。以建议形式给出动作 （例如「建议将 CORE-101 标记为 Done」）。
• 使用当前 Active / 即将结束的迭代；不要审计已 Completed 或 Planned 的迭代。
• 建议要具体且有序：先分诊 Critical 缺陷，验证已 Fixed 未关闭的缺陷， 补齐覆盖率缺口，稳定失败套件，确认接近完成的需求，并按真实速率重新 校准下一迭代的承诺量。