euthyna 0.1.1 → 0.2.0

package/.agents/skills/euthyna/SKILL.md

@@ -0,0 +1,256 @@
+---
+name: euthyna
+description: 代码安全审计的判定纪律与交付门禁。当用户要求对一段代码、一个 PR、一次变更或一条已有的漏洞结论做安全审查与验证时使用。它做三件事：补上模型算不准的确定性事实（调用方、测试覆盖、git 历史来源），用 6 道门禁判定每条结论真假，拿不出证据的一律降级为「观察」而不是「发现」。不适用于：仅询问某个 CVE 的详情、仅要求跑一次现成扫描器、纯文档或格式化改动、以及用户只要一句快速摘要且明确接受风险时。
+whenToUse: 用户要求审计代码或仓库的安全面、验证一条疑似漏洞结论真假、判定某个发现是否可利用、审查一次变更是否引入安全回归，或要求「审完再交付」时使用。只查密钥、只查依赖版本这类单一主题，直接用对应专项技能，不要触发本技能。
+disable-model-invocation: true
+user-invocable: true
+---
+
+# euthyna — 代码安全审计的判定纪律
+
+> εὔθυνα：雅典官员离任时必须交出账目接受审查，通不过就无法体面离任。
+> 本技能的核心机制即此：**说"审完了"不算数，证据交齐、门禁通过，才算交付。**
+
+**本技能不找 bug，它管住结论。** 找 bug 由模型与现成工具做；本技能负责：
+每条结论必须过门禁，过不了就只能降级为「观察」。
+
+---
+
+## 何时用 / 何时不用
+
+**用**：
+
+- 用户要求审计代码、仓库、一次变更（PR / commit / diff）的安全面
+- 用户拿来一条疑似漏洞，问「这是真的吗」「是否可利用」
+- 用户要求审查某次变更是否把已有的安全防护改弱了
+- 用户要求「验证完再交付」
+
+**不用**（直接拒绝或转其他技能）：
+
+- 只问某个 CVE / 某个依赖的详情 → 用依赖审计类工具
+- 只要求跑一次现成扫描器并贴出结果 → 那是工具调用，不是审计
+- 纯文档、格式化、lint 类改动 → 无安全面
+- 用户明确只要快速摘要并接受风险 → 说明这是「非审计模式」，不套用本技能的裁定格式
+
+---
+
+## 三条不可跳过的规则
+
+这三条是本技能与「让模型仔细点」的全部区别。任何阶段、任何路径都不许跳过。
+
+### 规则 1：可测量的量一律由命令产出，模型只做判读
+
+调用方数量、测试覆盖率、依赖版本、行号、提交哈希——**这些一律不许靠印象回答**。
+模型可以在命令不可用时说「不可测量」，但不许估算后当成事实写进结论。
+
+> 这条来自一次实测翻车：某包在 GitHub 上显示 5+ 人维护，而 npm 的实际权限列表只有 1 人；
+> 另一个每周下载 1.6 亿次的包在某个数据源里显示零下载。**手感估数字必错。**
+
+### 规则 2：证据强制到 `file:line`，禁止占位符
+
+- 每条主张引用具体位置，格式 `path:L123`，有版本时写 `path:L123 (commit abc1234)`
+- 禁用 `probably` / `likely` / `大概是` —— 去追真实代码，追不了就明说追不了
+- 演示代码（PoC）里禁止 `TODO`、`...`、`// 攻击者在这里做某事`
+- **一旦发现 PoC 用了人为绕过**（mock、stub、禁用检查），该 PoC 判定**无效**
+
+### 规则 3：缺数据 ≠ 干净
+
+每个判据只能落到三态：**已评估-干净 / 已评估-标记 / 因某原因不可评估**。
+
+- 一次什么都没测到的运行，产出的是「不可评估」，**不是**「没发现问题」
+- 引用任何「干净」结论之前，先看覆盖表
+- **数字必须逐字引用**，不得重新推导、四舍五入或修饰
+- 没发现不等于背书
+
+---
+
+## 入口决策树
+
+```
+用户给了什么？
+│
+├─ 一条已有的疑似漏洞断言 ──────────► 阶段 C：结论面验证
+│   （「这是真的吗」「可利用吗」）        读 references/verification-gates.md
+│                                       ★ 结论依赖「测过没有」→ 跑 coverage
+│
+├─ 一次变更（PR / diff / commit）────► 阶段 B：变更面审计
+│   （「这个 PR 安全吗」）               读 references/change-audit.md
+│                                       ★ diff 里有删除行 → 先跑 history
+│                                       ★ 要谈测试覆盖   → 先跑 coverage
+│
+├─ 一个仓库 / 依赖面 ────────────────► 阶段 A：依赖面审计
+│   （「依赖有没有问题」）               读 references/dependency-audit.md
+│
+└─ 一个仓库的整体安全审计 ───────────► 阶段 B 为主，A 与 C 作为子步骤
+```
+
+★ = **在动手人工读代码之前**先跑，不是读完之后的补充说明。
+产出器给的确定性事实，决定了人工阅读该往哪里使劲。
+
+**可以做多个阶段，但阶段之间不许互相替代。**
+特别是：**阶段 B 报出的疑似发现，必须逐个走阶段 C 验证**，不许直接写进报告当结论。
+
+---
+
+## 本技能自带的两个确定性测量
+
+调用方、覆盖率、依赖漏洞、密钥这些**不重造**（见文末分工表）。但有两件事没人做、
+且模型自己算不准，所以本技能自带一个零依赖 CLI：
+
+| 测量 | 回答的问题 | 什么时候**必须**跑 |
+|---|---|---|
+| `history` | 这次变更**删掉**的代码来自哪个提交？那个提交是不是安全修复？ | diff 里有删除行时（阶段 B） |
+| `coverage` | 某个符号在测试运行中**到底有没有被调用过**？ | 报告里要说「测过 / 没测过」时（阶段 B / C） |
+
+```powershell
+node <euthyna 仓库>/bin/euthyna.js history  --base <改前版本> --repo <被审计的仓库>
+node <euthyna 仓库>/bin/euthyna.js coverage --coverage <覆盖率文件绝对路径> --symbol <符号名>
+```
+
+⚠️ **`node bin/euthyna.js` 这种相对路径一定失败。** 审计时当前目录是**被审计的项目**，
+不是 euthyna 仓库，会报 `Cannot find module`。要用 euthyna 仓库的路径，
+并把被审计仓库用 `--repo` 显式传进去（`--base` / `--head` 相对它解析）。
+
+**退出码**——`2` 与 `0` 的区别就是这套东西存在的意义：
+
+| 码 | 含义 | 怎么办 |
+|---|---|---|
+| `0` | 已测量，无安全相关发现 | 继续，但**要读「未评估的判据」一节** |
+| `10` | 已测量，存在 `security` 分类的事实 | **提高优先级**，逐条走阶段 C，不要直接当结论 |
+| `1` | 用法错误 | 修命令。这不是测量结果 |
+| **`2`** | **完全无法测量** | **不得当作干净**。换测量方式，或把判据标为「不可评估」 |
+
+命令不可用时（没装、没有检出）：**把判据标为「不可评估」，不要手工估算顶上。**
+
+操作手册（命令、真实输出样例、失效情形）：`references/fact-producers.md`。
+
+---
+
+## 事实契约（测量与判定之间的接口）
+
+本技能定义的是**测量层与判定层之间的接口**：`docs/fact-contract-zh.md`。
+
+要点：
+
+- 契约只装**事实**，不装分数、不装严重性等级、不装修复建议
+- 每条事实必须带**复现命令**或**产出工具+版本**
+- **分数不得用作门禁**（这是从 `dsh-trust-check` 学到的：它的契约明写「不要拿 `score` 或 `band` 做门禁」）
+- `approximate` 的事实**不得参与门禁**
+- **`unknown` 不是「干净」**——三态里最常被误用的就是它
+
+事实的读法（能推出什么、**不能**推出什么）：`references/fact-contract.md`。
+
+---
+
+## 裁定格式
+
+无论走哪条路径，产出必须落到这个形状：
+
+```
+BUG #N TRUE POSITIVE — [一句话描述]
+  门禁全部通过。证据：path:L123 (commit abc1234)
+  复现：<可重跑的命令或 PoC 位置>
+  可利用性：EASY / MEDIUM / HARD
+  影响：具体到资金量 / 被提升的权限 / 被暴露的数据
+
+BUG #N FALSE POSITIVE — [拒绝理由]
+  门禁 N（门禁名）FAIL：<具体证据>
+  例：第 98 行校验保证 packet_size >= 16，故 (packet_size - header_size) >= 8。
+      下溢在数学上不可能。
+
+BUG #N INCONCLUSIVE — [无法判定的原因]
+  门禁 N（门禁名）未评估：<为什么>
+```
+
+**第三态 `inconclusive` 必须存在。**
+Trail of Bits 的原始 fp-check 只有两态，因为它靠 Stop hook 无限强制继续直到补完；
+**DSH 上做不到**（Stop hook 必须自带限流，见 `docs/dsh-stop-gate-zh.md`）。
+所以必须有这个诚实出口——不许把「没查完」写成 `FALSE POSITIVE`。
+
+---
+
+## 门禁的程序化校验（euthyna gate）
+
+上面的格式不是摆设：`euthyna gate <报告文件>` 会机械地逐条核对——
+
+- **TRUE POSITIVE**：证据必须到 `path:L123`、必须有复现命令、必须说明影响、六门禁必须全过；
+- **FALSE POSITIVE**：至少一条门禁 FAIL 且带具体证据；
+- **INCONCLUSIVE**：至少一条门禁未评估，且没有任何 FAIL。
+
+缺证据、缺复现、或门禁与裁定互相矛盾（如 TRUE POSITIVE 却带 FAIL 门禁）的 finding，
+会被**降级为「观察」**并以退出码 `10` 报出——不需要裁定者自觉，校验器替你卡住。
+
+```powershell
+node <euthyna 仓库>/bin/euthyna.js gate <报告文件>
+# 重跑每条复现命令核验（白名单工具、按 argv 执行不走 shell）：
+node <euthyna 仓库>/bin/euthyna.js gate <报告文件> --verify --cwd <被审计仓库>
+```
+
+- 退出码 `0` = 全部通过；`10` = 有 finding 被降级；`2` = 报告无法读取 / 没有可校验的 finding。
+- `--verify` 下复现命令跑不通同样构成降级——「说能复现」不算数，跑通才算。
+
+**报告交出去之前，先过一遍 `euthyna gate`。** 它校验的是报告自己的自我声明，
+不测量目标仓库——因此它不能代替裁定，只能保证「拿不出证据的结论不会以已确证的面貌出去」。
+
+---
+
+## 报告必须落盘
+
+- 只输出到聊天算**失败**。必须写报告文件
+- 文件名：`<PROJECT>_EUTHYNA_AUDIT_<YYYY-MM-DD>.md`
+- 写文件失败的降级顺序：当前工作目录 → 用户桌面 → 临时目录 → **最后手段**才输出到聊天并提示用户手动保存
+
+---
+
+## 交付前的自检（逐条打勾，缺一条不许说「审完了」）
+
+- [ ] 每个疑似发现都走了**完整的**阶段 C，不是「看一眼觉得是假的」
+- [ ] **diff 有删除行时跑过 `history`**；删自安全修复提交的代码已按最高风险处理
+- [ ] 报告里每句「测过 / 没测过」都有 `coverage` 输出支撑，或已标为「不可评估」
+- [ ] **退出码为 `2` 的判据没有出现在「干净」一栏**
+- [ ] 每条结论都带 `file:line`
+- [ ] 每条结论都标了三态之一（干净 / 标记 / 不可评估）
+- [ ] 覆盖表写清了**哪些判据没评估、为什么**
+- [ ] 恶魔代言人 13 问逐条答过（含防假阴性的第 12、13 问）
+- [ ] 报告文件已落盘
+- [ ] 报告已通过 `euthyna gate` 校验（退出码 `0`；有降级要读降级原因）
+- [ ] 没有把「缺数据」写成「干净」
+
+---
+
+## 参考文件
+
+按需加载。**不要一次全读**——渐进披露是这套东西能在长会话里保持有效的原因。
+
+| 文件 | 内容 | 什么时候读 |
+|---|---|---|
+| `references/verification-gates.md` | **阶段 C**：路由、6 门禁、误报清单、恶魔代言人、PoC 规则 | 判定一条已有断言时（**最常用**） |
+| `references/change-audit.md` | **阶段 B**：基线、深度 vs 风险、来源归属、爆炸半径、对抗建模 | 审一次变更时 |
+| `references/dependency-audit.md` | **阶段 A**：清单/锁文件、三态、文体规范、禁止事项 | 审依赖面时 |
+| `references/bug-classes.md` | 9 类缺陷的专项检查与**默认假设方向** | 定了缺陷类别之后 |
+| `references/meta-mechanisms.md` | 六个元机制：让流程不退化成走过场 | **审计开始时读一次** |
+| `references/fact-producers.md` | **操作手册**：两个测量何时跑、命令怎么写、退出码怎么处理、真实输出样例、失效情形 | **跑产出器之前**（阶段 B / C） |
+| `references/fact-contract.md` | 拿到事实之后能推出什么、**以及它不能推出什么** | 读完产出器输出之后 |
+
+> **技能文本自包含**：以上文件都在 `references/` 内，不依赖技能目录之外的路径，
+> 可以整目录复制到任何技能根使用。
+>
+> ⚠️ 但**产出器本身是独立程序，不在技能目录里**。复制技能不会把 CLI 一起带走。
+> 新环境里要单独安装、或提供本项目的一份检出，否则相关判据只能标为「不可评估」——
+> 那也是一个诚实的结果，比手工估算强。见 `references/fact-producers.md` 第一节。
+
+---
+
+## 与既有生态的分工（避免重复劳动）
+
+| 已经有人做的事 | euthyna 怎么做 |
+|---|---|
+| 调用图 / 爆炸半径（`dsh-tool-lens`、`dsh-blast-radius`） | **不重造**，消费其输出 |
+| 覆盖率（`dsh-code-coverage`） | 不重造，消费其输出 |
+| 依赖漏洞（`dsh-dep-vuln-scan` 等） | 不重造，消费其输出 |
+| 密钥扫描（`dsh-code-security`） | 不重造，消费其输出 |
+| 交付门禁机制（`dsh-doublecheck`、`formalswarm`） | 机制可借鉴；euthyna 的门禁内容是**安全专属**的 6 门禁 |
+| 证据生命周期与 PoC 实验室（`dsh-omv`） | 可并存：`dsh-omv` 可作为事实契约的**消费方** |
+
+**euthyna 只补两件没人做的确定性测量**（见 `docs/positioning-zh.md` §7.2）：
+git 安全回归的机械判定，以及「符号 × 真实执行覆盖」的 join。

