D7Day 7 View
Day 1 Day 2 Day 3 Day 4 Day 5 Day 6 Day 7
Hardening

Day 7 加固、演示和验收

Day 7 不再追求新增大功能,而是把 Day 1 到 Day 6 的链路整理成“可演示、可验收、可继续接手”的状态。没有这一层收口,前面做出来的东西很容易停在“只有作者自己懂”的阶段。

上游依赖
Day 1 到 Day 6 的全部核心路径。
当天输出
回归记录、权限边界、审计和 Trace 补齐、测试记录、演示脚本、交接说明。
当天关键
冻结新增需求,只收验收相关缺口。
Three-Layer Mapping

三层文档映射

路线图

周计划要求完成回归、权限补齐、审计补齐、错误态和空态、评测、演示数据、构建和交付说明。

执行细则

执行层拆成核心链路回归、权限和风险边界、审计和 Trace、前端体验修补、测试补齐、评测集、演示数据、演示脚本和文档收尾。

架构依据

主要受整体 README、开发路线图、可观测性和评测集约束。Day 7 的本质是把所有边界和证据讲清楚。

Build Order

推荐收口顺序

Step 1先汇总 Day 1 到 Day 6 未完成项,冻结新增需求。
Step 2回归核心链路:资产、规则、语义解析、Orchestrator、User Agent、Hermes、Trace、AuditLog。
Step 3补权限边界与高风险动作拦截。
Step 4补测试、评测、演示数据和前端体验问题。
Step 5写演示脚本和交接说明,形成最终交付。
Must Deliver

今天必须产出的东西

回归与边界

  • 未审核规则不能上线。
  • 付款、审批、上线等高风险动作都不能绕过确认。
  • disabled 能力不能被调用。

审计与 Trace

  • 规则保存、审核、上线都能看到 AuditLog。
  • Hermes 生成知识候选 / 规则草稿有审计。
  • 任意演示路径都能追到 run_id

测试、评测、演示数据

  • 后端测试、前端构建、语义评测至少有执行记录。
  • 报销 / 应收 / 应付 / 风险 / 知识都准备好演示数据。
  • 失败样例和已知边界要明确写出。

演示脚本与交接

  • 从任务规则中心、规则详情、版本切换、上线拦截,到 User Agent 问答、Hermes 任务、Trace 和审计,都有明确步骤。
  • 新开发者按脚本能走通一遍。
Acceptance Snapshot

最终验收快照

端到端链路
从规则中心到 User Agent,再到 Hermes 和 Trace,至少有一条完整演示路径可复现。
证据完整
AgentRun、ToolCall、AuditLog、测试记录、评测结果和演示脚本都存在。
风险边界
MVP 期间不存在绕过人工审核、自动付款、自动上线的暗门路径。
可交接性
下一位开发或 Codex 打开文档就能知道已完成、未完成和生产化前必补项。
Common Misses

这一天最容易漏掉的点