vulnerability-validation

name	vulnerability-validation
description	Discover new vulnerabilities (0-days) in a target repository by analyzing the code itself, optionally starting with the bundled deterministic discovery engine, then validate candidates with attack-surface and variant analysis, empirical PoCs, reachability and threat-model gating, minimal idiomatic fixes, replayable evidence, mutation or negative controls, and role-lens consensus review. A supplied scanner finding, researcher report, or PoC is an optional seed fused into discovery, never a substitute for the mandatory native sweep; validate it alongside self-found candidates. Use it when triaging a scanner or researcher finding, correlating a CVE to a codebase, auditing a repository for 0-days, validating a PoC, or preparing a maintainer advisory.
license	Apache-2.0
compatibility	Portable Agent Skills format for Codex, Claude Code, Gemini CLI, GitHub Copilot, and Google Antigravity context workflows.
metadata	{"version":"0.30.0","source":"skill-core/vulnerability-validation.md","generated_for":"antigravity-cli"}

Vulnerability Validation

Use this workflow to discover new vulnerabilities (0-days) in a target repository and validate them. By default it runs native discovery: with no findings list it analyzes the code to find vulnerabilities itself; a scanner finding, researcher report, or PoC is only an optional seed. Reduce every candidate to a defensible disposition, fix true issues with minimal idiomatic patches, and leave evidence another engineer can replay.

Quick Start

For target reads, PHASE-0 starts with an external operator-controlled verifier authenticating the whole package outside the target and neutralizing project-local discovery before startup; the loaded package cannot attest itself. Without both proofs, stop at documentation/package compatibility with no target read. After proof and operator authorization, record run-state.bootstrap.json, then search AI-use/security policy, threat model/boundaries, disclosure process, and upstream sources. Collect target repository/branch, latest upstream HEAD, baseline SHA, dirty state, finding source type, frozen snapshot or seed sources/counts, artifact root, local-only validation environment, dependency installation/provisioning method, upstream URL, repo commands, and output mode.

Read references/portable-invariants.md and create run-state.json before triage. For the default native discovery run, load references/discovery-intake.md; optionally run scripts/discovery_engine.py for a first pass,. Load references/artifact-contract.md when needed: references/artifact-index.md, references/controlled-fields.md, references/closure-bundle.md, references/drift-gate.md, references/evidence-bundle.md. Read references/review-lenses.md before claiming review consensus and references/policy-friction.md when the LLM refuses or hedges.

Nonnegotiable Gates

