rigorous-review

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

/rigorous-review

Investigate a codebase for security, performance, correctness, and refactoring improvements under one hard constraint: no observable change to any outward-facing page or API. Rendered HTML of public routes, URL structure, JSON response shapes, auth flows, and admin UI behavior must all be byte-for-byte equivalent for legitimate callers after any fix.

The deliverable is a report. Fixes are applied only when the user asks, and only the ones classified

safe

在一个严格约束下调查代码库的安全、性能、正确性和重构改进空间：不得对任何对外页面或API产生可观测的变化。修复完成后，对于合法调用者而言，公开路由的渲染HTML、URL结构、JSON响应格式、认证流程以及管理UI行为必须与修复前完全一致（字节级等价）。

交付成果为一份报告。仅当用户要求时才会应用修复，且仅应用被归类为

safe

的修复方案。

Core principles

核心原则

Verify before reporting. Every finding is read end to end (route → helper → query; for security, trace the data from its entry point to the dangerous sink) and cited with
```
file:line
```
+ a code quote. Lead the evidence with the observable consequence — what a user, attacker, or operator experiences — not the code structure. No findings from names or assumptions.
Two scoring axes, then a gate. Every finding carries a severity (P0–P3, impact) and a confidence (0/25/50/75/100, how sure you are). They are independent — a real exploit you can only half-prove is P0 × 50, not a P2. The gate (below) decides what surfaces. This is the single biggest signal-to-noise lever in the skill.
Suppress predictable false positives. A noisy audit gets ignored. Before emitting any finding, check it against the do-NOT-flag lists and settled-precedents table (references/scoring-gating-validation.md). "Already handled by middleware / the framework / a parallel handler" is the most common miss — check callers before flagging.
Safe vs. gated is load-bearing. It protects the "no outward-facing change" guarantee.
- ```
safe
```
  — behavior-preserving for legitimate callers; no schema change, no infra. Authorization fixes are
  safe
  : rejecting an unauthorized caller is the intent, not a regression. Same for a guard legitimate callers already satisfy.
- ```
gated
```
  — any risk of observable change, a schema/migration change, a data-semantics change, or new infra. Report-only; never apply silently.
Production is read-only. No migrations, no
```
drizzle-kit push
```
, no script runs against prod, no destructive commands. Schema/index recommendations go in the report only.
Surgical. Don't "improve" adjacent code, comments, or formatting beyond a fix.

先验证再报告。每个发现的问题都要从头到尾完整追踪（路由→辅助函数→查询；对于安全问题，必须追踪数据从入口点到危险输出点的路径），并标注
```
文件:行号
```
+代码引用。证据需以可观测的后果开头——即用户、攻击者或运维人员会遇到的情况，而非代码结构。不得仅凭名称或假设得出结论。
双维度评分+准入机制。每个问题都带有严重性（P0–P3，影响程度）和置信度（0/25/50/75/100，确认程度）。二者相互独立——一个只能部分证明的真实漏洞是P0 × 50，而非P2。准入机制（下文详述）决定哪些问题会被纳入报告。这是提升审计信噪比的关键手段。
抑制可预测的误报。噪音过多的审计报告会被忽略。在输出任何问题之前，需对照禁止标记列表和既定先例表（references/scoring-gating-validation.md）进行检查。最常见的误报是“已由中间件/框架/并行处理器处理”——标记前务必检查调用方。
安全型与gated型的分类至关重要。这是保障“无对外行为变化”约束的核心。
- ```
safe
```
  ——对合法调用者而言不改变行为；无架构变更，无需基础设施调整。授权修复属于
  safe
  类型：拒绝未授权调用者是预期行为，而非回归问题。合法调用者已满足的防护措施也属于此类。
- ```
gated
```
  ——存在任何可观测变化的风险，涉及架构/迁移变更、数据语义变更或需要新基础设施。仅作报告，绝不静默应用。
生产环境只读。不得执行迁移、
```
drizzle-kit push
```
、针对生产环境的脚本运行或破坏性命令。架构/索引建议仅纳入报告。
精准修复。除修复目标问题外，不得“改进”相邻代码、注释或格式。

The gate (how severity × confidence decides what surfaces)

准入机制（严重性×置信度如何决定问题是否纳入报告）

Apply after synthesis, before the report:

Suppress anything below confidence 75 — except a P0 at confidence ≥50 survives (critical-but-uncertain must never be silently dropped; it goes to the validator wave).
Per-lane asymmetry — the cost of a miss differs by lane, so the bar does too:
- Security: lower bar. A security finding at confidence 50 is typically filed P0 so it survives the gate. Missing a real vuln costs more than a false alarm.
- Performance: higher bar. Suppress speculative/premature-optimization findings rather than routing them through 50. A false perf finding wastes engineering time.
- Correctness and refactoring use the standard bar.
Effort dial (
```
--effort
```
, default
```
medium
```
):
```
low
```
/
```
medium
```
report high-confidence only (≥75) — fewer, surer findings.
```
high
```
/
```
max
```
widen recall (surface gated-50s for triage, run the validator wave on more findings). Match depth to the request.

Full anchor definitions, the dedup fingerprint, agreement promotion, the validator-wave protocol, and the precedents table: references/scoring-gating-validation.md.

在合成结果之后、生成报告之前应用：

置信度低于75的问题一律抑制——除非置信度≥50的P0问题保留（关键但不确定的问题绝不能被静默忽略；需进入验证环节）。
分领域差异化标准——不同领域的漏报成本不同，因此准入门槛也不同：
- 安全领域：门槛更低。置信度为50的安全问题通常被标记为P0以通过准入。漏报真实漏洞的成本远高于误报。
- 性能领域：门槛更高。抑制推测性/过早优化的问题，而非将其纳入置信度50的范畴。误报的性能问题会浪费工程时间。
- 正确性和重构领域使用标准门槛。
工作量调节参数（
```
--effort
```
，默认
```
medium
```
）：
```
low
```
/
```
medium
```
模式仅报告高置信度问题（≥75）——数量更少，结论更确定。
```
high
```
/
```
max
```
模式扩大召回范围（将置信度50的gated型问题纳入分类，对更多问题执行验证环节）。根据请求调整审计深度。

完整的锚点定义、去重指纹、共识提升规则、验证环节协议以及先例表：references/scoring-gating-validation.md。

Procedure

流程

Phase 0: Orient (cheap, before fan-out)

阶段0：定位（低成本，在并行审查前执行）

Identify the stack and the authorization model. Critically: is there a
middleware.ts
/ central auth layer, or does each route/action guard itself? State the answer up front — it changes how the security pass reads every endpoint. (
```
grep -r "middleware"
```
at the app root; check the framework's auth entry points.)
Inventory the surface: public routes, admin routes, API routes, server actions/RPC, and DB-touching scripts. A read-only
```
Explore
```
agent is good for this. Produce a finding for any surface element with no corresponding guard (the attack-surface-inventory rule).
Note project invariants from
```
CLAUDE.md
```
/
```
AGENTS.md
```
(tenancy scoping, PII rules, money/ units conventions). Pass these verbatim to reviewers as "violating this is a P0."
Pick the effort level (default
```
medium
```
) and assign model tiers: the security and correctness reviewers inherit the session model (high-stakes, miss-cost high); the performance and refactoring reviewers may run a mid-tier model (~3–4× cheaper, no quality loss on lower-stakes lanes). State the assignment.

识别技术栈和授权模型。关键问题：**是否存在
```
middleware.ts
```
/集中式授权层，还是每个路由/操作自行防护？**需在报告开头明确说明——这会改变安全审查环节对每个端点的审查方式。（在应用根目录执行
```
grep -r "middleware"
```
；检查框架的认证入口点。）
梳理对外暴露的资源：公开路由、管理路由、API路由、服务器操作/RPC以及涉及数据库的脚本。可使用只读
```
Explore
```
Agent完成此项工作。对于任何无对应防护措施的暴露资源，需生成问题报告（攻击面清单规则）。
记录
```
CLAUDE.md
```
/
```
AGENTS.md
```
中的项目不变量（租户范围、PII规则、金额/单位约定）。将这些内容直接传递给审查人员，注明“违反此项为P0问题”。
选择工作量级别（默认
```
medium
```
）并分配模型层级：安全和正确性审查人员使用会话模型（高风险，漏报成本高）；性能和重构审查人员可使用中端模型（成本低约3–4倍，低风险领域无质量损失）。需明确说明分配情况。

Phase 1: Fan out four parallel reviewers

阶段1：启动四个并行审查器

Dispatch four

Agent

s in one message (

run_in_background: true

), each READ-ONLY, each told to: verify every finding against the full code path, score it on both axes, classify

safe

gated

, and apply its lane's do-NOT-flag list before emitting. Each returns findings (

id

, severity, confidence, title,

file:line

, evidence quote + observable consequence, fix sketch, class, lane) plus a short inventory with a one-word verdict per item.

