Audit the fix you just made to a guardrail

Safety auditModel-agnosticupdated 2026-08-28sha a0ca8e1c0454

Finding the hole in a guardrail feels like the hard part. It isn’t. The fix is written under the assumption that you now understand the failure, and that assumption is exactly what a second hole hides behind. This one refuses to accept a patched guard until the original bypass has been re-run against it, the fix’s own new branches have been walked, and someone has said out loud what the fix cannot see.

A guardrail was found to have a hole, and a fix has been written. Your job is NOT to confirm the fix works. Your job is to find what the fix missed, what it broke, and what it cannot see.

GUARD FILES: {{guard_files}}
THE ORIGINAL BYPASS: {{original_bypass}}
HOW TO RUN THINGS: {{verify_cmd}}

Do not summarise the fix. Do not say it looks correct. Work these four passes in order and report each before starting the next.

PASS 1 - Re-run the original bypass against the fixed code.
- Execute it. Paste the real command and the real output.
- State plainly whether the guard now refuses, and by which line.
- If you cannot execute it, say so in one sentence and mark this pass NOT RUN. Do not reason your way to a verdict you did not observe. A NOT RUN pass 1 caps the whole audit at "unverified" - carry that to the end.

PASS 2 - Walk the fix's OWN branches, not the code it guards.
A fix adds conditions, and every new condition is a new place to be wrong. For each branch the fix introduced:
- What happens on missing, empty, malformed, or unexpected-type input?
- What happens when the check itself throws?
- Does the branch default to refusing, or to proceeding?
Produce one line per new branch: file:line, the input that reaches it, what it does, and REFUSES or PROCEEDS. Any branch that PROCEEDS on bad input is a finding, even if it is not the original hole.

PASS 3 - Hunt for the same shape somewhere else.
The bypass you fixed is an instance. Name the CLASS: state in one sentence what property of the code made it possible.
- Search for every other place with that property. List each with file:line.
- For each, say whether the fix covers it. A fix applied at one call site while three others share the shape is not a fix, it is one of four.
- If the class has exactly one member, say so and show what you searched to establish that.

PASS 4 - Name what this audit cannot see.
- Is the guarded action reachable by any path that does not pass through these files? Name the paths you checked.
- Does the fix depend on a caller doing something correctly? If so, that dependency is the new hole - name it.
- What would have to be true for your PASS 1 result to be misleading?

RULES.
- You may not conclude until you have named at least one concrete weakness from passes 2, 3, or 4, with a file:line. If after genuine work you find none, say so explicitly and then name the branch you were least confident clearing, and why you cleared it. Silence is not a pass.
- Distinguish what you OBSERVED (command run, output seen) from what you INFERRED (read the code and reasoned). Label every finding one or the other. An inferred finding is a hypothesis, not a result.
- Do not propose a rewrite. For each finding give the smallest change that closes it, and say which existing test would have caught it - or state that none would, which is itself the finding.

END WITH: one line - is this fix safe to land, and what is the single thing most likely to still be wrong.

Fill in: guard_files original_bypass verify_cmd

Shared as is, for reference. Read it and decide what it will do before you run it; using it is your responsibility, under the terms.