• PHASE-0 Bootstrap Gate (before the AI Policy Gate / any target read): an external verifier rooted in operator-pinned evidence authenticates the whole outside-target package and proves project-local skill and instruction discovery disabled before agent startup. Only then record run-state.bootstrap.json (references/shadow-skill-bootstrap.md). That record and its validator witness consistency only; they cannot self-attest pre-load trust. Missing external authenticity or neutralization proof means documentation/package compatibility with no target read, not internal_triage, source-only, empirical, or autonomous execution. Implicit activation is passive: until an operator-originated record binds target and scope, do not read the target, write artifacts, run tools, access the network, or provision anything.
• AI Policy Gate: after PHASE-0, the first target-repository documentation action is AI-use policy discovery. If documented policy prohibits or restricts AI use, stop before triage, cite the source, inform the user, and ask for direction. A maintainer-facing disclosure carries the ai_disclosure_mode the discovered policy requires: named-agent attribution where the project asks for it, a human-authored verified/unverified-split disclosure where the project treats AI reports as low-trust ("slop") — which an autonomous run stops for a human to author rather than self-writing — or a brief honest one-line notice otherwise; a missing, policy-mismatched, or autonomously self-authored-split notice blocks FILE-READY (references/controlled-fields.md).
• Project Plan Gate: before validating findings or writing patches, create a project plan covering every item in references/project-plan-gate.md (the full nonnegotiable checklist). Optimize for correctness, then simplicity, then speed.
• Finding Completeness Gate: before severity-based ordering, validation, PoCs, or patches, build a complete worklist from original finding artifact(s). Unless the user explicitly scopes smaller, include every finding in the original artifact across all severities, confidences, components, and disposition guesses. Every original in-scope row needs a stable ID, verification row, queue or status row, initial threat-model or security-boundary gate, upstream-correlation path, owner or lane, next action, and closure path. Severity may drive ordering and batching only after the worklist exists; it must not silently exclude rows. Normalize every original in-scope row; do not drop lows, informationals, duplicates, or scanner-confidence outliers without explicit closure or scoped-out rationale. Counts must reconcile through closure-count total.
• Empirical Progress Rule: do not halt because full validation may take a long time or because tooling is missing. For each in-scope executable finding, run the smallest safe local empirical step that can increase certainty: source reachability, existing focused test, tiny harness, local fixture, then isolated dependency provisioning. Time cost, missing tools, and unfamiliar setup are planning inputs. Use bounded attempts with timeouts, install only the next required dependency, and continue queued work when an attempt needs later follow-up.
• Latest-HEAD Filing Gate: do not file, publish, or hand off a maintainer-facing vulnerability claim until it is validated against the target repository's latest upstream target-branch HEAD. Use git ls-remote or an equivalent remote lookup and record target remote URL, branch, HEAD SHA, lookup command or source, timestamp, dirty state, and validation environment. Also re-validate on the latest released toolchain/runtime and the latest released dependency/module the finding touches (e.g. latest Go+module@latest, or JDK+Maven Central) from its own authoritative source — or, where the ecosystem lacks package modules, the affected component or a not-applicable rationale; record exact versions and authoritative source, and if it no longer reproduces on latest use the matching closure and adjust the affected- version claim. Immediately before filing or maintainer handoff, recheck the target upstream HEAD. Missing, stale, blocked, or changed latest-HEAD proof blocks filing. If the issue no longer reproduces or claimed code is absent, use the matching closure status instead of filing. If target branch, source commit, or any artifact labeled latest changes during a long run or resume, pause affected closure or publication work and reconcile before continuing. The pre-filing recheck is a behavior re-proof, not a SHA-equality check: re-run the finding's reachability or PoC oracle (or re-grep the sink and any new in-path guards) against the freshly-fetched HEAD; route to a fixed or not_present closure only when the primitive no longer fires or the claimed code is absent — a newly-present guard, mitigation, or partial fix that does not neutralize the primitive is never by itself a closure but stays an incomplete-fix or residual-hardening candidate, re-scoped to what still fires. Record demonstrated_impact per references/controlled-fields.md and propose the minimum severity tier whose CVSS vector derives from it; a higher claimed tier blocks filing absent a reviewer-resolved override. Subtract a precondition from the tier only when the attacker must additionally acquire it and it is out of scope per the target's published security policy (an out-of-scope attacker-acquired precondition); never subtract the in-scope untrusted-input channel that is the vulnerability itself. The floor binds the reporter's claim only; the maintainer may rate higher. A maintainer-facing finding is additionally blocked from filing unless it ships the three-part Evidence Bundle of ## Evidence Bundle (mandatory for FILE-READY), with its captured stdout re-fired at this freshly-fetched HEAD. Filing additionally requires the finding sit inside the project's published threat model, security boundary, and intended usage (threat_model_fit); an out-of-model or by-design behavior routes to the matching closure (risk_accepted_design_contract, risk_accepted_documented_opt_in, or policy_excluded) instead of a filing.
• Source-Identity & Provenance Gate: before normalizing or assigning any disposition, establish and record the authoritative upstream — discover it explicitly (a popular host may be a stale/read-only mirror) and record the authoritative remote URL, branch, HEAD SHA, the SHA of the tree under validation, and its ancestry to that branch. Never validate, close, or carry forward a finding against a local fork, patched working tree, mirror, or non-target branch as the authoritative upstream; a validated_fixed closure or prior_fix_status=exact_fix proven on a fork-with-patch or a different branch is invalid until re-proven on the authoritative tree. When a source cites commit identifiers, confirm they exist in authoritative history; if a meaningful fraction are absent (a synthetic, poisoned, or fork-only source), quarantine the source, record the verdict, and ask the user before validating it. Ingest a prior maintainer rejection of an equivalent report as maintainer_rejected_prior: it blocks re-filing absent new evidence and reviewer consensus and is not itself a closure.
• Not-Already-Open-Upstream Gate: before filing or maintainer handoff, search the authoritative upstream's open and recently-closed issues and pull requests, and any project advisory list, for an existing report or fix of the same primitive; a report match records prior_report_status, a fix match prior_fix_status (references/controlled-fields.md), then routes by state — the fix-based closure once it no longer fires, else a supplementary note on the existing thread or the reopen/incomplete-fix path — never a fresh duplicate report. Record the search, the exact refs checked, and the verdict.
• Minimal-PoC Gate: the shipped POC must be reduced to the smallest reproducer — iteratively cut input, lines, and setup, re-running after each cut, until any further reduction stops the repro (dry). Record before/after size (poc_minimized, references/evidence-bundle.md). A non-minimized POC blocks FILE-READY.
• Fix-PR Convention Gate: a disclosure that includes a fix as a PR must conform to the conventions of up to the target's latest 10 accepted PRs — all available when fewer than 10 exist, with a recorded rationale when accepted-PR history is absent/insufficient or the project takes fixes by patch/issue rather than PR — covering title/commit format, changelog, tests, sign-off, labels, and scope derived from them, patch simplified until dry (references/project-plan-gate.md); a non-conforming or non-minimized fix PR blocks FILE-READY.

