Back to Details

pasteurize

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

/pasteurize

/pasteurize

A discipline for hard bugs. Skip phases only when explicitly justified.
When exploring the codebase, call the selected source-code backend directly according to 
code-intelligence-routing.md
, and check 
.cheese/specs/
for any spec or design notes that touch the failing seam.
Portability reference: 
../cheese/references/harness-portability.md
. It covers helper resolution, sub-agent dispatch, GitHub operations, and handoff transitions; prefer the bundled or repo-local helper first, and treat 
${CLAUDE_SKILL_DIR}
as optional host-provided fallback. The handoff blocks below are the portable contract; slash commands are host renderings, not the control model.
疑难BUG处理规范。仅在有明确理由时才可跳过阶段。
在探索代码库时，请根据
code-intelligence-routing.md
直接调用选定的源代码后端，并检查
.cheese/specs/
中所有涉及故障环节的规范或设计说明。
可移植性参考：
../cheese/references/harness-portability.md
。它涵盖了助手解析、子Agent调度、GitHub操作以及交接过渡；优先使用捆绑或仓库本地的助手，并将
${CLAUDE_SKILL_DIR}
视为可选的宿主提供的回退方案。 以下交接模块是可移植契约；斜杠命令是宿主渲染形式，而非控制模型。

Phase 1 — Feedback loop

阶段1 — 反馈循环

This is the skill. Everything else is mechanical. If you have a fast, deterministic, agent-runnable pass/fail signal for the bug, you will find the cause — bisection, hypothesis-testing, and instrumentation all just consume that signal. If you don't have one, no amount of staring at code will save you.
Spend disproportionate effort here.
这是核心技能。其他所有步骤都是机械性的。如果您拥有针对该BUG的快速、确定性、可由Agent运行的通过/失败信号，您就能找到根因——二分法、假设测试和插桩（instrumentation）都只是在利用这个信号。如果没有这个信号，再怎么盯着代码看都没用。
在此阶段投入更多精力。

Ways to construct one

构建反馈循环的方法

To pick a loop shape, see 
references/feedback-loops.md
 for the ten-option ordered menu.
要选择循环形式，请查看
references/feedback-loops.md
中的十大选项有序列表。

Iterate on the loop itself

迭代优化反馈循环本身

Treat the loop as a product. Once you have a loop, ask:
  • Can I make it faster? (Cache setup, skip unrelated init, narrow the test scope.)
  • Can I make the signal sharper? (Assert on the specific symptom, not "didn't crash".)
  • Can I make it more deterministic? (Pin time, seed RNG, isolate filesystem, freeze network.)
将反馈循环视为一个产品。一旦您有了一个循环，请思考：
  • 我能让它更快吗？（缓存设置、跳过无关初始化、缩小测试范围。）
  • 我能让信号更清晰吗？（针对特定症状断言，而不是“没有崩溃”。）
  • 我能让它更具确定性吗？（固定时间、设置RNG种子、隔离文件系统、冻结网络。）

Non-deterministic bugs

非确定性BUG

The goal is not a clean repro but a higher reproduction rate. Loop the trigger 100×, parallelise, add stress, narrow timing windows, inject sleeps. A 50%-flake bug is debuggable; 1% is not — keep raising the rate until it's debuggable.
目标不是完美的重现，而是更高的重现率。循环触发100次、并行执行、增加压力、缩小时间窗口、注入延迟。重现率50%的不稳定BUG是可调试的；1%的则不行——持续提高重现率直到它可调试。

When you genuinely cannot build a loop

当确实无法构建反馈循环时

Stop and say so explicitly. List what you tried. Ask the user for: (a) access to whatever environment reproduces it, (b) a captured artifact (HAR file, log dump, core dump, screen recording with timestamps), or (c) permission to add temporary production instrumentation. Do not proceed to hypothesise without a loop. Write a 
status: halt
handoff slug (see below) and stop.
Do not proceed to Phase 2 until the loop passes all four checks:
  • Deterministic — runs the same way every time (or, for flaky bugs, reproduction rate >50% and rising).
  • Agent-runnable — a single command with no human in the loop.
  • Asserts the user’s exact symptom — the failure message / wrong output / timing the user reported, not a nearby failure.
  • Fast — under 30 seconds end-to-end (aim for under 5).