package/.agents/skills/euthyna/references/bug-classes.md

@@ -0,0 +1,130 @@
+# 缺陷类别专项要求
+
+> 判定一条结论时，**先定类别，再套对应的默认假设**。
+>
+> 因为不同类别下，「什么算可疑」和「什么算误报」是**相反的**。用同一套直觉判所有类别，
+> 必然在某些类别上系统性出错。
+
+---
+
+## 0. 默认假设按类别翻转
+
+这是本文件最重要的一条，也是最反直觉的一条：
+
+| 类别 | 默认假设的方向 |
+|---|---|
+| **内存破坏** | 默认**是误报**。在内存安全语言里几乎总是误报，除非有编译器缺陷或类型系统漏洞 |
+| **逻辑缺陷** | 默认**不是误报**。「逻辑缺陷会通过每一个边界检查」——**不要让干净的静态分析说服你它是误报** |
+| 其余类别 | 逐类见下 |
+
+把这两行搞反，就会在内存破坏上刷出一堆误报，同时在逻辑缺陷上漏掉真漏洞。
+
+---
+
+## 1. 内存破坏
+
+**先做语言核查**：safe Rust、未使用 `unsafe.Pointer`/cgo 的 Go、以及所有托管语言
+（Java / C# / Python / JS）里的内存破坏**几乎总是误报**。先过这一关，能省掉绝大部分工作。
+
+过了语言核查再查：
+
+- 具体破坏了什么（栈 / 堆 / 全局 / 对象）
+- 破坏的大小与偏移**是否攻击者可控**
+- 是有用的原语（任意读、任意写、虚表覆写）还是仅仅崩溃
+- 分配器加固是否在位
+- UAF 的对象生命周期：释放后是否真能再被引用
+- 类型混淆：要给出**类型不匹配的证明**，不是「看起来像」
+
+---
+
+## 2. 逻辑缺陷
+
+**默认假设反过来：不要让「静态分析很干净」说服你这是误报。**
+
+- 对照 **spec / RFC / 设计文档**判，不是只读代码
+- 绘制**全部状态转换**——能否到达开发者未预料的状态？
+- 找出**从未被强制的隐式假设**
+- 认证类缺陷要验证**全部**认证与授权路径，不是主路径
+
+---
+
+## 3. 竞争条件
+
+- 实际竞争窗口是**纳秒还是秒**？两者是完全不同的问题
+- 攻击者能否**扩大窗口**（慢速文件系统、大分配、CPU 争用）
+- 核验线程模型：单线程 / 事件循环 / 多线程，结论完全不同
+- 检查全部同步原语，而不是只看有没有锁
+- 文件系统类要看**符号链接竞争**（TOCTOU 的经典形态）
+
+---
+
+## 4. 整数问题
+
+- 每一点的**精确类型与取值范围**，不是「大概是个整数」
+- 有符号溢出（C/C++ 里是未定义行为）vs 无符号回绕（**有定义**）——不能混为一谈
+- 追踪所有 cast / conversion / promotion
+- **结果是否真的用于危险用途**：分配大小、数组下标、循环边界。用于日志打印的溢出不是漏洞
+- 开启 `-Wconversion`、`-Wsign-compare` 这类检查，让编译器替你找
+
+---
+
+## 5. 加密弱点
+
+- 对照 NIST / IETF 标准与已知攻击检查参数
+- 核验随机源：是不是密码学安全的
+- **nonce 重用要证明实践中确实能发生两次**，不是「理论上可能」
+- 时序侧信道要看两点：攻击者能否触达，以及网络抖动是否让远程攻击不切实际
+- 与参考实现的测试向量对比
+
+---
+
+## 6. 注入
+
+- 追攻击者输入从入口到 sink 的**完整路径**，沿途是否净化、转义
+- 框架的自动转义是否启用，**且未被绕过**
+- XSS 要看上下文：HTML 正文 / 属性 / JS / URL，**各需不同的转义**，一种转义不能覆盖全部
+- 路径穿越要看：访问检查**之前**是否已经规范化
+- 用**真实 payload** 走完所有中间处理，不要在手写的示例里验证
+
+---
+
+## 7. 信息泄露
+
+- **具体泄露什么**：栈泄露（能拿 ASLR 基址或 canary）是严重的；静态字符串毫无价值
+- 泄露的数据对进一步利用**是否真的有用**
+- 未初始化内存要**证明读点确实未初始化**
+- 时序侧信道看测量精度与噪声水平
+- 错误信息**是否真能到达攻击者**——写进日志不算
+
+---
+
+## 8. 拒绝服务
+
+- 资源消耗比与放大倍数**是否有意义**
+- 资源可回收还是永久耗尽——两者严重性差别很大
+- **复杂度主张要证明实际最坏输入能触发**，不要只声称 O(n²)。
+  要指出具体输入、给出实测耗时
+- 崩溃是否**可靠**触发
+- 服务是否自动重启：100 毫秒重启和需要人工介入是两个完全不同的问题
+
+---
+
+## 9. 反序列化
+
+- 攻击者**是否确实控制**到达反序列化点的数据
+- classpath / import 图里**有没有可用的 gadget 链**——
+  **没有 gadget 链，不安全反序列化只是设计异味，不是可利用缺陷**
+- 库与版本，以及该版本已知的链
+- 类型限制 / allowlist 过滤器是否在位
+- 语言特定形态：Java `ObjectInputStream`、Python `pickle`、PHP `unserialize`、.NET `BinaryFormatter`
+
+---
+
+## 用法
+
+1. 在阶段 C 的**第零步**就给断言定类别
+2. 类别决定默认假设的方向（见 §0）
+3. 走数据流与可利用性分析时，**叠加**该类别的专项检查（上表）
+4. 门禁评估时，该类别特有的「什么算阻止」也按上面的定义判
+
+> 类别定错，后面全错。**不确定时明说不确定，不要挑一个像的凑。**