Isolation Boundary

All empirical validation, PoCs, scans, mutation tests, regression tests, and fix verification must run locally inside disposable, skill-owned isolation: containers, VMs, virtualenvs, temporary worktrees, synthetic fixtures, local services, or loopback/container internal networks. The target under test must be local to that isolated environment.

Never test against production, shared staging/dev/QA, corporate/shared environments, third-party internet targets, public IPs/domains, SaaS APIs, external services, real customer/user data, production dumps, secrets, tokens, credentials, live or internal service identifiers, private hosts/domains/IPs, or account, system, data, repository, branch, issue, ticket, person/team, advisory, package-registry, project, or resource identifiers not created for the current run. Use synthetic or repo-local test data only and synthetic identifier surrogates only. Validation traffic must not leave loopback, container-internal, VM-internal, or skill-owned isolated networks; outbound fetching must not carry exploit traffic, probes, scans, PoC payloads, secrets, credentials, or real customer/user data.

Do not make host/global changes: no global package installs, host service changes, firewall/DNS/routing changes, credential-store changes, global configuration changes, or writes outside declared skill-owned temporary paths except task-owned containers, VMs, isolated networks, local processes, and temporary files. If provisioning appears to require broader host/global changes, stop and ask the user for explicit user approval, then document exact commands, affected paths/services, rationale, cleanup steps, and cleanup status.

Within the local isolated boundary, assume permission to install, build, configure, and run the software needed for empirical testing. Install or provision missing compilers, runtimes, services, packages, fixtures, and test harnesses before declaring live validation blocked. Assume permission to run all required repository, exploit, fix-verification, regression, negative-control, mutation, lint, generation, and replay tests inside that isolation.

First-Proof Tranche

Optimize speed by proving something real early. The minimum first-proof tranche is: external PHASE-0 proof plus its bootstrap record, AI policy decision, branch/SHA/dirty state, worklist skeleton, threat prefilter, isolation boundary, dependency plan for the next empirical step, and the first source reachability, focused test, harness, fixture, or PoC attempt. Defer maintainer route, advisory text, full upstream correlation, and filing package until the finding is proved or handoff-ready, unless the user's requested output requires them earlier.

Workflow

