ralph-flow-pi 0.1.0

package/skills/everything2rust-validate/SKILL.md

@@ -0,0 +1,85 @@
+---
+name: everything2rust-validate
+description: 独立 QA 视角对 everything2rust 重构做最终验收。跑全量构建/测试/lint/geiger/覆盖率/smoke，逐能力核对行为契约，逐条验收标准取证，产出 report.md。在 everything2rust 工作流的 verify 步骤触发。
+---
+
+你是独立 QA，对完成的 Rust 重构做发布前验收。原则：**每条结论都要附你亲手采集的证据**（命令 + 输出片段），不引用之前步骤的自述。发现不达标项立即修复，修完重新取证。
+
+## 输入 / 输出
+
+> `<产出目录>` = DO 提示词「产出目录」一节给出的路径（形如 `.ralph-flow/artifacts/<任务摘要>-<后缀>/`）。
+
+- 输入：完成的 Rust 项目 + `<产出目录>/plan.json` + `behavior-spec.md` + `golden/` + 源项目路径
+- 输出：`<产出目录>/report.md` — 逐条验收标准的 PASS/FAIL + 证据
+
+## 验收标准与取证方法
+
+在 plan.json `target.output_dir` 下逐条执行：
+
+### 1. 可构建可运行
+
+```bash
+cargo build --release 2>&1 | tail -3        # 零 error
+<plan.json target.smoke_cmd>                # 正常启动不 panic，记录输出
+```
+
+### 2. 测试全绿 + lint 干净
+
+```bash
+cargo test --all 2>&1 | tail -10            # 无 FAILED；统计 passed 数
+grep -rn '#\[ignore' src/ tests/            # 只允许差分测试的 ignore（有标注理由）
+cargo clippy -- -D warnings 2>&1 | tail -3
+```
+
+### 3. 全量实现无桩
+
+```bash
+grep -rn 'todo!\|unimplemented!\|dbg!' src/ tests/   # 应为空
+jq -r '.capabilities[] | select(.status!="done") | .id' <产出目录>/plan.json  # 应为空
+```
+
+抽查 3-5 个能力的实现：非空函数体、非仅返回默认值。
+
+### 4. Unsafe 在预算内
+
+```bash
+RATIO=$(cargo geiger 2>/dev/null | grep -m1 -F "$(basename "$PWD") " | grep -oE '[0-9]+/[0-9]+' | sed -n '2p')
+U=${RATIO%/*}; T=${RATIO#*/}
+awk -v u="$U" -v t="$T" -v b="<unsafe_budget_pct>" 'BEGIN{ if(t==""||t+0==0){print "geiger 解析失败"; exit 2} r=u*100/t; printf "unsafe expr %d/%d = %.1f%% (target <%s%%)\n",u,t,r,b; exit (r<b?0:1) }'
+grep -rn 'unsafe' src/ | grep -v 'SAFETY'    # 每处 unsafe 上一行应有 SAFETY 注释（人工核对输出）
+```
+
+### 5. 行为等价（核心标准）
+
+- golden 语料测试全过（含在 cargo test 里，单独确认对应测试名出现在 passed 列表）
+- 原系统可运行时跑差分：`cargo test -- --ignored 2>&1 | tail -10`
+- 对照 behavior-spec.md 逐能力过一遍 audit 留下的 notes（plan.json）——audit 修复过的点重点复验
+- checklist 能力：核对 `tests/CHECKLIST.md` 的核对记录；能当场验证的抽验 2-3 条
+- 数据格式互通：抽一个格式做双向读写验证
+- 确认无 parity_exceptions 之外的行为偏差；parity_exceptions 逐条确认有 ADR 依据
+
+### 6. 主干路径覆盖
+
+```bash
+cargo llvm-cov --summary-only 2>&1 | tail -5
+```
+
+覆盖率是参考不是门槛——重点人工确认：核心能力有针对性测试、happy path 和 error path 都有、边界有、确定性核心有 property 测试（对照 test-map.json 抽查）。
+
+## report.md 结构
+
+```markdown
+# everything2rust 验收报告：<项目名>
+## 概览        — 源系统 → Rust 的一段话总结；能力数、测试数、代码规模
+## 验收结果    — 7 条标准的 PASS/FAIL 表
+## 逐条证据    — 每条标准：执行的命令 + 输出片段 + 结论
+## 行为等价明细 — 逐能力：预言策略 / 测试结果 / audit notes / 复验结论
+## parity_exceptions — 白名单逐条 + ADR 引用
+## 遗留与建议  — 未验证项（含原因）、后续改进建议
+```
+
+## 完成标准
+
+- report.md 七条标准全 PASS，每条有亲手采集的证据
+- 发现的不达标项已修复并重新取证
+- 无声明外的行为偏差；checklist 未验证项如实标注原因

package/workflows/c-to-rust.yaml

