尧图网站建设 
React Doctor PR 诊断 Parity 实战用 Daytona 评估器与确定性 NDJSON 对比检测 PR 引入的诊断回归【免费下载链接】react-doctorYour agent writes bad React. This catches it项目地址: https://gitcode.com/GitHub_Trending/re/react-doctor本篇指南完整讲解 React Doctor 仓库中run-parity技能.agents/skills/run-parity/SKILL.md所定义的「PR 诊断一致性」工作流如何把 PR 的 base 与 head 两个版本在同一批真实仓库语料上分别跑出 React Doctor 诊断结果写出确定性的 NDJSON 工件并逐条对比从而判断一个 PR 是否新增或删除了任何诊断。读完后你将掌握完整的运行准备、配对沙箱评估、增量规则影响分析、基线缓存与 provenance 校验、诊断/性能双对比器以及多 PR 矩阵批量评估的操作方式并能读懂每个脚本如 compare-parity.mjs背后的实现约束。什么是 PR 诊断 Parity以及为什么需要它React Doctor 是一个诊断 React 代码问题的检测器Your agent writes bad React. This catches it。检测器本身的规则实现会不断演进一条规则逻辑的改动、一个共享工具的调整都可能在成千上万个真实仓库上产生「多报 / 少报 / 换位置报」的差异。Parity一致性评估就是为这类改动兜底的门禁运行同一语料、比较两个版本把 PR 的 base 提交和 head 提交各跑一遍评估得到两份「每仓库一条记录」的 NDJSON 工件再做逐条诊断 diff确定性优先工件可复现、可缓存、可审计比较器对输入做二次校验任何不完整或非法的记录都会直接判为无效输入而不是被静默忽略增量优先、全量兜底能证明只影响少数规则的 PR 走「scoped规则范围」评估以节省 Daytona 配额其余情况一律回退到全量对比full parity。从源码结构看整套工作流由两类组件构成.agents/skills/run-parity/scripts/下的本地 Node/jq 脚本对比器、校验器、影响分析器、Merkle 索引构建器以及 packages/evals 下基于 Daytona 的评估器packages/evals/package.json 中的eval、matrix-corpus-identity、source-hash三个 npm script。准备工作解析 PR、固定提交与运行目录前置条件技能文档明确要求环境变量DAYTONA_API_KEY已配置ghCLI 已完成 GitHub 认证PR 的 head 已经 push 到远端未经许可不得 push 任何变更本仓库内安装依赖与运行脚本一律使用ni/nrantfu/ni 封装不要直接写npm。解析 PR 并推导两侧仓库gh pr view pr-number-or-url \ --json number,url,baseRefOid,headRefOid,headRepository,headRepositoryOwner关键约束有三条base 仓库从 PR 的 URL 推导head 仓库从headRepositoryOwner.loginheadRepository.name推导——fork PR 的 head 通常位于另一个仓库必须分别指向正确的 repo URL必须使用返回的完整 commit hashbaseRefOid/headRefOid而不是分支名。评估器内部也强制这一点packages/evals/src/constants.ts 中PINNED_REPOSITORY_REF_PATTERN /^[0-9a-f]{40}$/i只接受 40 位提交哈希输入语料中的仓库引用同样必须 pin 到精确提交——validate-parity-input.jq 校验.repository.ref必须匹配^[0-9A-Fa-f]{40}$未 pin 的仓库记录会被整批拒绝。这样做的目的正如技能文档所述基线记录了已解析的仓库 hash复用它作为 candidate 语料可以防止两次运行之间默认分支移动导致语料漂移。创建运行目录mkdir -p tmp/parity-pr-number-head-short-sha该目录约定命名为tmp/parity-pr-pr号-head短sha运行结束后必须保留以便审计工件。评估前先在仓库根执行ni安装依赖。双版本评估baseline 与 candidate 命令评估统一从packages/evals目录发起。语料默认是 packages/evals/repositories.json 中排名前 2000 的仓库对应 constants.ts 的DEFAULT_CORPUS_REPOSITORY_COUNT 2_000初始并发 200DEFAULT_CORPUS_CONCURRENCY 200。沙箱创建速率被硬性限制在 20SANDBOX_CREATE_CONCURRENCY 20以免压垮 Daytona评估器会清理失败资源并按 50、10 的并发重试失败项目constants.ts 的EVALUATION_RETRY_CONCURRENCIES [50, 10, 2]。# 1) baseline用 PR 的 base 提交跑全量诊断 nr --silent eval \ --react-doctor-repository base-repository-url \ --react-doctor-ref baseRefOid \ absolute-run-directory/baseline.ndjson # 2) candidate语料直接复用 baseline.ndjson已 pin 仓库 hash用 head 提交再跑一遍 nr --silent eval \ --repositories absolute-run-directory/baseline.ndjson \ --react-doctor-repository head-repository-url \ --react-doctor-ref headRefOid \ absolute-run-directory/candidate.ndjson两条命令都必须以退出码 0 结束且报告 100% 完成度否则报告失败项目并停止对比。candidate 阶段用 baseline 的输出作为--repositories输入而不是重新取默认语料——评估器会拒绝未 pin 的评估 NDJSON 输入。评估器如何「钉死」检测器版本与规则集在沙箱内评估器通过git fetch --depth 1检出指定的 40 位提交执行corepack enableni --frozenturbo run build --filterreact-doctor随后由MATERIALIZE_REACT_DOCTOR_EVALUATION_PROVENANCE_COMMAND见 constants.ts计算规则集哈希并写出 evaluation provenance 文件。这解释了技能文档中「评估器会给每条记录盖上精确的检测器提交、revision-local 规则/配置哈希、评估器源码哈希」的机制——其中configContract固定为revision-local-rule-config-v1EVALUATION_CONFIG_CONTRACT。因此永远不要缓存一份没有这些 stamp 的旧运行结果。scoped 评估还有一个值得注意的实现细节规则配置生成逻辑会把所有未选中的 revision-local 规则置为off并且当规则范围内不含 security-scan 规则时整体注入ignore: { tags: [security-scan] }跳过整树安全扫描路径见 constants.ts 中EVALUATION_RULE_CONFIGURATION_SOURCE。这正是技能文档所说「评估器把每个未选中的 revision-local 规则 stamp 为 off范围中无 security-scan 规则时跳过整个整树扫描」的来源。基线缓存provenance 文件的创建与校验全量 baseline 非常昂贵因此技能允许跨 PR 共享不可变 baseline但共享条件极严只有在完全相同的 React Doctor 提交、语料 manifest hash、评估器 schema、规则集/配置哈希下才能缓存成功基线缓存基线在被复用前仍必须通过流式校验器。多个 PR 可以共享同一个不可变 baseline但绝不能合并它们的 candidate head 或 delta。创建 provenance 文件正常的输入校验通过后在 baseline 旁边创建 provenance 文件node .agents/skills/run-parity/scripts/baseline-cache-provenance.mjs create \ --baseline baseline.ndjson \ --corpus-manifest corpus-manifest.json \ --base-commit full-base-commit \ --repository react-doctor-repository-url \ --evaluator-source-hash packages-evals-source-hash \ --config-contract revision-local-rule-config-v1 \ --rule-set-hash stamped-full-ruleset-hash其中--evaluator-source-hash的值从packages/evals目录执行nr --silent source-hash获得对应 packages/evals/package.json 中的source-hashscript。每次复用缓存前都用verify子命令重跑一遍同一校验。从 baseline-cache-provenance.mjs 的实现看verify是流式读取原始 NDJSON 字节的它要求全量 baseline 的ruleKeys: []即确属全量运行而非 scoped、逐条检查每条记录的 producer 绑定并独立要求「精确 pin 的语料项目集合」与 manifest 完全一致——任何一项不匹配都按 cache miss 处理。命中缓存时的走法cache hitbase 完全不进 Daytona。直接对已校验的缓存 baseline 跑上面的「candidate-only」命令且不得传任何--paired-*参数cache miss或需要「全量 vs scoped」shadow 运行时把 base 与 candidate 两个检测器放进同一个 Daytona 沙箱做配对评估下一节。配对沙箱评估同沙箱双检测器配对paired模式下一个沙箱同时容纳 base 与 treatmentcandidate两个 React Doctor 检出。从 constants.ts 中的PREPARE_PAIRED_REACT_DOCTOR_COMMANDS可以看到两侧各自git fetch --depth 1指定提交、分别turbo build、分别物化 provenanceSETUP_PAIRED_TARGET_REPOSITORY_COMMAND则显示目标仓库只 fetch 一次到一个 bare 对象库再为 base/treatment 各建一个隔离 worktree。这与技能文档描述完全一致配对沙箱把每个目标仓库 fetch 一次进同一个对象库然后在隔离的 base/treatment worktree 中用隔离的检测器安装、配置文件与报告路径扫描。一个项目对只有在两侧都成功后才会被写出因此重试不会在任一输出中留下半成功的项目对。配对写入使用单一写入者队列任一 sink 失败即回滚 baseline。命令形式如下nr --silent eval \ --repositories corpus-manifest-or-validated-input \ --paired-baseline-output absolute-new-baseline-path \ --paired-base-react-doctor-repository base-repository-url \ --paired-base-react-doctor-ref base-or-full-shadow-commit \ --paired-base-rule treatment-plugin/rule \ --react-doctor-repository treatment-repository-url \ --react-doctor-ref treatment-commit \ --paired-execution sequential \ --rule treatment-plugin/rule \ absolute-run-directory/candidate.ndjson配套规则与硬约束--paired-baseline-output以独占方式创建永不覆盖已有工件任何非零退出的配对评估都会使两份输出工件同时作废、不可复用——丢弃它们而不是喂给比较器或缓存性能对比必须两侧传相同的--paired-base-rule与--rule值全量对比则两个都省略。「全量 vs scoped」shadow 运行是有效的诊断证据但不是性能证据。沙箱规格、执行模式与超时预算技能文档给出的规格与 constants.ts 常量一一对应项目值源码常量配对沙箱 CPU / 内存 / 磁盘4 核 / 8 GiB / 20 GiBPAIRED_SANDBOX_CPU_CORES/PAIRED_SANDBOX_MEMORY_GIB/PAIRED_SANDBOX_DISK_GIB并行执行门槛沙箱 ≥4 核才并行PAIRED_SCAN_MINIMUM_PARALLEL_CPU_CORES 4配对默认并发50 个沙箱低于 4 核沙箱的实测容量上限DEFAULT_PAIRED_CORPUS_CONCURRENCY 50单次配对扫描上限5 分钟300s防止少数卡死沙箱吃掉整个 attempt 预算PAIRED_SANDBOX_SCAN_TIMEOUT_SECONDS 300--paired-execution auto默认仅在核数足够时并行--paired-execution sequential受控串行基准与下述性能对比必须用它保证 base 与 candidate 共享同一沙箱且互不抢 CPUauto/parallel只能用于「纯诊断 parity」计时证据将被丢弃。另外两种模式共享同一硬性 attempt 截止时间与完全一致的评估标签清理逻辑。普通非配对评估器保留其既有超时对于带较短预算的评估聚合重试保留时间被上限为 attempt 开始时剩余时间的 25%确保至少 75% 的预算留给实际工作而不是让快照构建吃掉整个首次 attempt 截止时间——对应 constants.ts 的EVALUATION_MAXIMUM_RETRY_RESERVE_RATIO 0.25。多 PR 矩阵评估treatment 描述符与共享 base当多个 PR 共享同一个不可变 base 与同一语料时使用可复现的矩阵 treatment 描述符。先固定语料身份与评估器哈希cd packages/evals nr --silent matrix-corpus-identity absolute-corpus-manifest-path nr --silent source-hash每个描述符是一个不可变 JSON 文件形状严格如下{ schemaVersion: 1, id: pr-1234, artifactDirectory: /absolute/path/pr-1234, reactDoctorRepository: https://github.com/millionco/react-doctor.git, reactDoctorCommit: 40-character-head-commit, impactManifestPath: /absolute/path/pr-1234-impact.json, impactManifestSha256: sha256, group: { baseReactDoctorRepository: https://github.com/millionco/react-doctor.git, baseReactDoctorCommit: 40-character-base-commit, baseFullRuleSetHash: full-base-rule-set-sha256, baseArtifactPath: /absolute/path/base-union-scoped.ndjson, baselineOutputPath: /absolute/cache/full-baseline.ndjson, baselineProvenancePath: /absolute/cache/full-baseline.provenance.json, corpusManifestPath: /absolute/path/corpus.json, corpusManifestSha256: matrix-corpus-identity manifestSha256, corpusProjectSetSha256: matrix-corpus-identity projectSetSha256, evaluatorSourceHash: source-hash, configContract: revision-local-rule-config-v1, scanContract: react-doctor-json-full-v1, reportContract: react-doctor-complete-report-v1, projectRootPolicy: manifest-root-dir-v1 } }其中scanContract/reportContract/projectRootPolicy三个契约字符串在 constants.ts 中有常量定义MATRIX_SCAN_CONTRACT、MATRIX_REPORT_CONTRACT、MATRIX_PROJECT_ROOT_POLICY。描述符引用 impact manifest 时的校验链很长它必须是find-impacted-rules.mjs的精确输出其 hash、base commit、head commit、mode 与 candidate 规则键都会被重新验证在 Daytona 启动前矩阵运行器会 fetch 钉住的 base/head 提交、用当前版本的生成器重跑一遍并要求字节级一致的 manifest 输出。所有参与重复运行的描述符必须具有完全相同的group对象、唯一的合法id、以及互不相同的 artifact 目录。发起矩阵运行nr --silent eval \ --matrix-treatment /absolute/path/pr-1234.json \ --matrix-treatment /absolute/path/pr-1235.json \ --matrix-wave-width 2矩阵运行器的行为可从 constants.ts 的常量交叉验证已验证的全量 cache hit 让 base 留在 Daytona 之外否则只要任一 treatment 需要全量 parity 就扫一次完整 base否则扫一次按排序后的增量规则范围并集一个目标 bare clone 供给各隔离 lane worktree默认 2-lane 波次DEFAULT_MATRIX_WAVE_WIDTH 2每沙箱 4 CPU / 8 GiBMATRIX_CPU_CORES_PER_LANE 2、MATRIX_MEMORY_GIB_PER_LANE 4运行器在 400 CPU 总包络MATRIX_MAXIMUM_CPU_CORES 400下推导并发沙箱创建保持 20重试保留已成功的(lane, project)结果只以 50 → 10 → 2 的并发重试失败工作前两级与普通评估的EVALUATION_RETRY_CONCURRENCIES对齐每个 treatment 与其 candidate NDJSON、精确语料 manifest、描述符、impact manifest、规则、哈希、计数与 provenance原子性发布为一个自包含目录base 缺失时成功的 treatment 被标记为blocked而不是做独立的合并判断。验证与对比已发布的 treatment 工件把每个已发布的 treatment 目录视为自包含证据对比之前先验证其 status、规范化相对路径、producer 绑定、字节长度、哈希、精确记录数、完整报告与语料项目元组。绝不要跟随 provenance 指向的共享缓存或 scoped-base 来源路径去取输入node .agents/skills/run-parity/scripts/verify-matrix-artifact.mjs \ treatment-artifact-directory # 增量 treatment带上规则范围 node .agents/skills/run-parity/scripts/compare-parity.mjs \ --rules treatment-artifact-directory/rules.json \ treatment-artifact-directory/base.ndjson \ treatment-artifact-directory/candidate.ndjson \ treatment-artifact-directory/parity.json # 全量 treatment node .agents/skills/run-parity/scripts/compare-parity.mjs \ treatment-artifact-directory/base.ndjson \ treatment-artifact-directory/candidate.ndjson \ treatment-artifact-directory/parity.jsonverify-matrix-artifact.mjs 的校验逻辑与上述「自包含证据」要求一一对应注意矩阵 lane 是并发执行的其工件仍属诊断证据——不要把矩阵工件喂给性能比较器。增量 Parity影响 manifest 与规则范围对「只改规则」的 PR可在 candidate 运行前构建保守的影响 manifestnode .agents/skills/run-parity/scripts/find-impacted-rules.mjs \ repository-root base-ref head-ref impact.jsonfind-impacted-rules.mjs 的工作原理值得了解因为它决定了「何时可以增量、何时必须全量」构建双向模块图分别用git ls-tree拉取 base 与 head 两个版本下packages/oxlint-plugin-react-doctor/src的运行时源码树RULES_ROOT 覆盖plugin/rules/、plugin/constants/、plugin/utils/三个增量运行时根用 TypeScript 编译器 API 解析每个文件的运行时 import/export/require/动态import()边建立依赖与反向依赖图规则键提取在规则文件中定位defineRule(...)/defineRetiredRule(...)调用的id属性拼出react-doctor/id形式的规则键反向传播从变更文件出发沿反向依赖传播收集被直接影响的规则诊断交互闭包candidateRuleKeys已自动包含已知诊断交互闭包源码 中DIAGNOSTIC_INTERACTION_GROUPS例如no-initialize-state与no-derived-state-effect一族、rules-of-hooks与react-hooks-js/hooks的配对保守回退出现以下任一情况manifest 的mode就是full——security-scan 规则变更全局 runner/config/report/registry 变更规则 ID 删除或重命名未解析的运行时模块边TS 解析失败插件工具模块不经过任何已映射规则边界就触达宿主模块甚至「没有任何运行时规则影响」空增量范围永远不被构造。使用规则只有 manifest 报告mode: incremental时才走增量模式。把candidateRuleKeys原样写入 rules JSON并在 candidate 命令中把每个键作为可重复的--rule参数传入nr --silent eval \ --repositories validated-baseline-or-corpus-manifest \ --react-doctor-repository head-repository-url \ --react-doctor-ref headRefOid \ --rule plugin/rule \ absolute-run-directory/candidate-scoped.ndjsonShadow 校验增量结果必须能被全量复现在增量 parity 积累足够的 shadow 历史、可以成为必选门禁之前技能要求额外做一次全量 candidate在与 scoped 运行完全相同的 head / 语料 / 并发策略下跑一次全量 candidate并要求其规则过滤后的输出与 scoped candidate精确一致。同时报告实测 wall time 与项目级延迟——不要从样本外推加速比。输入校验jq 流式验证器candidate 运行前逐条流式校验 baseline 的每一条记录。validate-parity-input.jq 会在不把整个 NDJSON 语料载入内存的情况下拒绝未 pinref 非 40 位哈希的仓库评估错误记录error字段畸形报告schema 校验支持 v1/v2/v3 报告 schema 与full/diff/staged/baseline模式不完整项目v3 要求complete true、skippedChecks为空、analyzedFileCount analyzedFiles.length等。jq -e -n \ -f repository-root/.agents/skills/run-parity/scripts/validate-parity-input.jq \ absolute-run-directory/baseline.ndjson /dev/nulljq 程序结尾的reduce还会用seen表检查项目键org/name/ref/rootDir四元组的 JSON 序列化不重复。若 baseline 命令退出码非零或该校验失败检查其失败记录并停止。对比诊断compare-parity.mjs 与退出码语义从仓库根目录执行node .agents/skills/run-parity/scripts/compare-parity.mjs \ run-directory/baseline.ndjson \ run-directory/candidate.ndjson \ run-directory/parity.json node .agents/skills/run-parity/scripts/compare-parity-performance.mjs \ run-directory/baseline.ndjson \ run-directory/candidate.ndjson \ run-directory/performance-parity.jsoncompare-parity.mjs的退出码语义源码 中PARITY_DIFFERENCE_EXIT_CODE 1、INVALID_INPUT_EXIT_CODE 2退出码含义0诊断完全一致1对比成功但存在诊断变化added/removed2输入不完整或非法含任一侧出现 skippedProjects 时的保守降级退出码1时先检查受影响的源码位置再对变化定性是真实修复、误报变化还是行为回归。比较器的实现要点阅读 compare-parity.mjs 可以印证技能文档中的每条工程承诺双次校验与 fail closed比较器对两侧输入重新执行与评估器等价的报告校验validateReport见 L313。任何一侧含评估错误、畸形报告、缺失完成标记或残缺 legacy 报告都会以「非法输入」状态退出规范化诊断身份canonicalDiagnosticL182把诊断路径解析为「相对报告根目录」的规范化路径统一 v1/v2/v3 报告 schema 下的身份tags 排序、重复 occurrence 计数保留。因此重叠的 workspace 扫描不会虚增计数schema 升级也不会被误报为诊断 churn流式 临时目录暂存readRun逐行流式读取baseline 记录按项目键的 SHA-256 写入系统临时目录react-doctor-parity-*大尺寸added/removed明细数组通过writeOutputArray增量写出变化的诊断条目只在排序所需时间内驻留内存。因此临时盘与输出容量要与运行规模成比例候选侧更严diagnosticsByIdentity对 candidate 传rejectOutsideRuleScope trueL472scoped 模式下任何范围外的 candidate 诊断直接报错——即「scoped 比较器拒绝任意的范围外 candidate 诊断」。增量scoped对比对 scoped 运行把全量 baseline 过滤到「同样的规则 always-on 不变量范围」后再比node .agents/skills/run-parity/scripts/compare-parity.mjs \ --rules rules.json \ baseline.ndjson \ candidate-scoped.ndjson \ run-directory/parity-scoped.json「always-on 不变量范围」在 源码 中有明确定义INVARIANT_DIAGNOSTIC_PLUGIN TS整个 TypeScript 插件范围TS/*外加一份固定的INVARIANT_DIAGNOSTIC_RULE_KEYS列表expo、pnpm-hardening、reduced-motion、RN 相关等约 20 个react-doctor/规则键。scoped 比较器还会要求精确的项目 / framework / analyzed-file 覆盖coverageFingerprintL416对 v3 报告的项目目录、packageRoot、framework、排序后的 analyzedFiles 做指纹两侧指纹不一致的项目被记入skippedProjects并触发退出码 2保留重复 occurrence 的多重性unchanged取两侧最小 occurrence 数多余部分分别记 added/removed比较全部语义诊断字段包括规范化后的 primary 与 related 路径。性能对比compare-parity-performance.mjs 的阈值体系性能比较器compare-parity-performance.mjs要求完整的 v3 报告且两侧的项目覆盖、规则范围ruleKeys、configContract、evaluatorSourceHash逐项相等任一不等即抛错退出 2。它只能在配对串行--paired-execution sequential评估上运行确保 base 与 candidate 共享同一 Daytona 沙箱、不互相争抢 CPU。退出码0 计时保持在固定的噪声容忍阈值内1 存在实质性项目级或聚合回归2 证据非法。具体阈值全部是源码常量且会原样写入输出的thresholds字段便于审计阈值值说明minimumBaselineElapsedMilliseconds1000 msbase 扫描不足 1 秒的项目被忽略minimumProjectRegressionMilliseconds2000 ms单项目须至少慢 2 秒maximumProjectRegressionRatio1.5且慢于 50%ratio ≥ 1.5才标记单个项目minimumAggregateProjectCount10聚合回归至少需要 10 个合格项目maximumAggregateRegressionRatio1.2且聚合 ratio ≥ 20%minimumAggregateRegressionMs10000 ms且聚合新增延迟 ≥ 10 秒输出的summary还包含 median 与 p95 的项目 ratio 分布L211。技能文档反复强调归因前先看输出的原始测量数据。Merkle 索引同一工件多次对比时的加速路径当同一个 baseline 或 candidate 将被对比不止一次时构建紧凑的 Merkle 索引build-parity-index.mjsnode .agents/skills/run-parity/scripts/build-parity-index.mjs \ --rules rules.json baseline.ndjson \ baseline.index.json node .agents/skills/run-parity/scripts/build-parity-index.mjs \ --candidate --rules rules.json candidate-scoped.ndjson \ candidate.index.json node .agents/skills/run-parity/scripts/compare-parity-indexes.mjs \ baseline.index.json candidate.index.json \ index-diff.json索引结构自底向上哈希每条诊断身份 occurrence 数构成叶节点 → 每个项目, 规则桶的semanticHash→ 每条规则跨项目的semanticHash→ 顶层wholeRunHashsemanticContract固定为compare-parity1算法 sha256。--candidate标志启用与比较器一致的「范围外诊断即拒绝」策略。对比策略见 compare-parity-indexes.mjs根哈希相等立即停止不同则先逐规则下钻再进项目桶。空的项目/规则桶是显式表达的空桶也有哈希不会与缺失混淆规则范围或覆盖元数据漂移会 fail closed。验证比较器本身的变更若你修改了上述任一脚本比较器、性能比较器、影响分析器、索引或输入校验从仓库根运行各自的测试node --test .agents/skills/run-parity/scripts/compare-parity.test.mjs node --test .agents/skills/run-parity/scripts/compare-parity-performance.test.mjs node --test .agents/skills/run-parity/scripts/find-impacted-rules.test.mjs node --test .agents/skills/run-parity/scripts/parity-index.test.mjs node --test .agents/skills/run-parity/scripts/validate-parity-input.test.mjs这些测试文件与脚本同目录如 compare-parity.test.mjs、find-impacted-rules.test.mjs覆盖了 canonical 身份、覆盖指纹、规则范围拒绝、影响图构建与闭包等关键路径。结果报告清单一次 parity 运行的最终报告必须包含以下字段缺一都会削弱结论的可审计性PR URL 与 base/head 两个完整 commit hash对比项目数compared与跳过项目数skipped以及两侧项目总数诊断总数baseline/candidate、added 与 removed 计数最大的规则级 deltarules.added/rules.removed排序后的头部条目所有工件路径baseline.ndjson、candidate.ndjson、parity.json、performance-parity.json及 provenance 文件。小结这套工作流的三条设计主线不可变性40 位提交 pin、语料 manifest 哈希、评估器源码哈希、规则集哈希、provenance 文件——每一层共享baseline 缓存、矩阵 group都以「字节级可复现」为代价换取「跨 PR 复用」的收益fail closed从 jq 输入校验、比较器的二次校验、配对输出的「任一非零即双工件作废」到索引对比对范围漂移的保守失败任何不确定的中间态都不进入 diff增量是优化全量是真理增量范围由保守的模块图影响分析自动推导uncertainty 一律回退全量并且在 shadow 历史足够之前scoped 结果必须由同策略的全量运行精确复现才算可信。【免费下载链接】react-doctorYour agent writes bad React. This catches it项目地址: https://gitcode.com/GitHub_Trending/re/react-doctor创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 React Doctor PR 诊断 Parity 实战：用 Daytona 评估器与确定性 NDJSON 对比检测 PR 引入的诊断回归
React Doctor PR 诊断 Parity 实战用 Daytona 评估器与确定性 NDJSON 对比检测 PR 引入的诊断回归【免费下载链接】react-doctorYour agent writes bad React. This catches it项目地址: https://gitcode.com/GitHub_Trending/re/react-doctor本篇指南完整讲解 React Doctor 仓库中run-parity技能.agents/skills/run-parity/SKILL.md所定义的「PR 诊断一致性」工作流如何把 PR 的 base 与 head 两个版本在同一批真实仓库语料上分别跑出 React Doctor 诊断结果写出确定性的 NDJSON 工件并逐条对比从而判断一个 PR 是否新增或删除了任何诊断。读完后你将掌握完整的运行准备、配对沙箱评估、增量规则影响分析、基线缓存与 provenance 校验、诊断/性能双对比器以及多 PR 矩阵批量评估的操作方式并能读懂每个脚本如 compare-parity.mjs背后的实现约束。什么是 PR 诊断 Parity以及为什么需要它React Doctor 是一个诊断 React 代码问题的检测器Your agent writes bad React. This catches it。检测器本身的规则实现会不断演进一条规则逻辑的改动、一个共享工具的调整都可能在成千上万个真实仓库上产生「多报 / 少报 / 换位置报」的差异。Parity一致性评估就是为这类改动兜底的门禁运行同一语料、比较两个版本把 PR 的 base 提交和 head 提交各跑一遍评估得到两份「每仓库一条记录」的 NDJSON 工件再做逐条诊断 diff确定性优先工件可复现、可缓存、可审计比较器对输入做二次校验任何不完整或非法的记录都会直接判为无效输入而不是被静默忽略增量优先、全量兜底能证明只影响少数规则的 PR 走「scoped规则范围」评估以节省 Daytona 配额其余情况一律回退到全量对比full parity。从源码结构看整套工作流由两类组件构成.agents/skills/run-parity/scripts/下的本地 Node/jq 脚本对比器、校验器、影响分析器、Merkle 索引构建器以及 packages/evals 下基于 Daytona 的评估器packages/evals/package.json 中的eval、matrix-corpus-identity、source-hash三个 npm script。准备工作解析 PR、固定提交与运行目录前置条件技能文档明确要求环境变量DAYTONA_API_KEY已配置ghCLI 已完成 GitHub 认证PR 的 head 已经 push 到远端未经许可不得 push 任何变更本仓库内安装依赖与运行脚本一律使用ni/nrantfu/ni 封装不要直接写npm。解析 PR 并推导两侧仓库gh pr view pr-number-or-url \ --json number,url,baseRefOid,headRefOid,headRepository,headRepositoryOwner关键约束有三条base 仓库从 PR 的 URL 推导head 仓库从headRepositoryOwner.loginheadRepository.name推导——fork PR 的 head 通常位于另一个仓库必须分别指向正确的 repo URL必须使用返回的完整 commit hashbaseRefOid/headRefOid而不是分支名。评估器内部也强制这一点packages/evals/src/constants.ts 中PINNED_REPOSITORY_REF_PATTERN /^[0-9a-f]{40}$/i只接受 40 位提交哈希输入语料中的仓库引用同样必须 pin 到精确提交——validate-parity-input.jq 校验.repository.ref必须匹配^[0-9A-Fa-f]{40}$未 pin 的仓库记录会被整批拒绝。这样做的目的正如技能文档所述基线记录了已解析的仓库 hash复用它作为 candidate 语料可以防止两次运行之间默认分支移动导致语料漂移。创建运行目录mkdir -p tmp/parity-pr-number-head-short-sha该目录约定命名为tmp/parity-pr-pr号-head短sha运行结束后必须保留以便审计工件。评估前先在仓库根执行ni安装依赖。双版本评估baseline 与 candidate 命令评估统一从packages/evals目录发起。语料默认是 packages/evals/repositories.json 中排名前 2000 的仓库对应 constants.ts 的DEFAULT_CORPUS_REPOSITORY_COUNT 2_000初始并发 200DEFAULT_CORPUS_CONCURRENCY 200。沙箱创建速率被硬性限制在 20SANDBOX_CREATE_CONCURRENCY 20以免压垮 Daytona评估器会清理失败资源并按 50、10 的并发重试失败项目constants.ts 的EVALUATION_RETRY_CONCURRENCIES [50, 10, 2]。# 1) baseline用 PR 的 base 提交跑全量诊断 nr --silent eval \ --react-doctor-repository base-repository-url \ --react-doctor-ref baseRefOid \ absolute-run-directory/baseline.ndjson # 2) candidate语料直接复用 baseline.ndjson已 pin 仓库 hash用 head 提交再跑一遍 nr --silent eval \ --repositories absolute-run-directory/baseline.ndjson \ --react-doctor-repository head-repository-url \ --react-doctor-ref headRefOid \ absolute-run-directory/candidate.ndjson两条命令都必须以退出码 0 结束且报告 100% 完成度否则报告失败项目并停止对比。candidate 阶段用 baseline 的输出作为--repositories输入而不是重新取默认语料——评估器会拒绝未 pin 的评估 NDJSON 输入。评估器如何「钉死」检测器版本与规则集在沙箱内评估器通过git fetch --depth 1检出指定的 40 位提交执行corepack enableni --frozenturbo run build --filterreact-doctor随后由MATERIALIZE_REACT_DOCTOR_EVALUATION_PROVENANCE_COMMAND见 constants.ts计算规则集哈希并写出 evaluation provenance 文件。这解释了技能文档中「评估器会给每条记录盖上精确的检测器提交、revision-local 规则/配置哈希、评估器源码哈希」的机制——其中configContract固定为revision-local-rule-config-v1EVALUATION_CONFIG_CONTRACT。因此永远不要缓存一份没有这些 stamp 的旧运行结果。scoped 评估还有一个值得注意的实现细节规则配置生成逻辑会把所有未选中的 revision-local 规则置为off并且当规则范围内不含 security-scan 规则时整体注入ignore: { tags: [security-scan] }跳过整树安全扫描路径见 constants.ts 中EVALUATION_RULE_CONFIGURATION_SOURCE。这正是技能文档所说「评估器把每个未选中的 revision-local 规则 stamp 为 off范围中无 security-scan 规则时跳过整个整树扫描」的来源。基线缓存provenance 文件的创建与校验全量 baseline 非常昂贵因此技能允许跨 PR 共享不可变 baseline但共享条件极严只有在完全相同的 React Doctor 提交、语料 manifest hash、评估器 schema、规则集/配置哈希下才能缓存成功基线缓存基线在被复用前仍必须通过流式校验器。多个 PR 可以共享同一个不可变 baseline但绝不能合并它们的 candidate head 或 delta。创建 provenance 文件正常的输入校验通过后在 baseline 旁边创建 provenance 文件node .agents/skills/run-parity/scripts/baseline-cache-provenance.mjs create \ --baseline baseline.ndjson \ --corpus-manifest corpus-manifest.json \ --base-commit full-base-commit \ --repository react-doctor-repository-url \ --evaluator-source-hash packages-evals-source-hash \ --config-contract revision-local-rule-config-v1 \ --rule-set-hash stamped-full-ruleset-hash其中--evaluator-source-hash的值从packages/evals目录执行nr --silent source-hash获得对应 packages/evals/package.json 中的source-hashscript。每次复用缓存前都用verify子命令重跑一遍同一校验。从 baseline-cache-provenance.mjs 的实现看verify是流式读取原始 NDJSON 字节的它要求全量 baseline 的ruleKeys: []即确属全量运行而非 scoped、逐条检查每条记录的 producer 绑定并独立要求「精确 pin 的语料项目集合」与 manifest 完全一致——任何一项不匹配都按 cache miss 处理。命中缓存时的走法cache hitbase 完全不进 Daytona。直接对已校验的缓存 baseline 跑上面的「candidate-only」命令且不得传任何--paired-*参数cache miss或需要「全量 vs scoped」shadow 运行时把 base 与 candidate 两个检测器放进同一个 Daytona 沙箱做配对评估下一节。配对沙箱评估同沙箱双检测器配对paired模式下一个沙箱同时容纳 base 与 treatmentcandidate两个 React Doctor 检出。从 constants.ts 中的PREPARE_PAIRED_REACT_DOCTOR_COMMANDS可以看到两侧各自git fetch --depth 1指定提交、分别turbo build、分别物化 provenanceSETUP_PAIRED_TARGET_REPOSITORY_COMMAND则显示目标仓库只 fetch 一次到一个 bare 对象库再为 base/treatment 各建一个隔离 worktree。这与技能文档描述完全一致配对沙箱把每个目标仓库 fetch 一次进同一个对象库然后在隔离的 base/treatment worktree 中用隔离的检测器安装、配置文件与报告路径扫描。一个项目对只有在两侧都成功后才会被写出因此重试不会在任一输出中留下半成功的项目对。配对写入使用单一写入者队列任一 sink 失败即回滚 baseline。命令形式如下nr --silent eval \ --repositories corpus-manifest-or-validated-input \ --paired-baseline-output absolute-new-baseline-path \ --paired-base-react-doctor-repository base-repository-url \ --paired-base-react-doctor-ref base-or-full-shadow-commit \ --paired-base-rule treatment-plugin/rule \ --react-doctor-repository treatment-repository-url \ --react-doctor-ref treatment-commit \ --paired-execution sequential \ --rule treatment-plugin/rule \ absolute-run-directory/candidate.ndjson配套规则与硬约束--paired-baseline-output以独占方式创建永不覆盖已有工件任何非零退出的配对评估都会使两份输出工件同时作废、不可复用——丢弃它们而不是喂给比较器或缓存性能对比必须两侧传相同的--paired-base-rule与--rule值全量对比则两个都省略。「全量 vs scoped」shadow 运行是有效的诊断证据但不是性能证据。沙箱规格、执行模式与超时预算技能文档给出的规格与 constants.ts 常量一一对应项目值源码常量配对沙箱 CPU / 内存 / 磁盘4 核 / 8 GiB / 20 GiBPAIRED_SANDBOX_CPU_CORES/PAIRED_SANDBOX_MEMORY_GIB/PAIRED_SANDBOX_DISK_GIB并行执行门槛沙箱 ≥4 核才并行PAIRED_SCAN_MINIMUM_PARALLEL_CPU_CORES 4配对默认并发50 个沙箱低于 4 核沙箱的实测容量上限DEFAULT_PAIRED_CORPUS_CONCURRENCY 50单次配对扫描上限5 分钟300s防止少数卡死沙箱吃掉整个 attempt 预算PAIRED_SANDBOX_SCAN_TIMEOUT_SECONDS 300--paired-execution auto默认仅在核数足够时并行--paired-execution sequential受控串行基准与下述性能对比必须用它保证 base 与 candidate 共享同一沙箱且互不抢 CPUauto/parallel只能用于「纯诊断 parity」计时证据将被丢弃。另外两种模式共享同一硬性 attempt 截止时间与完全一致的评估标签清理逻辑。普通非配对评估器保留其既有超时对于带较短预算的评估聚合重试保留时间被上限为 attempt 开始时剩余时间的 25%确保至少 75% 的预算留给实际工作而不是让快照构建吃掉整个首次 attempt 截止时间——对应 constants.ts 的EVALUATION_MAXIMUM_RETRY_RESERVE_RATIO 0.25。多 PR 矩阵评估treatment 描述符与共享 base当多个 PR 共享同一个不可变 base 与同一语料时使用可复现的矩阵 treatment 描述符。先固定语料身份与评估器哈希cd packages/evals nr --silent matrix-corpus-identity absolute-corpus-manifest-path nr --silent source-hash每个描述符是一个不可变 JSON 文件形状严格如下{ schemaVersion: 1, id: pr-1234, artifactDirectory: /absolute/path/pr-1234, reactDoctorRepository: https://github.com/millionco/react-doctor.git, reactDoctorCommit: 40-character-head-commit, impactManifestPath: /absolute/path/pr-1234-impact.json, impactManifestSha256: sha256, group: { baseReactDoctorRepository: https://github.com/millionco/react-doctor.git, baseReactDoctorCommit: 40-character-base-commit, baseFullRuleSetHash: full-base-rule-set-sha256, baseArtifactPath: /absolute/path/base-union-scoped.ndjson, baselineOutputPath: /absolute/cache/full-baseline.ndjson, baselineProvenancePath: /absolute/cache/full-baseline.provenance.json, corpusManifestPath: /absolute/path/corpus.json, corpusManifestSha256: matrix-corpus-identity manifestSha256, corpusProjectSetSha256: matrix-corpus-identity projectSetSha256, evaluatorSourceHash: source-hash, configContract: revision-local-rule-config-v1, scanContract: react-doctor-json-full-v1, reportContract: react-doctor-complete-report-v1, projectRootPolicy: manifest-root-dir-v1 } }其中scanContract/reportContract/projectRootPolicy三个契约字符串在 constants.ts 中有常量定义MATRIX_SCAN_CONTRACT、MATRIX_REPORT_CONTRACT、MATRIX_PROJECT_ROOT_POLICY。描述符引用 impact manifest 时的校验链很长它必须是find-impacted-rules.mjs的精确输出其 hash、base commit、head commit、mode 与 candidate 规则键都会被重新验证在 Daytona 启动前矩阵运行器会 fetch 钉住的 base/head 提交、用当前版本的生成器重跑一遍并要求字节级一致的 manifest 输出。所有参与重复运行的描述符必须具有完全相同的group对象、唯一的合法id、以及互不相同的 artifact 目录。发起矩阵运行nr --silent eval \ --matrix-treatment /absolute/path/pr-1234.json \ --matrix-treatment /absolute/path/pr-1235.json \ --matrix-wave-width 2矩阵运行器的行为可从 constants.ts 的常量交叉验证已验证的全量 cache hit 让 base 留在 Daytona 之外否则只要任一 treatment 需要全量 parity 就扫一次完整 base否则扫一次按排序后的增量规则范围并集一个目标 bare clone 供给各隔离 lane worktree默认 2-lane 波次DEFAULT_MATRIX_WAVE_WIDTH 2每沙箱 4 CPU / 8 GiBMATRIX_CPU_CORES_PER_LANE 2、MATRIX_MEMORY_GIB_PER_LANE 4运行器在 400 CPU 总包络MATRIX_MAXIMUM_CPU_CORES 400下推导并发沙箱创建保持 20重试保留已成功的(lane, project)结果只以 50 → 10 → 2 的并发重试失败工作前两级与普通评估的EVALUATION_RETRY_CONCURRENCIES对齐每个 treatment 与其 candidate NDJSON、精确语料 manifest、描述符、impact manifest、规则、哈希、计数与 provenance原子性发布为一个自包含目录base 缺失时成功的 treatment 被标记为blocked而不是做独立的合并判断。验证与对比已发布的 treatment 工件把每个已发布的 treatment 目录视为自包含证据对比之前先验证其 status、规范化相对路径、producer 绑定、字节长度、哈希、精确记录数、完整报告与语料项目元组。绝不要跟随 provenance 指向的共享缓存或 scoped-base 来源路径去取输入node .agents/skills/run-parity/scripts/verify-matrix-artifact.mjs \ treatment-artifact-directory # 增量 treatment带上规则范围 node .agents/skills/run-parity/scripts/compare-parity.mjs \ --rules treatment-artifact-directory/rules.json \ treatment-artifact-directory/base.ndjson \ treatment-artifact-directory/candidate.ndjson \ treatment-artifact-directory/parity.json # 全量 treatment node .agents/skills/run-parity/scripts/compare-parity.mjs \ treatment-artifact-directory/base.ndjson \ treatment-artifact-directory/candidate.ndjson \ treatment-artifact-directory/parity.jsonverify-matrix-artifact.mjs 的校验逻辑与上述「自包含证据」要求一一对应注意矩阵 lane 是并发执行的其工件仍属诊断证据——不要把矩阵工件喂给性能比较器。增量 Parity影响 manifest 与规则范围对「只改规则」的 PR可在 candidate 运行前构建保守的影响 manifestnode .agents/skills/run-parity/scripts/find-impacted-rules.mjs \ repository-root base-ref head-ref impact.jsonfind-impacted-rules.mjs 的工作原理值得了解因为它决定了「何时可以增量、何时必须全量」构建双向模块图分别用git ls-tree拉取 base 与 head 两个版本下packages/oxlint-plugin-react-doctor/src的运行时源码树RULES_ROOT 覆盖plugin/rules/、plugin/constants/、plugin/utils/三个增量运行时根用 TypeScript 编译器 API 解析每个文件的运行时 import/export/require/动态import()边建立依赖与反向依赖图规则键提取在规则文件中定位defineRule(...)/defineRetiredRule(...)调用的id属性拼出react-doctor/id形式的规则键反向传播从变更文件出发沿反向依赖传播收集被直接影响的规则诊断交互闭包candidateRuleKeys已自动包含已知诊断交互闭包源码 中DIAGNOSTIC_INTERACTION_GROUPS例如no-initialize-state与no-derived-state-effect一族、rules-of-hooks与react-hooks-js/hooks的配对保守回退出现以下任一情况manifest 的mode就是full——security-scan 规则变更全局 runner/config/report/registry 变更规则 ID 删除或重命名未解析的运行时模块边TS 解析失败插件工具模块不经过任何已映射规则边界就触达宿主模块甚至「没有任何运行时规则影响」空增量范围永远不被构造。使用规则只有 manifest 报告mode: incremental时才走增量模式。把candidateRuleKeys原样写入 rules JSON并在 candidate 命令中把每个键作为可重复的--rule参数传入nr --silent eval \ --repositories validated-baseline-or-corpus-manifest \ --react-doctor-repository head-repository-url \ --react-doctor-ref headRefOid \ --rule plugin/rule \ absolute-run-directory/candidate-scoped.ndjsonShadow 校验增量结果必须能被全量复现在增量 parity 积累足够的 shadow 历史、可以成为必选门禁之前技能要求额外做一次全量 candidate在与 scoped 运行完全相同的 head / 语料 / 并发策略下跑一次全量 candidate并要求其规则过滤后的输出与 scoped candidate精确一致。同时报告实测 wall time 与项目级延迟——不要从样本外推加速比。输入校验jq 流式验证器candidate 运行前逐条流式校验 baseline 的每一条记录。validate-parity-input.jq 会在不把整个 NDJSON 语料载入内存的情况下拒绝未 pinref 非 40 位哈希的仓库评估错误记录error字段畸形报告schema 校验支持 v1/v2/v3 报告 schema 与full/diff/staged/baseline模式不完整项目v3 要求complete true、skippedChecks为空、analyzedFileCount analyzedFiles.length等。jq -e -n \ -f repository-root/.agents/skills/run-parity/scripts/validate-parity-input.jq \ absolute-run-directory/baseline.ndjson /dev/nulljq 程序结尾的reduce还会用seen表检查项目键org/name/ref/rootDir四元组的 JSON 序列化不重复。若 baseline 命令退出码非零或该校验失败检查其失败记录并停止。对比诊断compare-parity.mjs 与退出码语义从仓库根目录执行node .agents/skills/run-parity/scripts/compare-parity.mjs \ run-directory/baseline.ndjson \ run-directory/candidate.ndjson \ run-directory/parity.json node .agents/skills/run-parity/scripts/compare-parity-performance.mjs \ run-directory/baseline.ndjson \ run-directory/candidate.ndjson \ run-directory/performance-parity.jsoncompare-parity.mjs的退出码语义源码 中PARITY_DIFFERENCE_EXIT_CODE 1、INVALID_INPUT_EXIT_CODE 2退出码含义0诊断完全一致1对比成功但存在诊断变化added/removed2输入不完整或非法含任一侧出现 skippedProjects 时的保守降级退出码1时先检查受影响的源码位置再对变化定性是真实修复、误报变化还是行为回归。比较器的实现要点阅读 compare-parity.mjs 可以印证技能文档中的每条工程承诺双次校验与 fail closed比较器对两侧输入重新执行与评估器等价的报告校验validateReport见 L313。任何一侧含评估错误、畸形报告、缺失完成标记或残缺 legacy 报告都会以「非法输入」状态退出规范化诊断身份canonicalDiagnosticL182把诊断路径解析为「相对报告根目录」的规范化路径统一 v1/v2/v3 报告 schema 下的身份tags 排序、重复 occurrence 计数保留。因此重叠的 workspace 扫描不会虚增计数schema 升级也不会被误报为诊断 churn流式 临时目录暂存readRun逐行流式读取baseline 记录按项目键的 SHA-256 写入系统临时目录react-doctor-parity-*大尺寸added/removed明细数组通过writeOutputArray增量写出变化的诊断条目只在排序所需时间内驻留内存。因此临时盘与输出容量要与运行规模成比例候选侧更严diagnosticsByIdentity对 candidate 传rejectOutsideRuleScope trueL472scoped 模式下任何范围外的 candidate 诊断直接报错——即「scoped 比较器拒绝任意的范围外 candidate 诊断」。增量scoped对比对 scoped 运行把全量 baseline 过滤到「同样的规则 always-on 不变量范围」后再比node .agents/skills/run-parity/scripts/compare-parity.mjs \ --rules rules.json \ baseline.ndjson \ candidate-scoped.ndjson \ run-directory/parity-scoped.json「always-on 不变量范围」在 源码 中有明确定义INVARIANT_DIAGNOSTIC_PLUGIN TS整个 TypeScript 插件范围TS/*外加一份固定的INVARIANT_DIAGNOSTIC_RULE_KEYS列表expo、pnpm-hardening、reduced-motion、RN 相关等约 20 个react-doctor/规则键。scoped 比较器还会要求精确的项目 / framework / analyzed-file 覆盖coverageFingerprintL416对 v3 报告的项目目录、packageRoot、framework、排序后的 analyzedFiles 做指纹两侧指纹不一致的项目被记入skippedProjects并触发退出码 2保留重复 occurrence 的多重性unchanged取两侧最小 occurrence 数多余部分分别记 added/removed比较全部语义诊断字段包括规范化后的 primary 与 related 路径。性能对比compare-parity-performance.mjs 的阈值体系性能比较器compare-parity-performance.mjs要求完整的 v3 报告且两侧的项目覆盖、规则范围ruleKeys、configContract、evaluatorSourceHash逐项相等任一不等即抛错退出 2。它只能在配对串行--paired-execution sequential评估上运行确保 base 与 candidate 共享同一 Daytona 沙箱、不互相争抢 CPU。退出码0 计时保持在固定的噪声容忍阈值内1 存在实质性项目级或聚合回归2 证据非法。具体阈值全部是源码常量且会原样写入输出的thresholds字段便于审计阈值值说明minimumBaselineElapsedMilliseconds1000 msbase 扫描不足 1 秒的项目被忽略minimumProjectRegressionMilliseconds2000 ms单项目须至少慢 2 秒maximumProjectRegressionRatio1.5且慢于 50%ratio ≥ 1.5才标记单个项目minimumAggregateProjectCount10聚合回归至少需要 10 个合格项目maximumAggregateRegressionRatio1.2且聚合 ratio ≥ 20%minimumAggregateRegressionMs10000 ms且聚合新增延迟 ≥ 10 秒输出的summary还包含 median 与 p95 的项目 ratio 分布L211。技能文档反复强调归因前先看输出的原始测量数据。Merkle 索引同一工件多次对比时的加速路径当同一个 baseline 或 candidate 将被对比不止一次时构建紧凑的 Merkle 索引build-parity-index.mjsnode .agents/skills/run-parity/scripts/build-parity-index.mjs \ --rules rules.json baseline.ndjson \ baseline.index.json node .agents/skills/run-parity/scripts/build-parity-index.mjs \ --candidate --rules rules.json candidate-scoped.ndjson \ candidate.index.json node .agents/skills/run-parity/scripts/compare-parity-indexes.mjs \ baseline.index.json candidate.index.json \ index-diff.json索引结构自底向上哈希每条诊断身份 occurrence 数构成叶节点 → 每个项目, 规则桶的semanticHash→ 每条规则跨项目的semanticHash→ 顶层wholeRunHashsemanticContract固定为compare-parity1算法 sha256。--candidate标志启用与比较器一致的「范围外诊断即拒绝」策略。对比策略见 compare-parity-indexes.mjs根哈希相等立即停止不同则先逐规则下钻再进项目桶。空的项目/规则桶是显式表达的空桶也有哈希不会与缺失混淆规则范围或覆盖元数据漂移会 fail closed。验证比较器本身的变更若你修改了上述任一脚本比较器、性能比较器、影响分析器、索引或输入校验从仓库根运行各自的测试node --test .agents/skills/run-parity/scripts/compare-parity.test.mjs node --test .agents/skills/run-parity/scripts/compare-parity-performance.test.mjs node --test .agents/skills/run-parity/scripts/find-impacted-rules.test.mjs node --test .agents/skills/run-parity/scripts/parity-index.test.mjs node --test .agents/skills/run-parity/scripts/validate-parity-input.test.mjs这些测试文件与脚本同目录如 compare-parity.test.mjs、find-impacted-rules.test.mjs覆盖了 canonical 身份、覆盖指纹、规则范围拒绝、影响图构建与闭包等关键路径。结果报告清单一次 parity 运行的最终报告必须包含以下字段缺一都会削弱结论的可审计性PR URL 与 base/head 两个完整 commit hash对比项目数compared与跳过项目数skipped以及两侧项目总数诊断总数baseline/candidate、added 与 removed 计数最大的规则级 deltarules.added/rules.removed排序后的头部条目所有工件路径baseline.ndjson、candidate.ndjson、parity.json、performance-parity.json及 provenance 文件。小结这套工作流的三条设计主线不可变性40 位提交 pin、语料 manifest 哈希、评估器源码哈希、规则集哈希、provenance 文件——每一层共享baseline 缓存、矩阵 group都以「字节级可复现」为代价换取「跨 PR 复用」的收益fail closed从 jq 输入校验、比较器的二次校验、配对输出的「任一非零即双工件作废」到索引对比对范围漂移的保守失败任何不确定的中间态都不进入 diff增量是优化全量是真理增量范围由保守的模块图影响分析自动推导uncertainty 一律回退全量并且在 shadow 历史足够之前scoped 结果必须由同策略的全量运行精确复现才算可信。【免费下载链接】react-doctorYour agent writes bad React. This catches it项目地址: https://gitcode.com/GitHub_Trending/re/react-doctor创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考