414960701/harness-distiller

Harness Distiller（Agent Harness 蒸馏器）

Wandele öffentliche Beweise in eine implementierbare, verifizierbare und aktualisierbare Agent-Harness um. Behandle Produktnamen als Verhaltens- und Fähigkeitsrezepte, kopiere keine Marken, proprietären Prompts, geschützten Materialien oder nicht verifizierbaren internen Implementierungen.

Verpflichtend

1. Unterscheide zwischen code, official-doc, protocol, behavior und inference; stelle Inferenzen von Closed-Source-Produkten niemals als Quellcode-Fakten dar.
2. Vier Reifegrade teilen sich das gleiche Protokoll, Zustandsmodell und Modulgrenzen; Upgrades fügen nur Fähigkeiten und Optimierungen hinzu, erzeugen keine inkompatiblen vier Engineering-Sets.
3. Zuerst einen vertikalen Slice durchgängig implementieren: Modell → Agent-Loop → ein Lesewerkzeug → Berechtigungen → Ausführung → Ereignis → Zustand → Oberfläche.
4. Die Laufzeit bleibt headless; CLI, TUI, IDE, Desktop und Web interagieren nur über versionierte Command/Event-Protokolle.
5. Approval Policy und Sandbox Enforcement trennen; Benutzerfreigabe ersetzt keine OS-, Container-, Pfad- oder Netzwerk-Grenzen.
6. Jeder „implementierte“ Punkt benötigt eine Code-Position; jeder „verifizierte“ Punkt benötigt ausführbare Tests oder reproduzierbare Verhaltensevidenz.
7. Betrachte nicht „Modell kann Shell aufrufen“ als vollständige Harness. Es müssen Abbrechen, Fehlschlag, Wiederherstellung, Persistenz, Berechtigungen und UI-Zustandswiederaufbau implementiert werden.

Nach Bedarf lesen

• Produktauswahl und Prüfung der Verzeichnisvollständigkeit: Lies references/catalog.md.
• Stufenauswahl oder stufenübergreifende Upgrades: Lies references/levels.md.
• Entscheide, wann jede Fähigkeit als verifiziert markiert werden kann: Lies references/capabilities.md.
• Beurteile die Zuverlässigkeit von Beweisen: Lies references/evidence.md und references/source-registry.md.
• Verstehe die gemeinsamen Grenzen: Lies references/architecture.md.
• Bevor du mit dem Code beginnst: Lies references/implementation/index.md und lade dann die Implementierungsspezifikationen gemäß der Route.
• Wähle gemeinsame Fähigkeiten: Lies references/knowledge/index.md und lade nur die ausgewählten Wissensmodule des Blueprints.
• Forke ein Produkt: Lies references/products/<product>/index.md und lade die 13 Dossiers dieses Produkts in der angegebenen Reihenfolge.
• Neues Projekt: Lies references/workflows/build.md.
• Upgrade eines bestehenden Projekts: Lies references/workflows/upgrade.md.
• Abnahme eines Projekts: Lies references/workflows/validate.md.

Anfrage analysieren

Analysiere aus der Benutzeranfrage und dem Ziel-Repository:

• recipe: ein Produkt, hybrid oder custom;
• level: runnable, usable, productive oder polished;
• surfaces: cli, tui, ide, desktop, web, sdk, headless;
• execution: local, container, remote oder eine Kombination;
• stack: Bevorzugt das Ziel-Repository; für neue Projekte wähle basierend auf Produktoberfläche und Sicherheitsanforderungen;
• providers: Modell-Anbieter, lokale Modelle und Anforderungen an Fähigkeitsdegradation;
• security: Bedrohungsmodell für Einzelpersonen, Teams oder Unternehmen;
• distribution: Quellcode, Paket, Erweiterung, Desktop-Anwendung oder gehosteter Dienst.

Wenn der Benutzer nur sagt: „Mach ein Produkt wie Codex/Claude Code/QoderWork“, wähle standardmäßig das entsprechende Rezept, usable, die Hauptoberfläche des Produkts plus headless und schreibe die Annahmen in die Entscheidungsdokumentation.

Wenn keine anderen Optionen angegeben werden, verwende die Fallback-Standardwerte: execution=local, security=personal, distribution=source; Codex-artig standardmäßig Rust + headless/TUI, Claude-Code-artig standardmäßig TypeScript + headless/CLI, QoderWork-artig standardmäßig TypeScript + Tauri/Rust Executor + headless/Desktop, Aider-artig standardmäßig Python + headless/CLI, OpenCode standardmäßig TypeScript/Bun + headless/TUI, OpenHands standardmäßig Python + TypeScript/React + headless/Web/SDK, AgentScope, LangGraph und Deep Agents standardmäßig Python + headless/SDK. Wenn kein Provider angegeben ist, implementiere zuerst einen Provider-neutralen Vertrag, deterministische scripted Fixtures und OpenAI-kompatible Adapter-Schnittstellen; binde keine kostenpflichtigen Dienste eigenmächtig ein; fordere den Benutzer auf, die Provider-Konfiguration bereitzustellen, bevor die echte Integration getestet wird.

Generierungsablauf

