Beweisgestützte Verifikation

Was macht Beweisgestützte Verifikation?

Verwenden Sie diese Fähigkeit, wenn Sie vorhandene Implementierungen, delegierte Arbeit oder die Abnahmebereitschaft prüfen. Ein grüner Befehl, eine statische Prüfung oder eine Zusammenfassung durch einen Agenten ist kein Beweis, solange sie nicht das behauptete Verhalten tatsächlich ausübt.

Wann anwenden

• Ein Agent erklärt eine Aufgabe für abgeschlossen.
• Tests bestehen, aber ihre Verhaltensstärke ist unbekannt.
• Ein Bugfix, eine UI-Änderung, eine Integration oder eine operative Änderung muss validiert werden.
• Eine statische Prüfung widerspricht einem zuvor zur Laufzeit verifizierten Verhalten.

Diese Fähigkeit nicht anstelle von test-driven-development für neuen Code verwenden; sie dient der Validierung von Belegen nach oder parallel zur Implementierung.

Vorgehen

1. Das behauptete Verhalten benennen.

   • Das benutzersichtbare oder extern beobachtbare Ergebnis angeben, das behauptet wird.
   • Abschlusskriterium: Die Behauptung kann ohne Rückgriff auf Implementierungsdetails getestet werden.

2. Den nächstgelegenen realen Prüfpunkt wählen.

   • Eine Interaktion mit einer eingebundenen Komponente, einen Integrationsrequest, einen CLI-Aufruf, einen API-Aufruf oder einen End-to-End-Flow bevorzugen gegenüber einem import- oder snapshot-basierten Test.
   • Realistische Nutzdaten und produktionsnahe Testdaten verwenden.
   • Abschlusskriterium: Der Prüfpunkt erreicht den Codepfad, dessen Verhalten behauptet wird.

3. Nachweisen, dass der Prüfpunkt aussagekräftig ist.

   • Bei geändertem oder entferntem Verhalten zuerst einen Fehlschlag beobachten, wenn die Implementierung fehlt oder – sofern sicher – ein bewusster No-Op eingesetzt wird.
   • Ein Test, der grün bleibt, wenn die geänderte Einheit umgangen wird, ist nichtssagend und darf nicht als Beleg verwendet werden.
   • Abschlusskriterium: Der Prüfpunkt kann funktionierendes Verhalten von dem relevanten defekten Verhalten unterscheiden.

4. Den Beweis ausführen und inspizieren.

   • Die fokussierte Prüfung durchführen, danach die relevanten breiteren Prüfungen des Projekts.
   • Den Test oder das Test-Harness selbst lesen, anstatt einer Zusammenfassung des Autors zu vertrauen.
   • Abschlusskriterium: Ausgabe und Implementierung stützen beide die exakte Behauptung.

5. Mit widersprüchlichen Belegen umgehen.

   • Benutzerverifiziertes Laufzeitverhalten als Beleg behandeln, das eine Erklärung erfordert, bevor es durch eine statische Prüfungsempfehlung ersetzt werden darf.
   • Die Framework-, Cache-, Infrastruktur- oder Laufzeitsemantik zurückverfolgen, die den scheinbaren Widerspruch verursacht.
   • Abschlusskriterium: Jede Änderung folgt dem stärksten verfügbaren Beleg, nicht dem Vertrauen des Prüfers.

Fallstricke

• Browser-Konsolenverhalten nicht mit Node verifizieren. Node's console.log unterstützt kein %c – es behandelt Style-Strings als normale Argumente und verwirft sie stillschweigend. Ein Node/Python-Harness gibt daher ein sauberes Raster aus und maskiert eine defekte DevTools-Darstellung. Um Konsolenausgaben zu verifizieren, den echten Browser über CDP ansteuern (Headless Chrome --remote-debugging-port + ein WebSocket-Skript, das Runtime.consoleAPICalled abfängt), oder benutzersichtbare Belege aus der tatsächlichen Konsole einholen. Ein Harness, das auf einer anderen Konsolen-Engine läuft, ist kein Beweis.
• Ein console.log mit sehr vielen %c-Segmenten überläuft die DevTools. Der Konsolen-Formatierer verbraucht die Argumente nacheinander entsprechend der Spezifikatoren; wenn ein einzelner Aufruf zu viele gestylte Segmente enthält (z. B. ~193), werden die nachfolgenden Style-Strings nicht mehr als Styles verbraucht – sie werden buchstäblich als unformatierter Text ausgegeben (der klassische color:#...;font-family...-Müll). Abhilfe gemäß Chrome-Dokumentation: ein console.log pro Zeile/Reihe, jedes mit einer begrenzten Anzahl von %c-Läufen. Deshalb „leckt“ per-Zeichen-ASCII-Kunst als ein riesiger console.log('%c%s%c%s...') die Styles.
• „Wird ohne Fehler gerendert“, typisierte Testdaten, Mocks, die die getestete Einheit ersetzen, und .todo()-Tests beweisen kein Verhalten.
• Niemals Produktionsverhalten nur ändern, um ein oberflächliches Test-Scaffolding zu befriedigen.
• Keine Abgabe behaupten, wenn eine externe Abhängigkeit, eine UI-Interaktion oder ein Deployment-Pfad nicht ausgeführt wurde; die nicht verifizierte Grenze melden.

Verifikation

Ein Fertigstellungsbericht muss Folgendes enthalten: das bewiesene Verhalten, den exakten verwendeten Befehl oder die ausgeführte Aktion, das beobachtete Ergebnis sowie jede Grenze, die weiterhin unverifiziert bleibt.