明确告知用户。列出您尝试过的方法。向用户请求：(a)访问可重现故障的环境，(b)捕获的工件（HAR文件、日志转储、核心转储、带时间戳的屏幕录制），或(c)添加临时生产环境插桩的权限。没有循环时，请勿继续提出假设。编写
status: halt
交接标记（见下文）并停止操作。
在循环通过以下四项检查之前，请勿进入阶段2：
  • 确定性——每次运行方式一致（对于不稳定BUG，重现率>50%且持续上升）。
  • Agent可运行——无需人工干预的单一命令。
  • 断言用户的确切症状——用户报告的失败消息/错误输出/计时问题，而非附近的其他故障。
  • 快速——端到端耗时低于30秒（目标是低于5秒）。

Phase 2 — Reproduce

阶段2 — 重现故障

Run the repro loop N times and verify the failure is consistent:
python3 skills/pasteurize/scripts/pasteurize.pyz repro-rerun --cmd "<repro-command>" --runs 5
Confirm the returned 
reproduced: true
and check 
failures
matches the expected failure mode. If 
reproduced: false
at N=5, the bug is flaky — increase 
--runs
before proceeding.
Do not proceed until you reproduce the bug.
运行重现循环N次，验证故障是否一致：
python3 skills/pasteurize/scripts/pasteurize.pyz repro-rerun --cmd "<repro-command>" --runs 5
确认返回的
reproduced: true
，并检查
failures
是否与预期故障模式匹配。如果N=5时
reproduced: false
，说明BUG不稳定——在继续之前增加
--runs
的值。
在重现BUG之前，请勿继续。

Symptom-shape gate

症状形态检查

Before forming any hypothesis, classify the symptom shape:
  • Clean stack trace + deterministic repro — stay at current tier, proceed to Phase 3 normally.
  • Heisenbug, race condition, cross-module failure, or perf regression — warn to upgrade (harness-detected phrasing: claude 
    /model opus
    + 
    /effort
    ; codex/OMP named equivalent; generic fallback) before forming any hypothesis. The extra tier buys the wider context window and reasoning depth these shapes need; do not start Phase 3 at the current tier once this branch fires.
在提出任何假设之前，先对症状形态进行分类：
  • 清晰的堆栈跟踪 + 确定性重现——保持当前层级，正常进入阶段3。
  • 海森堡BUG、竞态条件、跨模块故障或性能退化——在提出任何假设之前，先警告升级（Harness检测到的表述：claude 
    /model opus
    + 
    /effort
    ；codex/OMP对应命名；通用回退方案）。额外的层级能为这些形态的BUG提供更宽的上下文窗口和推理深度；一旦触发此分支，请勿在当前层级启动阶段3。

Phase 3 — Hypothesise

阶段3 — 提出假设

Generate 3–5 ranked hypotheses before testing any of them. Single-hypothesis generation anchors on the first plausible idea.
Each hypothesis must be falsifiable: state the prediction it makes.
Format: "If 
<X>
is the cause, then 
<changing Y>
will make the bug disappear / 
<changing Z>
will make it worse."
If you cannot state the prediction, the hypothesis is a vibe — discard or sharpen it.
Show the ranked list to the user through the host routing guide in 
../cheese/references/handoff-gate.md
 before testing. They often have domain knowledge that re-ranks instantly ("we just deployed a change to #3"), or know hypotheses they've already ruled out. Cheap checkpoint, big time saver. Don't block on it — proceed with your ranking if the user is AFK or running 