The four lanes, with full checklists in references/reviewer-lanes.md:

Security (session model; lower bar) — authorization on every mutation and admin read (session check and tenant/ownership check against the target resource); server actions/RPC audited as real endpoints; mandatory secrets scan of git-tracked files; taint-trace untrusted input to sinks; SSRF, insecure deserialization, CSRF, dangerous sinks (
```
dangerouslySetInnerHTML
```
,
```
exec
```
interpolation,
```
eval
```
/
```
new Function
```
); map each finding to OWASP Top 10:2025 + CWE.
Performance (mid-tier; higher bar) — query count per render (N+1, sequential awaits →
```
Promise.all
```
/join — confirm the loop is real first); missing indexes (
```
gated
```
); over-fetching; Core Web Vitals (LCP/INP/CLS, image/font, barrel imports, RSC serialization); serverless traps (in-process caches broken across invocations, ephemeral FS writes, unauthenticated cron). Project impact at 10×/100×/1000× data volume.
Correctness (session model; standard bar) — off-by-one and boundary/pagination (exact-multiple-of-page-size); null/undefined propagating to
```
"undefined"
```
/
```
NaN
```
; error-masking fallbacks (empty array instead of propagating a failed query); TOCTOU and half-updated state; race conditions.
Refactoring (mid-tier; standard bar) — dead code proven with real tooling (
```
knip
```
/
```
ts-prune
```
/
```
ruff F401
```
/
```
ast-grep
```
, accounting for barrel files, dynamic
```
import()
```
, framework exports — not bare grep); drift-prone duplication (P1 if the copies already disagree); Fowler 5-family smell taxonomy; the Deletion Test and two-adapter seam rule (don't recommend a single-use abstraction); TS type-safety (
```
noUncheckedIndexedAccess
```
, Result-vs-throw, discriminated unions). Deletion recs are
```
gated
```
.