package/.agents/skills/euthyna/references/change-audit.md

@@ -0,0 +1,219 @@
+# 阶段 B：变更面审计
+
+> 审一次变更（PR / commit / diff），回答一个问题：**这次改动有没有让系统变弱？**
+>
+> 前置：`../SKILL.md` 的三条不可跳过规则。
+
+---
+
+## B.0 先建立基线
+
+**这是第一动作，不是准备工作。** 没有基线，后面所有判断都只能靠感觉。
+
+在**变更前**的版本上，把它们记下来：
+
+| 要记的 | 为什么 |
+|---|---|
+| 系统级不变量 | 「什么必须永远为真」——不知道就没法判断这次有没有破坏它 |
+| 信任边界与权限级 | 哪些数据可信、哪些不可信；代码以什么身份运行 |
+| 既有的校验模式 | 这个代码库惯用的校验长什么样，在哪里做 |
+| 关键函数的调用关系 | 改动的影响半径靠它判断 |
+| 状态流 | 数据从哪来、经过什么、到哪去 |
+| **代码本应做什么** | 不是它现在做什么——是它的设计意图 |
+
+漏掉最后一项，就会把「实现与设计不符」误判成「实现有 bug」，或者反过来。
+
+---
+
+## B.1 分清两件事：分析深度 vs 风险等级
+
+这两件事经常被混为一谈，混了就必然出错。
+
+**分析深度**由**改动规模**决定——它只决定你花多少力气：
+
+| 改动规模 | 策略 | 做法 |
+|---|---|---|
+| < 20 个文件 | 深读 | 读完全部相关代码，全量 blame |
+| 20–200 | 聚焦 | 只追一跳依赖，优先高风险文件 |
+| 200+ | 外科 | 只做关键路径 |
+
+**风险等级**由**改了什么**决定——它跟规模**无关**：
+
+| 级别 | 触发条件 |
+|---|---|
+| 高 | 认证、加密、外部调用、资金流转、**任何校验被删除** |
+| 中 | 业务逻辑、状态变更、新增公开接口 |
+| 低 | 注释、测试、界面、日志 |
+
+> **一行改动可以是最高风险，两千行可以是零风险。** 按规模判断风险是最常见的偷懒。
+
+---
+
+## B.2 逐文件读两个版本
+
+对每个变更文件，不要只看 diff。**把改动前后的版本并排读**，然后逐段回答四个问题：
+
+| 问题 | 要说什么 |
+|---|---|
+| 改之前是什么 | 原逻辑 |
+| 改之后是什么 | 新逻辑 |
+| **改动做了什么** | 一句话概括意图 |
+| **安全上意味着什么** | 攻击面变大还是变小？校验变强还是变弱？ |
+
+diff 只显示「哪些行变了」，不显示「行为怎么变了」。删掉一行可能什么都没删（比如那行本来就是死代码），
+加一行可能把整个执行顺序改了。
+
+### 被删掉的代码要额外查来源
+
+**这是本阶段最容易被跳过、也最有价值的一步。**
+
+对每一段被删的代码，用本项目的产出器查它的来源：
+
+```powershell
+node <euthyna 仓库>/bin/euthyna.js history --base <改前版本> --repo <被审计的仓库>
+```
+
+⚠️ **不能写成 `node bin/euthyna.js`**——审计时当前目录是**被审计的项目**，不是 euthyna 仓库，
+相对路径会报 `Cannot find module`。`--repo` 指的是**被审计的仓库**，`--base` 相对它解析。
+
+它会告诉你：这段被删的代码是哪个提交引入的、那个提交的信息里有没有安全关键词。
+**从 `fix` / `CVE` / `security` 提交里删掉的代码，风险默认拉到最高**，除非能证明它是多余的。
+
+不要自己跑 `git blame` 再肉眼读提交信息——那正是本产出器存在的原因，
+机器判定同一个 diff 跑两次结果一致，人读两次可能不一致。
+
+读输出时注意「⚠ 未评估的判据」一节：它非空时，这次运行**不能**读成「查过了没问题」。
+退出码 `2` 表示完全无法测量，**不得当作干净**。命令与退出码详见 `fact-producers.md`。
+
+### 三条红线
+
+| 现象 | 默认处理 |
+|---|---|
+| 被删的代码来自安全修复提交 | 按**最高**风险处理，除非证明它已无必要 |
+| 校验被删除且没有等价替代 | 按**最高**风险处理 |
+| 代码曾经被加进来 → 因安全原因移除 → **现在又被加回来** | 按**回归**处理 |
+
+第三条用产出器可以机械检出：
+
+```powershell
+node <euthyna 仓库>/bin/euthyna.js history --base <改前版本> --pickaxe --repo <被审计的仓库>
+```
+
+---
+
+## B.3 测试覆盖：缺口要升级风险，不是记录一下
+
+**没有测试不是「顺便提一句」的事，它是风险升级的理由。**
+
+| 情况 | 处理 |
+|---|---|
+| 新增函数且无测试 | 中风险升**高** |
+| 修改了校验且测试没跟着变 | **高风险** |
+| 复杂逻辑（> 20 行）且无测试 | **高风险** |
+
+想说出「已覆盖」，必须拿真实执行证据，不能靠「这个文件有测试文件」推断：
+
+```powershell
+node <euthyna 仓库>/bin/euthyna.js coverage --coverage <覆盖率文件绝对路径> --symbol <被改的函数>
+```
+
+没有覆盖率文件时：**要么用项目自己的方式跑一次测试产出它，要么把该判据标为「不可评估」**——
+`coverage` 会以退出码 `2` 明确告诉你「没能测量」，那不是「没被覆盖」。
+
+> ⚠️ 这个产出器**只能证伪，不能证实**。它说「没被调用过」是可信的；
+> 它说「被调用了 N 次」**不能**推出「相关调用点被执行过」。
+> 详见 `fact-contract.md`。
+
+---
+
+## B.4 爆炸半径
+
+统计每个被修改的函数有多少调用方：
+
+| 调用方数量 | 等级 |
+|---|---|
+| 1–5 | 低 |
+| 6–20 | 中 |
+| 21–50 | 高 |
+| 50+ | 极高 |
+
+**优先级由「风险 × 半径」共同决定**：
+
+| | 半径极高 | 半径高/中 | 半径低 |
+|---|---|---|---|
+| **风险高** | P0——深度分析 + 全部依赖 | P1 | P2 |
+| 风险中/低 | P1 | P2 | P3 |
+
+数字要由工具产出，不要目测。可选的上游产出器见 `../SKILL.md` 的生态分工一节。
+
+---
+
+## B.5 高风险变更要做对抗建模
+
+对每个高风险改动，回答：
+
+**1. 攻击者是谁**
+
+| 维度 | 取值 |
+|---|---|
+| WHO | 未认证外部用户 / 已认证普通用户 / 恶意管理员 / 被攻陷的依赖 / 抢跑者 |
+| WHAT | 只能用公开接口 / 需要已认证角色 / 需要特定权限 |
+| WHERE | 具体端点或函数 |
+
+**2. 攻击路径**：入口点 → 具体调用与参数 → 如何到达脆弱代码 → 代码里发生了什么 → 达成什么。
+**必须给出可达性证明**：那个函数确实是公开可达的、攻击者确实有这个权限、路径确实经过真实接口。
+
+**3. 可利用性三档**
+
+| 档 | 条件 |
+|---|---|
+| 易 | 公开接口、无需特殊权限、单次调用 |
+| 中 | 需要特定条件或提升的权限、多步骤 |
+| 难 | 需要特权或罕见条件、需要大量资源 |
+
+**4. 完整利用场景**：起始位置 → 逐步（命令与参数 / 为什么有效 / 系统状态如何变化）→ **具体可测的影响**。
+
+> 影响**禁止**写「可能导致问题」。必须落到确切的数据、具体的权限、确切的量。
+> 写不出来，通常说明你还没追到影响。
+
+**5. 与基线交叉比对**
+
+- 是否违反了 B.0 记下的系统级不变量？
+- 是否跨越或破坏了信任边界？
+- 是否绕过了这个代码库惯用的校验模式？
+- 是否是此前已修复问题的回归？
+
+---
+
+## B.6 报告
+
+**只输出到聊天算失败。** 必须落盘，否则发现会丢失。
+
+报告至少覆盖：
+
+| 章节 | 内容 |
+|---|---|
+| 结论摘要 | 严重性分布 + 总体判断 + 关键指标 |
+| 变更概览 | 改了什么、多大、涉及哪些面 |
+| 发现 | 每条含位置、来源提交、爆炸半径、测试覆盖、历史上下文、攻击场景 |
+| 测试覆盖分析 | 缺口在哪、为什么算缺口 |
+| 爆炸半径分析 | 数字与分级 |
+| 历史上下文 | 删掉的代码来自哪里、是不是安全修复、有没有回归 |
+| 建议 | 分三级：立即阻断 / 上生产前 / 技术债 |
+| 分析方法 | 用了什么策略、**局限是什么**、置信度 |
+| 附录 | 证据 |
+
+> **「局限」一节不是走过场。** 没测什么、为什么没测，必须写清楚——
+> 读者据此判断这份报告的结论能覆盖到哪。
+
+**不适用的场景**（明说，不要硬套）：全新代码（无基线可比）、纯文档改动、格式化/lint、
+提问者明确只要快速摘要并接受风险。
+
+---
+
+## B.7 与阶段 C 的衔接
+
+**本阶段报出的每一条疑似发现，都必须逐个走阶段 C 验证，不许直接当结论写进报告。**
+
+阶段 B 产出的是「疑点」，阶段 C 才产出「裁定」。
+把疑点当结论，就是本项目要解决的那个问题本身。