把「找漏洞」
变成一件可复核的工程

这套技能的反向定义非常硬——它把「什么不算 finding」写在了第一步：

顺着这句话，整套设计都是它的推论。既然要指名主体和资源，就必须先把信任边界画出来；既然要有具体后果，就必须在有界范围内真的跑一次；既然结论要能被别人复算，就必须有一本记录每个格子审到哪一步的账。

选进完整模式后，还要定一个运行画像。画像改变的是广度与冗余，不改变证据门槛——不能因为选了快档就把候选门、执行边界、schema 校验或独立验证砍掉。

另有一种「限定范围运行」：只审指定路径或两个 commit 之间的 diff。它必须把自己呈现为部分覆盖，范围外一律记 out_of_scope，绝不能记成「已覆盖」。

1. 1

   侦察 · Reconnaissance

   并行四个只读 agent，各管一件事：产品与本地可运行性、主体与权限、入口与汇点、本地执行与部署可见性。产出的不是散文，是一份初始账本。本阶段不执行任何目标代码。

   architecture.md · coverage-ledger.json 初版 · run-metadata.json
2. 2

   覆盖化猎杀 · Hunting waves

   按账本单元派猎手，一个猎手只碰自己那几个单元。返回值是一个结构化 JSON：每个单元给 covered / candidate / blocked 之一，附上它读过的路径、做过的检查、以及发现的候选。纯散文的结果没法去重、没法复核，直接不收。

   各单元 checks · candidate 列表 · hardening 备注 · uncovered 提案
3. 每波之后 · 不是阶段，是门

   批评门 · Coverage critic

   每一波猎杀之后，一个全新的、只读的批评者拿账本问四个问题：有没有整块入口没被映射？有没有并行路径没人走？我选进来的攻击类有没有漏配单元？有没有单元在没留下路径和检查的情况下被关掉？它只提覆盖，不提漏洞。

   missing_units · reassign_ids · stop
4. 3

   候选验证 · Candidate validation

   每条去重后的候选交给一个没有猎过它的验证者，任务是「试图反驳它」。可以用猎手的产物作参考，但必须重读每一处被引用的源码，并独立复现任何它能安全复现的决定性检查。

   每条候选 → confirmed / needs_validation / rejected
5. 4

   结构化输出 · Structured output

   父进程把所有判决写进一个 JSON，按指纹排序。三档判决是三个互斥的 schema 分支，字段不许串味——比如 needs_validation 里出现 severity 就是硬错。

   findings.json · 两个校验器 PASS
6. 5

   记录复核 · Independent record verification

   每一条留下来的结论，再交给一个全新的、只读的验证者。它检查的不是猎手的叙述，而是结构化记录本身：路径、行号、条件、观测结果、严重度与影响是否匹配、修复是否只是把信任挪了个位置。

   verified / replace（替换必须再验一次）
7. 6

   中立报告 · Target-neutral report

   只从最终记录派生三份 Markdown。报告里不能出现任何「去打这个端点试试」的指引；needs_validation 不得带严重度；被判 rejected 的候选不得被描述成发现。

   REPORT.md · FINDINGS-DETAIL.md · NEEDS-VALIDATION.md

所以整套目录设计不是「整洁」，而是权限边界。父进程独占全部共享产物；每个子代理只有一个自己的 scratch/ 可写；artifacts/ 虽然挂在 agent 名下，但agent 和目标代码都不许写——只有父进程侧的受信代码能把文件「提升」进去。

「逐字节检查」听起来像洁癖，其实每一条都对着一种具体的伪造手法：

账本的基本单位不是文件、不是函数，而是一个四元组合：入口面 × 信任边界 × 子系统 × 攻击类。每个组合被编码成一个稳定的 coverage_id，规则是「百分号编码后拼起来」——不用 slug、不用小写化、不用行号，因为它必须跨运行时保持同一个身份。

八种状态，一个有意的漏洞

账本里每个单元只允许处在八种状态之一。看起来平平无奇，但它藏了一条很关键的设计：只有 candidate 能携带指纹和未决事实，covered 必须两者都为空。校验器会强制这一点。

改派：旧证据必须归档，不能继承

