Kronuz/campaign

Kampagne

Der Lead (die Hauptsitzung) verwandelt die Ziele des Eigentümers in Quests. Ein Mitwirkender-Agent schließt jede Quest in einem eigenen Branch ab; Maschinenarbeit geht an eine Job-Warteschlange, die sie auf genauen Commits ausführt, während kein Agent wartet. Ein Prüfer-Agent überprüft eine Quest aus einem frischen Kontext, wenn ihr Risiko dies erfordert. campaign land bringt eine Quest auf main, nur wenn ihre Prüfungen auf diesem exakten Code bestanden haben, jedes Kriterium die genannten Beweise vorweist und jede erforderliche Überprüfung für den geprüften Code akzeptiert wurde. Alles, was zählt, befindet sich im Repository, sodass jeder Agent, einschließlich des Leads, ersetzt werden kann.

goals ─► PLAN ─► quests ─► campaign start ─► mitwirkender ─► jobs (quiet) ─► beweise
                                                  │                              │
                                                  └─► prüfer (nach risiko) ─► akzeptieren ─► campaign land

Invarianten

1. Beweise, keine Erzählung. Eine Prüfung zählt nur, wenn ein Job sie auf dem zu mergenden Code ausgeführt hat; eine Zeile im Journal oder die Aussage eines Prüfers ist niemals ein grüner Test.
2. Ein Schreiber pro Dateisatz. campaign start lehnt sich überschneidende Dateisätze ab; land lehnt Änderungen außerhalb des Quest-Dateisatzes und Änderungen an den Dateien des Leads ab.
3. Kriterien vor Code. Der Lead schreibt die Akzeptanzkriterien jeder Quest und die Beweise, die jedes benötigt; Mitwirkende bearbeiten sie nie, und eine geänderte Quest-Datei macht frühere Akzeptanzen ungültig.
4. Überprüfung folgt dem Risiko. Ein frischer Prüfer pro Risiko, das einen benötigt; eine Akzeptanz deckt den Code ab, den seine Überprüfung gesehen hat, sowie den genauen Inhalt der Überprüfung.
5. Nichts wird stillschweigend geschwächt. Die Senkung eines Risikos, das Entfernen einer Linse oder einer Prüfung, der Verzicht auf eine Überprüfung, das Landen ohne CI oder die Aufzeichnung eines manuell durchgeführten Landens erfordert einen Grund, den das Tool aufzeichnet.
6. Zustand lebt in Dateien. .campaign/<kampagne>/ und git halten fest, wie die Kampagne läuft; was das Produkt ist, geht in docs/ des Repositorys, das es beschreibt.
7. Agenten warten nie auf Maschinen, und Messungen laufen nie ohne Isolation.
8. Der Eigentümer entscheidet über Ziele, Umfang und jede Entfernung oder Einschränkung des benutzersichtbaren Verhaltens. Der Lead entscheidet über den Rest und zeichnet ihn in PLAN.md auf. Campaign mietet nie Maschinen oder erzeugt andere abrechenbare Ressourcen.

Rollen

Rolle	Tut	Schreibt
Eigentümer (eine Person)	Ziele, Nicht-Ziele, vorbehaltene Entscheidungen	PLAN.md Ziele
Lead (die Hauptsitzung)	Plant Quests, startet Agenten, akzeptiert Überprüfungen, merged, berichtet an den Eigentümer	state.json (nur über campaign), Quest-Dateien, PLAN.md, main
Mitwirkender (campaign-contributor-Agent)	Eine Quest oder Aufgabe, gemäß seiner Zuweisung	Sein Branch und Journal
Prüfer (campaign-reviewer-Agent)	Eine Quest durch eine Linse, aus einem frischen Kontext	Eine Überprüfungsdatei

Die Zuweisung eines Mitwirkenden benennt die Art der Arbeit; jede außer der Implementierung hat eine Methode in references/assignments/<name>.md. Der Lead benennt die Zuweisung, die Modellstufe und den Aufwand bei jedem Start, wählt nach der Arbeit, nie aus Gewohnheit:

Zuweisung	Für	Stufe, Aufwand
Implementierung	Funktionen und Fehlerbehebungen mit konkreten Kriterien	Wirtschaftlich, mittel für niedriges und normales Risiko; stark, hoch für hohes und kritisches Risiko, oder nachdem ein wirtschaftlicher Versuch ins Stocken geraten ist
Design	Questlisten für folgenreiche Pläne; Formate, Protokolle, Haltbarkeit, Nebenläufigkeit	Stark, hoch; max für ein Design, das kurz vor dem Einfrieren steht
Recherche	selten: der Mechanismus selbst ist die Grenze	Stark, maximal
Leistung	Profiling und Optimierung	Stark, hoch
Erkundung	Ein Ziel einer Erkundungsrunde oder eine schnelle Frage	Wirtschaftlich, mittel
Dokumentation	Docs, Anleitungen, READMEs	Wirtschaftlich, mittel
Wartung	Eine mechanische Änderung über mehrere Repositorys hinweg	Wirtschaftlich, mittel

