SebastienElet/agent-skills

AssertLedger

Übersicht

Bewerte denselben Regressionstestkandidaten gegen korrigierten Code, einen deklarierten Fehler und eine neutrale Kontrolle. Bewahre die Beobachtungen auf und spiele das resultierende Manifest erneut ab, bevor du das begrenzte Urteil meldest. Der Benutzer liefert den Fehler und die Bedeutung der Kontrolle; das Tool stellt keine allgemeine Programmkorrektheit, Produzentenauthentizität oder dauerhafte Freiheit von flaky Tests her.

Dieser lokal gepflegte Workflow folgt der veröffentlichten AssertLedger 1.4.0 Dokumentation.

Verwendung

Verwende $assertledger <Repository und Regression> oder /assertledger <Manifest zum Abspielen>. Beispiel: Prüfe, ob die übertragene Parity-Regression die bereitgestellte fehlerhafte Revision erkennt. Verwende tdd für gewöhnliche Implementierungen und proof-integrity-review, wenn sich der Verifikationsmechanismus selbst ändert. Die AssertLedger-Qualifikation ist ein zusätzlich angeforderter Workflow, kein pauschales Test-Gate.

Beziehe die kompatible CLI über die deklarierte Tool-Installation des Hosts; das Skill selbst benötigt kein Dotfiles-Checkout zur Laufzeit. Falls die CLI fehlt, melde diese Voraussetzung, anstatt ein Paket zu installieren oder die Projektkonfiguration implizit zu ändern.

Schritte

1. Führe assertledger --version und assertledger doctor /pfad/zum/repository --json aus. Diese Diagnose ist statisch und schreibgeschützt. Untersuche Konflikte und Framework-Unterstützung, bevor du die Ausführung planst; die Erkennung eines Testbefehls zeigt nicht an, dass ein Adapter ihn ausführen kann.

2. Lege für die Git-Qualifikation die fehlerhaften, korrigierten und neutralen übertragenen Revisionen, den neutralen Grund, den Kandidatenpfad, die unveränderten Basistest-Pfade und ein neues Ausgabeverzeichnis relativ zum Repository fest. Beziehe bereitgestellte Fakten, wo möglich; erfinde niemals fehlende Kontrollsemantik. Konsultiere den Git-Leitfaden für die Zulässigkeit: dependencies-freies .js, .mjs oder .cjs, das node:test verwendet, unveränderte Basistests und identische Dateipfadmengen abgesehen vom Kandidaten. Lokale unbestätigte Änderungen werden ignoriert.

3. Lege das Ausführungs-Backend basierend auf der Autorisierung des Benutzers fest. Ein Containerlauf erfordert ein vom Benutzer ausgewähltes Image, das per Digest angepinnt, bereits auf einem Linux-Daemon vorhanden ist und Node enthält. Vertrauenswürdige lokale Ausführung ist UNSANDBOXED und erfordert eine Autorisierung für diesen Geltungsbereich. Kombiniere niemals beide Modi und leite keine Ausführungsberechtigung von der Installation oder einer Projektkonfiguration ab.

4. Führe den gewählten Befehl mit den tatsächlich festgelegten Eingaben aus. Für einen autorisierten Containerlauf:

   assertledger check /pfad/zum/repository --before BEFORE --after AFTER --neutral NEUTRAL --neutral-reason "Begründung der festgelegten Kontrolle" --test tests/regression.test.js --base-test tests/base.test.js --out .assertledger/evidence-001 --container-image node@sha256:DIGEST --json
   

   Für autorisierte vertrauenswürdige lokale Ausführung ersetze --container-image node@sha256:DIGEST durch --allow-unsafe-execution. Übergib keinen der beiden Flags, bevor dieses Backend festgelegt ist.