批评门可以要求重派一个已经关掉的单元。此时旧证据不是删掉，而是整体归档进 attempts：旧的波次、状态、owner、路径、检查、指纹、未决事实，连同批评者给出的理由一起封存。新的尝试从空证据开始，owner 必须是新人。这条规矩针对的是一种很常见的退化：用上一轮的结论给这一轮背书。

最容易搞错的是中间那一档。技能专门写了一句话来钉死它：

所以它不给严重度。不是「不方便给」，是逻辑上不能给：影响还没被证明，任何数字都是编的。它也不能是「暂时想不明白先放这儿」的停车场——每条 blocker 必须是决定性的，且必须已经在源码与本地能力内试过、确实取不到。

严重度锚点

严重度只在 confirmed 上出现，且整体严重度不得超过已演示的影响。判断 high 与 medium 的分界线只有一句：

分界线可以压缩成一句问话：你演示出来的结果，是完全击穿了这个控制，还是只是削弱了它？说不清具体损害，就该往下调一档。

修复只要一个「最小有效改动」

每条 confirmed 都要指出「代码必须维持的那条不变式」，以及在最后一个受信决策点上强制它的最窄改动。这里有一条隐含的否决线：如果建议的修复只是把信任挪了个位置（比如把检查从服务端挪到界面、从这个函数挪到那个函数），那它反过来说明——原来提的可能只是纵深防御缺口，不是边界失效。这次实战里有两条候选就是因此被判 rejected。

规则不是「尽量换人」，而是三条硬约束：

• 猎手不能验证自己的候选。验证者可以读猎手的产物，但必须自己重读每一处被引用的源码——因为「引用的行号对吗」本身就是最常见的第一类错误。
• Phase 3 与 Phase 5 不能合并（除 quick 画像）。一个检查「这条路径成立吗」，一个检查「这条记录写得对吗」。同一双眼睛看两遍，第二遍会继承第一遍的盲区。
• 物质性替换必须再过一手。如果 Phase 5 的复核者不只是改措辞，而是升级判决、改根因、改 trace、改执行输入或观测结果、改影响或严重度，那么这个替换不许直接应用——要交给第四位，没猎过、没做过 Phase 3、也没提出这个替换的人，重读源码并独立复现。

本轮实战里，这条规则真的触发了一次，也是整场最值得记录的一段（见 下篇第 8 节）：Phase 3 把「SDK 附令牌的行为源码不可见」写成了 blocker；Phase 5 的复核者去读源码，发现那份 SDK 就躺在仓库的 node_modules 里，行为完全可离线判定。于是它返回 replace；按规矩，这个替换不能当场生效，必须交给第四位独立验证者再确认一遍。

要跑目标代码，必须同时具备四个控制。注意是「同时」——不是「尽量」：

• 01无外网：需要本地客户端/服务端对话时，只给一个隔离的回环命名空间。
• 02空环境：从白名单显式构造，scratch 内自带 HOME、临时目录与缓存，绝不继承宿主环境变量。
• 03只读目标与工具链：目标受控进程只能写自己那份 scratch/。
• 04显式低资源与墙钟上限：CPU、内存、进程数、文件大小、磁盘、时间。

任何一项无法强制，结论都一样：不要执行，把缺失的能力写成 blocker，走 needs_validation。这条不是纸面规则——这次在 macOS 上实测，四项里三项直接落空：

这里有个容易被误解的推论：沙箱缺件不等于放弃候选。源码路径依然成立，只是「结果」还证明不了——所以它不是被删掉，而是从 confirmed 降级成 needs_validation，并附上一份不会给目标环境添麻烦的验证方案。这次三条待验证线索，就是这么来的。

因为结论是 JSON，所以它可以被机器检查。技能自带两个校验器，在 Phase 4 之后、Phase 6 之前各跑一次，报错必须清零才能继续。

但要有清醒的认识，技能自己就说了：

它不证明代码安全，不证明没有遗漏，也不证明报告好读。它只保证一件事：结论和覆盖声明之间没有自相矛盾。剩下的事，靠批评门、独立验证和人来判断。

顺便说，这也是为什么整套流程有两个互斥的终态——要么报告三件套写完且两个校验器都过，要么明确写 run_status: incomplete 加一条精确原因。不允许「差不多跑完了就停」。中途停下不算收尾，只能算中断。

