Ein echter Lauf.
Inklusive echter Wartezeit.

Was diese Akte nicht zeigt

Ca. 1 Stunde 54 Minuten Wartezeit vor dem Push. Die Freigabe wurde um 09:14:56 UTC erteilt, der tatsächliche Push/PR geschah erst um 11:08:37 UTC — die Proof Policy verlangt vorher einen unabhängigen Observer-Anker (independent_witness), der nicht beschleunigt werden kann. Kein Fehler, sondern das Gate, das genau das verhindert, was es verhindern soll: sofortiges Durchwinken ohne unabhängige Spur.

Testabdeckung nicht automatisch gemessen. Das Bundle bestätigt nur, dass die Tests laufen und bestehen — nicht, wie viel vom neuen Code sie tatsächlich abdecken.

Fachliche Richtigkeit nicht automatisiert geprüft. Ob debounce() die richtige Lösung für den eigentlichen Anwendungsfall ist, bleibt menschlicher Bewertung vorbehalten.

Abhängigkeitsprüfung nur partiell. Nur neu eingeführte Abhängigkeiten wurden gegen OSV.dev geprüft, nicht der gesamte bestehende Abhängigkeitsbaum des Ziel-Repos.

debounce() mit injizierbarem Timer implementieren

Eine exportierte Funktion debounce(fn, waitMs) bauen, die eine entprellte Version von fn zurückgibt: Mehrfachaufrufe innerhalb des Wartefensters lösen nur einen einzigen Aufruf mit den Argumenten des letzten Aufrufs aus. Zusätzlich eine cancel()-Methode, die einen ausstehenden Aufruf verwirft. Tests mussten deterministisch sein — kein echtes Warten, ein injizierbarer/gefakter Timer statt direktem setTimeout.

Scope war explizit auf genau zwei neue Dateien begrenzt: debounce.js und debounce.test.js, keine weiteren Änderungen erlaubt.

Begrenzter Checkout, kein freies Netzwerk

Direkter Steuerungsaufruf, kein Kunden-Self-Service

Dieser Lauf wurde von Bewusst.Ki selbst als Probelauf ausgelöst, nicht von einem zahlenden Kunden — wie bei den anderen Demo-PRs in diesem Repository.

Validierung und CI waren erfolgreich

Blockierte Aktionen: Im Bundle sind keine abgelehnten Aktionen aufgeführt. Das ist keine Aussage darüber, dass jede mögliche Abweichung vollständig beobachtet wurde.

Das finale VERIFIED setzt einen zweiten Schritt voraus, der im Bundle nicht als Ereignis erscheint

Das signierte Bundle entstand in zwei Schritten: ein erstes, automatisch direkt nach dem Push erzeugtes Paket war inconclusive (CI konnte zu dem Zeitpunkt strukturell noch nicht gelaufen sein). Erst ein zweiter, separater Aufruf (attachFinalEvidenceToPullRequest, entspricht dem "Nachweis an PR"-Schritt) prüfte die echten CI-Ergebnisse und erzeugte das hier verlinkte verified-Bundle. Dieser Übergang — dass ein früheres Zwischenergebnis existierte und wodurch es ersetzt wurde — steht in keinem eigenen trace_event des signierten Pakets.

Das behauptet dieser Widerspruch nicht: nicht, dass debounce() fachlich falsch ist, nicht, dass die Signatur bricht, nicht, dass VERIFIED falsch ist.

Antwort des Verifiers, nach Vertrag: Bindung an die Bundle-ID gültig. Das referenzierte Feld (ein eigenes Ereignis für den zweiten Attach-Schritt) fehlt im Bundle. Der Verifier bewertet nicht, ob der Widerspruch inhaltlich recht hat.

Wirkung: VERIFIED bleibt das signierte Verdict. Mit diesem Widerspruch gilt die Dokumentation des Laufs als unvollständig, bis ein späterer Lauf den Zwischenstand-Übergang als eigenes Ereignis bindet.

Gegenakte, nicht hier editiert — eigener Zeitpunkt, eigener Inhalts-Hash (SHA-256, Methode in der Datei), zeigt per disputes_bundle_id auf das Original. Manuell eingereicht, kein Formular, kein automatischer Widerspruchs-Knopf.