william-london/ownframework-loop

OwnFramework Loop - Spezifikation

Dieses Skill ist ein Host-Adapter über dem deterministischen ofloop-Kern.

Regeln

• Genehmige niemals dein eigenes Paket.
• Schreibe niemals STATE.json, APPROVAL.json, REVIEW_VERDICT.json, Ereignisprotokolle oder Sperrdateien direkt.
• Erstelle niemals das TTY-Bestätigungstoken.
• Führe niemals Push, Merge, Deploy, Publish, Send, Payment oder eine andere nicht zusammenhängende Remote-Autorität aus.

Neue Spezifikation (Normaler Ablauf)

1. Bestätige, dass das Arbeitsverzeichnis das Ziel-Git-Repository ist.

2. Ermittle die Repository-Identität VOR der Erstellung des Runs:

   • Untersuche die konfigurierten Git-Remotes;
   • Entscheide die Paketklassifizierung basierend auf dem tatsächlichen aktuellen Zustand, nicht dem beabsichtigten zukünftigen Zustand;
   • local_only bedeutet, dass kein Remote konfiguriert ist;
   • Wenn ein privates GitHub-Review-Surface Teil des Projekts ist, erstelle/konfiguriere es, pushe die beabsichtigte Baseline, beweise lokale/Remote-Parität und verwende github_private vor ofloop spec new;
   • Erstelle keinen lokalen Run und füge später einen Remote hinzu.

3. Untersuche nur so viel Repository-Kontext wie nötig, um ein genaues begrenztes Paket zu erstellen.

4. Verwende ofloop spec new <repo> "<mission>", um den Run zu erstellen.

5. Erstelle WORK_PACKET.md unter Verwendung des Repository-Schemas und der Paketkonventionen. Deklariere portable capabilities für Host/Tool-Anforderungen, anstatt Maschinenpfade einzubetten oder die toolspezifische Netzwerktopologie manuell zu rekonstruieren (z. B. toolchain.python, package.uv, browser.playwright.chromium). Verwende runner_profile nur als vertrauenswürdigen Profilnamen, wenn die Mission eine vom Operator beauftragte Modell-/Aufwandsrichtlinie benötigt; Pakete enthalten niemals rohe Claude-Flags. Verwende network_read_allowlist nur für paketspezifische zusätzliche Lese-Hosts, die nicht bereits durch einen Capability-Vertrag bereitgestellt werden. Füge niemals einen breiten Wildcard, Schema, Port, Pfad, Publikations-Endpunkt, Daemon-Socket oder nicht zusammenhängenden Host hinzu. Führe vor dem Einreihen in die Warteschlange ofloop capabilities probe aus, um den Host zu inspizieren, sowie ofloop capabilities preflight <repo> <capability>... für die exakt angeforderte Menge. Wenn eine angeforderte normale Capability nicht verfügbar ist, stelle sie auf dem Host bereit oder beauftrage sie, oder überarbeite das Paket vor der Ausführung; erweitere nicht HOME/PATH oder falle auf unsandboxierte Ausführung zurück. Privilegierte container.docker / local.http-service erfordern zusätzlich den vom Operator besessenen Canary-Commissioning-Ablauf.

6. Für PROGRAM-Pakete mit checkpoint-spezifischen Ergebnissen: Behalte den vollständigen Missions-Akzeptanzvertrag auf oberster Ebene und weise ihn deterministisch mit den acceptance_criterion_ids jedes Checkpoints zu. Wenn ein Checkpoint bereichsbezogene AC-IDs verwendet, muss jeder Checkpoint eine nicht-leere Liste deklarieren und die Vereinigung muss jede AC-ID der obersten Ebene abdecken. Verwende not_applicable nicht für zukünftige Checkpoint-Kriterien, nur um die Abdeckung zu erfüllen.

7. Validiere die Paketform mit dem unterstützten Validator.

8. Gib an den Operator zurück:

   • repo
   • run_id
   • packet_sha256
   • spec_baseline_branch / spec_baseline_sha
   • execution_mode / checkpoint_count
   • kanonisches unbeaufsichtigtes Einreihen: ofloop supervisor enqueue <repo> <run-id>
   • kanonischer Status: ofloop supervisor status <repo> <run-id>
   • Ausführungstakt, wenn nicht bereits als Dienst läuft: ofloop supervisor serve
   • Claude-Adapter Vordergrund/Debug nur: /of-loop:build <run-id>
   • Claude-Adapter Vordergrund/Debug nur: /of-loop:review <run-id>

9. STOP. Der normale Hintergrundbetrieb ist Supervisor-zuerst. Reihe den Run in die Warteschlange ein; ein bereits beauftragter Supervisor-Dienst verbraucht ihn, oder ofloop supervisor serve kann den Ausführungstakt manuell starten. Der erste ausführbare BUILD erstellt automatisch das unveränderliche Ausführungssiegel.

Interner vs. operatorbezogener Zustand

Der interne Speichername AWAITING_APPROVAL wird aus Gründen der Rückwärtskompatibilität beibehalten. Die operatorbezogene Bedeutung ist READY_TO_START (der Run ist startbar; es ist keine Genehmigungszeremonie erforderlich).

Nur Kompatibilität: Legacy TTY-Vorversiegelung

Der optionale historische TTY-Vorversiegelungsbefehl bleibt als rückwärtskompatibler / optionaler strenger Vorversiegelung erhalten. Er ist NICHT für den normalen Workflow erforderlich und darf NICHT in den Operatoranweisungen erscheinen.

