评估与审批完整使用¶

评估的目标是发现生成工作流与用户需求、UCAgent 协议和运行环境之间的真实差距，并提供可复核证据。评估报告不是评分作文，finding 数量也不是质量指标。

分项职责¶

工具、Checker、流程和环境静态评估各自只处理自己的责任域。跨域问题可以在最直接的根因域提交，并在影响中说明其他组件，不应四份报告复制同一段文字。运行评估单独检查真实执行是否卡住、返回码和产物行为。

严重程度¶

等级	典型影响
critical	UCAgent 无法启动或无限重试；破坏、错误覆盖正式文件；执行越权命令；错误宣称未完成需求已经完成
high	核心工具或 Checker 不可用；主路径产物错误；配置阶段无法衔接；make check 必然失败
medium	边界输入处理错误、开发维护困难、非主路径文档与实现不一致
low	不影响正确性的可读性、提示或局部体验问题

严重程度必须基于影响和可达性，不能因为规则文字中出现“必须”就全部判为 critical。

证据标准¶

有效证据包含具体文件、符号或字段，以及源码分析、确定性命令返回码或可复现 fixture。只写“看起来不对”“可能有问题”不足以批准修改。评估者提交 finding 前应尝试反证，确认不是可选输入、未来阶段产物、规范化等价路径或旧报告造成的假象。

审批动作¶

批准：允许增量流程在所述范围内修复，并给出验收意图。
拒绝：认为问题不成立或不应修改，说明理由。
暂缓：问题可能成立，但缺少业务决策、资源或合适时机。
删除：移除无效或不再需要的记录，不等同于“已修复”。
新增建议：用户直接提出没有来自评估 Agent 的改进需求。

可以用 CLI 或控制台批量操作。批量批准前确认条目修改边界一致；默认审批理由只是起点，关键业务决策仍应补充。

闭环¶

增量修改结束后，重新运行受影响的评估分项。聚合器保留旧 run，因此需要根据新 run 的 finding 状态判断当前质量。旧 finding 文本仍存在并不表示修复失败，也不能在没有新评估时自动标记已验证。

finding 结构示例¶

{
  "id": "FLOW-REFERENCE-001",
  "severity": "high",
  "title": "阶段引用执行前不存在的文件",
  "expected": "reference_files 只包含开始前存在的具体文件",
  "actual": "第一阶段引用 workflow/output/report.json",
  "evidence": [{"path": "workflow/config.yaml", "location": "stage[0].reference_files"}],
  "recommendation": "修正中心阶段设计并增加未来引用负向回归"
}

id 应在同类问题间稳定，fingerprint 绑定具体内容。evidence 写观察事实，不能混入未经证明的推断。recommendation 要限定修复位置和验收，而不是笼统“优化流程”。

审批前检查¶

确认问题存在、严重程度与影响匹配、建议没有越过用户需求、修改对象和验收明确、是否与其他 finding 同根因。缺少专业判断时选择暂缓并说明需要的用户信息。

批量批准同一种注册缺失或文档同步问题时，每项仍保留独立 source id 和 fingerprint。涉及不同业务决策或互相冲突建议时必须单独审批。

重新评估策略¶

工具修改运行 eval_tools，Checker修改运行 eval_checkers，config/GuideDoc/docs 修改运行 eval_flow，Makefile/setup/依赖修改运行 eval_env。跨域修改运行所有受影响分项；只有真实运行风险才额外执行昂贵 eval_run。