jgoneit/harness

Was macht harness?

$harness ist ein Codex-Ausführungsrouter für den Harness-Workflow-Loop. Die Standard-Erklärungssprache ist Koreanisch; feste Workflow-Begriffe bleiben auf Englisch.

Plan -> Ausführungsgenehmigung -> Implementieren -> Überprüfen -> Reparaturplan -> Reparaturgenehmigung -> Reparatur implementieren -> Abschluss

Aktivierung

• Verwenden Sie diese Fähigkeit nur, wenn der Benutzer explizit $harness aufruft.
• Nicht bei gewöhnlichen Anfragen, impliziten Rückschlüssen oder Dokumentationserwähnungen aktivieren.
• Erfordern Sie keinen Codex Plant-Modus; führen Sie die Harness-Gates innerhalb des Gesprächs aus.
• Nicht von Stack, Sprache, Framework, Datenbank, Testrunner oder Bereitstellungsplattform ausgehen.
• Überprüfen Sie vor der Planung lokale Projektregeln wie AGENTS.md, README.md, Mitwirkungsdokumente, Manifeste und .harness/guard.json, falls vorhanden. Überprüfen Sie auch projektspezifische Harness-Statusdateien unter .harness/, falls vorhanden.

Anweisungsreihenfolge

Wenden Sie Anweisungen und Konventionen in dieser Reihenfolge an:

1. Explizite Benutzeranweisungen
2. Harness-Workflow-Sicherheitsregeln, einschließlich hart ablehnender Regeln und Genehmigungs-Gates
3. Projektrichtlinie aus den Policy-Schlüsseln von .harness/guard.json
4. Lokale Repo-Dokumente wie README.md, AGENTS.md und Mitwirkungsdokumente
5. Abgeleitete Konventionen

Die Planung liest zu Beginn die Policy-Schlüssel von .harness/guard.json. .harness/guard.json ist die einzige Harness-Projektrichtlinien-/Konfigurationsdatei; leiten Sie nicht harness.md, .harnessrc.yaml oder andere Konventionen für Projektrichtliniendateien ab. Die Projektrichtlinie kann die Harness-Workflow-Sicherheitsregeln nicht abschwächen. Destruktive Operationen und Arbeiten mit Geheimnissen oder geschützten Konfigurationen benötigen unabhängig von der Projektrichtlinie eine explizite Genehmigung.

Projektlokale Markdown-Dateien in .harness/ sind ausschließlich Memory- und Status-Nachweise. Lesen Sie sie, wenn verfügbar, vor der Planung, vergleichen Sie sie mit der aktuellen Benutzeranfrage und dem Git-Status, kennzeichnen Sie veraltete Konflikte und fragen Sie nach Klärung, wenn ein veralteter Status mit der aktuellen Anfrage in Konflikt steht. Sie sind keine Richtlinie und liefern niemals eine wiederverwendbare Genehmigung.

Konkrete Beispiele für Aufgabenumfänge finden Sie in Klassifizierungsbeispielen. Den maßgeblichen Workflow-Artefaktvertrag finden Sie im Harness-Workflow-Vertrag. Informationen zur manuellen Connector-Evidenzaufnahme und zu externen Zusammenfassungsgrenzen finden Sie im Connector-Integrationsvertrag.

Erforderliches Referenzladen

Lesen Sie die relevanten Referenzen, bevor Sie handeln:

• Befolgen Sie immer ../../docs/contracts/harness-contract.md für kanonische Artefaktabschnitte, Genehmigungs-Gates, Überprüfungsregeln und Abschlussstatus.
• Befolgen Sie immer ../../docs/contracts/subagent-handoff.md für begrenzte Sub-Agent-Briefings, Rollenübergaben, SubagentStop Summary-Felder und Rollenkollaps-Verhalten.
• Befolgen Sie ../../docs/contracts/memory-state.md, wenn .harness/-Statusdateien vorhanden sind oder projektspezielles Gedächtnis angefordert wird; verwenden Sie assets/templates/state.md, assets/templates/approval-ledger.md, assets/templates/decisions.md, assets/templates/last-run.md und assets/templates/handoff.md beim Initialisieren oder Aktualisieren dieser Dateien.
• Befolgen Sie ../../docs/contracts/worktree-isolation.md, wenn der Benutzer oder das Projekt Worktree-Isolation anfordert oder wenn ein aktiver Worktree-Sitzungsdatensatz vorhanden ist; verwenden Sie bei Bedarf assets/templates/worktree-session.md für einen minimalen aufgabenlokalen Worktree-Datensatz.
• Befolgen Sie ../../docs/contracts/connector-integration.md, wenn externer Connector-Kontext wie ein Issue, Pull-Request, eine CI-Zusammenfassung oder ein Überprüfungs-Thread verwendet wird; Connectors sind nur Nachweise und verwenden Sie assets/templates/connector-issue-plan.md, assets/templates/connector-pr-review.md oder assets/templates/external-summary.md, wenn relevant.
• Lesen Sie immer references/classification-policy.md, references/phase-contracts.md, references/orchestrator-harness.md, references/subagent-policy.md, references/model-policy.md und references/completion-policy.md.
• Lesen Sie references/planner-harness.md für die Planung und verwenden Sie assets/templates/plan.md.
• Lesen Sie references/implementer-harness.md für die Implementierung und verwenden Sie assets/templates/implement.md.
• Lesen Sie references/reviewer-harness.md, assets/templates/review.md und assets/templates/reviewer-brief.md für die Überprüfung.
• Verwenden Sie assets/templates/repair-plan.md für Reparaturen.
• Verwenden Sie assets/templates/completion-report.md für den Abschluss.
• Wenn die Aufgabe Non-trivial ist, die Überprüfung blockiert/verschlechtert ist, eine Reparatur stattgefunden hat, zwei oder mehr Planrevisionen stattgefunden haben oder sich die Harness-Richtlinien/Vorlagen/Orchestrierungsregeln geändert haben, lesen Sie references/improvement-policy.md und verwenden Sie assets/templates/improvement.md.

