yibie Check
用证据判断“实现是否满足已经确认的契约”。默认只读，不在检查过程中改代码或重写计划。
独立性声明
开头写明：本次 check 是否由执行 do 的同一上下文完成。
同一上下文时，下面的「权威落点」一项需要正面举证 —— 点名落点、点名地图条目、 说明两者相符 —— 而不是「没看出问题」。选择落点的上下文去审自己选的落点，是在 复核自己的决定；真实事故中的 15 条违例是独立 reviewer 发现的，不是自审发现的。
不强制独立执行：强制会让每个小改动都变贵。这里只是把盲区变成显式的。
固定比较基点
确定一个比较基点。读取变更相关的 .spec-agents/doctrine/docs/WORKFLOW.md、
CONTEXT.md、项目 .spec-agents/state/KERNEL.md、Protocol、Runbook、Lesson 和 AGENTS.md。
只读取与当前意图相关的知识记录，不要加载整个 docs/，也不要只凭 diff
猜意图。
比较基点按路径取：
- SPEC 路径：另读相关
SPEC.md和目标 Slice，契约轴对着它们比。 - 短路径（
plan直接approve）：没有 SPEC 也没有 Slice，契约轴对着plan交出的那句验收比，加上.spec-agents/state/KERNEL.md、Protocol 和AGENTS.md。 不要因为找不到 SPEC 就跳过契约轴，也不要为此创建 Slice。
三条轴在两条路径上都要跑。
三条检查轴
契约
- 目标、边界和 out-of-scope 是否符合 SPEC；
- 项目概念、身份、关系、生命周期和不变量是否符合
.spec-agents/state/KERNEL.md；框架工作流 语义是否符合.spec-agents/doctrine/docs/WORKFLOW.md与CONTEXT.md； - Action Contract 和稳定接口是否符合 Protocol；
- 相关代码实践、Runbook 前置条件和 Lesson 的
applies_when是否满足； - 旧行为是否仍被验证，新行为是否有明确证据。
权威落点。 符合 .spec-agents/state/KERNEL.md 不等于落在对的位置：第二份实现完全符合每一条
概念、身份、关系、生命周期和不变量，它只是多了一个。本体影响必答对它也会答
「否」——它没新增任何概念，那条规则 Kernel 里早就有。所以要单独核：
- 这条规则已经有权威落点了，本次改动是不是在第二个位置又实现了一遍？
- 前端／客户端是不是复制了一份服务端已经强制的规则？
- 派生状态是不是被持久化了两次？
- 切片写了
n/a的话，对着 diff 看它是否属实 —— 这次改动真的没有碰到任何 已有归属的规则吗？arrange只读意图，核不了这一条；check读得到 diff， 这里是唯一能核的地方。
命中任何一条，产出 semantic 发现交回 plan：要么改回权威落点，要么经
plan 修 Kernel 的地图，不允许沉默分叉。允许存在的第二落点必须有同输入等价
测试，见 .spec-agents/doctrine/docs/single-authority.md。
注意单测全绿不构成反证：与实现同层的测试无法证明实现在正确的层，测试和 错误落点是同一个决定的两个结果。
工程
- 测试、类型、错误处理、安全、可访问性和仓库规范；
- 是否存在数据丢失、状态泄漏或未覆盖的调用方；
- 项目自己的
docs/protocols/与编码约定。
在项目自身约定之上，叠加这份 smell 基线。它来自 Fowler 的 Refactoring， 是跨语言跨项目通用的判据，不是本框架发明的规则：
| Smell | 判据与处置 |
|---|---|
| Mysterious Name | 名字讲不清它是什么；改名，改不动就说明设计需要重想 |
| Duplicated Code | 同一段逻辑出现多处；抽出可复用形式 |
| Feature Envy | 一个方法主要在动别的对象的数据；把方法搬过去 |
| Data Clumps | 几个字段总是一起出现；打包成一个类型 |
| Primitive Obsession | 用基本类型冒充领域概念；建立类型 |
| Repeated Switches | 同一组条件分支反复出现；换成多态或映射表 |
| Shotgun Surgery | 一次改动散落到很多文件；把它们合并到一处 |
| Divergent Change | 一个文件为互不相关的原因被反复修改；按职责拆开 |
| Speculative Generality | 为想象中的需求做的抽象；SPEC 没要求就删掉 |
| Message Chains | a.b().c().d() 式的长导航；用一个方法封装 |
| Middle Man | 一个类大部分方法只是转发；直接调真正的目标 |
| Refused Bequest | 子类用不上继承来的大部分东西；改用组合 |
不是每条都对每次改动适用。只报当前 diff 里真实出现的，并给出位置和处置； 不要把这张表当检查清单逐条打勾。
引用完整性
本次改动触及的每一条引用都必须仍能解析：
- 知识记录的
source与verification； - Slice 的
spec_ref、context_ref、evidence_ref； - Markdown 相对链接与散文中引用的文件路径、行号锚点；
- 被移动、重命名、删除或拆分的文件所留下的指向。
明确属于历史记述的引用记为历史，不修补——它在写下时是对的，改掉就是伪造 记录。无法判断是历史还是断裂时，报告给用户，不要自行选择。
这一轴放在 check 而不是 learn，因为断裂大多在 do 段产生；等到 learn
才发现，改动已经铺开。
版本控制比较基点
- In a JJ repository, use
jj status,jj log, andjj diffas the local comparison basis; inspect the current JJ Change and any explicitly named bookmark. - In a Git-only repository, use the existing Git comparison basis without pretending that it has JJ change semantics.
- A check never creates a bookmark, pushes, or initializes JJ.
输出
每个发现包含位置、影响、复现或证据、建议动作、严重度和路由目的地。 四种类型，路由目的地写在类型里，不靠读的人推断：
| 类型 | 含义 | 路由到 |
|---|---|---|
blocker |
违反不变量、数据契约或安全边界 | do |
required |
SPEC/验收未满足 | do |
suggestion |
不影响当前契约的改进 | do |
semantic |
本次改动动了本体，或代码与 Kernel 不一致 | plan |
semantic 只陈述观察到了什么、它关系到 Kernel 的哪一条，然后停。
check 不裁决：它绝不判定是代码错还是 Kernel 陈旧。那是 plan 的事，
在 check 里判掉就绕过了「Kernel 的演化必须经 plan」这道门——而绕过它
正是本体悄悄漂移的方式。
没有发现时明确写出检查基点、运行过的验证和剩余风险。需要改代码时把动作交回
do；semantic 交回 plan；不要在 check 中顺手修复，也不要在 check 中
修改 .spec-agents/state/KERNEL.md。
本体影响（每次必答）
三轴之后，写下这个问题的答案：
本次改动是否新增、改变或废止了概念、身份、关系、生命周期、不变量或 Action Contract？
六类逐一过。特别注意「新增」——引入一个 Kernel 里本来没有的概念不违反 任何不变量，三条检查轴都不会响，这是本体遗漏的主要方式。
答「否」也要写下来。不写不等于没有，只等于没人问过；而没人问过正是当前的
失败模式。答「是」就产出一个 semantic 发现，由 plan 决定 Kernel 是否
修订。
如果 Slice 有可选的 evidence_ref，只判断当前事实是否足以进入
learn；不要填写或修改该字段。
对于 Kernel Bootstrap，额外检查：K1 的每条 enacted 记录都有直接来源，
候选/unknown 没有混入稳定层，且 K1 足以约束当前 Action Contract。发现缺口时
返回 plan 或修订 SPEC，不把猜测写入 Kernel。
完成条件
独立性已声明，三条检查轴都有结论（含权威落点一项），本体影响问题已写下答案（含答「否」的情形），验证命令和
结果可复核，所有 blocker/required 已关闭或记录，semantic 发现已交回
plan，且明确是否可以进入 learn。