Pasteurize

/pasteurize

Use this process for hard bugs.

Discipline

Iron Law: Build a reliable feedback loop before you form one hypothesis.

Stop at each red flag:

• You name a cause before the loop reproduces the failure.
• You accept an unrelated failure as the reproduction.
• You add a test at a mocked seam because the real seam is difficult.
• You make a fourth fix attempt on the same hypothesis list.
• You report a clean worktree without the session-tag sweep.

Follow `code-intelligence-routing.md` when you explore code. Resolve the specification store with artifact-path specs. Read the notes about the failed seam from the resolved directory.

Read `harness-portability.md` for portable tool use. Use bundled or repository helpers before ${CLAUDE_SKILL_DIR}. Treat ${CLAUDE_SKILL_DIR} as an optional host fallback. Use the handoff blocks as the portable contract. Remember that slash commands are host renderings, not the control model.

Inputs

<input> is the reported symptom. Accept a bug report, a stack trace, failing test output, or an artifact path. Accept an investigation request from Affinage, Cheese, or Cook.

An investigation request uses these fields:

Accept these flags:

• --auto runs the phases without the two questions.
• --open-pr reaches Plate through Cook.
• --hard reaches the final Hard-cheese gate through Cook.

Forward --open-pr and --hard to every /cook and /mold command. Do not drop a flag that the caller supplied.

Cheese can supply handoff_context.wiki_hits. Each hit has a page, a line, and a why field. Read each hit before Phase 1. Name any hit that changes the hypothesis ranking.

A request with mode: investigate stops after Phase 2. Return reproduced, not-reproduced, or inconclusive to the source skill. Do not start Phase 4 for an investigation request.

Phase 1: Build the feedback loop

Build a fast and reliable pass-or-fail feedback loop before you diagnose the bug. This feedback loop controls every later phase.

Read `references/feedback-loops.md` for the ordered loop options. Select the first option that reaches the failed seam.

Improve the loop before you continue.

• Reduce setup and unrelated initialization.
• Check the exact symptom.
• Control time, random values, files, and network access.

Non-deterministic bugs

Increase the reproduction rate above 50 percent. Repeat the trigger. Add stress. Narrow the timing window. Add a controlled delay.

No usable loop

Stop when you cannot build a usable loop. List each method that you tried. Request access to the reproduction environment. Alternatively, request a captured artifact or permission for temporary production instrumentation. Write a status: needs-context: <the access you need> handoff slug. The orchestrator retries this run after it supplies the access. Do not form hypotheses without a loop.

Confirm these conditions before Phase 2:

• [ ] The loop gives the same result each time.
• [ ] A flaky loop reproduces the bug more than 50 percent of the time.
• [ ] One command runs the loop without human action.
• [ ] The loop checks the exact reported symptom.
• [ ] The loop completes in less than 30 seconds.

Aim for a loop that completes in less than five seconds.

Phase 2: Reproduce the bug

Run the loop five times.

python3 skills/pasteurize/scripts/pasteurize.pyz repro-rerun \
  --cmd "<repro-command>" --runs 5 \
  --expect-output "<expected failure text>" --threshold 0.5 --timeout 30

Always name the expected failure mode. Use --expect-output for a failure with known output. Use --expect-exit for a failure with a known exit code. Confirm that the result contains reproduced: true. Confirm that matches equals runs for a deterministic bug. Read the results list and confirm each matched run. Increase --runs when five runs do not reproduce a flaky bug. Do not continue until the loop reproduces the expected failure. Do not accept an unrelated failure as a reproduction.

Symptom gate

Classify the symptom before you form hypotheses.

• Continue at the current model tier for a clean stack trace and a reliable loop.
• Upgrade the model tier for races, cross-module failures, performance regressions, or Heisenbugs.

Use the harness command for the model upgrade. For Claude, use /model opus. Then use /effort. Use the named equivalent for Codex or OMP. Use a generic model upgrade on other hosts.

Phase 3: Form hypotheses

Write three to five ranked hypotheses before you test one. State a testable prediction for each hypothesis. Discard a hypothesis when you cannot state its prediction.

Use this format:

If <X> causes the bug, then <changing Y> removes it or <changing Z> makes it worse.

Show the ranked list through `handoff-gate.md`. Domain knowledge can change the ranking. Continue with your ranking when the user is unavailable or uses --auto.

Phase 4: Add instrumentation

Map each probe to one Phase 3 prediction. Change one variable at a time.

Use tools in this order:

1. Use a debugger or REPL when the environment supports it.
2. Add targeted logs at boundaries that distinguish hypotheses.
3. Do not log all data and search it later.

Select one session tag for this investigation, such as a4f2. Prefix each temporary log with the exact token [DEBUG-a4f2]. Record the session tag in the handoff slug. Use the session tag to find every temporary log during cleanup.

For performance regressions, measure a baseline before you change code. Use a timing harness, profiler, or query plan. Then bisect the failed range.

Phase 5: Fix the bug

Add the regression test before the fix. Only add the test when a correct test seam exists.

A correct seam exercises the real bug at its actual call site. It uses the real data path and failure mode. A shallow or mocked seam gives false confidence.

Treat a missing seam as an architectural finding. Record it in the handoff slug. Write the applicable early-stop status. Set next: mold. Do not add a test at an incorrect seam.

When a correct seam exists, complete these steps:

1. Convert the minimum reproduction into a failing test at that seam.
2. Run the test and observe the failure.
3. Apply the smallest production change that can fix the failure.
4. Run the test and observe success.
5. Run the original Phase 1 loop and confirm that the symptom is absent.

Revert an unsuccessful fix before the next attempt. Stop after three unsuccessful fix attempts. Return to Phase 3. Write a new ranked hypothesis list. Do not make a fourth attempt without a new hypothesis.

Restart at Phase 4 when you find a new hypothesis. Otherwise, write the fix-attempts-exhausted status. Then set next: mold.

Leave broader changes for /cook. Record those changes in the handoff slug.

Phase 6: Clean the worktree