用途
aligncheck 用于核验一份 AI 产出的文本（总结、ADR/glossary、spec、完成汇报等）相对它依据的源（对话，或已确认的 spec/tickets）是否忠实。主线查需求偏差（意图层）和文本漂移（细节层）；副线标记事实风险（只标记，不取证）。
界限：产物忠实复述源里的事实错误不算偏差，但必须靠事实风险标记指出来。
适用边界：只核文本对文本的忠实度。查事实真伪用 /factcheck，查代码实现用 code-review——这两类不在这里做。
定源与产物
- 用户带了产物文本：按用户给的来；贴了两段时先问清哪段是源、哪段是产物。
- 不带参数：产物 = 最近一次 AI 给的总结/文档/汇报，源 = 它依据的那几轮对话；拿不准先问。
- 没有源做不了忠实度核对：直说并请用户补源；可退而做产物内部自洽检查，但声明那不算忠实度核对。
主线一：需求偏差（意图层）
建需求账本：从源里抽出用户表达的需求、目标、约束、优先级和决定，每条挂原文证据。
逐条对产物找五类：
- 丢失（账本有、产物无）
- 歪曲（程度/范围/条件被改）
- 混入（源里没有的需求，尤其 AI 建议写成用户需求）
- 归因错位（AI 的话写成用户的、轮次安错）
- 抹平（悬而未决/有争议写成一致或已定）
完成标准：账本每条需求在产物里有落点（位置或"未出现"），产物每个需求能指回源；两边过完才算完。
主线二：文本漂移（细节层）
产物逐句对照源：数字、日期、版本、名称、引语、承诺、限定语（可能/尽量/暂时）、顺序、条件。
重点四类：
- 数值漂移（数字/精度/范围变）
- 限定语丢失（可能/暂时/部分被删成确定说法）
- 因果颠倒（顺序改动改了因果）
- 凭空增补（源里没有的细节/例子/结论；产物内部自相矛盾时至少一边是漂移）
完成标准：产物每句新增或改写都能指回源或标漂移，指不回必须标出。
差异落结论
每个差异三件套，缺一不算核完：位置（源哪句 ↔ 产物哪句）、类型（需求偏差/文本漂移及哪一类）、严重度（阻断：会按错行事；重要：影响结论或关键信息；轻微：表述走样无碍）。全部核完才汇报。
副线：事实风险标记（只标记，不取证）
挑出产物里可证伪主张：版本号、价格、日期/时间线、命令或 API 行为、数据统计、兼容性、外部事件；观点、偏好、决定、计划不算。
每条只标不判，不打开外部来源：与源一致 → "忠实，真伪未核验"；与源不一致 → 已在文本漂移处理；明显可疑（违背常识、自相矛盾、源里也含糊）→ 点名提示。
无可证伪主张时明说"本产物无事实主张，事实层面无风险"。
标记止于此，真伪判定留给 /factcheck。
汇报
正常对话，别逐项填空。先一句总判断（忠不忠实、能否采纳）；差异按严重度排，阻断/重要的讲清位置、差在哪、源原文，轻微归并带过；一句事实风险（几条值得 /factcheck 或明确无）；需要改则给最小修正建议。停，等用户确认。
场景重点
- grill-with-docs 后（ADR/glossary vs 对话）：防抹平、(待验证) 标记丢失、AI 推荐写成用户决定。
- to-spec 后（spec vs 对话）：防混入（AI 假设写成需求）。
- implement 后（完成汇报 vs spec）：防丢失/歪曲（声称完成 vs 实际覆盖）。代码本身的实现核对归 code-review，这里只核文字产物；描述与代码对不上时标出，不展开代码审查。
与 /factcheck 分工
这里只对源说话：源怎么说就是什么，不判对错；事实风险只标记不判定、不取证。
判定真伪（取证、给证据）是 /factcheck 的活；被标记的条目用它逐个核。
/factcheck 只认外部事实，不管产物与源是否一致。