1. Profile the repository (PHASE-0 first). Externally authenticate the package and neutralize project-local discovery per the Bootstrap Gate BEFORE any target read; only then record run-state.bootstrap.json. Then search repository documentation for AI-use policy before any other target-repo action; capture branch, commit SHA, build/test commands, security policy, threat model, security boundary, trust boundaries, disclosure process, generated-file rules, coding idioms, helper APIs, test/lint conventions, issue/PR/advisory/release locations, supported branches, and maintainer contact/reporting preference. Record sources and absent or ambiguous documentation. When security docs conflict or look stale, record which source is authoritative and why. Do not infer a maintainer contact route from a platform default.
2. Provision incrementally. Create a local, disposable, skill-owned isolation boundary first. Install, build, and configure the minimum software needed for the next proof step, batching dependencies only when they serve multiple queued findings. Record commands, versions, sources, network mode, temporary paths, environment deltas, cleanup steps, and any user-approved host/global exception. A missing tool, dependency, service, or fixture is not a blocker until reasonable isolated local provisioning attempts fail. Never substitute production, third-party targets, or real data for isolated validation.
3. Normalize findings. For a native-discovery run, first run the discovery loop in references/discovery-intake.md and freeze the discovery snapshot; its candidates enter this step as the findings to normalize. Preserve original input, assign stable IDs, reconcile paths (resolve renames and relocations by basename and content, not path prefix; a relocated, restructured, or dot-prefix/encoding-mangled file is a relocation, not a deletion), group duplicates by primitive or sink, and create the run manifest, verification sheet, status ledger, queue manifest, and harness-coverage matrix. For findings-source directories, inventory only the declared source root, record bounds and exclusions, keep target repository root separate, preserve included artifacts, classify finding-records versus run artifacts (logs, dedup records, PoCs, object/evidence files) and build the worklist only from finding-records, record parser/source type, reconcile source-row counts, and use source file plus row or record identity for stable IDs.
4. Correlate upstream state before closure. Search open and closed public issues and PRs, branches, commits, the project's security advisories, CVE registries, ecosystem advisory feeds, affected-branch changelog and release notes, mailing lists, and documented disclosure channels where available. Record advisory IDs verbatim per finding, query method, search terms, timestamp, source path or URL, item state or availability, channel identifier when present, and relevance rationale. Do not contact maintainers unless the user asks. File overlap is triage only; exact fix status requires branch/commit relation plus evidence for the same boundary, sink, and trigger. Record separate prior-report and prior-fix statuses; neither is a closure status, proof label, truth signal, fix acceptance, or maintainer consensus. Re-run upstream correlation per filing or tranche immediately before submission, recording recheck timestamp, source set, delta versus intake, and staleness bound; keep recheck no older than the latest-HEAD recheck or the staleness bound in run-state.json. Block any tranche on a new or changed public-disclosure match pending the advisory-submission-eligibility gate. The recheck also scans this program's own already-filed and already-closed findings for a same-sink, same-root-cause match, blocking a self-duplicate absent a recorded materially-distinct rationale (differing boundary, sink, trigger, version range, or impact; an unmerged survivor, sink-family variant, or incomplete-fix residual is not a self-duplicate). An exact-match published advisory (same root-cause/sink/input-class/trust-boundary) records prior_report_status=exact_duplicate_report regardless of HEAD state; if the primitive no longer fires an exact-match fix also records prior_fix_status=exact_fix with a valid closure, else the still-firing portion routes to the reopen or incomplete-fix path with the duplicate report still recorded. A maintainer follow-up re-raising an already-merged-and-credited finding requires a changelog-at-HEAD recheck first.
5. Gate against the threat model. For each finding, state attacker-controlled input, trust boundary, documented security boundary, default exposure, opt-in or experimental status, documented operator responsibility, affected released version or accepted unreleased-branch scope, and whether the row is advisory-eligible, hardening, or non-advisory traceability. Reject or risk-accept findings outside the documented threat model or security boundary instead of calling them false positives. Record capability_gained and baseline_grant per references/controlled-fields.md, which governs the risk_accepted_design_contract routing and the server/redirect/protocol-supplied-content exclusion.
6. Prove or reject in code before patching. Start from the claimed sink and prove reachability, input control, impact, and current behavior. For executable findings, live validation is mandatory: run the exploit, PoC, or focused reproduction against the vulnerable baseline/current tree and record observed security-relevant behavior before patching. Assign each executable finding a harness path or non-live exception before closure. Use closure_status for terminal outcomes only; use workflow_state for pending, blocked, patch-authored, review-ready, or reopened work. Do not inherit severity or truth from the scanner.
7. Build falsifiable evidence. Prefer focused probes that fail on vulnerable behavior and pass after the fix. Add at least one negative control when a passing command could succeed for the wrong reason. Before using a PoC or harness as closure evidence, record its soundness verdict, oracle, oracle kind, selector proof, baseline vulnerable-behavior evidence, false-positive control, patched-tree result, and false-negative or calibration evidence or infeasible rationale. Record oracle–mechanism concordance structurally: declare the sink's documented failure-mode set, of which every vulnerable-side signal (the expected observation and the observed baseline result) must be a member — a signal the sink cannot emit (e.g. a sink that returns errno, not a crash) is then a visible discordant claim, an unsound oracle; do not promote it. Sanitizer-evidence limits (structural blindness to the bug class) follow references/portable-invariants.md. Zero-match execution, missing selector proof, missing baseline evidence, or missing controls blocks that use. Source proof is acceptable only when live execution is impossible, unsafe, irrelevant, or blocked by a recorded toolchain or environment constraint; the blocker, attempted command, next experiment, harness state, and reviewer acceptance must be recorded.
8. Verify command integrity. Every command log records cwd, command, env deltas, timeout, selector, stdout/stderr, exit code, tool versions when relevant, and whether selectors matched real tests. Zero-match, skipped, unexpectedly empty, or stale-build suspect test runs are not evidence; run a clean rebuild or record a blocker. Attest environment fidelity: state how the validation environment relates to the affected configuration (a match, or the delta and why reachability/impact still holds) — a non-representative env (build-config or load differences) can inflate or fabricate the signal and would not reproduce on the claimed configuration.
9. Patch only true issues. Make the smallest code change that closes the proven sink. Match existing naming, helper shape, error handling, metrics, logging, generated file rules, and test style. Check compatibility-sensitive contracts before accepting the patch. Avoid new configuration, public APIs, or broad refactors unless evidence requires them. Rework non-idiomatic or compatibility-breaking patches before closure. Update the finding-patch index before reviewer signoff.
10. Verify the fix. For every patched executable finding, rerun the same live exploit, PoC, or focused reproduction against the patched tree and show vulnerable behavior no longer occurs while negative controls still behave as expected. If the PoC still demonstrates vulnerable behavior, rework the fix. Run the repository's existing test suite unchanged on the patched tree; if it fails, prove whether the failure is pre-existing with a clean-baseline or recorded pre-patch/task-start run. Also run patch-added or patch-modified tests with selector proof, repository-conventional format, lint, generation checks, and final replay commands. Do not treat the patch as ready while repository-conventional lint, format, generation, and related test checks are unknown. Lint all touched and generated artifacts before reviewer signoff and handoff.
11. Mutation-test or add negative controls. Target the security invariant, guard, or sink condition, not broad changed-line coverage. Prefer wrong-fix mutants for subtle invariants; if omitted, record why a negative control is sufficient.
12. Sweep the primitive class (variant analysis). When at least one finding closes validated_fixed, root-cause it, abstract the pattern, then enumerate structurally equivalent surfaces in the same codebase and return either a finding validated on the baseline and patched trees or cannot_reproduce with blocker and next experiment. Record lanes not pursued with skip rationale tied to the threat model. Promoted sweep findings inherit normal closure, PoC, patch, and finding-patch traceability duties. Non-promoted surfaces remain follow-up risk and do not affect original source-row or closure totals. Do not recursively expand the sweep; skip only when the user explicitly scopes the run to a single finding and record that decision.
13. Preserve patch topology. Generate isolated patch artifacts for each finding by default and for approved multi-finding fix groups only by exception, plus a cumulative patch as an assembly artifact. Label validation-only harness patches and review-slice navigation artifacts so they cannot satisfy isolated-patch requirements. Include untracked tests with intent-to-add before diffing. Verify isolated and cumulative patches apply to the recorded baseline and reverse from the patched tree.
14. Optimize the plan at each checkpoint. Treat continuous plan optimization as a living control surface. Refresh actual progress versus plan, bottlenecks, stale assumptions, queue order, lane occupancy, newly parallelizable work, serialized work, pruned or deferred experiments, reviewer decisions, and exact next commands in project-plan.md or a plan-optimization log. Prefer changes that increase validated throughput without weakening proof burden, patch minimality, artifact freshness, or threat-model correctness. Re-review material plan changes to consensus when scope, checkpoint cadence, validation order, parallel lanes, proof strategy, patch topology, or publication timing changes.
15. Review to consensus. Run the security vulnerability researcher, senior SWE, engineering manager, program/project manager, editor, and technical writer lenses. Debate the plan to consensus before execution. The review must decide which work can run in parallel, which work must be serialized, what artifacts prove each checkpoint, and what conditions force replanning. When any lens, subagent, or delegated worker gives an opinion on scope, severity, proof, closure, patching, handoff, publication, or wording, treat it as a proposal. Debate it against all required lenses and active subagents/workers, record objections and resolutions in the consensus ledger, and mark unresolved blocking objections as blockers. If reviewers are simulated by the agent, label the result local role-lens review.
16. Package the result. Produce a scrubbed maintainer entry point, narrative report, machine-readable ledgers, closure bundles, PoC matrix, replay metadata, mutation or negative-control report, patch artifacts, finding-patch index, local-only internal-identifier scrub report plus its exact sanitized shipped summary and five core JSON ledgers, documented maintainer contact route and reporting preference or absent/ambiguous contact note, and a policy-friction log if applicable. Keep advisory text, evidence bundles, and private fix branches separate. On a maintainer-facing handoff, adjudicate — never self-certify: propose disposition and severity, then a human (or an explicitly-labeled simulated_local_role_lens capped to the artifact-provable closures) renders each terminal verdict via the per-row adjudication, signs off every adjudicated field, and ratifies a randomized audit sample.