--auto
.
在测试任何假设之前，生成3–5个排序后的假设。单一假设生成会锚定第一个看似合理的想法。
每个假设必须是可证伪的：说明它做出的预测。
格式：“如果
<X>
是根因，那么
<修改Y>
会让BUG消失 / 
<修改Z>
会让BUG恶化。”
如果无法说明预测，该假设只是一种感觉——舍弃或细化它。
**在测试之前，通过
../cheese/references/handoff-gate.md
中的宿主路由指南向用户展示排序后的列表。**他们通常拥有能立即重新排序的领域知识（“我们刚刚部署了与#3相关的变更”），或者知道已经排除的假设。这是一个低成本的检查点，能节省大量时间。无需在此阻塞——如果用户离线或运行
--auto
，请按您的排序继续。

Phase 4 — Instrument

阶段4 — 插桩调试

Each probe must map to a specific prediction from Phase 3. Change one variable at a time.
Tool preference:
  1. Debugger / REPL inspection if the env supports it. One breakpoint beats ten logs.
  2. Targeted logs at the boundaries that distinguish hypotheses.
  3. Never "log everything and search".
Tag every debug log with a unique prefix, e.g. 
[DEBUG-a4f2]
. Cleanup at the end becomes a single content query through the selected search backend. Untagged logs survive; tagged logs die.
Perf branch. For performance regressions, logs are usually wrong. Instead: establish a baseline measurement (timing harness, 
performance.now()
, profiler, query plan), then bisect. Measure first, fix second.
每个探查必须对应阶段3中的特定预测。一次只改变一个变量。
工具优先级：
  1. 调试器/REPL检查（如果环境支持）。一个断点胜过十条日志。
  2. 针对性日志——在区分假设的边界处添加。
  3. 绝不“记录所有内容再搜索”。
为每个调试日志添加唯一前缀，例如
[DEBUG-a4f2]
。最终清理时，只需通过选定的搜索后端执行一次内容查询即可完成。未标记的日志保留；标记的日志删除。
性能分支。对于性能退化，日志通常无用。相反：建立基线测量（计时工具、
performance.now()
、性能分析器、查询计划），然后进行二分查找。先测量，再修复。

Phase 5 — Fix + regression test

阶段5 — 修复 + 回归测试

