3.9 KiB
3.9 KiB
name, description, disable-model-invocation
| name | description | disable-model-invocation |
|---|---|---|
| 审查变更是否合理 | 对真实 git diff 做提交前四维形而上审查（逻辑完整性、一致性、合理性、可行性），产出带 file:line 证据的通过或阻断裁决。取得用户提交授权后、git add/commit 前使用；机械门（skill_harness、run_selected 等）未绿时先跑机械门，不找本技能。 | true |
形而上审查（提交前四维裁决 | 红线 4.2 的执行载体）
唯一目的
在改动进入 Git 历史前，用四维审查回答一个问题：这份 diff 是否与它声称要做的事真正相符。只裁决、不修复——发现问题列证据阻断，修复归作者回合。
消费者
主会话在取得用户明确提交授权后、执行 git add / git commit 前调用本技能，由独立子代理装载执行。审查者不得以改动作者视角自审：作者回合的变更说明是待核对象，不是可信输入。
输入
| 项 | 合同 |
|---|---|
| 真实 diff | git diff（已暂存 + 未暂存）与 git status --short 的原始输出；禁止只读摘要或口头转述 |
| 变更说明 | 作者回合声称改了什么、为什么；用于反向核对，不作为事实源 |
| 触及合同 | diff 中出现的 SoT / 红线 / skills.json / DDL / 门禁文件清单（从 diff 自身提取） |
输出
审查报告（过程记录）落 docs/，结构固定：
verdict:PASS或FAIL——四维全部通过才 PASS，任一维 FAIL 即整体 FAIL；- 四维逐维结论，每条发现带
file:line证据与一句话定性； - FAIL 时给出阻断理由与最小修复方向（不代写修复）。
四维审查方法
1. 逻辑完整性
每个改动是否有完整的入口、路径与失败路径：新增分支的两边是否都处理；删除是否清干净被替代物；声称修复的问题是否真的被修（对照变更说明逐条核）；新约束是否覆盖了全部既有调用方。半成品、孤儿路径、只写一半的合同按此维 FAIL。
2. 一致性
改动与既有事实是否同口径：代码与 SoT / 红线 / 角色合同 / 表映射互为镜像；命名、术语、计数与相邻实现对齐；测试断言与实现行为同一事实；不引入第二套口径或过程措辞进稳定文档。两处说法不同且无裁决声明时按此维 FAIL。
3. 合理性
改动是否最小且必要：只动与目标相关的部分；不为单一调用方叠加无证据抽象；遵循项目已有架构与分层（framework 不碰 muse 业务、权威分层不混）；被删实现确属被替代而非仍被引用。顺手重构、无消费者抽象、越层写按此维 FAIL。
4. 可行性
改动在目标环境是否真的能跑：引用的模块 / 表 / 常量存在；依赖已声明；门禁命令按新文档原样可执行；不依赖未落地的假设。文档写了跑不通的命令、代码引用不存在的符号按此维 FAIL。
执行程序
- 机械上下文：
git diff --stat总览，再逐文件读 hunk；从 diff 提取触及的合同文件并回读相关段落； - 逐维审读：每个 hunk 对四维各过一遍，发现即记
file:line； - 反向核对：变更说明逐条对照 diff——声称的每件事要么有对应 hunk，要么记完整性 FAIL；
- 裁决：四维结论汇总为 verdict，写报告到
docs/，回报主会话。
红线
- 只读审查：不修改任何被审文件，不执行
git add/git commit； - 只运行只读命令（
git diff/git status/ 读文件 / 门禁脚本）；不写库、不调模型、不触发派发； - 证据规则：每条 FAIL 发现必须带
file:line证据；无证据不得判 FAIL，也不得凭风格偏好判 FAIL； - 机械门前置：
skill_harness --strict、相关测试族未绿时不得给出 PASS； - 独立性：审查者发现自己是改动作者时声明局限并建议换手，不静默自审通过。