Paket-Unveränderlichkeit

Vor dem ersten Ausführungssiegel: Paketänderungen werden über die unterstützte Änderungsoberfläche unterstützt.

Nach dem Ausführungssiegel: Das Paket ist unveränderlich. Eine geänderte Mission/Scope erfordert einen NEUEN RUN.

Repository-Identität vor der Ausführung

target.classification ist die Repository-Identität zum Zeitpunkt der Spezifikation, kein zukünftiger Deployment-Wunsch. Ein Run, der für ein privates GitHub-geprüftes Projekt bestimmt ist, sollte nur erstellt werden, nachdem das private Remote und der Baseline-Branch existieren und lokaler HEAD als gleichwertig mit der beabsichtigten Remote-Baseline nachgewiesen wurde.

Wenn sich die Remote-Topologie/Klassifizierung nach spec new aber vor dem ersten Ausführungssiegel ändert, ist es besser, den nie gestarteten Run zu stoppen und einen neuen Run aus dem endgültigen Repository-Zustand zu erstellen. Verlasse dich nicht auf den ersten BUILD-Anspruch, um eine vermeidbare local_only + Remote-Diskrepanz zu entdecken.

Die aktuelle Kernausführung schlägt bereits mit Fehler fehl, wenn ein local_only-Paket konfigurierte Remotes hat. Der Spezifikations-Workflow sollte verhindern, dass diese Ablehnung im Normalbetrieb erreicht wird.

PROGRAM Autonomie-Vorprüfung

Bevor ein v3 PROGRAM als bereit gilt:

• Verwende acceptance_criterion_ids auf Checkpoints; sende niemals Checkpoint-acceptance_criteria aus;
• Deklariere das kleinste portable capabilities-Set, das für die Mission benötigt wird, und führe eine Vorprüfung durch, bevor es in die Warteschlange eingereiht wird. Die effektive Netzwerk-Leseberechtigung ist die eingefrorene Vereinigung der paketspezifischen network_read_allowlist-Hosts und der exakten Capability-abgeleiteten Hosts. Eine leere Paketliste bedeutet daher KEINE EXTRA-Paketdomänen, nicht unbedingt null Domänen, wenn eine deklarierte Paket-/Browser-Capability enge Download-Endpoints erfordert;
• Wähle runner_profile nur aus vertrauenswürdigen Profilen, die von ofloop capabilities profile <name> offengelegt werden; explizite Modelle müssen gepinnte Provider-Modell-IDs sein, nicht sich bewegende Claude-Aliase. Ein expliziter Aufwand erfordert auch ofloop capabilities attest-effort <name> auf der aktuellen Claude-Laufzeit. Die Profilidentität ist run-gebunden und kann nur semantisches Modell/Einsatz auswählen, niemals Sandbox/Tool/MCP/Session-Autorität;
• Validiere die Paketbudgets vor der ersten Ausführung gegen ausführbare Obergrenzen;
• Behandle Build/Review/Repair-Werte auf oberster Ebene als kumulative PROGRAM-Hüllen;
• Finanziere diese globalen Hüllen aus den Summen der checkpoint-lokalen Budgets, es sei denn, das gesamte PROGRAM wird absichtlich gedrosselt;
• Stelle sicher, dass eine globale Reparaturzulage durch die globale Build/Review-Zulage realisierbar ist;
• Wähle max_pass_runtime_seconds für die Komplexität eines semantischen Durchlaufs (bis zu 28800 pro Durchlauf; die undeklarierte Fallsicherung beträgt 3600, daher muss jeder Durchlauf, der legitimerweise länger als eine Stunde braucht, sein Budget deklarieren);
• Deklariere risk_budget.max_runtime_seconds als die gesamt-Run-Wanduhr-Hülle, wenn das PROGRAM legitimerweise lange laufen kann (bis zu 2419200). supervisor enqueue verbraucht es als betriebliche Wanduhr-Obergrenze; ohne sie gilt keine Wanduhr-Obergrenze und der Run ist nur durch seine semantischen Pass/Repair/No-Progress-Schutzmechanismen begrenzt.

Ein Paket, das eine unmögliche deterministische Obergrenze erst entdecken kann, nachdem ein Modell bereits Arbeit geleistet hat, ist ein Spezifikationsfehler und darf nicht startbar sein.

Unbeaufsichtigte Budget-Semantik

Token-Obergrenzen sind standardmäßig deaktiviert und Kostenobergrenzen sind standardmäßig deaktiviert. Die unbeaufsichtigte Ausführung wird durch Schutzmechanismen für bedeutungsvollen Fortschritt begrenzt (Pass- und Reparaturcaps, No-Progress-Serie, Wiederholungssicherung bei identischen Befunden, Fehlerklassen-Wiederholungsrichtlinie), nicht durch Token- oder Kostensparsamkeit. Operatoren, die eine harte Ausgabengrenze wünschen, können --max-cost-usd / --max-total-tokens / --max-wall-seconds explizit zum Zeitpunkt des Einreihens übergeben. Wenn eine positive aggregierte Kostenobergrenze finanziert ist, verengt der Supervisor auch jeden Claude-Print-Mode-Pass mit dem exakt verbleibenden dauerhaften Run-Budget; das Loop-Ledger bleibt die kanonische aggregierte Abrechnungsquelle.