在隔离沙箱中编写并执行崩溃复现脚本以验证安全漏洞（含补丁重攻…

当已有可行发现（viable findings）需要编写并运行 PoC 脚本或原始载荷来实证验证崩溃/漏洞时使用。

适用场景

解决思路

1. 先做定位解析（Locator Resolution）：按优先级确定 CODE_ROOT——若本次调用传入 --target_root 则用它（权威且覆盖 snapshot_root 与状态回退，用于已打补丁的 shadow）；否则用 --snapshot_root/SNAPSHOT_ROOT；否则读 state_root/workspace/.mantis_state.json 的 active_snapshot.root/.snapshot_id/.snapshot_pinned；都没有则 CODE_ROOT=当前目录且 snapshot_pinned=false（MODE-OFF），不要停止。
2. 哨兵检查：仅当 snapshot_pinned 为 true 且未走 --target_root 路径时，验证 CODE_ROOT/.mantis_snapshot_id 存在且等于 SNAPSHOT_ID，否则以 "snapshot sentinel mismatch" 停止（--target_root 树故意被改动，免哨兵检查）。
3. 区分路径字段：SNAPSHOT-RELATIVE（在 CODE_ROOT 下读）包括 code_paths 条目与 plan 中作为文件路径的 target_files，只剥离末尾的 ":<digits>"；含 "://" 的是 URL/端点而非文件；非 <existing-path>:<integer> 形式的是非源码定位符（符号/偏移/端点），只检查其存在性并跳过所有行范围与行存在性逻辑。STATE-RELATIVE（在 state_root/workspace 下读写，绝不加 CODE_ROOT 前缀）包括 kb_references、repro_file_path、reattack_file_path、辅助脚本、报告文件及所有状态/findings JSON。
4. snapshot_pinned 为 true 时绝不写入 CODE_ROOT；任何编译、生成或写产物的命令必须在私有 shadow 副本中运行（用 mktemp -d 从 CODE_ROOT 复制），绝不以 cwd=CODE_ROOT 运行；只读检查可以 cd 进 CODE_ROOT。
5. VCS 元数据例外：历史日志提取与任何 VCS diff/blame 命令在仍含 .git/.hg/.repo 的实时仓库根运行，而非 CODE_ROOT（快照副本剥离了 VCS 元数据）；不要仅因 CODE_ROOT 缺少 .git/.hg/.repo 就停止。
6. 每条 shell 命令使用绝对路径并在该次调用中自行设置工作目录，不要假设工作目录在调用之间保持。
7. 当前 pass 防御性检查：若 active_snapshot 存在且 active_snapshot.pass != state.pass_number，视为该快照对本 pass 已过期——以 "stale active_snapshot: pass mismatch" 停止或降级为 HALT（snapshot_pinned 实际为 false：不产生权威结论，Block B 为 NOT_MATCHED，reproduce 记为 not_attempted）。
8. 对每个 finding 做快照匹配检查（Block B）：snapshot_pinned 为 false 则 NOT_MATCHED 并停止；读 F.discovery_commit，缺失/空/字面 "MIXED" 则 NOT_MATCHED，不等于 SNAPSHOT_ID 则 NOT_MATCHED，恰好等于 SNAPSHOT_ID 则 MATCHED；没有其他路径，绝不模糊比较；discovery_commit 缺失即 NOT_MATCHED（不适用向后兼容的默认字段规则）。
9. 在更新的每个 finding 上打上 repro_snapshot_id（普通运行）或 reattack_snapshot_id（--reattack），值为当前 SNAPSHOT_ID（来自 --snapshot_id 或状态 active_snapshot.snapshot_id）。
10. 加载可行发现：若提供 --finding_id，只加载 state_root/workspace/findings/<uuid>.json，不存在则退出；若同时指定 --reattack，强制校验补丁工作流状态——status 必须为 VALID 或 PROVISIONALLY_VALID，repro_status 必须为 reproduced，patch_status 不得为 MITIGATION_PROPOSED（VERIFIED_SECURE 允许，C5 会在重攻击结果非 failed_to_bypass 时原子降级），不满足则报错退出。
11. 若提供 --finding_id 但未指定 --reattack（定向普通运行）：未指定 --force 时强制标准资格过滤——status 必须为 VALID 或 PROVISIONALLY_VALID，production_viability 必须为 VIABLE、SAMPLE_OR_TEST 或 CONDITIONAL_VIABLE，不满足则报错退出；指定 --force 时绕过这些资格检查。
12. 若未提供 --finding_id：若指定了 --reattack 则退出（它需要 --finding_id）；读取 state_root/workspace/findings/ 下的 JSON 文件；普通运行严格资格过滤——只纳入 status 为 VALID 或 PROVISIONALLY_VALID 且 production_viability 为 VIABLE、SAMPLE_OR_TEST 或 CONDITIONAL_VIABLE 的发现（若不检查可行性可跳过可行性过滤，但始终检查 status）；无适用发现则通知用户并退出。
13. Tier 0 结构可达性预检（仅作建议性队列排序）：若有结构代码索引（mantis-structural-index），可在编写代码前用 query_structural_index.py（find_callers）查询从公共入口到漏洞 sink 是否存在 AST 调用路径，用于优先排序候选执行顺序（先处理已验证 AST 可达的发现）；关键护栏——AST 可达性只是排序提示，调用图会漏掉宏、函数指针、动态分派和接口表，缺失调用路径绝不能拒绝发现、跳过复现或设置 failed_to_reproduce。
14. 快照漂移检查：对每个已加载发现，若已有 repro_snapshot_id 且 Block B 返回 NOT_MATCHED，则把已存 PoC/偏移视为过期，针对当前 CODE_ROOT 从头重新生成复现器（不复用旧行号/地址）；若 Block B 为 MATCHED 则可复用已有 PoC。
15. 严格主机隔离：禁止在父主机终端直接执行命令；所有复现器执行必须隔离，使用环境提供的容器化或沙箱执行工具；内存安全 PoC 尽量限制网络访问与文件系统写入；逻辑/认证功能测试可按需启用本地网络服务，但绝不将环境暴露到外部互联网。
16. 编写并启动复现器：写自包含测试脚本（如 poc_[uuid].py 或同目录 C 复现文件）或原始崩溃输入载荷（如 crash_[uuid].payload）触发目标 bug；所有生成的 PoC/重攻击脚本与载荷必须写在 state_root/workspace/reproducers/ 目录内（绝不写在 target_root 目录）；写文件前先用 mkdir -p 确保父目录存在；仔细分析代码路径与约束；初次复现失败时，根据观察评估 finding 细节（输入路径、参数、假设）是否略有错误并动态调整以尝试修复；多种方法与调整后仍找不到可触发路径则放弃尝试，但不要直接标记 failed_to_reproduce——把放弃决策走 Step-5 Block F（Reached-Sink Evidence）门：若 harness 可证明到达了漏洞入口但 bug 未触发，归类 failed_to_reproduce；若证据缺失（setup/build 失败、exit 127、"No such file"、或 sink 从未到达），归类 not_attempted（可重试）；setup/build 失败导致的原始负面结果会烧掉重试上限并静默丢掉真实 bug。
17. 运行脚本或载荷时使用环境中的执行或容器化工具安全执行；选择最合适的运行时镜像与标志；所有编译与测试执行命令必须在私有 BUILD SHADOW 中运行，绝不以 Cwd=CODE_ROOT（快照只读）；编译前创建 BUILD_ROOT=$(mktemp -d) 并把 CODE_ROOT 复制进去（如 cp -a CODE_ROOT/. BUILD_ROOT/），所有编译/测试命令以 Cwd=BUILD_ROOT 运行，teardown 时删除 BUILD_ROOT；生成的 PoC 文件本身保留在 state_root/workspace/reproducers/（STATE-RELATIVE），并把其绝对路径存入 run_command/reattack_run_command。
18. Sanitizer 编译（C/C++ 目标）：bug 类为内存安全或未定义行为时，至少用 -fsanitize=address,undefined（ASan+UBSan）编译；数据竞争加 -fsanitize=thread（TSan），TSan 与 ASan 互斥，需单独构建；用 -fno-omit-frame-pointer 获得可用栈回溯；这些标志能暴露否则静默 exit 0 的 bug（UBSan 默认 recover 模式）。MSan 注意：-fsanitize=memory 检测未初始化内存读取，但要求整条依赖链（含 libc 与 C++ 运行时）都用 MSan 插桩，任意目标通常不满足，朴素 -fsanitize=memory 构建会产生虚假 WARNING: MemorySanitizer 回溯；MSan 也与 ASan 互斥（单独构建，不能叠加标志）；若无法保证完整插桩的 MSan 环境，不要加 -fsanitize=memory，回退到 ASan+UBSan，而不是信任可能虚假的 MSan 回溯；当有合法 MSan 插桩构建时，把 MSan 输出识别为证据（Step 5）仍然正确。Sanitizer 一致性护栏：baseline、attack、re-attack 运行必须使用相同的 sanitizer 标志——不同 sanitizer 会掩盖 bug 产生假阴性（INV-2）或假 VERIFIED_SECURE（INV-1）。
19. {TARGET_ROOT} 令牌替换：写 run_command 或 reattack_run_command 时，任何引用目标树的路径用字面令牌 {TARGET_ROOT}；运行时 reproduce 把 {TARGET_ROOT} 替换为实际根——首次执行用 CODE_ROOT（快照或 --target_root），重执行（重攻击或重试）用当前 CODE_ROOT/--target_root/active_snapshot.root；这确保快照 GC 后存储命令仍能正确解析，绝不把绝对 .mantis_snapshots/pass_<N> 路径写进存储命令。
20. 用合适环境执行复现：目标是固件可用 qemu、unicorn 或 Firmadyne 写脚本启动；是二进制可用动态插桩或标准执行；自行判断构造可用的 harness。
21. 并行轨迹搜索（广度优先）：有子代理时部署并发 worker 采取多样逻辑方法复现 bug；任一轨迹成功立即采用其载荷并丢弃其他，以摆脱可能的放弃循环并削减算力成本。
22. 分层迭代复现（深度优先载荷精炼）：每个轨迹 worker（或单代理）使用分层升级阶梯（Tier 1 -> Tier 2 -> Tier 3）逐步精炼触发载荷，而非一次性端到端启动。
23. Tier 1（微 harness / sink 逻辑验证）：构造轻量测试直接调用漏洞函数/模块，隔离验证核心 bug 假设是否成立。
24. Tier 2（子系统 / 接口验证）：让载荷经过输入序列化、解析器、路由与认证包装，验证输入在中间处理中未被净化或截断而存活。
25. Tier 3（完整沙箱服务 / E2E 验证）：在隔离沙箱（Docker、QEMU、VM）内通过公共 API 对目标服务执行自包含 PoC，产出 Block F 的权威 reproduced 结论。
26. 关键 Step-4 Tier-1 硬门（Fail-Closed）：Tier 1 和 Tier 2 只是内部踏脚石，绝不能基于 Tier-1 或 Tier-2 执行记录 repro_status = "reproduced" 或 "statically_confirmed"；若崩溃只能通过编译直接调用 harness 喂私有/静态函数或绕过公共 API 实现，且载荷无法升级到 Tier 3（公共 API/沙箱服务）触发，必须终止并记录 repro_status = "failed_to_reproduce"，详情引用 "Internal Invariant Protection"。
27. 尝试次数核算与本地重试：Tier-1 与 Tier-2 内部试运行是有界本地执行步骤（每会话最多 3 次试执行），不增加 state_root/workspace/archive/.repro_attempts.json 中的绝对每发现尝试计数；只有 Tier-3 完整沙箱服务执行（或完整端到端复现器运行）才增加绝对尝试计数，硬上限为 6；某层失败时检查日志、调整载荷参数、修复 harness 设置，并在当前会话内重试 2-3 次后再向编排器报告。
28. 变体搜寻（仅 --reattack，强制）：以 --reattack 调用时，除重跑原始 PoC 外，必须编写并执行 N ≥ 3 个边界变异变体输入；schema 明确称之为 "variant-hunting re-attack"，仅重跑原始 PoC 不够；过窄补丁只守护精确 PoC 字节是自动修复的主要失败模式，变体搜寻是零基础设施成本的防御。
29. 遗留发现：缺少 reattack_variants 的发现（在此规则存在前创建）在首次 --reattack pass 时按 ≥3 变体要求重新验证；这是有意的——遗留 VERIFIED_SECURE 结论升级到更严格门——但预期首次运行变体搜寻的 pass 会在归档发现上产生一次性变动。
30. 按 bug 类生成变体——内存安全 bug（缓冲区溢出、OOB 读写、UAF、整数溢出）：至少编写以下 3 个：off-by-one（len = bound、len = bound + 1、len = bound - 1）；大小变异（len ± 1、len = 0、len = SIZE_MAX、有符号长度符号翻转）；到同一 sink 的替代路径（若漏洞 sink 可通过多个调用点到达，编写通过不同路径到达的变体，如不同 API 端点、文件格式变体或协议命令）；类型混淆/宽度不匹配（利用不同类型路径到达同一 sink）。
31. 按 bug 类生成变体——非内存安全 bug（逻辑、认证、注入、SSRF、路径遍历）：搜寻同类真实变体——替代端点/参数（PoC 针对 /api/v1/echo 时试 /api/v2/echo，或替代参数名）；等价载荷（..%2fetc%2fpasswd、..\\..\\、URL 编码、双重编码、unicode 规范化变体）；认证边界变体（不同角色、空/null token、替代提权路径）；注入变体（'; EXEC--、 UNION SELECT、盲注变体、替代注入点）。
32. 并行变体生成（有子代理时）：应生成子代理并行编写与测试变体；每个子代理拿一种变异策略，写其变体 PoC 并报告是否触发；设置 reattack_status 前汇总所有结果；子代理不可用时顺序执行。
33. 执行变体：把每个变体写成 state_root/workspace/reproducers/ 下的独立脚本（如 reattack_variant_[uuid]_[N].py）；用与 Step 3 相同的隔离约束对已打补丁 shadow（--target_root）执行每个变体；用精确 schema 键 {"description": "...", "triggered": true/false} 把每个变体记录到 reattack_variants 数组（Step 6）。
34. 结论规则：reattack_status = "failed_to_bypass" 要求 reattack_variants 数组非空且含 ≥ 3 个有效变体输入，且全部未能在已打补丁 shadow 上触发 bug；空或过短的集合会让 "所有变体失败" 空洞成立——这是禁止的：若真正努力后仍无法构造 3 个有意义的变体，封顶为 VERIFICATION_INCOMPLETE（history 注记 insufficient_variants），绝不 failed_to_bypass；[] 情况只能与非 failed_to_bypass 状态共存（如 C5 baseline 失败在变体搜寻前就停止）。
35. 变体有效性护栏：变体只有在同时满足以下两条时才计为绕过（triggered = true 导致 bypassed_patch）：1) 同一漏洞类——变体复现原始 bug 类（同一 sink 函数/sanitizer 签名/崩溃类型）；垃圾变异体（如 len=SIZE_MAX 导致无关 OOM、替代端点 404 后报错、或完全不同的崩溃）不算绕过，丢弃它（设 triggered = false 并在描述中注明无效）并继续；对非内存 bug（逻辑、认证、注入），比较同一 sink 函数或行为（如同一未授权操作成功、同一注入执行、到达同一 sink 函数）——而不是对补丁前行号做 ±行窗口（补丁会移动行，非内存 bug 常无精确 sink 行）；若无法正面确认触发变体是不同 bug，按绕过计（fail-closed：宁可假 VERIFICATION_FAILED 也不要假 VERIFIED_SECURE）。2) 按 Step 4 是有效输入——变体必须是公共 API 或内部不变量的有效行使，不得依赖人工 harness 技巧（如私有函数直接调用配自定义分配缓冲区）绕过库执行不变量。
36. 理想情况下确认每个触发变体在未打补丁 shadow（原始 PoC 所跑的同一 baseline）上仍触发，以证明它行使的是原始 bug 而非伪影；若未打补丁 shadow 不可用（如快照不匹配），要求同一 sink 证据（同一 sanitizer 帧、同一崩溃地址、同一逻辑失败）作为佐证。
37. 若任何有效变体触发 bug，设 reattack_status = "bypassed_patch" 并应用 INV-1（把 VERIFIED_SECURE 降级为 VERIFICATION_FAILED）。
38. 复现状态分类：reproduced（PoC 成功触发漏洞）；failed_to_reproduce（PoC 已执行但未触发漏洞）；statically_confirmed（因环境限制无法复现，如缺硬件模拟器、外部服务不可用，但缺陷静态明显，如硬编码凭据；强烈不鼓励，仅作最后手段）；not_attempted（复现阶段完全跳过，如基础设施 setup 失败、超时或显式跳过配置）。
39. 严格公共 API 与内部不变量约束：崩溃复现器应尽可能通过公共 API 与代码库交互，或严格遵守库的全局执行不变量（如分配器填充）以避免产生人工、不可行的崩溃；若崩溃只能通过编译直接调用 harness 喂私有/静态函数自定义分配缓冲区（如 malloc(15)）绕过库保证的分配器包装（如 png_malloc(rowbytes + 48)）实现，不得声明为 reproduced；若无法通过公共 API 或标准分配填充触发崩溃，以 "Internal Invariant Protection" 归类为 failed_to_reproduce。
40. 功能与崩溃感知验证：分析 stdout、stderr 与退出码，按 bug 类分类复现成功；在分类任何负面结果（failed_to_reproduce，或 --reattack 模式下的 failed_to_bypass）前，应用 REACHED-SINK EVIDENCE GATE（机械门）：每个复现器通过一个通道产生 REACHED-SINK EVIDENCE 并记录在 repro_hints——(a) 脚本/源码 harness：在调用 sink 前把精确字节 MANTIS_REACHED_ENTRYPOINT 写入 sidecar 文件 $SENTINEL_FILE 并 flush+fsync（或无缓冲写），文件能在截断缓冲 stdout 的崩溃中存活；(b) 二进制/固件/原始载荷：到达 sink 证据是捕获的崩溃回溯或 sanitizer 帧（ASan/UBSan/MSan/TSan）明确命名目标 sink 函数（目标产生的追踪）；你编写的包装器在调用目标前写的标记只是 SETUP EVIDENCE，证明 "启动已尝试" 而非 "sink 已到达"，不算到达 sink 证据；若既无路径内标记（通道 a）也无目标产生的回溯/sanitizer 追踪（通道 b），则 sink 未到达。EVIDENCE PRESENT（到达 sink）= 通道 a sidecar 文件含路径内写入的 MANTIS_REACHED_ENTRYPOINT，或通道 b 目标产生的回溯/sanitizer 输出命名 sink；仅包装器预启动标记不算证据存在。EVIDENCE ABSENT 包括：任何编译器/构建非零退出；exit 127（命令未找到）；exit 2 且带 "No such file" 消息。决策门（门控决策而非特定结论字符串）：仅当 EVIDENCE PRESENT 才记录 repro_status = reproduced 或 statically_confirmed；若 ABSENT 则 repro_status = not_attempted（可重试）并停止；补丁验证中 EVIDENCE 要求在未打补丁 baseline（Block G）上，而非补丁后 attack 运行（正确补丁合法地在 sink 前阻止输入）；若此目标无法实现任何证据通道，降级为 not_attempted / VERIFICATION_INCOMPLETE，绝不合成标记。
41. 具体而言：若运行未产生到达 sink 证据（构建/setup 错误、exit 127、"No such file"、或 sink 从未到达），记录 repro_status = not_attempted（可重试）——绝不 failed_to_reproduce；--reattack 模式下保持 reattack_status 未设置并加 history 注记 "setup_failed"——绝不 failed_to_bypass；仅当 harness 可证明到达漏洞入口且 bug 未触发时才分类为负面。
42. HALT 上限（3 态规则）：若状态中 active_snapshot 存在但 snapshot_pinned 为 false（HALT 模式——树竞态或无法固定），绝不能记录 failed_to_reproduce 或 failed_to_bypass；HALT 中代码可能已漂移，负面复现结果不可信为权威；改为记录 repro_status = not_attempted（可重试），--reattack 模式下保持 reattack_status 未设置并加 history 注记 "HALT mode: snapshot unpinned, negative result suppressed"；这与 HALT 中所有阶段的权威结论禁令一致（MODE-OFF——无 active_snapshot——则照常分类负面）。
43. 逻辑与授权 bug：成功复现器是功能单元测试或脚本，明确展示逻辑失败（如未授权请求返回 200 OK，或测试脚本成功绕过验证并以 0 退出）。
44. 内存安全与二进制崩溃：若沙箱执行在 stdout/stderr 产生崩溃信号或 sanitizer 追踪，标记复现为 reproduced；无论退出码如何都扫描 stdout/stderr 中的 sanitizer 签名——UBSan 默认 recover 模式（exit 0），所以 exit-0 运行仍可能含有效 UBSan 追踪证明 bug 触发；检查：AddressSanitizer（ASan）错误输出（如 ERROR: AddressSanitizer）；UndefinedBehaviorSanitizer（UBSan）运行时报告（如 runtime error:、SUMMARY: UndefinedBehaviorSanitizer）；MemorySanitizer（MSan）错误输出（如 WARNING: MemorySanitizer）——仅当 repro_hints 记录有完整插桩 MSan 构建时 MSan 证据有效（Step 3 注意），无完整插桩的朴素 -fsanitize=memory 构建产生虚假追踪，不要分类为 reproduced；ThreadSanitizer（TSan）竞争报告（如 WARNING: ThreadSanitizer）；段错误（SIGSEGV，退出码 139）；中止信号（SIGABRT，退出码 134）；崩溃或核心转储。
45. Token 优化文件更新：为最小化 LLM 输出 token，不要重新输出或手动重写整个 JSON 对象；改用就地编辑工具（如首选语言的短脚本或 jq）以编程方式把新字段追加到现有 state_root/workspace/findings/<id>.json 文件。
46. 更新复现尝试缓存：维护 JSON 缓存文件 state_root/workspace/archive/.repro_attempts.json；创建、读取或锁定缓存文件前先用 mkdir -p 确保父目录 state_root/workspace/archive/ 存在。
47. 缓存键用跨循环运行稳定、即使 UUID 重新生成也持久的标识符：若 finding 有 signature 字段，直接用它作缓存键（它已是确定性内容身份哈希）；若 signature 缺失，用 finding 的规范化标题与其主文件路径计算稳定键：stable_key = normalized_title + "@" + primary_file_path；normalized_title 通过标题转小写并移除非字母数字字符计算；primary_file_path 取 code_paths 第一项并剥离行号后缀（如 src/auth.c:120 转为 src/auth.c）。
48. 快照感知上限（值形状 {count, last_snapshot}）：每个缓存值存为对象 {count, last_snapshot}；读值 V 时，若 V 是裸整数则 count=V 且 last_snapshot=UNKNOWN，若 V 是对象则用 V.count/V.last_snapshot（默认 UNKNOWN）；递增前运行 Block B 比较 finding 快照与当前 SNAPSHOT_ID：仅当 Block B 为 NOT_MATCHED 且因两个快照都存在且确实不同时才重置 count=0（真实代码变更赢得新预算）；UNKNOWN（缺失/pass_/未固定）时不重置——否则无 VCS 目标会永远重试；另外维护一个绝不重置的绝对每 finding-id 尝试计数器，达到硬上限（如 6）后无论快照变化都停止重试。
49. 防止并发执行竞态（包括原子文件替换导致的锁绕过）并保护无锁读者：使用单独的专用锁文件 state_root/workspace/archive/.repro_attempts.lock，它绝不删除或替换；用 Python 的 fcntl.flock 在此锁文件上原子更新：打开锁文件（缺失则创建）并在上下文管理器（with 语句）内获取排他锁（fcntl.flock 配 fcntl.LOCK_EX）；读缓存文件 state_root/workspace/archive/.repro_attempts.json 当前内容（缺失或空视为 {}）；仅对 Tier-3（完整端到端沙箱服务）执行把此 finding 缓存键条目（有 signature 用 signature，否则用 stable_key，同一键选择）的 count 字段加 1——内部 Tier-1 与 Tier-2 踏脚石试运行不得增加 count（受 Step 3 子预算规则约束）；把更新后 JSON 写到同目录临时文件（如 state_root/workspace/archive/.repro_attempts.json.tmp）；用临时文件原子替换目标缓存文件（如 Python 的 os.replace）确保读者永不见截断或不完整文件；关闭锁文件描述符释放锁（退出 with 上下文管理器自动处理）。
50. 普通运行（无 --reattack 标志）时在现有对象上追加或更新：repro_status（reproduced、statically_confirmed、not_attempted 或 failed_to_reproduce）；repro_file_path；run_command；repro_output；repro_snapshot_id（本次运行针对的当前 SNAPSHOT_ID）；repro_hints（记录编译与沙箱执行遥测，如 sanitizers_used: ASan+UBSan、assertions_disabled: true、build_profile: release，为 /mantis-critic 提供实证执行证据）。
51. 若复现成功（repro_status 评估为 reproduced 或 statically_confirmed）且 finding 当前 status 为 PROVISIONALLY_VALID：升级前扫描 finding 的 triage_checklist（若存在）；若任一条目 outcome == "UNKNOWN"（或 passes == false），不要升级——保持 status 为 PROVISIONALLY_VALID，仍把 repro_status 设为成功值（复现确实成功），并追加 history 注记 upgrade-to-VALID-blocked: triage_checklist has UNKNOWN entries (re-review required)；这避免违反 schema 的 VALID ⇒ no UNKNOWN allOf 门（schema.json 471-507 行），该门禁止任何 VALID 非链式 finding 的 triage_checklist 出现 UNKNOWN/passes:false；reproduce 不触碰 triage_checklist 条目（清单是 review 的产物，只有 review 可解决 UNKNOWN 条目）；若 triage_checklist 缺失（无 reviewer history 条目，如遗留 finding），或无条目为 UNKNOWN/passes:false，则必须把 status 更新为 VALID。
52. 普通运行时向 history 数组追加条目：{"stage": "reproduce", "action": "reproduced", "details": "Reproduction status evaluated as [reproduced/failed_to_reproduce] using command: [run_command]", "pass_number": <current_pass_number>, "timestamp": "<current_iso8601_timestamp>"}。
53. --reattack 运行时在现有对象上追加或更新（不触碰 repro_* 或 status）：reattack_status（bypassed_patch、failed_to_bypass、inconclusive_baseline_changed）；bypassed_patch——PoC 绕过补丁并触发 bug，若 patch_status 为 VERIFIED_SECURE 则在同一写入中原子设 patch_status = "VERIFICATION_FAILED"（绕过击败补丁），这是 "不触碰 status" 的显式例外，适用于 C5 step-3 路径与同快照运行；failed_to_bypass——PoC 已运行但未能绕过补丁（无需降级——failed_to_bypass 是 allOf 门对 VERIFIED_SECURE 要求的值）；inconclusive_baseline_changed——未打补丁 baseline 被重跑（见 C5）且 bug 在当前未打补丁代码上不再触发，不要声称 failed_to_bypass，若 patch_status 为 VERIFIED_SECURE 则在同一写入中原子设 patch_status = "VERIFICATION_INCOMPLETE"。
54. INV-1（单一来源——schema 的 VERIFIED_SECURE allOf 门）：VERIFIED_SECURE => reattack_status 必须为 failed_to_bypass，且 failed_to_bypass 要求 reattack_variants 数组非空且含 ≥ 3 个有效变体输入（Step 3a）且全部未能在已打补丁 shadow 上触发 bug；空或过短变体集让 "全部失败" 空洞成立——这是禁止的：改为封顶 VERIFICATION_INCOMPLETE；任何其他结果必须在同一写入中原子降级 patch_status——inconclusive_baseline_changed 或变体集不足用 VERIFICATION_INCOMPLETE，bypassed_patch 用 VERIFICATION_FAILED；绝不把 VERIFIED_SECURE 与非 failed_to_bypass 的 reattack_status 一起持久化。
55. 快照不匹配 -> 由下方 C5 治理：当 reattack_snapshot_id != repro_snapshot_id 时，不要独立记录结论——遵循 C5，它在当前快照上重建未打补丁 baseline；若 C5 无法运行，回退为保持 reattack_status 未设置并加 SNAPSHOT_MISMATCH history 注记。
56. C5——未打补丁 baseline 重跑（Phase 2）：在已打补丁构建上运行 attack 前，若 reattack_snapshot_id != repro_snapshot_id（真实快照变化，非 HALT 模式 live: 树），先重建未打补丁 baseline：1) 对当前快照的全新未打补丁副本运行复现器——active_snapshot.root 的全新 mktemp -d 副本，而非已打补丁 shadow（这与 mantis-patch Block G step 1 运行的未打补丁 baseline 相同；reproduce 没有 Block G）；2) 若未打补丁 baseline 未触发（按 Block F 证据缺失）：设 reattack_status = "inconclusive_baseline_changed"，不继续 attack，不声称 failed_to_bypass；仍必须用 baseline 重跑的详情填充 reattack_file_path、reattack_run_command 与 reattack_output；应用 INV-1（把 VERIFIED_SECURE 降级为 VERIFICATION_INCOMPLETE）；3) 若未打补丁 baseline 确实触发：继续 attack（bypassed_patch 或 failed_to_bypass）；应用 INV-1（若 bypassed_patch 则把 VERIFIED_SECURE 降级为 VERIFICATION_FAILED）。
57. C5 sanitizer 一致性：baseline 重跑、attack 与 re-attack 必须使用使原始 baseline 触发的相同 sanitizer 标志；若 baseline 通过 UBSan（exit 0）触发，不带 UBSan 重新编译 attack 会掩盖 bug 产生假阴性（INV-2）或假 failed_to_bypass（INV-1）。
58. C5 HALT 模式护栏：通过状态中该 pass 的快照 id（active_snapshot.snapshot_id 以 live: 开头）检测 HALT，而非 --snapshot_pinned=false 参数（那只是已打补丁 shadow 的哨兵豁免）；HALT 中跳过 C5 并遵循现有 HALT 上限（保持 reattack_status 未设置并加 HALT 注记）；这不改变 VERIFIED_SECURE 门——Block G 仍要求未打补丁 baseline 触发。
59. --reattack 运行时还追加或更新：reattack_file_path；reattack_run_command；reattack_output；reattack_variants——对象数组，每个对应 Step 3a 尝试的一个变体输入，每个对象必须恰好含两个必需键 "description"（字符串）与 "triggered"（布尔），不要发明自由形式或自定义键（如 input、result、bypassed、label、name）；description 说明变体做什么（如 "off-by-one: len=bound+1"、"alternate path via /api/v2/echo"）；triggered 为布尔——此变体是否在已打补丁 shadow 上触发原始漏洞类（按 Step 3a 变体有效性护栏）；产生无关崩溃或错误的无效/垃圾变异体记录为 triggered = false 并在描述中注明无效；reattack_status = "failed_to_bypass" 时 reattack_variants 必须非空（≥ 3 条目）；空数组 [] 只能与非 failed_to_bypass 状态共存（如 C5 baseline 失败在变体搜寻前停止，或 inconclusive_baseline_changed）。
60. --reattack 运行时还更新 reattack_snapshot_id（本次运行针对的当前 SNAPSHOT_ID），并向 history 数组追加条目：{"stage": "reattack", "action": "reproduced", "details": "Re-attack status evaluated as [bypassed_patch/failed_to_bypass] using command: [reattack_run_command]", "pass_number": <current_pass_number>, "timestamp": "<current_iso8601_timestamp>"}。
61. 复现有效性批判：为确保复现是报告漏洞的有效示例，让一个全新上下文窗口的子代理审查并批判生成的 PoC；寻求真实批判以确保虚假报告日后永不浮现。
62. 变体批判（仅 --reattack）：指定 --reattack 时，批判子代理还必须验证变体输入（Step 3a）确实多样——不是平凡相同的变异（如改注释但保持同一载荷）；若批判者发现变体不够有意义地多样，记录 history 注记 variant_diversity_insufficient 并在最终确定 reattack_status 前重新编写变体。
63. 完成后通知用户。

适用边界 · 注意事项

• 不要用于代码审计或打补丁（code auditing or patching）。
• 未提供 --finding_id 时不要指定 --reattack（它需要 --finding_id）。
• 不要在父主机终端直接执行命令，所有复现器执行必须隔离在沙箱/容器中。