@@ -0,0 +1,202 @@
+description: |
+  C 项目 → 惯用安全 Rust（binary target）：逐模块渐进移植 + TDD，unsafe<10%。
+
+adversarial_check:
+  timeout_ms: 3600000
+  model: "anthropic/claude-opus-4-5"
+steps:
+
+  - id: setup-env
+    desc: 环境配置——安装并校验工具链，fail-fast
+    do: |
+      你是搭建 CI 环境的工程师。安装并校验本工作流依赖的全部工具，确保后续步骤不会因缺工具而中途退化。直接执行安装命令，不要只列清单。先探测再决定：已就绪的工具直接复用、只补缺失的（保持幂等）。
+
+      必须就绪（缺则安装）：
+      - Rust 工具链：rustc / cargo（rustup 安装），组件 clippy、rustfmt
+      - cargo-geiger：cargo install cargo-geiger --locked。若编译失败，尝试较早版本
+      - cargo-audit：cargo install cargo-audit --locked
+      - cargo-llvm-cov：cargo install cargo-llvm-cov --locked，并 rustup component add llvm-tools-preview
+      - C 工具链与构建系统：编译/运行 C 测试所需（gcc 或 clang、make，若 C 项目用 cmake/meson 则一并装上）
+      - 文本/算术辅助：jq、bc
+
+      安装后把每个工具的版本写入 env.md。
+      任一必须工具无法安装时，如实说明卡点，不要输出 done。
+    input: 无
+    output: env.md（工具版本快照）；全部必须工具可调用
+    check: |
+      自主验证：
+      1. env.md 存在，列出各工具版本（无占位符）
+      2. cargo geiger --version、cargo clippy --version、cargo audit --version、cargo llvm-cov --version 均正常输出
+      3. jq --version、bc --version 均正常输出
+    on_pass: analyze
+    on_fail: setup-env
+    max_fail_count: 5
+
+  - id: analyze
+    desc: C 项目分析——探测布局/测试框架/构建系统，提取 API，依赖分层，产出 plan.json
+    do: |
+      使用 c-to-rust-plan skill（在可用 skill 列表中按 location 读取它）。
+      你是接手陌生 C 代码库的工程师。先探测项目真实布局（不要假设 src/inc），
+      识别测试框架与构建系统，再提取公开/内部 API、构建依赖分层、产出 plan.json + api-inventory.md + function-contracts.md。
+    input: C 项目源码目录路径
+    output: plan.json + api-inventory.md + function-contracts.md
+    check: |
+      自主验证：
+      1. plan.json 是合法 JSON，modules 覆盖每个非测试/非 vendor 的 .c 源文件
+      2. layers 是无环分层，每个 depends_on 只引用更低层
+      3. 每个模块含 public_functions、internal_functions、difficulty、recommended_crates、c_advanced_features
+      4. plan.json 含 output_name、output_dir、source_c_dir、c_test_dir、project_layout、test_framework、build_system、conditional_compilation、inline_asm_modules、completed_modules 字段
+      5. project_layout 真实反映探测结果（非硬编码 src/inc）
+      6. output_dir 是绝对路径且位于工作区内
+      7. api-inventory.md 列出每个 C 公开函数及拟议 Rust 签名
+      8. function-contracts.md 对复杂函数记录了语义要点
+    on_pass: baseline
+    on_fail: analyze
+    max_fail_count: 5
+
+  - id: baseline
+    desc: TDD 红阶段——Rust binary 骨架、API 桩、移植全部 C 测试、属性测试
+    do: |
+      使用 c-to-rust-test-gen skill（在可用 skill 列表中按 location 读取它）。
+      严格 RED：先确认 C 测试套件全绿，再建 binary target Rust 项目骨架，写好类型与错误，
+      把每个 C 测试移植成 Rust #[test]（断言语义精确保留，不合并降级）。
+      每个模块补属性测试（proptest）。所有桩用 todo!("module::fn") 占位。
+      目标状态：cargo build 通过，cargo test 因 todo!() 而 FAILED。
+    input: plan.json + C 源码 + C 测试
+    output: |
+      <output_name>_rust/ — Cargo binary 项目（src/main.rs + lib.rs + types.rs + error.rs + 各模块桩，
+      tests/oracle_*.rs + prop_*.rs）
+    check: |
+      在 output_dir 自主验证：
+      1. Cargo.toml 是 binary target，含 thiserror，dev-deps 含 proptest + rstest
+      2. src/types.rs 字段已完整定义（非桩）；src/error.rs 含全部错误变体
+      3. lib.rs 声明了 plan.json 中的全部模块
+      4. 每个 C 测试函数都有对应 Rust #[test]，断言语义精确保留
+      5. cargo build 通过；cargo test 出现 FAILED 且为 todo!() panic（不是编译错误）
+      6. 每个 public_functions + internal_functions 都有 todo!("名字") 桩
+      7. tests/ 含 oracle_*.rs 和 prop_*.rs，每个模块都有对应测试文件
+    on_pass: impl-core
+    on_fail: baseline
+    max_fail_count: 5
+
+  - id: impl-core
+    desc: 实现核心层（trivial+owned）——自底向上，每模块 TDD 转绿 + commit
+    do: |
+      使用 c-to-rust-implement skill（在可用 skill 列表中按 location 读取它），范围 = difficulty 为 trivial|owned 的模块。
+      你是工程师：读 C 原实现理解语义，写惯用安全 Rust，自底向上按 layer 顺序逐模块实现。
+      编译器/测试报错就是自愈信号——用 systematic-debugging 定位根因后修复。
+      对照 plan.json 逐函数确认：每个 public_functions + internal_functions 都有对应的 Rust 实现（非桩、非空函数体）。
+      每模块通过后 git commit（impl-core: <module>）。
+    input: plan.json + baseline Rust 项目 + C 源码
+    output: trivial|owned 模块全部实现，对应测试转绿，每模块一个 commit
+    check: |
+      在 output_dir 自主验证：
+      1. cargo build 通过
+      2. trivial|owned 模块的全部测试通过
+      3. 已实现模块内无 todo!()/unimplemented!()
+      4. 每个已实现模块有 impl-core: commit
+      5. cargo geiger Expressions used/total < 10%
+    on_pass: audit-core
+    on_fail: impl-core
+    max_fail_count: 15
+
+  - id: audit-core
+    desc: 独立审查 core 层——逐函数验证完整性与语义等价
+    do: |
+      使用 c-to-rust-audit skill（在可用 skill 列表中按 location 读取它），范围 = difficulty 为 trivial|owned 的模块。
+      你是审计师：对照 plan.json 逐模块逐函数自查 core 层的实现完整性和语义正确性。
+      对照 C 原实现和 function-contracts.md，确认每个函数的 Rust 版本行为等价。
+      发现遗漏或偏差立即修复。不要等到 CHECK 来发现问题。
+    input: plan.json + Rust 项目 + C 源码 + function-contracts.md
+    output: 所有 core 层函数确认完整且语义等价
+    check: |
+      你是独立审计师。审查 core 层（trivial|owned 模块）的 C→Rust 翻译质量。
+
+      对照 plan.json，用你自己的方法逐模块逐函数审查。
+      判断标准：给定相同输入，Rust 实现是否产生与 C 相同的输出和副作用。
+      任一函数缺失或语义不等价 → FAIL。
+    on_pass: impl-full
+    on_fail: impl-core
+    max_fail_count: 10
+
+  - id: impl-full
+    desc: 实现全量剩余层（stateful+callback+global）——分批推进，集成全绿
+    do: |
+      使用 c-to-rust-implement skill（在可用 skill 列表中按 location 读取它），范围 = 剩余模块（stateful|callback|global）。
+      同样的工程师循环：理解 C 语义 → 写安全 Rust → 测试转绿 → systematic-debugging。
+      若模块函数数较多，分批实现，每批独立 commit。
+      逐函数对照 plan.json，确保每个 public_functions + internal_functions 都有对应实现。
+      全部模块完成后做集成全量构建与全套测试。
+    input: plan.json + 已实现 core 的 Rust 项目 + C 源码
+    output: 全部模块实现，cargo build/test/clippy 全过，unsafe < 10%
+    check: |
+      在 output_dir 自主验证：
+      1. cargo build --release 通过
+      2. cargo test --all 全绿，无 FAILED，无 #[ignore]
+      3. cargo clippy -- -D warnings 无 error
+      4. src/ 与 tests/ 无 todo!()/unimplemented!()/dbg!() 残留
+      5. 每个模块都有 impl-core: 或 impl-full: commit
+      6. cargo geiger Expressions used/total < 10%
+      7. cargo run --release -- --help 正常启动
+    on_pass: audit-full
+    on_fail: impl-full
+    max_fail_count: 25
+
+  - id: audit-full
+    desc: 独立审查全量翻译——逐函数验证完整性、语义等价
+    do: |
+      使用 c-to-rust-audit skill（在可用 skill 列表中按 location 读取它），范围 = 全部模块。
+      你是审计师：对照 plan.json 逐模块逐函数自查全量实现。重点关注：
+      - 状态转换和多阶段操作是否被完整保留
+      - 错误路径和边界条件是否被保留
+      - 资源管理是否正确替换
+      - 回调/函数指针的控制反转是否正确建模
+      - 数据结构布局是否与 C 一致
+      对照 C 原实现和 function-contracts.md，逐函数验证语义等价性。
+      发现遗漏或偏差立即修复。
+    input: plan.json + Rust 项目 + C 源码 + function-contracts.md
+    output: 全部函数确认完整且语义等价
+    check: |
+      你是独立审计师。审查全量翻译质量，重点关注 stateful/callback/global 模块。
+
+      对照 plan.json，用你自己的方法逐函数审查。用你的专业判断评估每个函数翻译的语义等价性。
+      不要只检查函数是否存在——深入检查实现是否正确、是否完整。
+      任一函数缺失或语义不等价 → FAIL。
+    on_pass: verify
+    on_fail: impl-full
+    max_fail_count: 15
+
+  - id: verify
+    desc: 最终验收——对照验收标准逐条取证，产出 report.md
+    do: |
+      使用 c-to-rust-validate skill（在可用 skill 列表中按 location 读取它）。
+      以独立 QA 视角做最终验收：跑全量构建/测试/lint/geiger/覆盖率，逐条收集证据，产出 report.md。
+      发现不达标项立即修复。
+    input: 完成的 Rust 项目 + plan.json + C 项目路径
+    output: report.md（每条验收标准附证据）
+    check: |
+      你是独立验收审计师。逐条验证以下标准是否满足。
+      不要信任 report.md 的结论——自主探索项目，独立做出判断。
+
+      ## 验收标准
+
+      1. **可执行文件**：cargo build --release 产出二进制文件，cargo run --release -- --help 正常启动不 panic。
+
+      2. **测试框架**：所有测试使用 Rust 主流测试框架（#[test]、rstest、proptest 等），不依赖外部 C 测试框架或脚本。
+
+      3. **源码全量翻译**：src/ 下全部 .rs 文件为完整 Rust 实现。无 todo!()、unimplemented!()、空函数体、仅返回默认值的占位实现。
+
+      4. **编译与测试通过**：cargo build --release 零 error。cargo test --all 全部通过，无 FAILED，无 #[ignore]。
+
+      5. **Unsafe 比例 < 10%**：cargo geiger 度量，本项目 crate 的 Expressions used/total < 10%。每处 unsafe 须有 // SAFETY: 注释。
+
+      6. **业务逻辑 100% 不受破坏**：对照 plan.json 中每个函数，判断 C 原实现与 Rust 实现的语义等价性。给定相同输入，产生相同输出和相同副作用。任一函数语义不等价 → FAIL。
+
+      7. **单元测试覆盖主干路径**：核心函数有针对性测试。happy path 和 error path 均有覆盖。边界条件有测试。有 property-based 测试。
+
+      ## 输出
+
+      逐条标准报告 PASS/FAIL，附独立验证证据。全部 PASS → 工作流通过。
+    on_pass: done
+    on_fail: impl-core
+    max_fail_count: 10