Write the regression test before the fix — but only if there is a correct seam for it.
A correct seam is one where the test exercises the real bug pattern as it occurs at the call site. If the only available seam is too shallow (single-caller test when the bug needs multiple callers, unit test that can't replicate the chain that triggered the bug), a regression test there gives false confidence.
If no correct seam exists, that itself is the finding. Note it in the handoff slug as an architectural follow-up. The codebase is preventing the bug from being locked down. Skip the test write; do not paper over it. Phase 6's "what would have prevented this bug?" retrospective still applies.
Before writing the test, confirm the seam is correct: verify that the test you're about to write targets the boundary where the bug actually occurs — the real call site, the real data path, the real failure mode. A test at the wrong seam (too shallow, wrong abstraction level, mocked-away side that hides the failure) will pass after the fix but won't catch a regression. If you discover the seam is wrong at this point, treat it as "no correct seam": write the no-correct-seam halt string from Early-stop conditions and route to 
/mold
, per the halt path above.
If a correct seam exists:
  1. Turn the minimised repro into a failing test at that seam.
  2. Watch it fail.
  3. Apply the smallest production change that makes the test pass. No scope creep, no "while I'm here" cleanup. If the test still fails, revert and retry — but cap the retries (see After 3 failed fix attempts below).
  4. Watch the test pass.
  5. Re-run the Phase 1 feedback loop against the original (un-minimised) scenario to confirm the symptom is gone, not just the test seam.
After 3 failed fix attempts (3 cycles of "apply change → watch test → revert because test still fails"), stop attempting fixes and re-question the approach: is the hypothesis from Phase 3 actually correct? Is the seam exposing the right failure? Is the bug at a different layer than assumed? Step back to Phase 3 and generate a fresh ranked hypothesis list — do NOT attempt a 4th blind fix. If the re-questioning produces a new hypothesis, restart from Phase 4. If all hypotheses are exhausted, write the fix-attempts-exhausted halt string from Early-stop conditions and route to 
/mold
.
Broader implementation (related cleanup, follow-on changes, anything beyond the minimal fix) is not pasteurize's job. Note it in the slug and let 
/cook --auto
pick it up in Phase 6's handoff.
在修复之前编写回归测试——但前提是存在合适的测试切入点。
合适的切入点是指测试能在调用站点实际触发真实BUG模式的位置。如果唯一可用的切入点过于浅层（当BUG需要多个调用者时仅测试单个调用者，无法复制触发BUG的调用链的单元测试），此处的回归测试会给出错误的信心。
如果没有合适的切入点，这本身就是一个发现。在交接标记中注明这一点，作为架构后续工作。代码库无法锁定该BUG。跳过测试编写；不要敷衍了事。阶段6中“本可以如何预防此BUG？”的回顾仍然适用。
**在编写测试之前，确认切入点合适：**验证您即将编写的测试针对的是BUG实际发生的边界——真实调用站点、真实数据路径、真实故障模式。错误切入点的测试（过于浅层、错误抽象级别、模拟隐藏故障的依赖）在修复后会通过，但无法捕获回归。如果此时发现切入点错误，将其视为“没有合适的切入点”：编写提前终止条件中的无合适切入点终止字符串，并按照上述终止路径路由到
/mold
。
如果存在合适的切入点：
  1. 将最小化的重现用例转换为该切入点下的失败测试。
  2. 观察测试失败。
  3. 应用最小的生产变更使测试通过。不要扩展范围，不要“顺便”清理代码。如果测试仍然失败，回滚并重试——但要限制重试次数（见下文3次修复尝试失败后）。
  4. 观察测试通过。
  5. 针对原始（未最小化的）场景重新运行阶段1的反馈循环，确认症状已消失，而不仅仅是测试切入点的问题。
3次修复尝试失败后（3次“应用变更→观察测试→因测试失败回滚”的循环），停止尝试修复并重新审视方法：阶段3的假设是否正确？切入点是否暴露了正确的故障？BUG是否在预期之外的层级？回到阶段3生成新的排序假设列表——不要尝试第4次盲目修复。如果重新审视产生了新假设，从阶段4重新开始。如果所有假设都已用尽，编写提前终止条件中的修复尝试耗尽终止字符串，并路由到
/mold
而非
/cook
。
更广泛的实现（相关清理、后续变更、超出最小修复范围的任何内容）不属于pasteurize的职责。在标记中注明，让
/cook --auto
在阶段6的交接中接手。

Phase 6 — Cleanup

阶段6 — 清理

Before writing the handoff slug, confirm:
  • Original repro no longer reproduces (re-run the Phase 1 loop).
  • Regression test passes (or absence of seam is documented in the slug).
  • All 
    [DEBUG-...]
    instrumentation removed:
    python3 skills/pasteurize/scripts/pasteurize.pyz debug-tag-sweep --root .
    Exit 0 = clean. Exit 1 = tags found (listed in output). Resolve before continuing.
  • Throwaway harnesses / prototypes deleted (or moved to a clearly-marked debug location and called out in the slug).
  • The confirmed hypothesis is captured in the slug so the commit message downstream can reference it.
Then ask: what would have prevented this bug? If the answer involves architectural change (no good test seam, tangled callers, hidden coupling), note it in the slug under an architectural-follow-up line. The chain still runs; the user can pick up the architectural work via 
/mold
after the fix lands. Make the recommendation after the fix is in, not before.
Once the checklist is green and the slug is on disk, hand off to 
/cook <slug> --auto
(default). Cook --auto picks up the post-fix state, runs its taste-test against the applied diff for spec drift / readability / scope creep, produces its package-ready report, and triggers the autonomous 
/press → /age → /cure
chain. Pasteurize itself does not commit, open PRs, or drive the chain — cook owns that.
在编写交接标记之前，确认：
  • 原始重现用例不再重现故障（重新运行阶段1的循环）。
  • 回归测试通过（或切入点缺失已记录在标记中）。
  • 所有
    [DEBUG-...]
    插桩已移除：
    python3 skills/pasteurize/scripts/pasteurize.pyz debug-tag-sweep --root .
    退出码0 = 清理完成。退出码1 = 发现标记（输出中列出）。继续之前解决此问题。
  • 临时工具/原型已删除（或移至明确标记的调试位置，并在标记中注明）。
  • 已确认的假设已记录在标记中，以便下游提交消息可以引用。
**然后问：本可以如何预防此BUG？**如果答案涉及架构变更（没有合适的测试切入点、调用者混乱、隐藏耦合），在标记的架构后续工作行中注明。流程仍会继续；用户可以在修复落地后通过
/mold
接手架构工作。在修复完成后再提出建议，而非之前。
一旦检查清单全部完成且标记已写入磁盘，交接给
/cook <slug> --auto
（默认）。Cook --auto会接手修复后的状态，针对应用的差异运行其“味道测试”以检查规范偏差/可读性/范围扩展，生成可打包的报告，并触发自主的
/press → /age → /cure
流程。Pasteurize本身不负责提交、打开PR或驱动流程——这些由cook负责。

Fan-out sizing

扩展规模

/pasteurize
fans zero agents today. 
size_pasteurize_fanout(bug_shape, score, deterministic_repro)
in 
src/fanout/pasteurize_route.py
is the sizing policy for when it does.
The signal is inverted relative to review: a reviewer (
age_route.route
) reads a diff that exists — more diff, more agents. 
size_pasteurize_fanout
instead reads the 
review_surface
score descending, over the suspect range (last-known-good..HEAD), not over a diff under review — less evidence means more agents, because the search space is what gets fanned over.
Bug shapeRangeReproAgents
regressiontight (score <= 250)deterministic1 (linear, no fan)
regressiontight (score <= 250)non-deterministic2
regressionwide (score > 250)deterministic2
regressionwide (score > 250)non-deterministic3
regressionscore is 
None
(no diff to anchor to)		deterministic3
regressionscore is 
None
(no diff to anchor to)		non-deterministic5
heisenbug / race / perf regressionanyany3
cold bug (no diff to anchor to, score is 
None
)		--deterministic3
cold bug (no diff to anchor to, score is 
None
)		--non-deterministic5
Boundary: the code checks 
score > 250
, so exactly 
250
counts as tight (
score <= 250
), not 
score < 250
as a naive reading of "tight" might suggest.
Every constant above (
WIDE_RANGE_THRESHOLD
, 
_REGRESSION_TIGHT_DETERMINISTIC_N
, 
_REGRESSION_TIGHT_NONDETERMINISTIC_N
, 
_REGRESSION_WIDE_DETERMINISTIC_N
, 
_REGRESSION_WIDE_NONDETERMINISTIC_N
, 
_UNSTABLE_REPRO_N
, 
_COLD_BUG_DETERMINISTIC_N
, 
_COLD_BUG_NONDETERMINISTIC_N
) is reasoned, not measured. Unlike every reviewer threshold in the router -- each validated against 30 commits of real history -- these have no historical validation, because 
/pasteurize
fans zero agents today. They are named tunable constants and should be revisited once real runs exist.
On a bundle-only host, 
size_pasteurize_fanout
is also reachable as 
python3 skills/pasteurize/scripts/pasteurize.pyz pasteurize-route <request.json>
(JSON in, JSON out -- mirrors 
age-route
's bundle convention).
/pasteurize
目前不扩展Agent。
src/fanout/pasteurize_route.py
中的
size_pasteurize_fanout(bug_shape, score, deterministic_repro)
是未来扩展时的规模策略。
该信号与审核相反：审核者（
age_route.route
）读取已存在的差异——差异越多，Agent越多。
size_pasteurize_fanout
则读取降序的
review_surface
分数，针对可疑范围（最后已知正常版本..HEAD），而非正在审核的差异——证据越少，Agent越多，因为需要搜索的空间更大。
BUG形态范围重现性Agent数量
退化狭窄（score <= 250）确定性1（线性，无扩展）
退化狭窄（score <= 250）非确定性2
退化宽泛（score > 250）确定性2
退化宽泛（score > 250）非确定性3
退化score为
None
（无差异可锚定）		确定性3
退化score为
None
（无差异可锚定）		非确定性5
海森堡BUG/竞态/性能退化任意任意3
冷BUG（无差异可锚定，score为
None
）		--确定性3
冷BUG（无差异可锚定，score为
None
）		--非确定性5
**边界：**代码检查
score > 250
，因此恰好
250
算作狭窄范围（
score <= 250
），而非按“狭窄”的字面理解的
score < 250
。
上述所有常量（
WIDE_RANGE_THRESHOLD
、
_REGRESSION_TIGHT_DETERMINISTIC_N
、
_REGRESSION_TIGHT_NONDETERMINISTIC_N
、
_REGRESSION_WIDE_DETERMINISTIC_N
、
_REGRESSION_WIDE_NONDETERMINISTIC_N
、
_UNSTABLE_REPRO_N
、
_COLD_BUG_DETERMINISTIC_N
、
_COLD_BUG_NONDETERMINISTIC_N
）都是基于推理的，而非实测的。与路由器中的每个审核者阈值（均经过30次真实提交验证）不同，这些常量没有历史验证，因为
/pasteurize
目前不扩展Agent。它们是可调整的命名常量，在实际运行后应重新审视。
在仅捆绑的宿主上，
size_pasteurize_fanout
也可通过
python3 skills/pasteurize/scripts/pasteurize.pyz pasteurize-route <request.json>
访问（JSON输入，JSON输出——镜像
age-route
的捆绑约定）。

Preferred tools and fallbacks

首选工具与回退方案

NeedPreferFallback
Code search / blast radiussemantic caller and dependency searchbounded text search with explicit precision loss
Reading codefresh bounded read from the intended write backend familynative bounded read with snapshot/line anchors
Editing instrumentationstale-safe anchored editLSP or native snapshot edit with stale-write detection
Diff visualization
delta
plain 
git diff
GitHub context
gh
local git history or user-provided links
External sanity check
/briesearch
clearly mark as an assumption
Missing optional tools should not interrupt diagnosis.
需求首选回退
代码搜索/影响范围语义调用者和依赖搜索带显式精度损失的有限文本搜索
代码阅读从目标写入后端家族获取最新的有限读取带快照/行锚点的原生有限读取
编辑插桩防过期的锚定编辑带过期写入检测的LSP或原生快照编辑
差异可视化
delta
纯
git diff
GitHub上下文
gh
本地git历史或用户提供的链接
外部合理性检查
/briesearch
明确标记为假设
缺少可选工具不应中断诊断。

Output

输出

Return a short report covering:
  • The named cause (one sentence, with 
    <certain>
    / 
    <speculating>
    / 
    <don't know>
    calibration).
  • The feedback loop (command, observed vs expected).
  • Hypotheses considered and which one held.
  • The regression test path and the fix's file:line footprint.
  • Cleanup status (
    [DEBUG-...]
    removed, harnesses deleted or relocated).
  • Suggested next skill — 
    /cook <slug> --auto
    for the autonomous chain forward.
返回一份简短报告，涵盖：
  • 确定的根因（一句话，标注
    <确定>
    /
    <推测>
    /
    <未知>
    ）。
  • 反馈循环（命令、观察结果与预期结果）。
  • 考虑过的假设以及哪个假设成立。
  • 回归测试路径和修复的文件:行范围。
  • 清理状态（
    [DEBUG-...]
    已移除，工具已删除或迁移）。
  • 建议的下一步技能——
    /cook <slug> --auto
    用于自主流程推进。

Handoff slug

交接标记

Write a minimum-shape handoff slug to 
.cheese/pasteurize/<slug>.md
so 
/cook
(and any orchestrator) can resume without re-reading the full report. Schema:
markdown
status: ok | halt: <one-line reason>
next: cook | mold | done
artifact: <path-to-richer-report-if-any>
cause: <one-sentence named cause>
loop: <command or repro path>
seam: <regression-test path:line, or "none — architectural follow-up">
fix: <production diff footprint, e.g. "src/foo.ts:42">
follow_up: <architectural follow-up note, or "none">
<one-line orientation: what pasteurize converged on>
status: ok
when the regression test is green, the original repro no longer reproduces, and cleanup is done. 
status: halt: <reason>
when any early-stop condition fires — see Early-stop conditions below. 
next:
is 
cook
for the standard chain, 
mold
if the diagnosis itself recommends an architectural spec instead of a per-bug fix, or 
done
if the bug was caused outside the repo and no follow-up is needed.
编写最小形态的交接标记到
.cheese/pasteurize/<slug>.md
，以便
/cook
（和任何编排器）无需重新读取完整报告即可继续。 schema：
markdown
status: ok | halt: <一行原因>
next: cook | mold | done
artifact: <如有，指向更详细报告的路径>
cause: <一句话确定的根因>
loop: <命令或重现路径>
seam: <回归测试路径:行，或“none — 架构后续工作”>
fix: <生产代码差异范围，例如"src/foo.ts:42">
follow_up: <架构后续工作说明，或"none">
<一行说明: pasteurize得出的结论>
当回归测试通过、原始重现用例不再重现且清理完成时，
status: ok
。当任何提前终止条件触发时，
status: halt: <原因>
——见下文提前终止条件。
next:
对于标准流程为
cook
，如果诊断本身建议进行架构规范而非针对单个BUG的修复则为
mold
，如果BUG由仓库外部原因导致且无需后续工作则为
done
。

Handoff

交接

Pipeline: cheese (debug) → [pasteurize] → cook --auto → press → age → cure → plate
After the report is printed and the handoff slug is on disk, ask through the host routing guide in 
../cheese/references/handoff-gate.md
 which downstream to run. Lead each option with the verb (what the user wants to do next):
  • Validate and chain forward (recommended when 
    status: ok
    )     — 
    /cook <slug> --auto
    .
  • Validate without auto chain — 
    /cook <slug>
    (cook runs taste-test, then the user picks each subsequent step).
  • Spec the architectural follow-up first — 
    /mold <slug>
    (when 
    seam: none — architectural follow-up
    ).
  • Stop — fix is in tree; defer the chain.
Pre-select Validate and chain forward when 
status: ok
. The chain default is 
--auto
because pasteurize already wrote and verified the fix; the work left for cook → press → age → cure is mechanical validation, not new authoring. Never auto-invoke; the user must still select.
When invoked with 
--auto
, skip this host-routed question entirely and chain forward per Auto mode.
流程：cheese（调试）→ [pasteurize] → cook --auto → press → age → cure → plate
在打印报告并将交接标记写入磁盘后，通过
../cheese/references/handoff-gate.md
中的宿主路由指南询问用户下一步运行哪个下游流程。每个选项前加动词（用户接下来要做什么）：
  • 验证并推进流程 (当
    status: ok
    时推荐)     —— 
    /cook <slug> --auto
    。
  • 验证但不自动推进流程 —— 
    /cook <slug>
    （cook运行味道测试，然后用户选择后续每个步骤）。
  • 先制定架构后续工作规范 —— 
    /mold <slug>
    （当
    seam: none — 架构后续工作
    时）。
  • 停止 —— 修复已合并到代码树；推迟流程。
当
status: ok
时，预先选择验证并推进流程。流程默认使用
--auto
，因为pasteurize已经编写并验证了修复；cook → press → age → cure剩下的工作是机械验证，而非新的创作。请勿自动调用；仍需用户选择。
当使用
--auto
调用时，完全跳过此宿主路由问题，并按照自动模式推进流程。

Auto mode

自动模式

--auto
skips Phase 3's user-ranking gate, skips the Phase 6 handoff gate, and invokes 
/cook <slug> --auto
directly. Phase 4–5 still run in full.
--auto
跳过阶段3的用户排序检查点，跳过阶段6的交接检查点，并直接调用
/cook <slug> --auto
。阶段4–5仍完整运行。

Early-stop conditions

提前终止条件

  • Phase 1 fails (
    status: halt
    written, no loop achievable).
  • Phase 3 disproves all hypotheses across two rounds (cap at two Phase 3 rounds, then halt).
  • Phase 5's seam check finds no correct seam — write 
    status: halt: no correct regression-test seam
    and route to 
    /mold
    instead of 
    /cook
    .
  • The fix breaks an unrelated test that pasteurize cannot reconcile within scope.
  • Phase 5's fix loop exhausts all hypotheses after 3 failed fix attempts — write 
    status: halt: fix attempts exhausted — architectural re-examination needed
    and route to 
    /mold
    instead of 
    /cook
    .
In every early-stop case, write the halt slug and surface the report. Do not silently downgrade to "best guess".
  • 阶段1失败（已写入
    status: halt
    ，无法构建循环）。
  • 阶段3在两轮中推翻了所有假设（限制为两轮阶段3，然后终止）。
  • 阶段5的切入点检查发现没有合适的切入点——写入
    status: halt: no correct regression-test seam
    并路由到
    /mold
    而非
    /cook
    。
  • 修复破坏了pasteurize无法在范围内协调的无关测试。
  • 阶段5的修复循环在3次尝试失败后用尽所有假设——写入
    status: halt: fix attempts exhausted — architectural re-examination needed
    并路由到
    /mold
    而非
    /cook
    。
在所有提前终止的情况下，写入终止标记并展示报告。请勿默默降级为“最佳猜测”。

Rules

规则

  • Do not skip Phase 1, and do not hypothesise without a reproducing loop.
  • Phase 5 writes only the regression test and the minimal production change; broader work belongs in 
    /cook
    .
  • Do not leave 
    [DEBUG-...]
    tags in the tree — clean them before the handoff slug is written.
  • Do not claim "shipped". Pasteurize claims "cause named, regression green, fix in tree, ready for chain". The chain (cook → press → age → cure) claims shipped.
  • If the bug exposes an architectural gap (no correct regression-test seam), say so in the slug. Do not silently paper over it.
  • 请勿跳过阶段1，没有重现循环时请勿提出假设。
  • 阶段5仅编写回归测试和最小的生产变更；更广泛的工作属于
    /cook
    。
  • 请勿在代码树中留下
    [DEBUG-...]
    标记——在编写交接标记前清理它们。
  • 请勿声称“已发布”。Pasteurize声称“已确定根因、回归测试通过、修复已合并到代码树、准备好推进流程”。流程（cook → press → age → cure）负责声称已发布。
  • 如果BUG暴露了架构缺陷（没有合适的回归测试切入点），在标记中注明。请勿默默敷衍。

References

参考

  • skills/pasteurize/scripts/pasteurize.pyz repro-rerun
    — run the repro command N times and emit 
    {exit_code, reproduced, runs, failures}
    (Phase 2).
  • skills/pasteurize/scripts/pasteurize.pyz debug-tag-sweep
    — scan the tree for instrumentation tag prefixes and exit 1 if any survive (Phase 6 cleanup gate).
  • skills/pasteurize/scripts/pasteurize.pyz repro-rerun
    —— 运行重现命令N次并输出
    {exit_code, reproduced, runs, failures}
    （阶段2）。
  • skills/pasteurize/scripts/pasteurize.pyz debug-tag-sweep
    —— 扫描代码树中的插桩标记前缀，如果存在则退出码为1（阶段6清理检查）。