1. Überprüfe das Repository, den Technologie-Stack, vorhandene Anweisungen, nicht committete Änderungen und die verfügbare Laufzeitumgebung.
2. Bestätige in references/catalog.md, dass das Produkt auf Implementierungsebene ist; für Rezepte, die geplant sind, aber noch nicht 13 Dossiers abgeschlossen haben, darf kein Produkt-Fork erstellt werden. Ergänze zuerst die Dossiers oder wechsle explizit zu hybrid/custom. Führe dann scripts/new_blueprint.py aus, um .harness-distill/blueprint.yaml zu erstellen.
3. Lese die Produkt-index.md, product-contract.md, recipe.md und acceptance-tests.md.
4. Lade gemäß dem Rezept die Implementierungsspezifikationen und gemeinsamen Wissensdokumente; erstelle die Abhängigkeits-Abschlussmenge der Fähigkeiten.
5. Schreibe .harness-distill/evidence.md und dokumentiere Behauptungen, URLs, Daten, Versionen/Commits, Beweistypen und Vertrauenswürdigkeit.
6. Schreibe .harness-distill/decisions.md und dokumentiere Architekturentscheidungen, Closed-Source-Inferenzen, Nicht-Ziele, Risiken und Rückfallpunkte.
7. Implementiere zuerst das Protokoll, das Zustands-Grundgerüst und einen ausführbaren vertikalen Slice; speichere und spiele dessen Ereignisspur ab.
8. Ergänze die Fähigkeiten in der Reihenfolge: schema → protocol → runtime → executor/policy → surface → migration.
9. Füge gleichzeitig Contract-, Szenario-, Sicherheits-, Recovery-, Migrations- und Produkt-Blackbox-Tests hinzu.
10. Führe scripts/validate_blueprint.py, die Ziel-Repository-Prüfung und die Produkt-acceptance-tests.md aus.
11. Markiere eine Fähigkeit nur dann als verified, wenn sie eine Implementierungsposition und Testnachweise hat.

Minimaler Vertrag der Ergebnisse

Das Zielprojekt muss äquivalente Grenzen enthalten:

.harness-distill/
  blueprint.yaml       # Auswahl, Stufe, Fähigkeiten, Status und Vertragsversion
  evidence.md          # Öffentliche Beweise und Inferenzgrenzen
  decisions.md         # Architekturentscheidungen, Nicht-Ziele, Risiken und Migration
src/
  protocol/            # Command/Event/Error/Schema/Capability Negotiation
  runtime/             # Turn-Zustandsmaschine, Abbrechen, Wiederholen, Budget, Steering
  model/               # Provider-Adapter und Fähigkeitsverhandlung
  context/             # Anweisungen, Abruf, Gedächtnis, Budget, Kompression, Cache
  tools/               # Schema, Registry, Router, Lebenszyklus, Artefakt
  policy/              # Erlauben/Verweigern/Fragen/Ändern und Genehmigungsumfang
  execution/           # Arbeitsbereich, Dateien, Shell, Patch, Netzwerk, Sandbox
  state/               # Thread/Turn/Item/Event/Checkpoint/Migration
  surfaces/            # CLI/TUI/IDE/Desktop/Web-Adapter
tests/
  contracts/           # Verträge für Protokoll, Provider, Tool und Speicher
  scenarios/           # Echte Aufgaben-End-to-End
  security/            # Grenzüberschreitung, Injection, Secrets, Netzwerk und Escape
  recovery/            # Abstürze, doppelte Zustellung, Verbindungsabbrüche und Migration

Es ist erlaubt, Namen entsprechend den Sprachkonventionen zu ändern, aber die Grenzen zwischen Richtlinie und Durchsetzung, Domänenzustand und UI-Projektion sowie Modellverlauf und persistenten Fakten dürfen nicht verschmolzen werden.

Vollständigkeitsprüfung

Erst wenn alle folgenden Bedingungen erfüllt sind, gilt die Harness für die ausgewählte Stufe als vollständig:

• Blueprint, Produktvertrag und Implementierungspositionen stimmen überein;
• Die Thread/Turn/Item/Event-Spur von runnable kann persistiert und wiedergegeben werden; usable unterstützt zusätzlich Paginierung und Wiederherstellung nach Prozessneustart; polished erfordert zusätzlich versionenübergreifende Migration;
• Tool-Call/Result sind atomar gepaart, mit eindeutiger Semantik für Abbrechen, Timeout und verspätete Ergebnisse;
• Nach der Kontextkompression wird die Atomizität der Tool-Aufrufe, die Anweisungshierarchie und der Prüfumfang nicht beeinträchtigt;
• Eingeschränkte Aktionen werden zuerst durch die Richtlinie entschieden und dann durch die tatsächlichen Ausführungsgrenzen erzwungen;
• Die UI kann aus Snapshot + Ereignissen wiederhergestellt werden, ohne von Laufzeit-Speicherobjekten abhängig zu sein;
• Die Absturzwiederherstellung ab usable wiederholt keine irreversiblen Nebenwirkungen;
• Die aktuellen Stufenszenarien der Produkt-acceptance-tests.md bestehen;
• Die Auslieferungsnotiz listet nicht unterstütztes Verhalten, Beweislücken und direkte Upgrade-Pfade auf.

Stufenübergreifendes Upgrade

Beim direkten Upgrade von einer niedrigeren auf eine höhere Stufe:

1. Überprüfe den aktuellen Blueprint, das Protokoll und das Datenbank-Schema;
2. Berechne das Fähigkeitsdelta und entfalte die Zwischenabhängigkeiten;
3. Migriere zuerst das Schema, erweitere dann Protokoll, Laufzeit, Executor und Oberflächen;
4. Halte alte Konfigurationen und alte Ereignisse mindestens eine kompatible Migrationsgrenze lang aufrecht;
5. Richte Checkpoints, Idempotenzschlüssel oder manuelle Bestätigung für irreversible externe Aktionen ein;
6. Führe alle Regressionstests der niedrigeren Stufe und die Abnahmetests der neuen Stufe durch;
7. Aktualisiere den Fähigkeitsstatus erst, nachdem die Tests bestanden wurden.