grace-verification

加强对模块和变更的确定性验证。验证状态存储在 `.grace/verification/index.xml` 和已路由的验证文档中。每个持久模块都应有确定性的 `V-M-*` 覆盖，除非已计划明确例外。 1. 阅读相关的 `.grace/graph` 锚点和现有 `V-M-*` 条目。 2. 确定场景、命令、测试文件、所需日志标记和追踪断言。 3. 确保命令具有确定性，并且可从项目根目录或文档记录的工作目录运行。 4. 通过当前变更计划更新或提议 `.grace/verification` 变更。 5. 运行命令，并在回复中记录最新证据。 当验证命令从工作区或软件包目录运行时，向所属的 `V-M-*` 条目添加一个直接子节点 `relative/project/path`。将声明的 `...` 路径保持为相对于项目根目录的路径；CLI 仅使用 `Cwd` 将这些路径与相对于当前工作目录的命令参数进行比较。 当模块健康状态必须证明关联实现代码产生了运行时日志或追踪输出时，使用 ``。对于不需要运行时日志的确定性测试或追踪证据，例如纯函数、类型级模块和核心库，使用 ``。非空标记或追踪断言即可满足模块健康证据要求；只有自编标记需要匹配的运行时输出和 `BLOCK_*` 证据。 在 `MustPassCommand` 和 `ExpectedCommand` 中引用已命名的项目任务（例如 `bun run gate:e2e`），而不是内联的 `;` 链式命令。将完整门禁拆分为粒度更细的已命名任务（`gate:test`、`gate:typecheck`、`gate:build`、`gate:e2e`），这样选择性重跑时只需运行对应任务，超时也能对应一个连贯单元，并且 `grace lint --run-commands` 会为每个门禁步骤分别报告耗时和日志。 不稳定的门禁是验证条目的缺陷，而不是盲目重跑的理由。应根据 `~/.cache/grace/run-commands/` 下每次尝试的日志进行诊断。可通过拆分门禁任务、在任务中添加运行器级重试（例如 Playwright 的 `--retries`），或隔离不稳定场景来修复。静默手动重跑并不能解决问题：grace 会如实记录每次运行，而非确定性验证会削弱断言证据。