5. Bewahre den Exit-Status des Befehls, die Zusammenfassung, die ausgeführte Anfrage und das Manifest auf. Ein vollständiges Ausgabeverzeichnis enthält manifest.json, das zuletzt veröffentlicht wird. Führe assertledger replay /pfad/zum/repository/.assertledger/evidence-001/manifest.json --json aus. Positive Evidenz erfordert decision.status: VERIFIED und replay valid: true; behalte alle fehlgeschlagenen Versuche, Kontrollen, Gründungscodes, Ausführungsgrenzen und Isolationsfakten bei. Ablehnung, nicht schlüssige Beobachtungen, Betriebsfehler oder ungültiges Replay können eine Annahme nicht unterstützen.

6. Melde den genauen Fehler, die Revisionen, den ausgewählten Kandidaten, die Umgebung, die Artefaktorte und die Einschränkungen. Verwende assertledger explain CODE --json für Ablehnungen. Replay prüft Integrität und Entscheidungskonsistenz, ohne Tests erneut auszuführen oder ihren Produzenten zu authentifizieren. Bewahre Quellrevisionen, Anfragen und Rohprotokolle separat auf, wenn Reproduktion oder unabhängige Prüfung wichtig ist.

7. Lies für eine bereits bereitgestellte versionierte Anfrage oder eine unterstützte Bun-Kampagne die entsprechende Referenz, bevor du verify oder Replay verwendest. Der Bun-Adapter pinnt Bun 1.4.2 und erkennt Fehler von assertledger/bun assertSame; native Bun-expect-Fehler zählen nicht als Zielerkennung. Dieser untergeordnete Pfad erweitert nicht die Zulässigkeit des Git check-Befehls.

Fallstricke

• Anwenden der Git-Qualifikation auf TypeScript/Bun oder Rust — statische Erkennung kann vielversprechend aussehen, während check den Kandidaten nicht ausführen kann; behalte die vorhandenen nativen Tests bei und melde die Einschränkung.
• Ignorieren einer Repository-Symlink-Verweigerung — das Entfernen von Links oder das Erfinden von Ausschlüssen ändert die deklarierte Evidenz; bewahre das Checkout und melde UNSUPPORTED_REPOSITORY_SYMLINK. Nur der Benutzer darf einen rein lokalen Ausschluss deklarieren, nachdem die dokumentierten Regeln geprüft wurden.
• Wiederverwenden eines Evidenzverzeichnisses — die Ausgabereservierung schlägt fehl, anstatt eine vorherige Kampagne zu überschreiben; wähle einen neuen relativen Pfad und bewahre die vorherige Evidenz auf.
• Einen Absturz als Erkennung zählen — Timeouts, Kompilierung, Entdeckung und Prozessfehler stellen keine behauptete Regression fest; überprüfe die Gründungscodes und behebe das Ausführungsproblem.
• Client-Setup automatisch ausführen — connect --write installiert ein Projekt-Skill und eine MCP-Konfiguration und erstellt eine weitere entdeckte Kopie dieses Benutzer-Skills; zeige es nur bei einem angeforderten Client-Setup in der Vorschau an und löse diese Duplizierung vor jedem Schreibvorgang.

Einschränkungen

• Erfinde niemals Fehlersemantik, neutrale Begründung, beobachtete Ergebnisse oder Ausführungsautorisierung.
• Initialisiere niemals Projekte, registriere MCP-Server, ziehe Images oder ändere Ausschlüsse implizit.
• Führe niemals einen nicht unterstützten Runner durch einen erratenen Adapter aus oder schwäche die Richtlinie, um eine Annahme zu erhalten.
• Behandle die Replay-Gültigkeit niemals als Beweis für tatsächliche Ausführung, Authentizität oder allgemeine Korrektheit.
• Verwerfe niemals fehlgeschlagene Beobachtungen, verstecke unvollständige Ausgaben oder behandle eine Demo als Repository-Evidenz.
• Bewahre native Test- und CI-Anforderungen; dieses Skill ersetzt sie weder, noch autorisiert es einen Merge.