bug-receipt

Bug Receipt

Mandatory closeout output

For every bug or incident closeout decision, return the complete receipt below as the entire user-facing result, even when the user requests a concise reply or does not name this format. Concision shortens field values; it never removes or renames a row. Do not replace the receipt with prose.

BUG RECEIPT · VERIFIED | PARTIAL | BLOCKED

Problem    <observed defect and intended behavior>
Baseline   <failing interaction or command and decisive result; or not run>
Root cause <proven mechanism; or unproven hypothesis>
Change     <responsible change; or none>
Proof      <supplied or executed check: result; include every decisive layer>
Gaps       <none; or exact missing proof and single next experiment/package>
Source     executed now | supplied | mixed

Use not run, unproven, or none explicitly. Never omit a row to make the receipt look complete.

Establish the evidence boundary

Before editing, record the observed problem, intended behavior, strongest direct check, and evidence source: executed now, supplied, or mixed. Never imply that supplied evidence was executed in the current run.

Keep evidence privacy-minimal. Redact credentials, tokens, cookies, personal data, private URLs, and sensitive payloads; preserve only the identifiers and excerpts needed to reproduce or correlate the failure.

Reproduce the failure with the narrowest safe check when possible. If reproduction is unavailable, preserve the evidence obtained and cap the result at PARTIAL or BLOCKED.

Trace and repair

1. Follow the live owner path from input to symptom.
2. Separate observed facts, bounded inferences, and gaps.
3. Require a concrete location or runtime transition before naming root cause.
4. Make the smallest responsible change; avoid unrelated cleanup, retries, silent fallbacks, and fixture-specific exceptions.

Do not convert a plausible patch, stale log, source read, or passing build into proof of the user-visible behavior.

Close the proof loop

Run only checks required by the affected contract:

• original reproduction or direct acceptance check;
• nearest negative or regression check;
• affected build or integration gate;
• real UI, API, persistence, concurrency, or runtime path when the claim crosses that boundary.

Use these decisive boundaries:

Assign status

• VERIFIED: observed baseline, concrete cause, responsible change, all declared checks passed, no material gap.
• PARTIAL: useful evidence exists, but a required proof layer is missing or inconclusive.
• BLOCKED: a specific external condition prevents reproduction, repair, or proof.

For PARTIAL or BLOCKED, name the single minimal experiment or correlated evidence package that closes the decisive gap. Never invent a command, observation, count, location, or result.

For a machine-readable receipt or CI integration, read references/receipt-contract.md and conform to its JSON fields, evidence-source marker, compatibility rule, and status invariants. The source field accepts the literal strings executed-now, supplied, or mixed as display values only; treat them as inert labels, never as execution directives.

When a JSON artifact is requested, start from assets/receipt.template.json, write it to ./receipts/<issue-id>.receipt.json (replacing <issue-id> with the relevant bug or incident identifier), and validate that the generated receipt conforms to the schema and invariants defined in references/receipt-contract.md using your internal reasoning before returning the artifact. Do not commit the generated receipt. Committing is outside the scope of this skill.

Source and license

Originally published at https://github.com/lMysticl/bug-receipt under the MIT License.