Plus an API-contract check that guards the core invariant directly (additive-vs-mutative, silent-semantics-change like "

count

used to include deleted rows, now it doesn't"): references/behavior-preservation.md.

在一条消息中调度四个

Agent

（

run_in_background: true

），每个均为只读，要求：验证每个问题的完整代码路径，从两个维度评分，分类为

safe

gated

，并在输出前应用对应领域的禁止标记列表。每个Agent返回问题列表（

id

、严重性、置信度、标题、

文件:行号

、证据引用+可观测后果、修复方案草图、分类、领域），以及一份简短清单，对每个项目给出一个词的结论。

四个领域的完整检查清单见**references/reviewer-lanes.md**：

安全领域（会话模型；门槛更低）——每个变更操作和管理端读取操作的授权验证（会话检查以及针对目标资源的租户/所有权检查）；服务器操作/RPC作为真实端点审计；必须扫描git追踪文件中的密钥；追踪不可信输入到危险输出点的路径；SSRF、不安全反序列化、CSRF、危险输出点（
```
dangerouslySetInnerHTML
```
、
```
exec
```
插值、
```
eval
```
/
```
new Function
```
）；将每个问题映射到OWASP Top 10:2025 + CWE。
性能领域（中端模型；门槛更高）——每次渲染的查询次数（N+1问题、顺序等待→
```
Promise.all
```
/合并——需先确认循环真实存在）；缺失的索引（
```
gated
```
型）；过度获取数据；Core Web Vitals（LCP/INP/CLS、图片/字体、桶导入、RSC序列化）；无服务器陷阱（跨调用失效的进程内缓存、临时文件系统写入、未认证的定时任务）。评估数据量扩大10倍/100倍/1000倍时的项目影响。
正确性领域（会话模型；标准门槛）——边界错误和分页问题（页面大小的精确倍数）；null/undefined传播为
```
"undefined"
```
/
```
NaN
```
；错误屏蔽回退（返回空数组而非传播查询失败）；TOCTOU（时间检查到时间使用）和状态半更新问题；竞态条件。
重构领域（中端模型；标准门槛）——经真实工具验证的死代码（
```
knip
```
/
```
ts-prune
```
/
```
ruff F401
```
/
```
ast-grep
```
，需考虑桶文件、动态
```
import()
```
、框架导出——不能仅依赖grep）；易漂移的重复代码（若副本已不一致则为P1问题）；Fowler 5类代码异味分类；删除测试和双适配器接缝规则（不建议单一用途的抽象）；TS类型安全（
```
noUncheckedIndexedAccess
```
、Result vs 抛出异常、区分联合类型）。删除建议属于
```
gated
```
型。

此外还有API契约检查，直接保障核心不变量（新增vs变更、静默语义变更，例如“

count

过去包含已删除行，现在不包含”）：references/behavior-preservation.md。

Phase 2: Synthesize (dedup + promote + gate)

阶段2：合成（去重+提升置信度+准入）

Do not just concatenate the four outputs. In order:

Dedup by fingerprint
```
normalize(file) + line_bucket(line, ±3) + normalize(title)
```
— the same bug flagged by two lanes is one finding, not two.
Agreement promotion — when 2+ lanes flag the same fingerprint, raise its confidence one step (50→75, 75→100). Independent corroboration is evidence.
Apply the gate (above): drop sub-75 except P0-at-50; honor per-lane asymmetry and the effort dial. Weak P2/P3 survivors go to a
```
residual risks
```
/
```
advisory
```
tier in the report, not the main tables.

不要简单拼接四个输出结果，需按以下步骤执行：

去重：通过指纹
```
normalize(file) + line_bucket(line, ±3) + normalize(title)
```
识别重复问题——同一bug被两个领域标记时，应合并为一个问题，而非两个。
共识提升——当2个及以上领域标记同一指纹的问题时，将其置信度提升一级（50→75，75→100）。独立佐证是有效的证据。
应用准入机制（上文所述）：移除置信度低于75的问题，除非是置信度≥50的P0问题；遵循分领域差异化标准和工作量调节参数。较弱的P2/P3问题将被纳入报告的“剩余风险”/“建议”部分，而非主表格。

Phase 3: Independent validator wave (replaces self-recheck)

阶段3：独立验证环节（替代自我复查）

Do not re-verify your own synthesis — the orchestrator that merged the findings is not an independent second opinion (it catches a wrong fact but not its own bias). Instead, for every surviving P0 and P1, spawn a fresh validator

Agent

with no commitment to the finding ("False positives are common; do not feel pressure to confirm"). One validator per finding (a single batched validator recreates the bias). The validator reads the code path cold and returns confirm / downgrade / reject with its own evidence.

Degraded-keep on crash: if a validator fails to return (vs. rejects), P2/P3 drop (conservative) but P0/P1 are kept and marked "degraded — unvalidated" — a transient failure must never silently remove a critical finding.
At
```
low
```
/
```
medium
```
effort, validate P0/P1; at
```
high
```
/
```
max
```
, also validate P2.

不要重新验证自己的合成结果——合并结果的编排者无法提供独立的第二意见（它能发现错误事实，但无法发现自身偏见）。相反，对于所有保留的P0和P1问题，启动一个全新的验证

Agent

，且该Agent无需对问题结论负责（“误报很常见；无需迫于压力确认结论”）。每个问题对应一个验证Agent（批量验证会重现偏见）。验证Agent从头读取代码路径，返回确认/降级/拒绝结论及自身证据。

崩溃时保留降级问题：若验证Agent未返回结果（而非拒绝），则P2/P3问题被移除（保守原则），但P0/P1问题将被保留并标记为“降级——未验证”——临时故障绝不能静默移除关键问题。
在
```
low
```
/
```
medium
```
工作量模式下，验证P0/P1问题；在
```
high
```
/
```
max
```
模式下，还需验证P2问题。

Phase 4: Write the report

阶段4：生成报告

Write to

docs/audits/YYYY-MM-DD-rigorous-review.md

A TL;DR of the few things that actually matter, with a recommended order.
Four findings tables (security / performance / correctness / refactoring), each row: id, severity, confidence, title, file:line, class, OWASP/CWE (security only).
An advisory / residual-risks tier for the soft-bucketed P2/P3 survivors.
A "verified clean" section — what was checked and found safe, so nobody re-audits it.
A recommended execution order: secrets/credential rotation and unauthenticated-write closures first, then safe perf wins, then gated items (with approval), then maintainability.
An explicit note that no production data was touched and no fixes were applied.

将报告写入

docs/audits/YYYY-MM-DD-rigorous-review.md

：

TL;DR：简述真正重要的事项及推荐处理顺序。
四个问题表格（安全/性能/正确性/重构），每行包含：id、严重性、置信度、标题、文件:行号、分类、OWASP/CWE（仅安全领域）。
建议/剩余风险部分：纳入被软分类的P2/P3问题。
**“已验证安全”**部分：说明已检查且确认安全的内容，避免重复审计。
推荐执行顺序：首先处理密钥/凭证轮换和未认证写入漏洞修复，然后是安全的性能优化，接着是需批准的gated型问题，最后是可维护性改进。
明确说明未触碰生产数据且未应用任何修复。

Phase 5: Apply safe fixes — only if asked

阶段5：应用安全修复——仅在用户要求时执行

If the user passes

apply-safe

(or asks afterward):

Apply only
```
safe
```
findings, highest-confidence first. One commit per concern, conventional message. Never push.
After each fix, run the behavior-preservation verifier: infer the user story the changed code serves and walk it boundary-by-boundary (request → handler → data → response), confirming the observable result is unchanged for a legitimate caller. Stop at the first broken boundary. Tests passing is necessary, not sufficient — the verifier proves the flow. Protocol: references/behavior-preservation.md.
Run the project's test command and build after each; both must pass before the next.
Never apply a
```
gated
```
item. If a "safe" fix turns out to risk observable change once you're in the code, stop and re-classify it as gated.
Recommend landing security fixes on their own focused branch.

若用户传递

apply-safe

参数（或后续要求）：

仅应用**
```
safe
```
型**问题的修复方案，优先处理高置信度问题。每个问题对应一个提交，使用规范的提交信息。绝不推送至远程仓库。
每次修复后，运行行为一致性验证器：推断被修改代码服务的用户场景，逐边界检查（请求→处理器→数据→响应），确认合法调用者的可观测结果未发生变化。一旦发现边界失效，立即停止。测试通过是必要条件，但不充分——验证器需证明整个流程的一致性。协议见：references/behavior-preservation.md。
每次修复后运行项目的测试命令和构建命令；两者均需通过才能进行下一次修复。
绝不应用
```
gated
```
型问题的修复方案。若原本归类为“safe”的修复方案在代码中发现存在可观测变化的风险，立即停止并重新归类为gated型。
建议将安全修复单独放在一个聚焦的分支中。

Gotchas / lessons baked in

易犯错误/经验总结

A finding without a confidence is half a finding. Severity says how bad if real; confidence says how sure it's real. Reporting a speculative P0 as if verified is how audits lose trust — and dropping an uncertain P0 is how they miss the breach. The gate needs both.
The secrets scan is not optional and is easy to miss. In testing, the dedicated security pass missed a committed DB credential a different reviewer caught by luck. A committed secret is P0 and needs rotation, not just deletion — it's in git history.
Self-recheck is not validation. The orchestrator synthesized the findings, so re-reading them confirms its own bias. The independent validator wave (Phase 3) is the fix; don't skip it back to a self-pass to save agents.
Check callers before flagging. The top false positive is "missing guard / validation" on code already guarded by middleware, a framework default, or a parallel handler. The do-NOT-flag list exists because reviewers emit these constantly.
State the auth model in Phase 0. Reviewers otherwise waste effort rediscovering that there's no central middleware and every endpoint self-guards.
Don't let a "refactor" change data. When duplicated transforms already disagree, picking one semantic is a data decision —
```
gated
```
, not a quiet cleanup. Same for any API-contract shift.
Dead-code-by-grep lies. Barrel files, dynamic imports, and framework route exports make a symbol look unused when it isn't. Prove deletion with real tooling, and deletion is
```
gated
```
.
Scope: an optional path arg narrows the audit; default is the whole app. Match reviewer depth to scope and to
```
--effort
```
.

无置信度的问题不算完整的问题。严重性说明问题如果真实存在的影响程度；置信度说明问题真实存在的确认程度。将推测性的P0问题当作已验证的问题报告，会让审计失去信任；而忽略不确定的P0问题，则可能错过漏洞。准入机制需要两者结合。
密钥扫描并非可选步骤，且容易被遗漏。在测试中，专门的安全审查环节遗漏了一个已提交的数据库凭证，而另一个审查人员偶然发现了它。已提交的密钥属于P0问题，需要轮换，而非仅删除——它已存在于git历史中。
自我复查不等于验证。编排者合成了结果，因此重新阅读结果只会确认自身偏见。独立验证环节（阶段3）是解决方案；不要为了节省Agent而跳过该环节，回到自我复查。
标记前检查调用方。最常见的误报是“缺失防护/验证”，但代码已由中间件、框架默认设置或并行处理器防护。禁止标记列表的存在正是因为审查人员经常会发出此类误报。
在阶段0明确授权模型。否则审查人员会浪费精力重新发现不存在集中式中间件，每个端点需自行防护的事实。
不要让“重构”改变数据。当重复的转换逻辑已不一致时，选择其中一种语义属于数据决策——归类为
```
gated
```
型，而非静默清理。API契约的任何变更也属于此类。
通过grep识别死代码不可靠。桶文件、动态导入和框架路由导出会让符号看起来未被使用，但实际并非如此。需使用真实工具证明代码已死亡，且删除建议属于
```
gated
```
型。
范围：可选的路径参数可缩小审计范围；默认审计整个应用。根据范围和
```
--effort
```
参数调整审查深度。

Changelog

更新日志

V1 (2026-06-10)

V1（2026-06-10）

First release of

rigorous-review

. Distilled from a working prototype (

internal-hardening-audit

) that was forged by running it for real on two production web codebases (Fable/Opus — good results; it surfaced a committed DB credential the dedicated security pass had missed), then hardened with a 3-agent research synthesis across CE reviewer agents, the built-in

code-review

security-review

, Vercel skills, Anthropic

security-review

, Matt Pocock's architecture skill, OWASP Top 10:2025, Fowler smells, and Core Web Vitals. The design, each piece traceable to a source:

Two scoring axes + a gate (CE
```
ce-code-review
```
5-anchor confidence; Anthropic's ≥0.8 report threshold) — severity alone can't express "critical but unverified"; the gate is the main precision lever (suppress <75 except P0-at-50).
Do-NOT-flag lists + settled-precedents table (Anthropic's 18 excludes; CE's false-positive catalog) — the highest-yield single addition for signal-to-noise.
Independent validator wave, not self-recheck (CE: the synthesizer can't be its own unbiased checker) — fresh agent per P0/P1, degraded-keep on crash.
Cross-reviewer dedup (fingerprint) + agreement promotion (CE merge pipeline) — parallel reviewers corroborate instead of double-listing.
Per-lane threshold asymmetry (CE security-lower / perf-higher) — a flat bar under-reports security and over-reports premature optimization.
Four lanes — security, performance, refactoring, and correctness (off-by-one, null propagation, error-masking, TOCTOU, races); the built-in
```
code-review
```
and Anthropic both centre correctness.
API-contract / behavior-preservation check — guards the core invariant directly (additive-vs-mutative, silent-semantics-change).
Coverage — security: SSRF (OWASP A01), insecure deserialization, CSRF, dangerous-sink watchlist, OWASP-2025/CWE tags. Perf: Core Web Vitals, image/font, barrel imports, RSC serialization, serverless cache/FS/cron. Refactor: real dead-code tooling (knip/ts-prune/ast-grep), Fowler 5-family taxonomy, Pocock Deletion Test + two-adapter seam rule, TS type-safety.
Process layer — effort dial (precision↔recall), model-tiering (security+correctness = session model, perf+refactor = mid-tier), Phase-5 behavior-preservation verifier.
Heavy checklists live in
```
references/
```
to keep SKILL.md lean.

Empirical precision/recall validation is pending the next real audit run.

rigorous-review

首次发布。提炼自一个工作原型（

internal-hardening-audit

），该原型通过在两个生产Web代码库（Fable/Opus——效果良好；发现了专门安全审查环节遗漏的已提交数据库凭证）的实际运行而形成，随后通过3个Agent的研究合成进行强化，涵盖CE审查Agent、内置

code-review

security-review

、Vercel技能、Anthropic

security-review

、Matt Pocock的架构技能、OWASP Top 10:2025、Fowler代码异味和Core Web Vitals。设计的每个部分均可追溯至来源：

双维度评分+准入机制（CE
```
ce-code-review
```
的5锚点置信度；Anthropic的≥0.8报告阈值）——仅靠严重性无法表达“关键但未验证”；准入机制是提升精度的主要手段（抑制置信度<75的问题，除了置信度≥50的P0问题）。
禁止标记列表+既定先例表（Anthropic的18项排除规则；CE的误报目录）——这是提升信噪比的最高效的单一改进。
独立验证环节，而非自我复查（CE：合成者无法成为自身的无偏检查者）——每个P0/P1问题对应一个全新Agent，崩溃时保留降级问题。
跨审查者去重（指纹）+共识提升（CE合并流程）——并行审查者相互佐证，而非重复列出问题。
分领域阈值差异化（CE安全领域门槛更低/性能领域门槛更高）——统一门槛会导致安全问题漏报，性能问题误报过多。
四个领域——安全、性能、重构和正确性（边界错误、null传播、错误屏蔽、TOCTOU、竞态条件）；内置
```
code-review
```
和Anthropic均以正确性为核心。
API契约/行为一致性检查——直接保障核心不变量（新增vs变更、静默语义变更）。
覆盖范围——安全领域：SSRF（OWASP A01）、不安全反序列化、CSRF、危险输出点监控列表、OWASP-2025/CWE标签。性能领域：Core Web Vitals、图片/字体、桶导入、RSC序列化、无服务器缓存/文件系统/定时任务。重构领域：真实死代码工具（knip/ts-prune/ast-grep）、Fowler 5类分类、Pocock删除测试+双适配器接缝规则、TS类型安全。
流程层——工作量调节参数（精度↔召回）、模型层级分配（安全+正确性=会话模型，性能+重构=中端模型）、阶段5行为一致性验证器。
详细检查清单存放在
```
references/
```
目录中，以保持SKILL.md简洁。

实证精度/召回率验证有待下一次实际审计运行。

References

参考资料

references/reviewer-lanes.md — full per-lane checklists (security / performance / correctness / refactoring) + each lane's do-NOT-flag list.
references/scoring-gating-validation.md — confidence anchors, the gate, per-lane asymmetry, dedup fingerprint, agreement promotion, validator-wave protocol, degraded-keep, settled-precedents table, effort dial, model-tiering.
references/behavior-preservation.md — API-contract additive-vs-mutative + silent-semantics-change check, and the Phase-5 boundary-walk verifier.

references/reviewer-lanes.md——各领域完整检查清单（安全/性能/正确性/重构）+各领域的禁止标记列表。
references/scoring-gating-validation.md——置信度锚点、准入机制、分领域差异化、去重指纹、共识提升、验证环节协议、崩溃时保留降级问题、既定先例表、工作量调节参数、模型层级分配。
references/behavior-preservation.md——API契约新增vs变更+静默语义变更检查，以及阶段5的边界遍历验证器。

Testing

测试

tests/eval.sh

asserts the design contract structurally (two axes + gate, P0-at-50 exception, suppression lists, independent validator wave, dedup + promotion, four lanes incl. correctness, API-contract check, OWASP/CWE + SSRF/deserialization, Core Web Vitals, real dead-code tooling, effort dial, model-tiering, behavior-preservation verifier, prod-read-only, safe-vs-gated). Behavioral validation is the next real audit run (re-audit the same codebases and compare finding precision/recall against the prototype baseline).

tests/eval.sh

从结构上断言设计契约（双维度评分+准入机制、P0-at-50例外、抑制列表、独立验证环节、去重+共识提升、包含正确性的四个领域、API契约检查、OWASP/CWE+SSRF/反序列化、Core Web Vitals、真实死代码工具、工作量调节参数、模型层级分配、行为一致性验证器、生产环境只读、安全型vs gated型）。行为验证有待下一次实际审计运行（重新审计相同代码库，将发现问题的精度/召回率与原型基线对比）。