1:1-Spiegel aus dem Repo
Quelle: FLEET_REGELN.md · Stand der Quelldatei: 09.08.2026 22:08 · erzeugt: 14.08.2026 00:33
Diese Seite ist eine wortgetreue Kopie. Geaendert wird immer die Quelldatei, nie diese Seite.
FLEET_REGELN — W6 Verbund · v1.5 (parallel-dev-fleet + github-agent-memory + w6-morning-standup)¶
0 Gedächtnis: das Repo ist das Gehirn¶
~/W6_GITHUB ist das gemeinsame Gedächtnis aller Akteure (wird als privates Repo w6-fleet-ops versioniert, Ablauf T1-02). Drei Schichten: NOW (STATUS.md + comms/
1 Akteure & ID-Konvention¶
T1, T2, … = Terminal-Agenten (Worker) · G = Governor (Lead im Cowork-Chat; schreibt Pläne/Freigaben über die Brücke, committet nie) · M = Mensch (Taktgeber, Freigaben, Merges nach main, Fremdsysteme). Abläufe heißen <Akteur>-<lfd> (T1-01, T2-01, G-01 …), jeder mit stabilem Ordner ablauf/<ID>_<name>/: PROMPT.md (Auftrag, unverändert) · FEEDBACK.md (fortlaufend, nur anhängen: Datum · Runde/Schritt · Ergebnis) · GATE_
1b Eindeutige Uebergabeorte (v1.5, 08.08.2026 · D-058) — EIN Ort je Zweck, keine Ausnahme¶
| Zweck | Ort | Schreiber | Regel |
|---|---|---|---|
| ABHOLEN (was soll ich tun?) | ablauf/<ID>/FREIGABEN.md — Kopfblock "AKTUELLER AUFTRAG" |
nur G | Der Kopfblock ganz oben ist die einzige gueltige Auftragsquelle; Historie darunter ist Archiv. G aktualisiert den Kopf bei JEDER Freigabe. |
| SPRINT-ANMELDUNG (wer arbeitet woran?) | Kopfzeile von comms/<LANE>_AKTUELL.md: Sprint: <Strang-Nr aus ROLLING_PLAN> · Auftrag <Kurzname> · UEBERNOMMEN <Datum HH:MM> |
Lane | Erste Handlung nach dem Einstieg, letzte Handlung beim STOPP (ZURUECKGEGEBEN + Meldekopf). |
| RUECKGABE (was ist der Stand?) | comms/<LANE>_AKTUELL.md (komplett ueberschreibend, §7-Meldekopf) |
Lane | DER einzige Rueckgabeort. status/T*.md bleibt nur als Ein-Zeilen-Heartbeat; dort steht nie Inhalt. |
| PLAN (wo stehen wir insgesamt?) | planning/ROLLING_PLAN.md |
nur G | Der interne agile Plan (rollend, Skill w6-morning-standup). Lanes LESEN ihn im SYNC; sie schreiben ihn nie — G rollt ihn im Morgen-Standup aus den Rueckgaben. |
| FEHLER-/WUNSCH-EINGANG von M | GitHub Issues im Repo w6-fleet-ops (github.com/thetha/w6-fleet-ops/issues) | M (auch mobil) | G holt neue Issues im Standup/der Abholrunde ab (via Lane mit gh bzw. n8n), uebersetzt sie in Befunde (F-Nr) oder FREIGABEN-Auftraege und antwortet im Issue; geschlossen wird ein Issue erst mit Beleg. Kein GitHub-Projects-Board: der PLAN hat genau EINE Wahrheit (ROLLING_PLAN), sichtbar via mkdocs. (D-060) |
| SICHTBARKEIT fuer Menschen | mkdocs-Bibliothek (w6-library, T6) — Sektion "Entwicklungsstand" | T6 (Generator) | Spiegelt ROLLING_PLAN.md + alle comms/*_AKTUELL.md bei jedem Build automatisch — der Live-Stand und die Ziele sind IMMER im Browser sichtbar, ohne Repo-Kenntnis. |
SPRINTBOARD.md ist damit ERSETZT durch planning/ROLLING_PLAN.md (Stub mit Verweis bleibt). Ein Agent, der nicht weiss, wo er etwas holt oder abgibt, hat diese Tabelle nicht gelesen — es gibt genau diese fuenf Orte.
2 Die zwei Rituale (jeder Akteur, keine Ausnahme)¶
SYNC (vor jeder Runde/Aufgabe): Stand ziehen (sobald Repo: git pull) → STATUS.md + planning/ROLLING_PLAN.md + comms/-Blätter der anderen lesen → eigenen Auftrag gegen den Stand prüfen; passt er nicht mehr → stoppen, Frage ins FEEDBACK. PERSIST (nach jeder Runde/Aufgabe): comms/
3 Invarianten¶
I1 Atomarität: 1 Ablauf = 1 PROMPT = 1 STOPP; gültig ist nur, was ein Report beschreibt. I2 Handoff-Readiness: nach jedem Abschluss Tree clean, STATUS aktuell, alles auf origin — Übernahme-Test ≤ 10 min (LIES_MICH → STATUS → SPRINTBOARD → DECISIONS → aktives FEEDBACK). I3 Recovery: nach Crash nie weiterwursteln — Bestandsaufnahme (git status/log + offener PROMPT) wörtlich ins FEEDBACK, dann fertigführen oder auf letzten Commit zurück und Ablauf neu.
4 Gates & Freigaben¶
Jede Runde endet mit ablauf/<ID>/GATE_<n>.md + Terminal-Ausgabe. Danach WARTEN. G prüft und schreibt die Entscheidung nach ablauf/<ID>/FREIGABEN.md — erst dann weiter. Abschluss: STOPP.md, PROMPT-Ablage bleibt im Ablauf-Ordner.
5 Qualität¶
Repo-eigene Checks vor jedem Gate (Eintausch: npm run verify grün · Zips: SHA256SUMS) · kleine, benannte Commits (Was + Warum) · keine TODO-Platzhalter in Verträgen. v1.5/D-063: Jeder FREIGABEN-Kopfblock nennt wo moeglich einen AUSFUEHRBAREN Check (Test/Build/Script) · vor jeder GATE-Abgabe prueft ein Subagent im frischen Kontext den Diff GEGEN DEN AUFTRAG ("nur Korrektheits-Gaps, keine Stilnoten") · Recherche in Subagents auslagern (Kontext-Schonung) · nach 2 Fehlkorrekturen am selben Problem: Fenster neu mit besserem Prompt.
6 Verboten¶
Push nach main ohne M-Merge · --force · öffentliche Repos · Secrets in Dateien/Chat (Tokens leben bei M bzw. in Plattform-Secrets) · fremde Schreibzonen · alter Core 2.9.x · im Eintausch-Repo Trigger aktivieren / DEBUG aus / Deploy · Raten (→ Frage ins FEEDBACK).
(v1.0/v1.1-Altablagen reports/ und kickoffs/ bleiben; Neues läuft über ablauf/ + comms/.)
7 Meldeprotokoll (neu in v1.3, 05.08.2026 · D-032)¶
- Meldekopf ist Pflicht. Jede Rueckmeldung (STOPP, Zwischenmeldung, Blocker, Befund) beginnt mit genau einer Zeile:
MELDUNG <Akteur> · <Ablauf> · Runde <n> · <Datum ~HH:MM> · <STOPP|ZWISCHEN|BLOCKIERT>Auch jede FEEDBACK-Zeile traegt den Absender (T<x>:bzw.G:). Es muss ohne Kontext erkennbar sein, wer was meldet. - Zentrale Abholung durch G. Meldungen richten sich an G, nicht an M. Pflicht-Schlusszeile jeder Meldung:
Abholung: zentral durch G ueber Cowork. Weiter erst nach FREIGABEN-Eintrag; auf »weiter« im Terminal zuerst FREIGABEN.md und comms/G_AKTUELL.md neu lesen.M stoesst die Abholung im Cowork-Chat mit dem Kommando „Rueckmeldungen abholen" an: G liest dann comms/_AKTUELL.md, status/T.md und neue GATE_/FEEDBACK-/BEFUNDE-Staende aller Lanes, entscheidet, schreibt FREIGABEN — und liefert M ausschliesslich die Mensch-Aufgabenliste. - Weiter-Signal. M tippt in ein Lane-Fenster nur noch
weiter(oder einen von G ausdruecklich benannten M-Befehl). Der Agent liest daraufhin zuerst FREIGABEN.md + comms/G_AKTUELL.md und faehrt gemaess Gates fort — niemals aufgrund muendlicher Zusammenfassungen im Terminal. - Rollenteilung fest: G plant und steuert die Agenten (PROMPTs, FREIGABEN, n8n, Abnahmen). M deployt (Google Script, Browser-Konsolen), fuehrt benannte M-Befehle aus und schaltet Schalter (Odoo-UI). Meldungen an M enthalten nur M-Aufgaben.
0b Commit-Ritual im Gedaechtnis-Repo w6-fleet-ops (v1.4, 05.08.2026 · aus T5-GATE_1, von G abgenommen)¶
- Jede Lane committet ihre eigene Zone selbst und pusht direkt nach
main(Zonen sind disjunkt; Ein-Merger-Regel gilt weiter fuer die CODE-Repos core/runtime/eintausch). - G-Staende committet die naechste pushende Lane als eigenen, getrennten Commit mit Praefix
Gedaechtnis: G-Stand mitgeschrieben (…)— Urheberschaft bleibt im Log lesbar. (Korrektur 05.08. spaet: Gs Direkt-Commit ueber die Cowork-Bruecke funktioniert, hinterlaesst aber Git-Sperrdateien, weil die Bruecke nicht loeschen darf — einmal passiert, M hat aufgeraeumt, Standard ist jetzt diese Variante. G committet nicht mehr selbst.) - Zeitpunkt: nach jeder Runde, vor jedem STOPP, nie mittendrin. Reihenfolge:
git pull --rebase→ schreiben →git addNUR der eigenen Pfade (niegit add -A) → Commit (Was + Warum) → sofort push. - Konflikt in fremder Zone: nie aufloesen —
git rebase --abort, Befund ins FEEDBACK, Meldung an G (Matrix-Verletzung = Governance-Fall). - Keine Tags in w6-fleet-ops; Tags nur in den Code-Repos (annotiert + D-014).
§7.7 Wochen-Retro (v1.5-Ergaenzung, D-063) — Selbstverbesserung als Ritual¶
Freitags erweitert der Morning Kickoff zur RETRO: G sammelt die Woche (DECISIONS, Incidents, FEEDBACK-Lehren, Fehlversuche, Benchmark-Zahlen) und destilliert MAX DREI konkrete Verbesserungen — je als Regel-Aenderung (diese Datei), Skill-Update (versioniert an M) oder Hook/Check. Jede mit Beleg (welcher Vorfall lehrt das?) und Umsetzung binnen der Folgewoche; ROLLING_PLAN-Archiv vermerkt sie. Kandidaten-Liste lebt in zulieferung/W6_DEV_SETUP_EMPFEHLUNGEN_2026-08-08.md §2. Nicht mehr als drei — sonst wird Lernen zu Rauschen.
§7.6 Kickoff-Zyklus (v1.5-Ergaenzung, D-062)¶
M-Befehle im Cowork-Chat: "Morning Kickoff" (morgens) und "Update" (jederzeit) → G faehrt den vollen Zyklus des Skills w6-morning-standup: Rueckmeldungen ziehen → ROLLING_PLAN rollen → Briefing-Artefakt → M wirft den stehenden Auftrag ablauf/T-SYNC-PUSH_STANDARD.md in ein Terminal → Push → Cloudflare-Pages-Build → Doku-Website zeigt den Live-Stand. Erst dann ist der Zyklus fertig.
§7.5 M-Kurzsignale (v1.4-Ergaenzung, D-037)¶
M tippt in Terminals nur noch drei Dinge: T<x> (neues Fenster — Lane-Start ueber das CLAUDE.md-Routing im Wurzelverzeichnis, wird von jedem Terminal-Claude automatisch geladen) · weiter (Fortsetzung; Agent liest FREIGABEN + G_AKTUELL neu) · von G benannte einzelne Befehle (Deploys, Schalter). G schreibt jeden Auftrag vollstaendig in FREIGABEN/G_AKTUELL — nie als Chat-Text, den M weiterreichen muesste.
Par.0c — Worktree-Isolation + Ordner-Identitaet (D-067, beschlossen 09.08., Aktivierung an sauberem Punkt)¶
- Jede Fach-Lane arbeitet in IHREM eigenen Worktree (~/W6_LANES/
); der Haupt-Checkout ~/W6_GITHUB gehoert dem Governor (Schreibort der Bruecke) und der GIT-Lane. Keine Fach-Lane arbeitet mehr im Haupt-Checkout. - Identitaet kommt aus dem ORDNER: .lane-Datei (gitignored) im Worktree-Root; ein SessionStart-Hook injiziert sie automatisch in jede Session (auch nach resume/compact). Widerspricht eine getippte Kennung der .lane → FEHLPASS: melden, nichts ausfuehren. Der Startbefehl braucht keine Kennung mehr.
- Lane-Commit-Standard (Zonen sind disjunkt): git fetch origin && git rebase origin/main && git add
&& git commit && git push origin HEAD:main; verliert der Push ein Race → Sequenz wiederholen. Kein --force, keine fremden Pfade (unveraendert). - Stufe 2: PreToolUse-Zonen-Waechter verweigert Writes ausserhalb der eigenen Zone technisch (ablauf/zones.conf; comms/
_AKTUELL.md immer erlaubt). Aktivierung erst nach G-Review der Zonen-Datei. - Mehr-Fleet-Regel: ein zweites Fleet bekommt eigenes Repo, eigene Wurzel, Kennungs-Praefix und Farbfamilie; nie zwei Governors schreibend auf einem Repo. Details/Skripte: ablauf/worktree-isolation/ · Skill parallel-dev-fleet v2.