Prüfer verwenden die starke Stufe mit hohem Aufwand (max für kritische Quests); für kritische Quests und die Plangenehmigung wird ein Prüfer aus einer anderen Modellfamilie verwendet, wenn das Geschirr einen anbietet. Die Modelle des Geschirrs für die Stufen sind in references/harness.md. Ändere einen Standard aufgrund von Ergebnissen (campaign usage, erfüllte Kriterien, Nacharbeit), nicht nur aufgrund des Preises. Der Lead erledigt kleine Änderungen selbst (eine Fünfzeilen-Korrektur, ein trivialer Konflikt): Ein Start kostet mehr.

Eine Kampagne starten

1. Im Haupt-Checkout des Home-Repositorys: campaign init --name NAME [--ci github]. Der Eigentümer schreibt Ziele, Nicht-Ziele, Einschränkungen und vorbehaltene Entscheidungen in .campaign/<kampagne>/PLAN.md.
2. Zerlege die Ziele in Quests: campaign new ID --title T --risk R --files GLOBS [--needs IDS] [--after IDS] [--provides C] [--consumes C] [--milestone M] --check NAME[:LEVEL[:MIN]]=CMD. Fülle jede Quest-Datei (.campaign/<kampagne>/quests/ID.md) aus: Ergebnis, Kriterien A1... jedes mit den benötigten Beweisen (Beweise, unten), Verträge, Entscheidungen, was früh landen darf.
3. Wenn die Architektur folgenreich ist, hinterfragt ein Prüfer (Linse design) den Plan und die Questliste, bevor etwas gebaut wird. Dies ist die eine Überprüfung, auf die es sich zu warten lohnt.

Quests

• Größe: die kleinste Änderung, die ein vollständiges, sinnvolles Verhalten liefert, das ein Prüfer im Kopf behalten kann, normalerweise einige hundert bis ~1.500 Zeilen. Größere aufteilen; eine Änderung, die keinen eigenen Landevorgang rechtfertigt, in die Quest einordnen, der sie dient.
• needs müssen landen, bevor eine Quest startet; after müssen landen, bevor sie landet. Eine Quest darf nur gegen eine after-Abhängigkeit starten, weil diese Abhängigkeits-Quest-Datei den Vertrag festlegt.
• Verträge (--provides, --consumes) benennen APIs, Formate und Protokolle, sodass campaign check sieht, dass zwei Quests einen berühren.
• Aufgaben: parallele Schreiber innerhalb einer Quest (campaign start ID --task T --files GLOBS), die vom Lead in den Quest-Branch gemergt werden. Die Quest wird dennoch einmal überprüft.
• Inkremente: campaign land ID --upto COMMIT --reason R landet ein Präfix, das die Quest-Datei unter „Darf früh landen“ erlaubt (verhaltenserhaltende Refactorings, Tests, ungenutzte interne APIs, Code hinter einem deaktivierten Schalter). Nie früh: Bytes auf der Platte oder der Leitung, öffentliche API, benutzersichtbares Verhalten oder der Teil, für den die Überprüfung existiert.
• Repositoriumsübergreifende Arbeit besteht aus mehreren Quests (--repo PATH), geordnet durch after, mit einem Integrationsjob, der jeden Commit jedes Repositorys festlegt (--ref NAME=PATH@REF). Das Landen ist geordnet, nie atomar: Jeder Zwischenzustand muss funktionieren.
• Nachrichten: Ein Agent mit einem Befund für eine Quest, an der er nicht arbeitet, in einer beliebigen Kampagne auf der Maschine, sendet campaign message NAME:ID "text" --from WHO. Die Quest kann nicht landen, bis eines ihrer Journale sie mit ihrer ID beantwortet (msg-N) oder der Lead sie schließt (campaign message ID --close msg-N --reason R); NAME: schreibt an den Lead dieser Kampagne und blockiert nie ein Landen. Details und andere Maschinen: references/host.md, Nachrichten.
• Umfangsänderungen: Eine neue Anforderung kommt zuerst in die Quest-Datei (ein Kriterium oder eine eigene Quest, wenn sie allein landen kann), dann zum Mitwirkenden; überholte Arbeit wird mit campaign set ID status=dropped reason=... bearbeitet.

Direkter Weg zuerst

