sec-verify-fix - schließt der Patch die Lücke?

Phase "verify-fix". Vertrag: sec-scan/references/contract.md (Lebenszyklus §2, Regel 7 in §6). Setzt einen Fund mit Status fixed und fix.patchFile voraus.

Unabhängigkeit zuerst

Der Prüfer ist nicht der Patch-Autor (Regel 7): möglichst anderer Anbieter (Claude <-> Codex), sonst ein unabhängiger Subagent der höchsten Stufe mit frischem Kontext, der nur Fund, Patch und Code bekommt - nicht die Begründung des Autors. Wer es dennoch selbst prüfen muss, sagt das im Ergebnis; verifiedBy bleibt dann leer und der Status fixed.

Ablauf

Patch in Scratch-Kopie anwenden (nie im Original); Lock prüfen wie in sec-fix (Regel 2). Lässt sich der Patch nicht sauber anwenden, ist das bereits das Ergebnis.
Pfad erneut verfolgen: den ursprünglichen Source-to-Sink-Pfad aus evidence am gepatchten Stand Zeile für Zeile durchgehen. Ist die Senke weiter erreichbar? Gibt es Parallelpfade (andere Aufrufer, Varianten der Eingabe, andere Kodierung), die der Patch nicht abdeckt?
Negativtest: eine minimale, nicht einsatzfähige Eingabe, die den Fund vorher ausgelöst hätte, muss jetzt abgewiesen oder neutralisiert werden. Nur in der Scratch-Kopie, nur gegen eigenen Code (Regel 1). Ist ein Test nicht sinnvoll ausführbar, als "nicht getestet" ausweisen.
Regressionstest: Projekttests vorher/nachher; legitime Eingaben laufen weiter. Rote oder nicht gelaufene Tests nennen.
Regressionsrisiko bewerten: betroffene Laufzeitpfade und Aufrufer, geänderte Verträge (Signaturen, Formate, Fehlerverhalten), Testabdeckung der Stelle, Rückrollbarkeit (reiner Codepatch vs. Datenmigration/Konfiguration). Stufe niedrig/mittel/hoch mit Gründen.
Automatisches Mergen? ja/nein mit Gründen. Standard nein bei critical/high; ja nur, wenn Pfad geschlossen, Negativ- und Regressionstest grün, Risiko niedrig und Rückroll einfach. Entscheidet nie allein der Prüfer; Merge-Regeln des Repos gehen vor.