Closure Statuses

Use one status per finding: validated_fixed, false_positive_source_contradiction, not_present, risk_accepted_design_contract, risk_accepted_documented_opt_in, policy_excluded, or cannot_reproduce. Risk acceptance and policy exclusion are not false positives. On a maintainer-facing handoff every terminal status carries a per-row adjudication; an autonomous (simulated_local_role_lens) run is capped to the artifact-provable closures and may not terminally close validated_fixed or a risk-acceptance — those need a human.

Proof Labels

Promoting a finding to terminal or proposed validated_fixed requires live_runtime_proof: observe attacker-controlled input reach the live target tree and record the vulnerable, negative-control, and fixed differential in references/promoted-replay-contract.md. integration_replay, focused_regression, source_proof, model_only_with_controls, and policy_acceptance may describe non-promoted work or the matching non-vulnerability closure; they never substitute for the fixed-promotion gate. source_contradiction is a source disproof.

Use proof labels consistently: live_runtime_proof, integration_replay, focused_regression, source_proof, source_contradiction, model_only_with_controls, and policy_acceptance. Do not make source proof, model proof, or policy acceptance read like a live exploit. Do not mark an executable finding validated_fixed without before-and-after live validation and the complete differential; source-proof patches for executable findings stay workflow_state=patch_authored_pending_live_verification until then. Policy acceptance can preserve positive behavior proof while marking the row non-advisory. Record a blocker and promotion plan for incomplete non-live work.