Nur das, was den nächsten Schritt bestimmt, blockiert ihn. Die Gate-Prüfungen einer Quest (--check: der Build, die Tests und die Beweise, die ihr Risiko erfordert) blockieren ihr Landen. Ihre aufgeschobenen Prüfungen (--later: andere Plattformen, lange Soak-Tests, vollständige Matrizen, erweitertes Fuzzing) werden mit niedriger Priorität auf den gelandeten Code in die Warteschlange gestellt und müssen vor dem Meilensteinabschluss grün sein. Eine rote Prüfung ist ein Fehler in campaign check: Korrektur vorwärts oder rückgängig machen, dann campaign verify ID --deferred führt sie auf main erneut aus. Die Beweise, die ein hohes oder kritisches Risiko benötigt (TSan für Nebenläufigkeit, Fuzzing für einen Decoder, das Absturzmodell für Haltbarkeit), sind immer ein Gate. Langsame CI-Workflows können auf die gleiche Weise nicht-gatend gemacht werden (campaign config ci_later=NAME,...).

Eine Quest ausführen

1. campaign start ID erstellt quest/<campaign>/ID in einem eigenen Worktree mit einem Journal. Starte einen Mitwirkenden im Hintergrund, damit er per Nachricht fortgesetzt werden kann, mit dem „Mitwirkender“-Prompt (references/prompts.md); führe Quests nur parallel aus, wenn sie bereit, disjunkt sind und nicht auf derselben Maschine warten.
2. Der Mitwirkende arbeitet in seinem Worktree, hält sein Journal aktuell und erzeugt Beweise als Jobs: campaign job submit --quest ID --level L --minutes M -- CMD und campaign verify ID. Wenn nur noch Jobs übrig sind, zeichnet er ihre IDs auf und beendet seinen Durchgang.
3. Der Lead wartet mit einem Hintergrund-campaign wait --commits (keine Token, bis ein Job endet, ein Branch sich bewegt oder eine Nachricht eintrifft), setzt dann den Mitwirkenden per Nachricht fort, während sein Kontext klein ist (etwa 150k Token). Ein größerer Kontext oder ein Geschirr, das ihn nicht fortsetzen kann, erhält einen frischen Mitwirkenden mit dem „Fortsetzen“-Prompt, der aus dem Journal und den Jobaufzeichnungen neu aufbaut.
4. Wenn das Journal „bereit zur Überprüfung“ sagt, setzt der Lead status=review und startet die Prüfer, die das Risiko erfordert; jeder schreibt .campaign/<campaign>/reviews/ID-LENS.md. Der Lead leitet blockierende Befunde per ID an den Mitwirkenden weiter.
5. campaign accept ID LENS, sobald eine Überprüfung genehmigt, oder nach ÄNDERUNGEN mit den bestätigenden Jobs (Risiko und Überprüfung); es committet die Überprüfungsdatei mit der Akzeptanz. Dann campaign land ID, was auch die Worktrees, gemergten Branches und Build-Slots der Quest entfernt und benennt, was es behalten hat.

Erkundungsrunden

Für eine Liste, die es wert ist, gejagt zu werden (die Verliererreihen eines frischen Benchmarks, Hotspots eines Profils, dünn bewiesener Code, ein Backlog kleiner Fehler), sende mehrere wirtschaftliche Mitwirkende auf einmal, ein Ziel pro Mitwirkender, Ziele aus einer frischen Messung auf aktuellem main: references/assignments/exploration.md. Dimensioniere die Runde nach ihren Zielen und danach, was der Lead überprüfen und landen kann, niemals nach Leerlaufkontingent.

Risiko und Überprüfung

Risiko (erster Treffer gewinnt)	Vor dem Bauen	Vor dem endgültigen Landen
kritisch: irreversibel (Einfrieren eines Formats oder Protokolls für die Veröffentlichung, Migration von Benutzerdaten, Entfernen benutzersichtbaren Verhaltens)	Genehmigung des Eigentümers; eine design-Überprüfung	Die Überprüfung für hohes Risiko, plus Akzeptanzbeweise, die der Prüfer selbst ausgeführt hat
hoch: persistente Formate, Drahtprotokolle, Haltbarkeit, Nebenläufigkeit, Sicherheitsoberflächen, gemeinsam genutzte öffentliche APIs	Eine design-Überprüfung, wenn eine Entscheidung teuer rückgängig zu machen ist	Eine Überprüfung durch die Linse des vorherrschenden Risikos (Haltbarkeit, Sicherheit oder Korrektheit)
normal: gewöhnliche Funktionen und Fehlerbehebungen	—	Eine Korrektheit-Überprüfung oder --waive GRUND für eine kleine Änderung mit starken Beweisen
niedrig: Doku, Tests, Tooling, mechanische Änderungen, verhaltenserhaltende Refactorings	—	Prüfungen grün; der Lead liest das Diff