package/workflows/everything2rust.yaml

@@ -0,0 +1,259 @@
+description: |
+  任意软件 → 惯用安全 Rust：语言无关、领域无关（CLI/库/服务/游戏/GUI 等）。
+  以能力（capability）+ 行为契约 + 预言（oracle）为等价单位，不做函数一比一复刻。
+  grill 式方案设计（ADR）+ TDD 增量实现 + 独立审计。
+  design 步骤为手动步骤：DO 完成后暂停，供人工审查技术选型与架构；运行 /ralphflow-continue
+  确认后才进入独立验证，通过后自动继续。如需全自动运行，删除下方 manual_step 配置即可。
+
+adversarial_check:
+  timeout_ms: 3600000
+  model: "anthropic/claude-opus-4-5"
+manual_step:
+  - design
+
+steps:
+
+  - id: setup-env
+    desc: 环境配置——安装并校验 Rust 侧工具链，fail-fast
+    do: |
+      你是搭建 CI 环境的工程师。安装并校验本工作流依赖的 Rust 侧工具，确保后续步骤不会因缺工具而中途退化。直接执行安装命令，不要只列清单。先探测再决定：已就绪的工具直接复用、只补缺失的（保持幂等）。
+
+      必须就绪（缺则安装）：
+      - Rust 工具链：rustc / cargo（rustup 安装），组件 clippy、rustfmt
+      - cargo-geiger：cargo install cargo-geiger --locked。若编译失败，尝试较早版本
+      - cargo-audit：cargo install cargo-audit --locked
+      - cargo-llvm-cov：cargo install cargo-llvm-cov --locked，并 rustup component add llvm-tools-preview
+      - 文本/算术辅助：jq、bc
+
+      源语言工具链（Node/Python/JVM/Go/编译器等）这一步不装——survey 步骤探测出源语言后按需安装。
+
+      安装后把每个工具的版本写入 env.md。
+      任一必须工具无法安装时，如实说明卡点，不要输出 done。
+    input: 无
+    output: env.md（工具版本快照）；全部必须工具可调用
+    check: |
+      自主验证：
+      1. env.md 存在，列出各工具版本（无占位符）
+      2. cargo geiger --version、cargo clippy --version、cargo audit --version、cargo llvm-cov --version 均正常输出
+      3. jq --version、bc --version 均正常输出
+    on_pass: survey
+    on_fail: setup-env
+    max_fail_count: 5
+
+  - id: survey
+    desc: 系统勘察——探测语言/领域/构建/运行，让原系统真实跑起来，产出能力清单
+    do: |
+      使用 everything2rust-survey skill（在可用 skill 列表中按 location 读取它）。
+      你是接手陌生代码库的工程师。先探测源项目的真实形态：语言、领域（CLI/库/服务/游戏/GUI/…）、
+      构建系统、测试框架、外部接口、依赖。然后安装源语言运行时，**让原系统真实构建、运行、跑测试**——
+      它是后续行为等价验证的预言（oracle），跑不起来的系统无法做高质量重构。
+      产出 system-map.md（系统全貌）、capabilities.md（能力清单）、oracle-evidence.md（原系统可运行的实证）。
+    input: 源项目路径（来自用户任务描述）
+    output: system-map.md + capabilities.md + oracle-evidence.md
+    check: |
+      自主验证：
+      1. system-map.md 存在，含：源语言、领域判定、构建/测试/运行命令、外部接口清单、依赖清单（均来自真实探测，无占位符）
+      2. oracle-evidence.md 含原系统构建/运行/测试的**真实命令输出片段**；若原系统确实无法运行，如实记录了原因和替代预言来源（已有测试套件/文档/样例数据）
+      3. capabilities.md 列出能力清单，每条能力有：一句话描述、源码位置引用、外部可观察的行为
+      4. 能力清单覆盖 system-map.md 外部接口清单中的每一项（无遗漏的接口）
+      5. 能力粒度合理：不是逐函数罗列，也不是一条"实现整个系统"
+    on_pass: spec
+    on_fail: survey
+    max_fail_count: 5
+
+  - id: spec
+    desc: 行为契约——逐能力定义必须保留的可观察行为，选定预言策略，采集 golden 语料
+    do: |
+      使用 everything2rust-spec skill（在可用 skill 列表中按 location 读取它）。
+      你是规格工程师。对 capabilities.md 中每个能力写行为契约：输入/输出/副作用/不变量/错误路径。
+      为每个能力选定预言策略（ported-tests / golden / differential / property / checklist），
+      并**实际运行原系统采集 golden 语料**到 golden/——这些语料是后续验收测试的判据。
+      契约描述"外部可观察什么"，不描述"内部怎么实现"——这是允许 Rust 重新设计架构的前提。
+    input: capabilities.md + system-map.md + 源项目
+    output: behavior-spec.md + golden/（语料目录）
+    check: |
+      自主验证：
+      1. behavior-spec.md 覆盖 capabilities.md 中每个能力，无 TBD/待补占位
+      2. 每个能力标注预言策略，取值 ∈ {ported-tests, golden, differential, property, checklist}
+      3. 预言为 golden/differential 的能力，golden/ 下有对应语料文件；抽查语料内容与原系统行为一致（语料含采集命令元数据，可复现）
+      4. 预言为 checklist（无法自动判定）的能力占比合理，且每个都写明了为何无法自动判定
+      5. 契约只描述可观察行为（输入/输出/副作用/不变量/错误路径），不锁定内部实现细节
+      6. 抽查 2-3 个契约：对照源码验证描述准确（错误路径、边界行为没有想当然）
+    on_pass: design
+    on_fail: spec
+    max_fail_count: 5
+
+  - id: design
+    desc: 方案设计——grill 式拷问设计树每个分支，技术选型 ADR，产出 design.md + decisions.md + plan.json
+    do: |
+      使用 everything2rust-design skill（在可用 skill 列表中按 location 读取它）。
+      你是架构师。对设计树的每个分支做 grill 式自我拷问：目标形态、总体架构、每个子系统的
+      技术选型、迁移顺序、测试策略、性能目标、unsafe 政策、范围取舍。每个问题：给出选项、
+      查证据（源码/领域 playbook/crate 生态）、下结论、记 ADR。能查证据回答的不留给拍脑袋。
+      这不是函数级翻译计划——是为 Rust 重新设计的架构，以行为契约为约束。
+      产出 design.md（架构方案）、decisions.md（ADR 集）、plan.json（机器可读增量计划）。
+    input: behavior-spec.md + system-map.md + capabilities.md + 源项目
+    output: design.md + decisions.md + plan.json
+    check: |
+      自主验证：
+      1. plan.json 是合法 JSON，含 source、target、stack、capabilities、increments、parity_exceptions 字段
+      2. behavior-spec.md 中每个能力在 plan.json capabilities 中恰好归入一个 increment
+      3. increments 第一项是 walking-skeleton（端到端可运行的最小闭环），每个 increment 有 phase(core|full) 和 exit_criteria
+      4. stack 每项选型在 decisions.md 有对应 ADR（问题/选项/选择/理由/推翻条件）
+      5. decisions.md 覆盖关键分支：目标形态、总体架构、每个子系统选型、迁移顺序、测试策略、unsafe 政策；每个 ADR 的理由引用了证据（源码事实/契约要求/crate 现状），不是空断言
+      6. parity_exceptions 每条有理由和 ADR 引用；design.md 中没有 parity_exceptions 之外的行为改变计划
+      7. design.md 的架构覆盖全部能力，无过度设计（没有契约不要求的层和抽象）
+      8. target.output_dir 是工作区内绝对路径；target.smoke_cmd 已定义且与领域匹配
+    on_pass: baseline
+    on_fail: design
+    max_fail_count: 5
+
+  - id: baseline
+    desc: TDD 红阶段——Rust 项目骨架、验收测试（golden harness + 属性测试）、全桩
+    do: |
+      使用 everything2rust-test-gen skill（在可用 skill 列表中按 location 读取它）。
+      严格 RED：按 plan.json target 建 Rust 项目骨架（类型/错误/模块结构），
+      为每个能力写验收测试——golden 语料驱动的 harness、从原测试套件移植的断言、属性测试。
+      测试断言忠实于 behavior-spec，不弱化。所有实现用 todo!() 占位。
+      产出 test-map.json 记录能力→测试的映射。
+      目标状态：cargo build 通过，cargo test 因 todo!() 而 FAILED。
+    input: plan.json + behavior-spec.md + golden/ 语料 + 源项目测试套件
+    output: |
+      target.output_dir 下的 Cargo 项目（骨架 + 全桩 + tests/）；
+      test-map.json（能力 id → 测试名列表）
+    check: |
+      在 plan.json 的 target.output_dir 自主验证：
+      1. Cargo 项目形态与 plan.json target 一致（bin/lib/workspace），依赖与 stack 选型一致
+      2. test-map.json 把每个能力映射到至少 1 个测试；映射的测试在 tests/ 或 src/ 中真实存在
+      3. golden 语料被 harness 实际读取（测试代码引用 golden/ 或已复制的语料路径），不是硬编码期望值
+      4. 抽查 2-3 个测试：断言忠实于 behavior-spec 的契约（精确断言，没有降级为"不 panic 即可"）
+      5. cargo build 通过；cargo test 出现 FAILED 且失败源自 todo!() panic（不是编译错误）
+      6. 每个 increment 的能力都有对应桩（todo!("...")），模块结构与 design.md 一致
+    on_pass: impl-core
+    on_fail: baseline
+    max_fail_count: 5
+
+  - id: impl-core
+    desc: 实现 core 增量（walking-skeleton + 核心域）——逐增量 TDD 转绿 + commit
+    do: |
+      使用 everything2rust-implement skill（在可用 skill 列表中按 location 读取它），范围 = plan.json 中 phase 为 core 的增量。
+      你是工程师：读原实现理解行为语义，写惯用安全 Rust，按 increments 顺序逐增量转绿。
+      第一个增量是 walking-skeleton——先让系统端到端跑起来（哪怕功能最少），再填充核心域。
+      编译器/测试报错就是自愈信号——用 systematic-debugging 定位根因后修复。
+      每增量达到 exit_criteria 后 git commit（e2r-core: <increment>），更新 plan.json 能力 status。
+    input: plan.json + baseline Rust 项目 + 源项目 + behavior-spec.md
+    output: core 增量全部实现，对应测试转绿，smoke_cmd 可运行，每增量一个 commit
+    check: |
+      在 plan.json 的 target.output_dir 自主验证：
+      1. cargo build 通过
+      2. 对照 test-map.json：phase=core 增量所辖能力的全部测试通过
+      3. 已完成能力在 plan.json 中 status=done，对应实现非桩（无 todo!()/unimplemented!()、非空函数体）
+      4. 每个 core 增量有 e2r-core: commit
+      5. cargo geiger 本 crate Expressions used/total < plan.json target.unsafe_budget_pct（默认 10%）
+      6. 执行 plan.json target.smoke_cmd 正常启动不 panic
+    on_pass: audit-core
+    on_fail: impl-core
+    max_fail_count: 15
+
+  - id: audit-core
+    desc: 独立审计 core——逐能力对照行为契约验证等价性
+    do: |
+      使用 everything2rust-audit skill（在可用 skill 列表中按 location 读取它），范围 = phase 为 core 的增量。
+      你是审计师：对照 behavior-spec.md 逐能力自查 core 实现。判据是行为契约，不是代码形状——
+      给定契约中的输入，Rust 实现是否产生契约要求的输出和副作用？错误路径和边界是否保留？
+      golden 语料是否全部通过？发现偏差立即修复。不要等 CHECK 来发现问题。
+    input: plan.json + behavior-spec.md + golden/ + Rust 项目 + 源项目
+    output: core 增量所有能力确认与行为契约等价
+    check: |
+      你是独立审计师。审查 core 增量（plan.json 中 phase=core）的重构质量。
+
+      对照 behavior-spec.md，用你自己的方法逐能力审查。
+      判断标准：给定契约中描述的输入，Rust 实现是否产生契约要求的可观察行为
+      （输出、副作用、错误路径、不变量）。允许的偏差仅限 plan.json parity_exceptions 中列出的。
+      必要时运行原系统与 Rust 版本做差分对比。
+      任一能力缺失或行为不等价 → FAIL。
+    on_pass: impl-full
+    on_fail: impl-core
+    max_fail_count: 10
+
+  - id: impl-full
+    desc: 实现全量剩余增量——分批推进，集成全绿
+    do: |
+      使用 everything2rust-implement skill（在可用 skill 列表中按 location 读取它），范围 = plan.json 中 phase 为 full 的增量。
+      同样的工程师循环：理解原行为 → 写安全 Rust → 测试转绿 → systematic-debugging。
+      增量大时分批实现，每批独立 commit（e2r-full: <increment> batch n/m）。
+      全部增量完成后做集成全量构建与全套测试，clippy 清零。
+    input: plan.json + 已完成 core 的 Rust 项目 + 源项目 + behavior-spec.md
+    output: 全部增量实现，cargo build/test/clippy 全过，unsafe < 预算
+    check: |
+      在 plan.json 的 target.output_dir 自主验证：
+      1. cargo build --release 通过
+      2. cargo test --all 全绿，无 FAILED，无 #[ignore]
+      3. cargo clippy -- -D warnings 无 error
+      4. src/ 与 tests/ 无 todo!()/unimplemented!()/dbg!() 残留
+      5. plan.json 全部能力 status=done；每个增量都有 e2r-core: 或 e2r-full: commit
+      6. cargo geiger 本 crate Expressions used/total < plan.json target.unsafe_budget_pct
+      7. 执行 plan.json target.smoke_cmd 正常启动不 panic
+    on_pass: audit-full
+    on_fail: impl-full
+    max_fail_count: 25
+
+  - id: audit-full
+    desc: 独立审计全量——逐能力验证行为等价，重点状态/并发/交互类能力
+    do: |
+      使用 everything2rust-audit skill（在可用 skill 列表中按 location 读取它），范围 = 全部增量。
+      你是审计师：对照 behavior-spec.md 逐能力自查全量实现。重点关注：
+      - 有状态能力的状态转换和多阶段操作是否完整保留
+      - 错误路径和边界条件是否保留
+      - 并发/异步行为的语义是否等价（顺序保证、超时、取消）
+      - 交互类能力（UI/游戏循环）的 checklist 项是否逐条核对
+      - 数据格式（文件/协议/存档）是否与原系统互通
+      发现偏差立即修复。偏差仅允许出现在 parity_exceptions 中。
+    input: plan.json + behavior-spec.md + golden/ + Rust 项目 + 源项目
+    output: 全部能力确认与行为契约等价
+    check: |
+      你是独立审计师。审查全量重构质量，重点关注有状态、并发、交互类能力。
+
+      对照 behavior-spec.md，用你自己的方法逐能力审查。不要只检查测试是否通过——
+      深入检查实现的行为是否与契约一致、是否完整。必要时运行原系统与 Rust 版本做差分对比。
+      checklist 类能力逐条人工核对证据。
+      允许的偏差仅限 plan.json parity_exceptions。任一能力缺失或行为不等价 → FAIL。
+    on_pass: verify
+    on_fail: impl-full
+    max_fail_count: 15
+
+  - id: verify
+    desc: 最终验收——对照验收标准逐条取证，产出 report.md
+    do: |
+      使用 everything2rust-validate skill（在可用 skill 列表中按 location 读取它）。
+      以独立 QA 视角做最终验收：跑全量构建/测试/lint/geiger/覆盖率/smoke，
+      逐能力核对行为契约，逐条收集证据，产出 report.md。
+      发现不达标项立即修复。
+    input: 完成的 Rust 项目 + plan.json + behavior-spec.md + 源项目路径
+    output: report.md（每条验收标准附证据）
+    check: |
+      你是独立验收审计师。逐条验证以下标准是否满足。
+      不要信任 report.md 的结论——自主探索项目，独立做出判断。
+
+      ## 验收标准
+
+      1. **可构建可运行**：cargo build --release 零 error；执行 plan.json target.smoke_cmd 正常启动不 panic。
+
+      2. **测试框架**：所有测试使用 Rust 原生测试设施（#[test]、rstest、proptest、insta 等），不依赖源语言运行时（差分测试 harness 除外，且差分 harness 不阻塞 cargo test）。
+
+      3. **全量实现**：src/ 下全部 .rs 为完整实现。无 todo!()、unimplemented!()、空函数体、仅返回默认值的占位实现。
+
+      4. **测试全绿**：cargo test --all 全部通过，无 FAILED，无 #[ignore]。cargo clippy -- -D warnings 无 error。
+
+      5. **Unsafe 在预算内**：cargo geiger 度量，本 crate Expressions used/total < plan.json target.unsafe_budget_pct（默认 10%）。每处 unsafe 有 // SAFETY: 注释。
+
+      6. **行为等价**：对照 behavior-spec.md 逐能力判断可观察行为等价性——输出、副作用、错误路径、不变量、数据格式互通。golden 语料测试全部通过。偏差仅限 plan.json parity_exceptions 中声明并有 ADR 依据的项。任一未声明的行为偏差 → FAIL。
+
+      7. **主干路径覆盖**：核心能力有针对性测试。happy path 和 error path 均有覆盖。边界条件有测试。确定性核心有 property-based 测试。
+
+      ## 输出
+
+      逐条标准报告 PASS/FAIL，附独立验证证据。全部 PASS → 工作流通过。
+    on_pass: done
+    on_fail: impl-core
+    max_fail_count: 10

