grahama1970/acceptance-contract

Was macht acceptance-contract?

Verwende dies vor der Implementierung, wenn ein Briefing, Ticket, eine E-Mail, eine README, ein ZIP-Bündel oder ein Beweispaket in ausführbare Akzeptanzkriterien umgewandelt werden muss.

Erster Befehl für die Implementierungsarbeit:

skills/acceptance-contract/run.sh ensure <zip|directory|file> \
  --out /tmp/acceptance-contract \
  --project-name oai-trial \
  --goal-mode create

ensure ist die mechanische Absicherung: Es validiert ein bestehendes acceptance_bundle.json, extrahiert automatisch eines, wenn es fehlt, und schlägt fehl, wenn sich das gelieferte Quellbündel seit dem Einfrieren des Vertrags geändert hat. Sein JSON-Beleg enthält einen acceptance_contract.progress.v1-Meter mit percent, checks, outstanding, und next_steps. Implementiere nicht aus einem Briefing, bis ensure status=PASS zurückgibt und der Fortschrittsmesser angibt, was noch übrig ist.

Übergib das Kunden-Briefing, ZIP-Bündel oder bewusst bereitgestellte Spezifikationsverzeichnis als Eingabe. Die CLI lehnt Repository-Wurzeln standardmäßig ab, damit Implementierungsdateien nicht stillschweigend zur Akzeptanzquelle werden können. Verwende --allow-repo nur, wenn der Mensch explizit nach einem repository-weiten Vertrag fragt.

Für risikoreiche Kunden-Briefings führe vor der Implementierung eine zweite $ask-Runden-Tisch-Überprüfung des Briefings/ZIP-Bündels plus acceptance_bundle.json durch. Beziehe WebGPT als einen Prüfer ein, wenn verfügbar. Frage direkt: "Sind diese Vertragsanforderungen korrekt, und haben wir etwas übersehen?" Verlange von den Prüfern, zu überprüfen, ob keine Kundenverpflichtung im eingefrorenen Vertrag fehlt, insbesondere Darstellungsklassen, typisierte Werte, Randbedingungen und disqualifizierende Fehlermodi. Die Überprüfung ist beratender Beleg; deterministische Tore entscheiden weiterhin über BESTANDEN/NICHT BESTANDEN. Die oai-trial-Überprüfung ergab, dass die Abdeckung typisierter Skalare auch kanonische Äquivalenz erfordern muss: formatierte Richtlinienzeichenfolgen, nur-Ziffern numerische Skalare, Dezimalformen, wissenschaftliche Notation und SQLite numerische Werte können nicht separate Akzeptanzuniversen sein.

Was es tut

skills/acceptance-contract/run.sh extract <zip|directory|file> \
  --out /tmp/acceptance-contract \
  --project-name oai-trial \
  --goal-mode create

Ausgaben:

• acceptance_bundle.json — pydantic-validierte Quelle der Wahrheit
• acceptance_report.json — create_report.report.v1 JSON
• acceptance_report.md — gerendert durch $create-report
• IMMUTABLE_GOAL.draft.md — Entwurf des Zieltexts oder Änderungsvorschlag

Befehle:

• extract schreibt immer ein neues Entwurfsbündel/bündel aus der gelieferten Quelle.
• ensure validiert oder erstellt das eingefrorene Bündel und lehnt veraltete Quell-Hashes ab.
• validate validiert nur ein bestehendes acceptance_bundle.json und gibt den Fortschrittsmesser aus.
• status liest ein bestehendes acceptance_bundle.json und gibt nur den maschinenlesbaren Fortschrittsmesser aus.

Zielrichtlinie

Standardverhalten ist Entwurf, nicht Mutation.

• --goal-mode create schreibt einen neuen Entwurf eines unveränderlichen Ziels.
• --goal-mode amend schreibt einen Änderungsvorschlag, keine stille Bearbeitung.
• --goal-mode none extrahiert Anforderungen ohne Zieltext.

Ein echtes unveränderliches Ziel sollte nur nach menschlicher Genehmigung erstellt oder geändert werden. Diese Regel existiert, weil oai-trial fehlschlug, als implementierungsdefinierte Tests für das Kunden-Briefing einstanden.

Abgrenzung

Dieses Skill extrahiert klare, quellgestützte Anforderungen aus bereitgestellten lokalen Dateien. Es behauptet nicht, dass der extrahierte Vertrag vollständig ist, wenn das Quellbündel mehrdeutig ist. Mehrdeutigkeit wird zu open_questions[] und einem Bericht "Änderungen erforderlich". Es lehnt Repository-Wurzeln standardmäßig ab, weil oai-trial fehlschlug, als codeförmige Prüfungen für das gelieferte Briefing einstanden.

Für Battle übergib das resultierende acceptance_bundle.json als die Arena acceptance_floor und ordne jedes acceptance_cases[].id einer oder mehreren Generator-Case-IDs im Battle-Kampagnenprofil von required_case_ids zu. Diese zugeordneten Fälle sind die Vertragsbasis, die bestehen muss, bevor Fuzz- oder vertragsfremde Angriffe gutgeschrieben werden können. Lass Battle die Anforderungen nicht erfinden.