用途：这是仓库变更的完成关卡。任何改动了代码、测试、配置、模式或基础设施的任务，在最终回复前都要产出一份自包含 HTML 文件（不依赖 CDN，可从磁盘直接打开），保存到 reports/ 下，文件名用描述性 kebab-case 的 *-changes.html，并把该路径作为主要评审交接物，聊天摘要保持简短。报告不替代代码评审或所属工作流的结论权；若准备报告时发现新的重大缺陷，应停止并交回所属工作流处置与验证，再从解决后的状态重新生成。
主要能力：从 assets/report-template.html 起步（含视觉系统、高亮器、弹窗/跳转 JS 及每个组件的可用示例），复制后替换内容，不要从零重设样式。主页面为 5 分钟阅读：构建了什么、如何契合、风险在哪、需要决定什么；清单、逐文件拆解和协议细节放在点击后的弹窗中。每个统计块和关键论断可点击（data-pop 或 data-goto）。Critical points 加可选 Additional key code 合计最多五个 pre.hl 代码片段，每段唯一来源、不重复。
使用方式：先收集证据——依据 git status、暂存/未暂存 diff 及基线或提交确定精确范围，包含新增/未跟踪文件，不凭记忆推断；阅读变更源码与测试，以及计划/规格、跟踪器和既往评审记录；自行运行项目要求的检查套件并记录真实命令与结果，不报告未复现的检查或数字；提取弹窗数据（变更文件清单与行数增减、测试名、逐文件行数、适用计数）；追踪主行为从入口到副作用，记录兼容性、数据、认证、错误与回滚影响。再分析为两个不合并的部分：Critical findings（按重要性排序，带严重度徽章，必含一条“排查后干净”的条目）与 Critical points（风险集中点而非缺陷，最多五个排序且不重叠）。然后按模板章节顺序构建，最后必须验证渲染：通过 HTTP 提供文件并自行查看截图（浅色全页、深色模式、一个 ?pop= 弹窗、桌面与约 320–360px 窄宽下展开的 critical point），并检查键盘切换 details、◆ 跳转与 #hot-<slug> 锚点、长路径换行、代码滚动、打印展开详情、控制台无错误，之后清理临时文件并停止服务与浏览器。
限制：资料未提供具体安装命令、收费或价格信息；颜色须用 CSS 自定义属性，深色模式在一个 @media (prefers-color-scheme: dark) 块中覆盖，正文不得硬编码十六进制色值；徽章颜色仅表严重度且必须配文字标签；图表单色、直接标值，不用图表库、双轴或彩虹配色；片段内需转义 <、>、&。