package/workflows/loop.yaml

@@ -0,0 +1,68 @@
+description: 检查点驱动的循环执行：先把需求拆解为检查点清单，再循环执行直到全部通过
+
+manual_step:
+
+adversarial_check:
+  # model: anthropic/claude-sonnet-4-5  # 可选：验证模型（"provider/model" 或 {providerID, modelID}）；不填则用 ralph-check agent 默认模型
+  timeout_ms: 3600000  # 60 分钟（上限）
+
+steps:
+  - id: checkpoints
+    desc: 拆解用户需求为检查点清单
+    do: |
+      仔细分析用户需求，产出检查点清单。只做分析和拆解，**不要开始实现任务本身**。
+
+      输出 `checkpoints.md`：
+      1. 逐句阅读用户需求，把每个要求拆成独立的检查点，绝对细致，不遗漏任何要点
+      2. 补充隐含要求的检查点（如：构建通过、现有测试不回归、无残留 TODO/调试代码）
+      3. 每个检查点必须是可独立验证的客观事实（如"函数 X 对输入 Y 返回 Z"、"文件 W 存在且包含 V"），
+         禁止模糊表述（如"代码质量好"、"功能正常"）
+      4. 每个检查点标注**验证方式**：跑哪条命令、看哪个文件、运行哪个测试
+      5. 格式：`- [ ] CP-<编号>: <检查点描述> ｜ 验证方式: <具体命令或方法>`
+    input: 用户输入的任务描述
+    output: "checkpoints.md"
+    check: |
+      对照用户需求逐句核对 checkpoints.md：
+      1. 用户需求中每一个明确要求都有对应检查点，无遗漏
+      2. 隐含要求已覆盖（构建通过、测试不回归等）
+      3. 每个检查点是可验证的客观事实，无模糊表述
+      4. 每个检查点都标注了具体可执行的验证方式
+      任何一条不满足即不通过，并指出缺失或含糊的具体条目。
+    on_pass: loop
+    on_fail: checkpoints
+    max_fail_count: 5
+
+  - id: loop
+    desc: 循环执行任务直到所有检查点通过
+    do: |
+      按 `checkpoints.md` 执行任务。
+
+      你需要：
+      1. 逐项完成检查点，每完成一项按其标注的验证方式自验，
+         然后把 `- [ ]` 改为 `- [x]` 并在该行追加验证证据（命令输出摘要或文件位置）
+      2. 实现过程中发现清单遗漏的要求，先在 checkpoints.md 中追加新检查点，再实现它
+      3. 遇到问题主动解决，不要跳过或放弃
+    input: "checkpoints.md + 用户任务描述"
+    output: 所有检查点完成的实现 + 全部打勾的 checkpoints.md
+    check: |
+      你是一个挑剔的测试工程师：你的目标不是确认任务完成，而是想办法证明它没完成。
+
+      第一步：逐条验证检查点
+      - 对每个检查点，执行其标注的验证方式，亲自确认事实成立
+      - 不要相信打勾状态和记录的证据，必须自己重新验证
+      - 存在未打勾的检查点直接不通过
+
+      第二步：抽查清单完整性
+      - 对照用户需求快速核对 checkpoints.md 是否有遗漏的要求
+      - 发现遗漏即不通过，并指出遗漏的具体要求
+
+      第三步：挑剔地审查本轮变更
+      - 用 git diff 查看本次变更涉及的文件，以挑剔测试工程师的视角自由发挥，
+        设法找出能让它出问题的场景
+      - 只审查变更涉及的文件，不要扩大到整个项目
+
+      通过条件：所有检查点验证通过 + 清单无遗漏 + 挑剔审查未发现实在的问题。
+      不通过条件：任一检查点失败、清单有遗漏、或发现实在的 bug（说明触发场景）。
+    on_pass: done
+    on_fail: loop
+    max_fail_count: 100