Independently rerun an unchanged bug reproduction package before repair. Check whether compiler diagnostics or runtime assertions support the exact reported claim, then preserve execution evidence and record a confirmed, unconfirmed, or inconclusive judgment.
Use when a bug PoC package needs an independent rerun and judgment before patching.
Review the instructions the agent will receive before you install.
Use after reproduce-bug has supplied a finding and PoC package. Read the
record contract.
Before target commands, follow its project guidance.
Do not use to repair a PoC, develop a patch, or infer reproduction from the reproducer's narrative.
Read finding.json, the reproduction's proof type, commands, any PoC, and raw receipts.
Do not read the reproducer's transcript.
Rerun the same baseline compiler command for compile failures, or rebuild and rerun
the unchanged runtime PoC and planned scoped inputs. Save stdout, stderr, exit
status and timing in validate/receipts/. If an observation is unreliable,
return inconclusive instead of inferring either presence or absence.
Decide whether the target diagnostic or runtime assertion demonstrates the exact claim and
violates the stated invariant. Write validate.json as confirmed,
not_confirmed, or inconclusive with a short reason and agent identity.
{
"schema_version": 1,
"outcome": "confirmed",
"agent": "validator-1",
"reason": "The unchanged PoC reached the assertion and demonstrated the claim."
}
validate/ directory with
uv run --no-project <script> manifest <validate-step-dir>, then run the
record checker. Return
the package without editing the PoC or finding.| Shortcut | Required action |
|---|---|
| Fix the PoC to make the claim work. | Mark it inconclusive and explain why. |
| Trust the reproducer's conclusion. | Rerun the unchanged package independently. |
No reviews yet. Tell others what you thought.
No login needed. Share how it worked for you, ask a question, or note where it did not run.
No comments yet. Be the first to write one.
Build and test code with AddressSanitizer, a tool that detects invalid memory access during execution. Configure checks for C/C++ and unsafe Rust, investigate crash reports, and adjust settings for fuzzing, or testing with generated inputs.
Assess source code and live reproduction evidence to decide whether a change introduced a regression, a newly caused defect. Record supported conclusions, exclusions, severity, and unresolved gaps in an evidence-linked decision file.
Sets up AFL++ to test C/C++ programs with varied generated inputs, a technique called fuzzing. Covers running tests across CPU cores, monitoring progress, reducing input collections, and reproducing crashes for investigation.
Audits GitHub Actions workflows that run AI coding agents. Traces how attacker-controlled content reaches prompts, checks permissions and sandbox settings, and reports evidence, severity, and fixes for prompt injection and related configuration risks.
Reviews Algorand smart contracts written in TEAL or PyTeal for 11 vulnerability patterns. Produces a complete coverage table and findings with code references, severity ratings, and suggested fixes, with optional automated checks using Tealer.
Set up Atheris to test Python code and C extensions with automatically varied inputs. It guides test harness creation, coverage tracking to explore more code, and AddressSanitizer setup for finding memory errors.