• Ein Prüfer standardmäßig, der jede Risikofrage der Quest trägt (der Prompt nennt drei bis fünf). Ein zweiter nur für eine Frage, die separate Expertise oder Unabhängigkeit erfordert.
• Eine Überprüfung ist an das gebunden, was sie gesehen hat. Sie nennt den Commit, den sie überprüft hat (Commit:), ein Urteil und eine Befundtabelle mit einer ID, Blockierend (ja oder nein) und Art (Defekt, Lücke, Kleinigkeit) pro Zeile. Ein GENEHMIGT deckt den Code dieses Commits ab; Commits, die nur .campaign/ berühren, behalten es. Das Bearbeiten der Überprüfung nach der Akzeptanz macht die Akzeptanz ungültig.
• Korrekturen werden durch Jobs bestätigt, nicht durch erneute Überprüfungen. Für jeden blockierenden Befund führe seine Sonde oder den neuen Test als Job auf dem korrigierten Commit erneut aus, dann campaign accept ID LENS --confirm C1=JOB --confirm C2=JOB. Ein Job bestätigt nur, wenn er auf dem akzeptierten Code im Repository der Quest bestanden hat; ein blockierender Defekt benötigt geänderten Code; das Tool zeichnet auf, ob dieselbe Sonde auf dem überprüften Commit fehlgeschlagen ist. Eine Korrektur, die Dateien ändert, die die Überprüfung nie gesehen hat, geht zurück zum Prüfer (die Überprüfung nennt den korrigierten Commit und genehmigt), es sei denn, --fix-scope GRUND erklärt, warum sie keinen Mechanismus hinzufügt (ein Regressionstest für einen Befund).
• Zwei Korrekturrunden, dann Stopp. Ein dritter Durchgang bedeutet, dass die Quest oder das Design falsch ist: Neu planen oder den Eigentümer fragen. Nicht blockierende Befunde werden zu einer Folge-Quest oder werden mit einem Grund verworfen.
• Ein Design wird einmal überprüft. Beilege strittiges Verhalten mit einem ausführbaren Modell oder Test, nicht mit einer weiteren Textrunde.
• Was eine Quest bestehen muss, ändert sich nur auf dem Record: campaign set ID ... --weaken GRUND senkt ihr Risiko, entfernt eine Linse oder entfernt, ändert oder schiebt eine Prüfung auf; die Änderung wird in ihrer Historie behalten, von campaign status ID angezeigt und macht ihre Akzeptanzen ungültig. Die Überprüfung, die ein Risiko benötigt (eine Code-Überprüfung über niedrig, eine Design-Überprüfung für kritisch), kann nicht entfernt werden, und ein Verzicht wird abgelehnt, sobald eine Überprüfung existiert.
• Systemüberprüfung bei Ereignissen, nicht nach Kalender: wenn campaign check meldet, dass zwei Quests eine Datei oder einen Vertrag ändern, frage einen Prüfer (Linse system) diese spezifische Frage.
• Ertrag: campaign status --reviews zählt Urteile und blockierende Defekte. Eine optionale Überprüfung (normales Risiko), die bei etwa fünf Quests einer Art nichts Wesentliches findet, wird für diese Art eingestellt; Überprüfungen für hohes und kritisches Risiko werden niemals wegen Ertrags eingestellt.

Beweise

Jedes Kriterium in einer Quest-Datei benennt die Beweise, die es benötigt; die Beweistabelle des Journals gibt eine Zeile pro Kriterium, und das Landen überprüft jede Zeile auf dem zu landenden Code:

Kriterium	Seine Zeile muss benennen
- A1 ... (unmarkiert)	Einen Job, der auf diesem Code bestanden hat (er oder derselbe Job erneut ausgeführt)
- A2 [artifact] ...	Einen pfad, der im Repository der Quest committet wurde
- A3 [decision] ...	Eine ID in der Entscheidungstabelle von PLAN.md
- A4 [manual] ...	Wer was von Hand überprüft hat; als manuell angezeigt, nie als automatischer Beweis

Beweise sind proportional zur Behauptung (references/review.md): Tests prüfen Werte, nicht Anzahlen; eine Korrektur hat einen Test, der ohne sie fehlschlägt; eine Behauptung hat eine Mutante, die ein Test tötet; Sanitizer in separaten Builds. Leistungsbehauptungen folgen references/measurement.md: vorher und nachher bei benannten Commits, exklusiv für Zahlen, die etwas entscheiden, ehrliche Größenordnung.

Maschinenarbeit

Stufe	Für	Isolation (quiet)
keine	winzige single-threaded Sonden	kein Halt
leicht	Builds, Test-Suites, Fuzzing	Einige gleichzeitig, nice 19
streng	Rauch-Timings, Verhaltenstests	Eigene Kerne unter Linux; allein unter macOS
exklusiv	Zahlen, die…

[... für die Übersetzung gekürzt]