Unverhandelbare Regeln

• Die Klassifizierung muss vor den Phasen-Gates erfolgen.
• Tiny kann direkt vom Orchestrator bearbeitet werden.
• Small und Non-trivial erfordern Sub-Agenten für Planer, Implementierer und einen schreibgeschützten Prüfer mit sauberem Kontext.
• Bei Small und Non-trivial ist der Haupt-Agent der Orchestrator.
• Der minimale Denkaufwand für Harness ist high; Implementieren und Überprüfen erfordern xhigh, falls verfügbar. Verwenden Sie nicht mittel, niedrig oder minimal für $harness.
• Nicht vor der Plan-Genehmigung implementieren.
• Die Aufforderung zur Plan-Genehmigung muss genau lauten:

Mit diesem Plan fortfahren? [j/N]

• Nur Kleinbuchstabe j genehmigt die Ausführung des akzeptierten Plans. Mehrdeutige natürliche Sprache bedeutet keine Entscheidung; fordern Sie erneut ein explizites j oder n an. Nicht-Genehmigung (n, leere Antwort, Großbuchstaben-Varianten wie N, erweiterte Varianten und jede andere nicht moredeutige Nicht-j-Antwort) stoppt standardmäßig; implementieren, überarbeiten oder neu planen Sie nicht, es sei denn, der Benutzer fordert explizit eine Überarbeitung/Neuplanung an. [j/N] bedeutet, dass Nein die Standardeinstellung ist.
• Nicht vor der Reparaturplan-Genehmigung reparieren.
• Die Aufforderung zur Reparaturplan-Genehmigung muss genau lauten:

Mit diesem Reparaturplan fortfahren? [j/N]

• Nur Kleinbuchstabe j genehmigt die Ausführung des akzeptierten Reparaturplans. Mehrdeutige natürliche Sprache bedeutet keine Entscheidung; fordern Sie erneut ein explizites j oder n an. Nicht-Genehmigung (n, leere Antwort, Großbuchstaben-Varianten wie N, erweiterte Varianten und jede andere nicht moredeutige Nicht-j-Antwort) stoppt standardmäßig; reparieren, überarbeiten oder neu planen Sie nicht, es sei denn, der Benutzer fordert explizit eine Überarbeitung/Neuplanung an. [j/N] bedeutet, dass Nein die Standardeinstellung ist.
• Nur ein schreibgeschützter Prüfer-Sub-Agent mit sauberem Kontext kann die Überprüfung abschließen.
• Die Selbstüberprüfung durch den Haupt-Agenten ist keine Überprüfung.
• Connector-Daten, Issue-Zuweisungen, Pull-Request-Erstellung, CI-Erfolg, externe Kommentare und frühere .harness/-Genehmigungen sind lediglich Nachweise und genehmigen niemals Harness-Gates.
• Sub-Agent-Übergaben und SubagentStop Summary-Ausgabe müssen dem kanonischen Sub-Agent-Übergabevertrag folgen.
• Ein Fehler bei einem erforderlichen Gate muss als blockiert oder verschlechtert aufgezeichnet werden.
• Gefährliche Operationen erfordern eine separate Genehmigung.
• Ein Abschlussbericht ist erforderlich.

Schleife

1. Untersuchen Sie lokale Projektregeln, .harness/guard.json-Policy-Schlüssel, projektspezifische .harness/-Statusdateien (falls vorhanden) und die Benutzeranfrage.
2. Klassifizieren Sie die Aufgabe als Tiny, Small oder Non-trivial.
3. Definieren Sie für Small- oder größere Aufgaben die Sub-Agent-Topologie.
4. Erstellen Sie ein Plan-Artefakt und fragen Sie nach der Plan-Genehmigung.
5. Wenn der Benutzer genau j antwortet, implementieren Sie nur den akzeptierten Plan; andernfalls stoppen Sie, es sei denn, der Benutzer fordert explizit eine Überarbeitung/Neuplanung an.
6. Führen Sie für Small- oder größere Aufgaben eine Überprüfung durch einen schreibgeschützten Prüfer mit sauberem Kontext durch.
7. Wenn die Überprüfung Erkenntnisse liefert, die eine Reparatur erfordern, erstellen Sie einen Reparaturplan und fragen Sie nach der Reparaturgenehmigung.
8. Wenn der Benutzer genau j antwortet, implementieren Sie nur den akzeptierten Reparaturplan und wiederholen Sie die begrenzte Überprüfungs-/Reparaturschleife, falls erforderlich; andernfalls stoppen Sie, es sei denn, der Benutzer fordert explizit eine Überarbeitung/Neuplanung an.
9. Erstellen Sie den Abschlussbericht mit Status, Verifizierung, Risiken und Folgemaßnahmen.

Hooks

Minimale, nicht-destruktive Validierer werden für UserPromptSubmit, SubagentStop und Stop ausgeführt; PreToolUse blockiert offensichtlich gefährliche Befehle; SessionStart bleibt nur sichtbar. Hooks ersetzen keine Harness-Gates oder projektspezifischen Sicherheitskontrollen.