Repro Fidelity
Use when a user asks whether a bug report is real, asks to reproduce a failure,
or mentions a runtime/deployment-specific issue such as a particular language
version, worker mode, platform, package manager, browser, SDK, or service model.
If the user asks for investigation only, combine this with $thoughts: verify
locally, report, and stop.
Contract
- Reproduce before accepting the report's diagnosis.
- Match the reported environment when feasible: runtime version, package
version, OS/platform, deployment mode, long-lived process model, flags, and
relevant data/state shape.
- Separate "the symptom is real" from "the proposed root cause is real".
- Prefer small, explicit repro harnesses over broad app runs.
- Do not treat sandbox, dependency, or local-service failures as product bugs
until rerun with the right permission/runtime model.
Workflow
- Pin the report:
- exact symptom, expected/actual result, affected version, runtime,
deployment shape, input/data pattern, and proposed root cause
- current branch/base and whether
main or a previous commit should be
compared
- Build the smallest repro:
- use the repo package manager and local docs
- use the requested runtime/version; try nix-comma or
nix shell when the
tool is missing
- keep scratch harnesses in
/tmp; when repo isolation is needed, follow
$thoughts and use a jj workspace when jj is available, otherwise a Git
worktree
- Increase fidelity only as needed:
- CLI/unit repro
- target runtime/version
- deployment mode such as worker/server/browser/device
- long-lived process/state accumulation
- before/after or A/B against the proposed fix
- Prove or falsify root cause:
- collect direct measurements such as logs, counters, memory, stored payloads,
traces, generated files, or persisted state
- if a suggested patch does not change the symptom, say the diagnosis was
falsified even if the bug is real
- Close out:
- state what reproduced, what did not, exact commands, environment, and
remaining fidelity gaps
- if implementing, add the smallest meaningful regression test once the
failing path is known
Output
Lead with the verdict:
- Reproduced / not reproduced / partially reproduced.
- Root cause: confirmed / falsified / still unknown.
- Fidelity: what matched the report and what still differs.
- Proof: key commands and observed output, not a transcript.
- Next action: fix shape, test to add, or evidence needed.
1---2name: repro-fidelity3description: Reproduce reported bugs with the relevant runtime, version, deployment shape, and state model before accepting the diagnosis or root cause.4---56# Repro Fidelity78Use when a user asks whether a bug report is real, asks to reproduce a failure,9or mentions a runtime/deployment-specific issue such as a particular language10version, worker mode, platform, package manager, browser, SDK, or service model.1112If the user asks for investigation only, combine this with `$thoughts`: verify13locally, report, and stop.1415## Contract1617- Reproduce before accepting the report's diagnosis.18- Match the reported environment when feasible: runtime version, package19 version, OS/platform, deployment mode, long-lived process model, flags, and20 relevant data/state shape.21- Separate "the symptom is real" from "the proposed root cause is real".22- Prefer small, explicit repro harnesses over broad app runs.23- Do not treat sandbox, dependency, or local-service failures as product bugs24 until rerun with the right permission/runtime model.2526## Workflow27281. Pin the report:29 - exact symptom, expected/actual result, affected version, runtime,30 deployment shape, input/data pattern, and proposed root cause31 - current branch/base and whether `main` or a previous commit should be32 compared332. Build the smallest repro:34 - use the repo package manager and local docs35 - use the requested runtime/version; try nix-comma or `nix shell` when the36 tool is missing37 - keep scratch harnesses in `/tmp`; when repo isolation is needed, follow38 `$thoughts` and use a jj workspace when jj is available, otherwise a Git39 worktree403. Increase fidelity only as needed:41 - CLI/unit repro42 - target runtime/version43 - deployment mode such as worker/server/browser/device44 - long-lived process/state accumulation45 - before/after or A/B against the proposed fix464. Prove or falsify root cause:47 - collect direct measurements such as logs, counters, memory, stored payloads,48 traces, generated files, or persisted state49 - if a suggested patch does not change the symptom, say the diagnosis was50 falsified even if the bug is real515. Close out:52 - state what reproduced, what did not, exact commands, environment, and53 remaining fidelity gaps54 - if implementing, add the smallest meaningful regression test once the55 failing path is known5657## Output5859Lead with the verdict:6061- Reproduced / not reproduced / partially reproduced.62- Root cause: confirmed / falsified / still unknown.63- Fidelity: what matched the report and what still differs.64- Proof: key commands and observed output, not a transcript.65- Next action: fix shape, test to add, or evidence needed.