| name | sprint-closeout |
| description | 为当前项目执行迭代收尾——核对已完成需求、按严重程度列出未关闭缺陷、标记低于覆盖率门槛的测试套件，并产出结转报告与下一迭代建议。 |
何时使用
在每个迭代结束时使用：当用户要求迭代收尾、迭代总结、结转复盘，或
「遗留事项与下一迭代建议」报告时。
输入
projectId（可选）：缺省取当前选中项目。coverageFloor（可选）：覆盖率门槛百分比，缺省 70。
任务清单
先用 manage_todo 创建清单（下面六个步骤一项一条），执行中逐步更新状态。
轮次预算：清单更新必须与该步骤的其他工具调用合并在同一轮发出——不要为
单纯更新清单消耗一整轮（每次 manage_todo 调用都占一轮轮次预算）。收尾前
先把在途条目按实际结果结算（成功标 completed，失败保持 in-progress 并
说明），最后再 clear。
步骤
-
确认上下文。 调用 list_projects 确认当前项目（缺省取当前选中项），
再调用 list_sprints 找到进行中 / 即将结束的迭代——不要拿更早迭代里
已完成（Completed）的。记录它的时间窗、已燃尽与承诺的故事点、进度。
-
拉取数据。 一次性批量调用该项目的 list_requirements、list_bugs
和 list_test_suites。
-
需求完成核对。 列出状态为 Done 的需求，逐条对照证据（关联缺陷已
关闭、覆盖它的测试套件通过、无未关闭缺陷），确认没有「假完成」。反过来，
标记那些看起来已完成——缺陷已 Fixed、相关套件通过——但仍是
In Progress 的需求，建议与负责人确认后翻转为 Done。所有
In Progress / Todo 的需求连同故事点一并计入结转清单。
-
未关闭缺陷。 过滤状态为 Open 的缺陷，按严重程度排序：
Critical → Major → Minor。列出 ID、标题、严重程度、模块、负责人与
创建日期。单独标注已 Fixed 但未 Closed 的缺陷——结转前需要
回归验证。
-
测试覆盖。 标记覆盖率低于 coverageFloor（缺省 70%）的套件。
覆盖率达标但仍有失败的套件也要标注（不稳定 / 回归风险），并给出整体
平均覆盖率。
-
渲染收尾 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 未关闭的缺陷，
补齐覆盖率缺口，稳定失败套件，确认接近完成的需求，并按真实速率重新
校准下一迭代的承诺量。