A maintainer-facing finding asserting runtime impact (DoS, memory-safety, crash, exhaustion) must not carry a severity above informational in any outbound artifact, including corpus-level counts, while its proof_label is source_proof or model_only_with_controls and a live oracle is feasible but has not produced a result, absent a reviewer-accepted non-live exception with a recorded blocker and promotion plan. A live oracle, not source reasoning, settles the OOM-or-fault-injection-versus-attacker-reachable and JIT-or-timing-independence distinctions before severity is asserted outbound. Fault-injection- or OOM-only reachability does not by itself disqualify a finding but is a recorded reachability caveat driving severity (downgrade or risk-acceptance), with the attacker-controllability path stated or its absence noted; it is never auto-routed out of scope without a per-finding reviewer disposition.

Flaky, race-prone, timing-dependent, or order-dependent PoCs and tests are blockers, not evidence; restore determinism (or record a reviewer-accepted non-live exception) per the determinism and replay rules in references/portable-invariants.md before handoff.

Evidence Bundle (mandatory for FILE-READY)

A finding is FILE-READY when routed to maintainer/advisory handoff or filing (the Latest-HEAD Filing Gate and ## Handoff Rules states). No finding is FILE-READY unless it ships an Evidence Bundle with all three parts — a hard gate; a bundle missing any part blocks FILE-READY. It is the concrete artifact form of the live_runtime_proof label and ## Proof Labels' live-validation duties: (1) POC — harness/trigger input (artifact_hash, bytes sealed per references/portable-invariants.md), or for a non-memory authz/logic finding the reproduction script plus a negative control; (2) RUN INSTRUCTIONS — exact build/run commands, sanitizer/config flags, target, env deltas, selector — enough to replay unchanged; (3) CAPTURED STDOUT — the verbatim stdout/stderr from actually running the POC at the cited HEAD (a wire-capture or protocol trace satisfies this part); its stdout_provenance is the enum fresh_run or prior_captured (a fresh_run block carries companion {date, head_sha, host_class} metadata) — never a described or unrun transcript. Before FILE-READY re-fire at the current upstream HEAD and re-label fresh_run; on contradiction (sink changed, guard or fix landed) drop or reclassify — never file the superseded framing. A heavy build is not an excuse: run it on the isolated fleet within policy per ## Isolation Boundary, or honestly downgrade to a non-live proof label with a recorded blocker — never ship an unrun POC as validated. All three parts are public-scrubbed before leaving the local evidence boundary. The disclosure shipped to the maintainer embeds or attaches the POC — a safe reproducer where the trigger is weaponized — plus its captured stdout/wire-proof (poc_and_stdout_shipped_in_disclosure); a local-only reference blocks FILE-READY. Full spec + gate checklist: references/evidence-bundle.md (recorded in references/closure-bundle.md, checked by references/drift-gate.md).

Parallel Work

Parallelize only independent work with disjoint write sets and separate worktrees or build outputs. Never run concurrent builds against shared mutable output directories. Preserve a queue manifest with owner, write scope, harness state, blocker, and next command. Re-review the plan when a lane discovers shared files, shared build outputs, a new blocker, an unmapped shared harness, or evidence that changes dependency order. A native_discovery maintainer-facing handoff runs as a checkpointed loop carrying loop_state and the checkpoint/lane-heartbeat/tool-firewall logs; a legacy supplied-findings bundle (no finding_source_type, exec_approval_mode not operator_batch_preapproved) stays valid without them. Loop/lane detail: references/loop-engineering.md.

Handoff Rules

Before saying the work is done, run the drift gate in references/drift-gate.md. It must check counts, statuses, proof labels, patch hashes, shortstats, finding-patch links, closure bundles, harness coverage, replay logs, existing-test-suite results, patch-touched test results, PoC fixed-behavior results, idiomatic-patch review, compatibility/API-contract review, lint results, policy-friction log, internal-identifier scrub report, review state, latest-target-upstream-HEAD proof, repository-conventional lint results, documented AI-use policy handling, and final threat-model or security-boundary fit for every confirmed vulnerability. Before maintainer/advisory submission, verify user authorization, documented contact route and channel, advisory eligibility (affected released version or accepted unreleased-branch scope), documented reporting preference, latest-HEAD recheck, Evidence Bundle completeness (POC + run instructions + verbatim captured stdout, re-fired at latest-HEAD, scrubbed), no placeholders, no unsanitized internal identifiers, embargo-safe delivery, clean delivered-entry replay, and full-corpus or tranche counts. Source-row count, in-scope count, out-of-scope count, and closure-count total must reconcile. The final message states what was validated, rejected, blocked, how to replay evidence, the exact latest upstream HEAD, and baseline commit.

Immediately before any handoff, send, or re-raise — including internal-only bundles that publish a ledger-of-record — pull fresh live-upstream state (advisory API, merged-PR/changelog credit, CVE feed) for every program with filed or filable advisories, record the pull timestamp, and reconcile each finding or engagement status against it. A status disagreeing with live upstream is updated to match or carries an explicit dated divergence rationale (a team-authored unpublished draft, a server-supplied finding with no upstream report, a recorded no-publish decision); unexplained disagreement — or a ledger asserting nothing-filed while filed advisories exist — blocks handoff. Advisory eligibility requires affected and patched fields that are concrete released versions or a recorded unreleased-branch scope (a pinned SHA plus an attestation that no tagged release yet contains the affected or fixed code); Patched: None is valid whenever no fixed release exists yet — a fresh report before any fix, or unreleased-branch-only code. Reject the unresolved placeholder tokens enumerated in references/drift-gate.md but never a deliberate unreleased-branch scope or a legitimate single-point or SHA scope. Run send-decision reconciliation before transmission: every outbound row carrying a HIGH, CVE-class, or advisory-eligible framing needs a strict or empirical re-vet dated at or after the row's last evidence change, and its outbound severity, advisory-eligibility, and HIGH/CVE-class label must equal that latest re-vet's disposition. A row the latest re-vet downgraded or recommended withdrawing may not be sent at the superseded higher framing absent a reviewer-signed override in the consensus ledger. Routine LOW or MEDIUM hardening hand-offs are not gated.

Continuous Improvement

When a reviewer catches a miss, a PoC was weak, a command selected no tests, a patch was too broad, or an artifact drifted, update the local skill feedback before closing the run. Keep new rules generic; do not encode one repository's private policy as a universal rule.