research-share 是一个 Node ESM 项目：用 node:http 自己做 SSR，数据放在 Postgres，授权靠 RLS 加 SECURITY DEFINER 函数。它的架构基线写得很清楚——db/03 的文件头直白地说：应用层可以被绕过，数据库层不能。

这句话决定了整个审计的重心。因为一旦「授权只在库侧」，那就必须回答一个问题：是不是所有写路径都真的走到了库侧的判定？

格子不是凭空播种的。侦察阶段按「入口面 × 边界 × 子系统 × 攻击类」穷举，之后每一波都要过批评门。这次四道批评门抓到的缺口，全都是真的会漏东西的那种：

也有一次偏差值得记下来。第 1 道批评门提出一个标识符 drawF，父进程查证时没找到，判为工具假阴性并换成了真实导出名 window.AnDash（assets/analytics.js:622）。到 final-clean 时才发现：drawF 确实存在（:417），只是被同一文件里已经接受的 AnDash 覆盖住了，所以覆盖没有丢。

这两条被推翻，说明上游对它们的具体反驳是有效的。而下面这一段，是反过来发生的：上游写下的一个前提被推翻了。

N3 这条线索的结论是「结论待定」，如果到此为止，它只是一条普通的待验证记录。真正有意思的是它被返工的过程。

1. 1

   Phase 3 的验证者写下 blocker 3

   「workbuddy-cloud-sdk 的令牌附着行为源码不可见」，因此在本地无法判定浏览器写请求到底带不带用户身份。

2. 2

   Phase 5 的复核者不同意，并给出了行号

   它去读了 node_modules/@tencent-ai/workbuddy-cloud-sdk/lib/index.js:81-96：createCloudFetch 恒设发布键头，且当请求没有 Authorization 时会取 access token 并以 Bearer 附上；:8249-8251 把 database 装配成带同一取令牌函数的 fetch。浏览器侧还有一份同源孪生 assets/vendor/workbuddy-cloud-sdk.global.js，由 admin.html 引入，语义逐字等价。于是它返回 replace。

3. 3

   父进程独立复核同一处源码

   不带立场地把那段打印出来对照，确认 Phase 5 说得对：这份 SDK 就在仓库里，行为可以离线判定。

4. 4

   但按规则，不能直接应用

   这不是改措辞——它改变了一条决定性 blocker 的成立与否，属于物质性改动。规则要求：交给第四位，既没猎过、没做过 Phase 3、也没提出这个替换的人。

5. 5

   第四位验证者重读源码，返回 verified

   它独立复现了那条结论，没有引用前两位的结论作为依据。

6. 6

   应用 → 重跑两个校验器 → 收窄 blocker

   blocker 3 从「SDK 行为不可见」收窄为「服务端边缘如何把 JWT 声明映射成 authenticated / anon 角色」。这才是真正本地取不到的那件事。

同一轮还顺手改掉了 4 处非物质错误，它们不改变判决、根因、trace 或影响，所以允许直接应用：批量请求的载荷补上漏掉的第二条 item；两处测试文件名写错（test/track.test.js → test/track-handler.test.js，后者才是那条 seam 所在，两个文件都存在所以证据本身不变）；CSV 载荷长度从含混的「约 50 字符」精确成 49（evil.example）与 52（example.invalid）。每次改完都重跑两个校验器，全部 PASS。

1. confirmed 全部来自离线证据。源码 + 纯函数 harness + 仓库自带测试；没有任何一条依赖对部署环境的探测。这既是优点（可复算）也是限制（库侧真实行为未验证）。
2. 需要本地 Postgres 的判断没做。N3 与那个 blocked 单元的写放大量化，都卡在这里，已按 needs_validation / blocked 记录并给出 owner 侧只读观测方案。
3. 需要真实浏览器、真实电子表格的判断没做。N1 与 N2 的观测方案都设计成 owner 在自己机器上用 dummy 数据完成，不含任何发往部署环境的审计流量。
4. 全量 IPv4 反演没跑。实测外推 0.52 核小时后按纪律停止，只用 /24 内的最小枚举证明「可反演」这件事本身。

最常见的四种误用

产物与文件索引

本页是上述产物与运行过程的二次叙述，不是审计结论本身。任何判决、严重度、blocker 的权威来源都是 findings.json；如果两者不一致，以 JSON 为准。页面为单文件、零外部依赖，可离线打开。