Zum Inhalt

1:1-Spiegel aus dem Repo

Quelle: decisions/DECISIONS.md · Stand der Quelldatei: 13.08.2026 23:15 · erzeugt: 14.08.2026 00:33 Diese Seite ist eine wortgetreue Kopie. Geaendert wird immer die Quelldatei, nie diese Seite.

DECISIONS (append-only — Änderungen nur per Rücknahme-Vermerk)

  • D-001 (05.08.2026, M+G): Alle Deploys über Git; GitHub = Referenz, versionierte Zips = Bootstrap-Pakete.
  • D-002 (05.08.2026, M+G): w6-agent-runtime bleibt eigenes Repo und wird 13. Submodul modules/w6-agent-runtime im Core; das Board deployt via Cloudflare Pages „Connect to Git" (Output board/) direkt aus dem Runtime-Repo.
  • D-003 (05.08.2026, M): Board-Domain agents.w6web.app; Zugang nur d.moreinis@w6-wertarbeit.app über Google-IdP (2FA im Google-Konto), One-time-PIN aus, pages.dev-Hostnames mitgeschützt; W6_BOARD_ORIGIN=https://agents.w6web.app.
  • D-004 (05.08.2026, M): Strikte Reihenfolge B-01 → B-06; kein T2-Start vor Board-Livetest (B-04).
  • D-005 (05.08.2026, M+G): W6-EIA — Plattform n8n im Verbund · Kundenmatch-Punktemodell (E-Mail 100 · Nachname 40 · Vorname 10 · PLZ 20 · Straße 20; Zuordnung ab 60 mit Abstand ≥ 20, sonst P1) · Palette Odoo-führend (Tag), Tabelle Spiegel, Zähler im Control Plane, Größe 40, Start Palette 1 · Startstufe 1 Trockenlauf.
  • D-006 (05.08.2026, M): ID-Konvention T/G/M; je Ablauf stabiler Ordner ablauf/<ID>_<name>/ mit PROMPT.md + FEEDBACK.md (+ GATE_.md, STOPP.md).
  • D-007 (05.08.2026, M+G): ~/W6_GITHUB wird privates GitHub-Repo w6-fleet-ops (Ablauf T1-02) = versioniertes Agenten-Gedächtnis; ab dann PERSIST-Pflicht mit sofortigem Push (ungepusht = nicht passiert).
  • D-008 (05.08.2026, G, nach Skill github-agent-memory): Drei-Schichten-Gedächtnis — NOW (STATUS.md + comms/*_AKTUELL.md, überschreibend) · LOG (decisions/ + STOPP-Reports, append-only) · WERK (ablauf/ + Artefakte). Freigaben stehen in ablauf/<ID>/FREIGABEN.md (Schreiber nur G) — nicht im FEEDBACK („ein Pfad = ein Schreiber").
  • D-011 (05.08.2026, M): Neue verbindliche Reihenfolge — T1 Board → T2 Governor-Agent (Ueberwachung) → T3 Vorkasse → T4 Eintausch → T5 Core-Doku, danach gemeinsames Live-Gate G-02 (vka=1, eia=1, Schedules aktiv). Bis dahin bleiben alle Fachagenten-Schalter auf 0 und alle Agent-Schedules inaktiv. D-004/D-009 ersetzt. Das enable_agent-Audit von 12:13 wurde NICHT vollzogen (Korrektur-Verdict in gov_actions).
  • D-012 (05.08.2026, G): Arbeitspakete T1-02…T5-01 liegen als PROMPT.md in ablauf// (Quelle: pakete/). n8n-Anlagen fuehrt G aus (MCP), Browser/Secrets/Odoo-UI der Mensch [M]; die Lane spezifiziert, prueft und dokumentiert. Ist die Cowork-Bruecke offline, gilt die Chat-Freigabe als Original und die Lane traegt sie in FREIGABEN.md nach.
  • D-013 (05.08.2026, G, auf Befund B4 von T1): SETUP.md §5 im Runtime-Repo (nennt noch One-Time-PIN statt Google-IdP/D-003) wird nicht sofort korrigiert — ein Commit loest den ersten Pages-Auto-Deploy aus, bevor Cloudflare Access steht (kurzes ungeschuetztes Zeitfenster). Korrektur erfolgt in T5-01 Runde 3 als Runtime v0.9.3 zusammen mit der Betriebsdoku. Textfassung wird vorab als Datei abgelegt.
  • D-014 (05.08.2026, G, auf Befund von T1): Lightweight-Tags werden von git push --follow-tags nicht zuverlaessig uebertragen. Regel fuer alle Lanes: nach jedem Push git ls-remote --tags origin gegen die Soll-Tagliste pruefen und fehlende Tags einzeln nachpushen (git push origin <tag>), nie --force. Gilt insbesondere fuer T4-01 (v0.5.1) und T5-01 (v3.1.0, v0.9.3).
  • D-015 (05.08.2026, M): Board-Login = Cloudflare-Konto als Identity Provider (Zero Trust > Integrations > Identity providers > Cloudflare, "Restrict to account members" AN) statt Google-IdP; MFA kommt aus der Cloudflare-Kontosicherheit (2FA im Konto Pflicht). Ersetzt insoweit D-003; Policy bleibt Allow nur fuer d.moreinis@w6-wertarbeit.app, One-time PIN bleibt aus, pages.dev-Hostnames bleiben mitgeschuetzt.
  • D-016 (05.08.2026, G): Zero-Trust-Menuepfade 2026 geaendert (Integrations > Identity providers; Access controls > Applications). Anleitungen und Doku sind darauf zu pruefen; Korrektur in ablauf/T1-02_board/FREIGABEN.md festgehalten, T1 aktualisiert die Klickanleitung.
  • D-017 (05.08.2026, G): Edge Function w6-board -> v0.9.3 mit neuer Route GET /diag (ohne Token aufrufbar; liefert ausschliesslich Metadaten: gesetzt ja/nein, Laenge, SHA-256-Praefix, CORS-Origin — nie Werte). Grund: Token-Fehlkonfiguration war sonst nicht von CORS-Fehlern unterscheidbar (Board zeigt beides als DEMO). Route bleibt dauerhaft; Aenderung ist im Repo nachzuziehen (T5-01).
  • D-018 (05.08.2026, G): Board ist live — https://agents.w6web.app, Cloudflare Access mit Cloudflare-IdP, vier Edge-Secrets gesetzt, /diag match=true. Sprint-Karten im Control Plane auf die D-011-Reihenfolge (T1-02 … T5-01, G-02) aktualisiert, damit das Board die Wahrheit zeigt.
  • D-019 (05.08.2026, G, Befund B6): board/index.html schaltet Start/Stopp/Stufe nur fuer hartkodierte agent_ids [vka,bma,vsa] frei; neue Agenten (eia) bleiben ohne Bedienelemente. Fix in T5-01 (generische Bedingung), zusammen mit SETUP-Korrektur als Runtime v0.9.3.
  • D-020 (05.08.2026, G, Blocker A1 von T1): Cloudflare Access ist auf agents.w6web.app und den pages.dev-Hosts nicht wirksam (curl ohne Cookies liefert 200 statt 302). Meine Gate-4-Freigabe zum Zugangsschutz wird zurueckgezogen; Daten bleiben geschuetzt (API 403 ohne gueltigen Token), keine Eskalation. Neue verbindliche Abnahmeregel: Zugangsschutz wird ausschliesslich per curl -sI (302 auf cloudflareaccess.com) nachgewiesen, nie per Browser/Inkognito. T2-01 startet erst nach Behebung; haeufigste Ursachen: Application nicht publiziert, Policy-Action Bypass statt Allow, fehlende Hostnames.
  • D-021 (05.08.2026, G): Blocker A1 behoben — Access-Application hatte die Hostnames als private Destinations; als public hostnames neu angelegt, seitdem curl -sI https://agents.w6web.app → 302 auf cloudflareaccess.com. Merksatz fuer kuenftige Setups: In der zusammengelegten App-Form „Self-hosted and private" entscheidet Add public hostname vs. Add private hostname darueber, ob oeffentlicher Traffic ueberhaupt erfasst wird; ein 404 auf /cdn-cgi/access/login ist das schnellste Erkennungsmerkmal. T1-02 damit vollstaendig abgenommen, T2-01 freigegeben.
  • D-022 (05.08.2026, M): Eintausch wird heute fertig — Prioritaet vor T2-01. Parallelbetrieb ausdruecklich freigegeben: T4 = Google Apps Script (Repo auf GitHub, Vertragsfixes v0.5.1, neue Support-Menues v0.6.0, clasp-Deploy, Tests) · G = n8n-Seite (EIA-Flow, Odoo-Discovery, Testtickets, Kalibrierung). Trennlinie ist der Envelope-Vertrag w6.tradein.ticket.v1; er bleibt unveraendert, nur das Feld source wird ergaenzt (manual-support).
  • D-023 (05.08.2026, M): Zwei neue Support-Menuepunkte im Apps Script (Ausgangslage: Kunden fuellen das Formular nicht immer aus). (A) Datenanfrage an Kunden senden — markierte Zeile mit nur E-Mail, Mail mit Formular-Link, kein Code; Rueckfluss ueber die normale Jotform-Zeile, Verknuepfung ueber die normalisierte E-Mail, kein zweiter Code. (B) Daten manuell erfasst → Code + Mail — Support traegt die Daten ein, markierte Zeile, deterministische Ersatz-Submission-ID, dann der normale Weg (HMAC-Code, Kundenmail, Werkstattmail). Beide mit Tests, Doku, neuen Statusspalten; Release v0.6.0.
  • D-024 (05.08.2026, M): Angebot senden beim Maschineneingang wird Teil der EIA-Spec (Stufe 2b): Wandert das Ticket in Stage Eintauschaktion (id 40), soll der Agent das vorbereitete Angebot an den Kunden senden. Sicherungen (G): nur bei eindeutigem Kundenmatch (>= 60 Punkte, Abstand >= 20), nur wenn Angebotssumme und Positionen exakt der Vorgabe entsprechen (399 EUR + 4x W-G-0015 a 0), nur einmal je Code (Chatter-Marker GRT-4 + external_ref), sonst P1-Karte fuer den Menschen. Freigabe erst nach dem Stufe-1-Trockenlauf.
  • D-025 (05.08.2026, G, aus dem ersten EIA-Echtlauf): Dubletten-Regel im Kundenmatch. Treffen mehrere Odoo-Konten mit derselben E-Mail zu, ist das eine Dublette und kein Zweifelsfall: der aelteste Datensatz (kleinste id) wird zugeordnet (E-OK-MATCH), die uebrigen wandern als Feld dubletten in die Queue-Karte (Vorarbeit fuer die Dublettenbereinigung). Echte Mehrdeutigkeit (verschiedene Personen, ohne E-Mail-Gleichheit) bleibt E-P1-MULTI. Anlass: Ticket 6213 lieferte 'Susannekupfer' und 'Susanne kupfer' mit je 190 Punkten — derselbe Mensch, zweimal erfasst. Verifiziert im zweiten Lauf: Zuordnung 43470, Dublette 43471 gemeldet.
  • D-026 (05.08.2026, G, Befund F1/T1): public.w6a_alert_seen(signature, hours) eingespielt (Migration w6a_alert_seen_v0_9_4) — der Watchdog kann Alert-Signaturen jetzt pruefen, ohne dass Schema w6a exponiert wird. Ablage weiterhin ueber gov_act ack_alert.
  • D-027 (05.08.2026, G, Befund F2/T1): W6-ADMIN validiert Agenten nicht mehr ueber eine harte Liste, sondern formal (Token-Muster) + ueber die Existenz des ICP; unbekannter Agent -> 404 rejected:unknown_agent. Damit ist die Fehlerklasse aus D-019 an dieser Stelle strukturell beseitigt (neue Agenten brauchen keine Codeaenderung).

D-028 · 05.08.2026 · Parallel-Betrieb der Lanes

M ordnet Parallel-Entwicklung an (inkl. T3 Vorkasse). Die D-011-Reihenfolge gilt nicht mehr fuer die Entwicklung, sondern nur noch als Gate-Logik fuer die Live-Schaltung (G-02 bleibt letzter Schritt; vka/bma bleiben 0, eia=1 ohne Schedule). Freigaben: T2-01 Runde 2 (nach „ADMIN aktiv"), T4-01 Runde 2, T3-01 Start. T5-01 startet auf Zuruf M.

D-029 · 05.08.2026 · Datenanfrage-Formular = Google Form mit kontrolliertem Rueckkanal

M entscheidet: Menue A verlinkt ein neues Google Form (nicht die Jotform). Antwortziel ist die Eintausch-Tabelle (eigenes Antworten-Tab). Ein Importer (v0.6.1, T4 Runde 3b) fuehrt Antworten zurueck: Zuordnung ueber normalisierte E-Mail NUR zu angefragten Stub-Zeilen (WAITING_INPUT + MANUAL_DATA_REQUEST), Stub wird vervollstaendigt (Submission-ID GF-), keine neue Zeile, nie ein zweiter Code; Antworten ohne angefragte Stub-Zeile werden geparkt (Fremd-Submissions loesen nie Codes aus). Bis v0.6.1: manueller Uebertrag + Menue B. v0.6.0-Zuschnitt unveraendert.

D-030 · 05.08.2026 · Google Form wird per Script angelegt

M-Anweisung „per Script entwickeln": Das Datenanfrage-Formular (D-029) wird nicht manuell erstellt, sondern durch eine idempotente Setup-Aktion im Apps Script (FormApp; W6_TI_FORM_ID verhindert Zweitanlage; Antwortziel = Eintausch-Tabelle; URL landet automatisch in W6_TI_FORM_URL). Teil von T4 Runde 3 / v0.6.0; Referenzcode von G als ANLAGE im Ablauf-Ordner. Manifest braucht zusaetzlich den forms-Scope (Re-Auth-Hinweis in der Doku).

D-031 · 05.08.2026 · Kill-Switch-Semantik zweistufig

w6.agents.enabled=0 ist NOT-AUS und blockt alle Modi aller Agenten. w6.<agent>.enabled=0 blockt nur write/act; read/Trockenlauf bleibt erlaubt (Spec §6, Voraussetzung fuer die Messwoche bei vka=0). Schreiben bleibt zusaetzlich durch Mode-Pruefung und Write-Budget gedeckelt. Umsetzung: G in GRT-1, gilt fuer alle Agenten. Ersetzt die bisherige Alle-Modi-Sperre je Agent (Befund T3/B-02).

D-032 · 05.08.2026 · Meldeprotokoll und Rollenteilung

Jede Meldung traegt einen Meldekopf (MELDUNG · · Runde · Zeit · Status); Rueckmeldungen gehen an G, nicht an M. M holt zentral ueber Cowork ab (Kommando „Rueckmeldungen abholen" → G liest alle Lanes, entscheidet, schreibt FREIGABEN, liefert M nur M-Aufgaben). M tippt in Lane-Fenster nur noch weiter. Rollen fest: G plant/steuert Agenten, M deployt und schaltet. Details FLEET_REGELN v1.3 §7.

D-033 · 05.08.2026 · Erst Fixpaket, dann Messwoche; Befunde als Runtime v0.9.3

Die T3-Befunde B-01/B-02/B-04/B-05/B-07/B-08 und T1/F8 sitzen im gemeinsamen Runtime-Unterbau und werden als Runtime v0.9.3 gefuehrt (Repo/Doku T5-01, n8n-Umsetzung G) statt als VKA-Einzelfixes. Die Trockenlauf-Messwoche (Spec §7) beginnt erst nach Einbau des Fixpakets — Messung mit bekannt kaputtem Lock/Rate/Read-Block ist wertlos.

D-034 · 05.08.2026 · Eintausch-Repo umbenannt und in den Core-Verbund aufgenommen

Neuer Name: w6_eintauschaktion_google_apps_script (vormals w6-eintausch-automation) — Eintauschaktionen sind ein wiederkehrendes Format, das Repo ist die Dauerloesung. Aufnahme in w6-odoo-core als 14. Verbund-Repo und ERSTES physisches Submodul (modules/w6_eintauschaktion_google_apps_script), Core v3.0.13 mit Eintraegen in modules/README, README, CHANGELOG, MODULREGISTER v2.0. Ausfuehrung durch M als Ein-Merger (gh rename + frischer Klon + Edit-Script von G + Tag + Push). GitHub-Redirects halten alte URLs am Leben; T4 zieht remote-URL und Eigenreferenzen in Runde 3 nach; T5 bindet die restlichen 13 Submodule mit v3.1.0 ein.

Nachtrag zu D-029 · 05.08.2026 · Importer-Version = v0.6.2

v0.6.1 wurde durch die G7/G8/D-034-Nachtraege belegt (GATE_3b). Der Rueckkanal-Importer traegt v0.6.2; Zuschnitt und Schutzregeln aus D-029 unveraendert.

2. Nachtrag zu D-029 · 05.08.2026 · Mailtexte = v0.6.2, Importer = v0.6.3

M-Textwuensche (Betreffe, Adressblock-Zeile, Kundenmail-Footer mit Feedback-Link + Impressum) muessen VOR der Stufe-3-Echtversand-Probe deployt sein → sie werden v0.6.2 (T4 Runde 4a). Der Rueckkanal-Importer rueckt auf v0.6.3. Envelope-Vertrag bleibt unveraendert.

D-035 · 05.08.2026 spaet · Stufe-3-Probe mit Standardabsender; Zwischenzustand "halb scharf"

Fuer die Ende-zu-Ende-Probe (M am Rechner, eigene Zeile) wird W6_TI_STRICT_FROM_ALIAS voruebergehend auf false gestellt (Absender = Standard-Gmail-Konto), weil der Alias eintauschaktion@w6-wertarbeit.de noch nicht als "Senden als" eingerichtet ist; Alias-Einrichtung folgt, danach STRICT wieder true. Erlaubter Dauer-Zwischenzustand danach: DEBUG=false + LIVE_SEND=true + Automatik CODE_ONLY = Codes automatisch, Versand NUR manuell je markierter Zeile mit SENDEN-Bestaetigung. SEND_ENABLED-Automatik bleibt hinter Stufe 4b (M-Wort).

D-036 · 05.08.2026 nachts · VOLLAUTOMATIK Apps Script (Stufe 4b) auf M-Wort

M ordnet an: "voll automatik heute noch". Freigegeben mit Ersatz-Sicherung fuer das "Alle offenen senden"-Tabu: VOR dem Umschalten wird der komplette Altbestand in beiden Reitern auf STATUS=DONE gesetzt (Bulk-Fill in der Spalte Automation Status) - Alt-Kunden bekommen nichts. Danach W6_TI_AUTO_MODE=SEND_ENABLED: neue Formular-Einsendungen laufen automatisch Code->Kundenmail->Werkstattmail->Odoo-Ticket->EIA-Klassifikation. Verbleibende Sicherungen: Batch-Cap 20/Lauf, Manual-Hold, SENT-Dedup + Gmail-Reconciliation, Health; Not-Aus = Automatik AUS oder DEBUG=true (Not-Stopp ueberlebt Triggerfehler). STRICT_FROM_ALIAS temporaer false (D-035), Alias-Einrichtung morgen. EIA/VKA-Live-Gate G-02 bleibt davon unberuehrt.

D-037 · 06.08.2026 · Kurzsignal-Protokoll: Auftraege wohnen in Dateien, nicht im Chat

M-Terminal-Eingaben beschraenken sich auf T<x> (neues Fenster), weiter (Fortsetzung) und von G benannte Einzelbefehle. Dafuer: CLAUDE.md im Wurzelverzeichnis (automatisch geladen von jedem Terminal-Claude) traegt Routing, Einstiegsreihenfolge, Kurzregeln und Zonen; G verpflichtet sich, jeden Auftrag vollstaendig in FREIGABEN/G_AKTUELL zu schreiben. Ende der Copy-&-Paste-Orgien.

D-038 · 06.08.2026 · Upgrade-Readiness-Pflicht (v19 -> v20)

Jede Custom-Sache (Modul, Studio-Feld, ICP, Server Action, Template, Automatisierung, n8n-Flow mit Odoo-Beruehrung) wird ab sofort mit einem v20-Impact-Vermerk im MODULREGISTER dokumentiert (hoch/mittel/kein + Testschritt). Upgrade-Vorgehen in vier Phasen P0 Inventar / P1 laufende Pflicht / P2 Testinstanz-Probe (n8n-Zweitvariablen) / P3 Cutover mit NOT-AUS und Rollback-Kriterien / P4 Nachlauf — Plan: Core docs/W6_UPGRADE_V20_PLAN.md (Entwurf v0.1 von G, Einchecken T5).

D-039 · 06.08.2026 · Handoff-Artefakte verbindlich

Gap-Analyse gegen den github-agent-memory-Skill geschlossen: README.md (Uebernahmepfad + Verbund-Karte + Matrix-Verweis), AGENTS.md (toolneutral, Cursor-faehig), docs/THREAD_HANDOFF.md (lebend; G aktualisiert es bei jeder Abholung; enthaelt die woertliche Erstnachricht fuer einen neuen Governor-Thread), LIES_MICH_ZUERST als Wegweiser, reports/stopp/.gitkeep. Uebernahme-Test I2 gilt jetzt auch fuer Fremd-Agenten via AGENTS.md; Test morgen ueber Terminal (Cursor).

D-040 · 06.08.2026 · W6 Library: Variante A, eigenes Repo, Ablauf T4-02

M entscheidet Variante A (MkDocs Material + Cloudflare Pages hinter bestehendem Access, docs.w6web.app). Praezisierung gegen das Konzept v0.1: Die Library lebt in einem EIGENEN privaten Repo w6-library (15. Verbund-Repo) statt im Core — Grund: Zonentrennung (Core-Pushes sind T5-Zone; die Library baut Lane T4 als Ablauf T4-02, nachdem T4-01 geschlossen ist). Der Core verlinkt die Library; spaeteres Submodul optional. Seitenschema, App-Gruppierung, A-Z-Index, mike-Versionen wie im Konzept.

3. Nachtrag zu D-029 · 06.08.2026 · Importer-Auswahlkriterien bestaetigt

Die von T4 in v0.6.3 umgesetzte Auswahl (LAST_SOURCE=MANUAL_DATA_REQUEST hart · DATA_REQUEST_STATUS=SENT hart NEU · Einsendecode leer hart NEU · Automation Status in {WAITING_INPUT, BLOCKED, leer} gelockert) ist BESTAETIGT — die Lockerung ist noetig, weil die Automatik Stub-Zeilen nach autoMaxAttempts auf BLOCKED eskaliert; die zwei zusaetzlichen harten Bedingungen machen die Auswahl enger als der D-029-Wortlaut.

D-041 · 06.08.2026 · Eintausch-Nacharbeit: Palette 25, manueller Vorrang, Recycling-Feld, Entsorgungslogik, Paletten-Board

M-Vorgaben: (1) Palettengroesse = 25 statt 40 — Policy palette_size sofort umgestellt, wirkt ab dem naechsten Platz. (2) Manueller Vorrang: traegt ein Mitarbeiter die Palette von Hand ins Feld x_studio_eintausch_palette ein, ueberschreibt das System sie NIE; der Agent uebernimmt den Wert und registriert ihn im Control Plane (slot=manuell). (3) x_studio_recycling (boolean) wird vom Agenten beim Wareneingang aus dem Envelope (recycling.requested) gesetzt. (4) Entsorgungslogik (G-Default, M kann Startpunkt aendern): recycling=JA → entsorgbar ab Wareneingang · recycling=NEIN → entsorgbar ab Kaufabschluss + 30 Werktage (Widerruf; Start default = Auftragsbestaetigung des zugehoerigen Verkaufs, Verknuepfung ueber W6TI:), ohne Kauf → Eingang + 12 Wochen. Neues Feld x_studio_entsorgbar_ab (Date), Agent berechnet; Anzeige als gefilterte Ansicht „Recycling/Entsorgung" (entsorgbar_ab <= heute). (5) Paletten-Board ohne Custom-Modul: Studio-Menuepunkt „Eintauschaktion" nach dem Muster „Schnaeppchen einbuchen" — Kanban/Liste gruppiert nach Palette, druckbare Uebersicht; Umsetzung M per Anleitung. Einbau der Agent-Seite: EIA v0.3 (G).

Nachtrag zu D-041 (06.08., Vormittag) — Befund: EIA-Stufe stand auf 1, Chatter war nie live

Die Stufe-2a-Chatter-Vermerke (mail.message create, in der Allowlist seit v0_9_5) waren seit Anlage des eia-Registry-Eintrags durch stage=1 dry-run-geblockt: Guard-Verdict G1:stage1_dry_run (Beleg exec 7466), run_log arrival:guard_block 3× (05.08. 21:18 / 22:03, 06.08. 09:18). Die 📦-Ankunftsnotizen zu 6212/6218/6220/6219 wurden also NIE in Odoo gepostet — Paletten-Register (CP) und Klassifikation liefen korrekt; auch Ankunftskarten wurden auf dem geblockten Pfad nicht angelegt. Korrektur: stage_change eia 1→2 via w6a_gov_act mit Audit-Eintrag (06.08. ~09:31 UTC). Chatter-Backfill der 4 Tickets folgt mit EIA v0.3. Lehre (in die Betriebsdoku): die Stufen-Matrix (agent_registry.stage) gehört sichtbar auf Board/STATUS — ein Schalter, den niemand sieht, ist ein Befund in Wartestellung.

2. Nachtrag zu D-041 (06.08., mittags) — Paletten-Zeiger folgt dem Lager (M-Entscheid) + Feld bestaetigt

M-Vorgabe aus dem Lager-Ablauf: der Mitarbeiter traegt die Palettennummer von Hand ein, wenn er eine neue Palette BEGINNT; ab da soll alles Weitere automatisch die aktuelle Nummer bekommen. Regeln fuer EIA v0.3 (ersetzt die reine Zaehl-Logik): 1. Das Feld gewinnt immer. Eine von Hand eingetragene Zahl wird nie ueberschrieben; aendert der Mitarbeiter eine Zahl nachtraeglich, uebernimmt der Agent sie ins Register (manual=true, slot=NULL). 2. Der Zeiger folgt der hoechsten Nummer. Automatische Vergabe geht immer auf die hoechste im Register bekannte Palette (inkl. manuell uebernommener). Stellt das Lager einmal auf 2, bekommt ab da alles die 2 — auch wenn Palette 1 rechnerisch noch keine 25 hat (physisch voll schlaegt Zaehlstand). 3. Nachzuegler erlaubt. Eine niedrigere manuelle Zahl (Maschine passt noch auf eine alte Palette) gilt nur fuer dieses Ticket und senkt den Zeiger nicht. 4. 25er-Deckel bleibt Auto-Wechsel. Zaehlt die aktuelle Palette >= palette_size Registrierungen (manuell + automatisch), wechselt der Agent selbst auf die naechste Nummer. 5. Tippfehler-Schutz. Ein Sprung um mehr als +1 wird uebernommen (Feld = Wahrheit), aber mit ⚠️-Hinweis im Chatter; korrigiert das Lager das Feld, folgt das Register beim naechsten Abgleich. Umsetzung: w6a_palette_next v2 als Migration v0_9_8 + Feld↔Register-Abgleich je Lauf. Ausserdem bestaetigt: Studio-Feld x_studio_entsorgbar_ab (Date, helpdesk.ticket) ist angelegt (Screenshot M) — alle M-Voraussetzungen fuer EIA v0.3 sind erfuellt.

Nachtrag zu D-035 (06.08., mittags) — Alias verschoben (M-Entscheid)

M: „gmail alias, lassen wir auf info@ — erstmal nach hinten packen, so ist okey." Der Absender der Eintausch-Mails bleibt info@w6-wertarbeit.de; W6_TI_STRICT_FROM_ALIAS bleibt false auf unbestimmte Zeit. Der Punkt wandert von der Tagesliste in den Backlog; D-035 (temporaere Ausnahme) wird damit zur bewussten Betriebsentscheidung. Kein M-Handgriff mehr offen dazu.

D-042 (06.08.2026) — Korrektur-Mechanismus: Agenten reparieren ihren eigenen Bestand

M-Frage: „Wenn ein Agent falsch gelaufen ist — brauchen wir einen Mechanismus für Korrekturen?" Entschieden: ja, als Bauprinzip. 1. Selbstreparatur-Pfad: Jeder Agent prüft Bestand statt blind anzulegen (Idempotenz über refs/Marker/dedup) und REPARIERT Abweichungen: EIA prüft je W6TI-Entwurf Positionen+Preis und korrigiert (ergänzt fehlende Zeilen, setzt Aktionspreis), setzt fehlendes Land am Kunden (DE/AT aus Angabe/PLZ-Laenge), setzt den Kunden ans Ticket, traegt fehlende Chatter nach; VKA arbeitet mit lueckenlosem Cursor + [W6-VKA]-Marker. 2. Ausloesung durch Cursor-Rewind (G): Governor setzt den Scan-Zeiger zurueck; der Agent laeuft ueber den Bestand und repariert automatisch — nichts wird doppelt angelegt. Beleg 06.08.: Sweep-Laeufe 70/71 = 21 Entwuerfe neu (349/399 korrekt), 5 repariert, Laender + Ticket-Kunden gesetzt, Rest „in Ordnung". 3. Sichtbarkeit: Jeder Reparatur-Befund steht woertlich auf Board-Karte und run_log („REPARIERT · SO … · Preis war X statt Y"). 4. Schreibende Reparaturen laufen wie alle Writes hinter eigenen GRT-1-Guards (B-11).

3. Nachtrag zu D-041 (06.08., nachmittags) — Aktionspreise FEST + Befunde aus dem Entwurfs-Sichttest

  • Preise (M-Entscheid): W-NM-868 = 399 (549−150) · W-NM-868-S = 349 (499−150) — als Festwerte im Agenten; der Odoo-Listenpreis ist keine Basis, denn die 868-S steht in Odoo selbst auf 549. Datenpflege-Hinweis an M: Listenpreis der W-NM-868-S (Produkt 12059) auf 499 korrigieren; der Agent loggt die Abweichung je Angebot.
  • Ursache des Preisfehlers: Festwert 399 fuer beide Varianten aus dem v0.2-Vorschlagstext uebernommen — die S-Variante war nie separat bepreist. Vom Entwurfs-Modus wie vorgesehen VOR jedem Versand sichtbar gemacht.
  • Mehrfach-Einsendungen: je Code EIN Angebot mit EINEM 150-EUR-Rabatt, ein Kundenkonto (Dublettenschutz) — 2 Angebote fuer Kroells-Brandner sind korrekt (2 Maschinen).
  • Neu am Ticket: partner_id wird vom Agenten gesetzt/aktualisiert (M-Befund „Ticket haengt nicht am richtigen Kunden").

  • AddressFactory/Adress-Check-Integration (voller Adress-Validator statt nur Land) = Ausbaustufe, gehoert zu K-01-Nachbarschaft.

  • D-041 Nachtrag 4 (06.08. ~14:00, G): Entsorgbar-ab-Rechner LIVE (EIA v0.3d, Kette "Taeglich 0530", Version 71c39b80). Regeln: Recycling JA -> ab Eingang - Kauf bestaetigt -> Auftragsdatum + 30 Werktage - sonst Eingang + 84 Tage. FELD GEWINNT: nur leere x_studio_entsorgbar_ab werden befuellt, manuelle Eintraege nie ueberschrieben (Abweichungen nur im run_end gemeldet). Erster Lauf 07.08. 05:30. D-041 KOMPLETT.

  • D-020 Nachtrag (06.08., G, aus T1): Terminal-Abnahme fuer Access-geschuetzte Hosts = curl -sI -> 302 (cookiefrei) + aud/kid-Vergleich; die 404-Heuristik auf /cdn-cgi/access/login ist KEIN Unterscheidungsmerkmal (tritt auch im behobenen Zustand auf) und kommt nicht ins Playbook. Beim Anlegen von Cloudflare-Access-Applications sind ausdruecklich PUBLIC hostnames zu verlangen (Private hostnames schuetzen nur Client/Tunnel-Traffic — Ursache Blocker A1).

  • D-043 (06.08. ~19:00, M): Stufe 2b = JA — Angebots-Entwurf wird bei Maschinen-Ankunft AUTOMATISCH an den Kunden versendet (Odoo-Vorlage mail.template 12 "Sales: Send Quotation", Absender info@ per D-035, force_send). Sicherungen (D-024): genau EIN Entwurf je Code · nur state=draft (Versand setzt state->sent = Idempotenz; versendete Angebote werden nie mehr automatisch geaendert) · 0 < Betrag <= 500 · Partner vorhanden · Palette gezogen · Odoo-Suchfehler => kein Versand im Takt · eigener B-11-Guard (eia-Allowlist + mail.template send_mail = 10 Eintraege). Gebaut als EIA v0.4 (119 Nodes, Fan-out hinter Chatter-Vermerk). AKTIVIERUNG (Publish) macht M in der n8n-UI — die Cowork-Schranke blockt Kunden-Mail-Automation fuer G, korrekt als M-Vollzug.

  • D-044 (06.08. ~19:00, M): C4: Bank-Sync auf 1 Stunde (ir.cron 23, bisher 12 h; Umstellung M in Odoo). G-Hinweis: Anbieter-Drossel moeglich (PSD2-Rahmen, typ. 4 unbeaufsichtigte Abrufe/Tag) — nach Umstellung beobachten, Fallback 6 h. Wirkung: VKA-Messwoche ~12x schneller.
  • D-045 (06.08. ~19:30, M): Daumen-Feedback am Board — je Vorschlags-Karte Daumen rauf/runter (+ optional Notiz) als Lern-Signal je Agent. Weg: Board v0.9.5 (zwei Buttons -> ADMIN action=verdict detail {job_id, rating, note}) · gov_act-Handler schreibt rating an agent_queue (Migration v0_9_12) · Auswertung je Agent (Daumen-runter-Karten = Verbesserungs-Futter, G/T3 clustern reasons und schaerfen Regeln). Haken bleibt "gesehen/erledigt", Daumen ist QUALITAET.
  • D-046 (06.08. ~19:30, M): Buchhaltungs-Korrektur hat Prioritaet VOR BMA. Ms Analyse (Parallel-Thread): Verbuchungen laufen nicht richtig; Ziel: so nah wie moeglich an korrekte Verbuchung, Bilanz, GuV und Verbraeuche (Werkstatt), pruefungsfest mit Erlaeuterungen (Wirtschaftspruefung). Vorgehen nach Skill odoo-buchhaltung-gutachten: Phasen B0–B9, Leitstand = G/Cowork, Werkbank = Terminal-Lane (Vorschlag T1-03, T1 ist frei), jeder Eingriff einzeln rueckrollbar, Gutachten am Ende (kein Testat — Bewertung Steuerberater). B0-Interview (4 Rahmenfragen) an M gestellt. BMA baut danach auf den korrigierten B4-Regeln auf (Payout-Verrechnungskonten).

  • D-047 (06.08. ~19:30, M): Versand-Werkstatt-Nacharbeit als Paket aufgenommen (Ms Parallel-Thread, w6-versand-werkstatt v1.0.0): 3 Knoepfe auf stock.picking (Packliste · DHL-Label 2 Wege · Silent-Bestaetigung), Server Actions + Studio, kein Custom-Modul; Abnahmetest SPR/RESHIP2/00185. Priorisierung im v20-/Wochenplan; Doku-Aufnahme sofort (T5 Core-Registrierung + T4 Library-Seiten).

  • D-048 (06.08. ~23:20, M): Compliance Garantie/Gewaehrleistung in die Mail-Vorlagen (PDF "Hinweise zum Garantie- und Gewaehrleistungslabel", zulieferung/compliance/, 3 Faelle). PRIO VOR der Status-Seite. Umfang: (1) Template 12 "Sales: Send Quotation" DEU+ENG um beide Hinweis-Bloecke ergaenzen (vorvertragliche Pflicht; Garantie-Anhang-Automatik fuers Angebot existiert bereits) · (2) Template "Invoice: Sending" KANAL-DIFFERENZIEREN: Odoo-Direktkunden = beide Hinweise + Anhaenge JETZT; Shopify = nur Gewaehrleistungsblock (Garantie kommt von Shopify) VORBEREITET, spaeter aktivieren; Amazon = Fall 3 wartet auf Plattform · (3) bestehende Angebots-Automatisierungsregel (produktpassende Garantiedokumente anhaengen) fuer die Rechnungsmail erweitern/nachbauen. Weg: G-READ zieht Ist-Staende (beide Templates + base.automation "Garantie"), G liefert exakte Aenderungstexte, M setzt in der UI um (oder Werkbank per kw) — keine naechtlichen Aenderungen.

  • D-049 (06.08. ~23:20, M): Status-Seite status.w6web.app — PLANUNGSAUFTRAG (nach D-048). Sammelt Odoo-/Shop-Gesundheit mit Schwellen + Handy-Alarm: Shopify-Bestelleingang · Amazon-Bestelleingang · queue_job-Haenger (failed/cancelled + can_validate-Pakete aelter 2 Tage, aus Versand-Werkstatt-Doku) · Aussen-Check www.w6-wertarbeit.de (HTTP/Cloudflare-Parameter) · Odoo-API-Health inkl. der neuen "HTML-statt-JSON"-Signatur (Incident 06.08.) · Access/Login-Status agents.w6web.app. Muster: Board/Pages + WD-Takte; Push-Kanal (Handy) = Planungsfrage (Mail-Push vorhanden; ntfy/Pushover pruefen). SPEZ-Entwurf G+T2-Review, Bau T5/G nach Freigabe.

  • D-048 Umsetzung 07.08. ~00:05: odoo19-email-templates v1.7.0 geliefert (sale 1.3.0 + invoice 1.2.0 mit Kanal-Weiche, SA-Rechnungs-Kopiervorlage, Anleitung; alles unter zulieferung/compliance/, ZIP unter module/). Vorlagen einspielen + Regel anlegen + 3 Tests + GitHub-Push = M. Shopify-Hinweis vorbereitet, Aktivierung spaeter ueber shopify_hinweis_aktiv=True.

D-050 (07.08.2026 ~00:45, M im Chat) — Vollstaendigkeits-Grundsaetze Board/Logging/Not-Aus

Wortlaut M: "alles was du aufsetzt und irgendwie selbststaendig laeuft, taucht auf dem Board auf; alles was die Agenten machen, muss geloggt werden (Zeitfenster-Abfrage -> CSV/Liste); alles was angelegt wird, muss auf dem Board registriert werden; alles muss ueber den Notschalter abschaltbar sein. Zweck: Rollback-Faehigkeit — wir haben die Infos, was gemacht wurde und wo." Konsequenzen (Massnahmenliste siehe G_AKTUELL 00:45): Registry-Pflicht fuer ALLE Selbstlaeufer (auch WD, G-READ, Alt-Automationen, Odoo-Automatiken als Inventar), Not-Aus-Kette auf Alt-Flows ausweiten, WD bekommt eigenen Schalter + Kachel + Lauf-Logging, Board bekommt Zeitraum-Ansicht mit CSV-Export, Loesch-Verbot fuer echte Laufdaten (Testkoerper markieren statt loeschen).

  • D-050-N1 (07.08. ~00:50, M): AN-/ABMELDE-PFLICHT fuer ALLES Temporaere — auch kurzfristige Tests, Debugs, READS und alle G-Werkzeuge mit Odoo-Zugriff: im Board (Registry) anmelden -> Laeufe loggen -> abmelden (Muster TESTKOERPER, von M ausdruecklich bestaetigt). Konsequenz morgen: G-READ wird als Werkzeug nachregistriert und loggt jede Lesung als Lauf; Registry braucht Kategorie/Flag (agent|werkzeug|test, is_test) — v0_9_12.
  • D-050-N2 (07.08. ~00:50, M): Board-DESIGN spaeter, FUNKTIONEN ZUERST ("alles zu statisch, geht in die richtige Richtung"). Ressourcen-Freigabe: Supabase PRO und Cloudflare PRO vorhanden — nicht sparen (Realtime, Edge Functions, Worker fuer Board v0.9.5 + status.w6web.app frei nutzbar).

D-052 (07.08.2026 ~09:30, M im Chat) — INCIDENT-DOKUMENTATIONS-PFLICHT

Wortlaut M: "Immer wenn ich Fehler finde, muss das mit Zeitachse etc. und Loesungsansaetzen, Ursache und Loesung dokumentiert werden, und was es verursacht hat — damit wir spaeter solche Events einfach handhaben koennen." Regel: JEDER von M oder einer Lane gefundene Fehler mit Betriebs- oder Kundenwirkung wird als Incident-Datei nach zulieferung/incidents/_TEMPLATE_INCIDENT.md erfasst (Zeitachse UTC+Berlin, Symptom, Ursachenkette, Ausloeser, Auswirkung, Loesungsansaetze [verworfene MIT Grund], gewaehlte Loesung, Rollback, Erkennungsrezepte fuer die Zukunft, Lessons, offene Folgepunkte). Erfassung durch den Akteur, der aufklaert (meist G); Ablage zulieferung/incidents/; T6-Library bekommt je Incident eine Seite (Sektion "Incidents"). Kleinbefunde ohne Wirkung bleiben B-Nummern in FREIGABEN. - D-053 (gleichzeitig, M): MENSCHEN-DOKU (MkDocs-Library) startet JETZT parallel als EIGENE LANE T6 — uebernimmt den w6-library-Stand aus T4-02 (GATE_1-Geruest); T6 ist der EINE Library-Schreiber. T4-02 wird geschlossen (Vermerk), T4 bleibt Eintausch.

D-054 (07.08.2026 ~09:45, M im Chat) — CREDENTIAL-GRENZE BLEIBT: KEIN Odoo-Key im Terminal/Schluesselbund

Wortlaut M: "Odoo-API-Key rein in den Schluesselbund: zu unsicher — wenn ein Terminal crashed und wir Schreibvorgaenge haben, ist das unsicher. Die Regeln zur Aufteilung wurden bisher so geregelt und bleiben so. Es funktioniert bisher gut." Regel (bestaetigt): Odoo-Credentials leben AUSSCHLIESSLICH in n8n-$vars/Credentials. Terminal-Lanes erhalten KEINEN Odoo-Schluessel — weder im Schluesselbund noch in Env/Dateien. Jeder Odoo-Zugriff laeuft ueber die n8n-Werkzeuge (Agenten, ADMIN, G-READ) mit deren Leitplanken und Board-Anmeldung. Konsequenz: Gs Freigabe "Variante A (Uebergang)" aus T1-03 vom ~09:20 ist WIDERRUFEN. B1-Erhebung laeuft stattdessen ueber den n8n-Leseweg (G/gread) nach T1s Query-Spezifikation; T1 bleibt Werkbank fuer Auswertung/Paketierung ohne Odoo-Zugriff. B-T1-1 (eigenes LESE-Konto) bleibt — aber als eigener Odoo-User fuer einen n8n-LESE-Credential, nicht fuers Terminal.

D-055 · 2026-08-07 · Buchhaltungs-Rahmen (B0) fixiert

M-Antworten (Wortlaut): "Steuerberater extern er nutzt Datev" · "Zeitraum ab 01.01.2026 alles nach möglichkeit, so genau wie möglich mit unserem limied scope" · "achtung laufender betriben nicht stören" · Zielbild: "nur internes Steuerungssystem, Vorsystem (liefert dem StB zu), irgendwann später führend, jedoch nicht diese noch näcstes jahr" · Eingangsrechnungen: "extern beim chef, soll auch so bleiben, wir können nur schätzungen anhand der kosten und der zugänge machen." Konsequenzen: (1) Odoo = internes Steuerungssystem + GoBD-Vorsystem (AR-Seite); fuehrend fruehestens 2028, kein Projektziel. (2) Projekt-Scope ab 01.01.2026; Alt-Zone davor nur kennzeichnen/abgrenzen, Eingriffe nur mit StB. (3) Eingangsseite bleibt extern (Chef/StB/DATEV) — F-003 umgewidmet von "Luecke fuellen" auf "OP-Herkunft klaeren + kennzeichnen"; Schaetz-Zulauf (Kosten/Zugaenge) optional spaeter. (4) B6-Abstimmung laeuft gegen DATEV-Auswertungen des StB (SuSa/BWA). (5) Betriebsauflage "laufenden Betrieb nicht stoeren" bestaetigt die Skill-Betriebsregeln (Schreibfenster, ein Paket, Vorschlagsmodus zuerst). Volltext: buchhaltung/w6-buchhaltung/docs/00_RAHMEN.md

D-056 · 2026-08-07 · Buchhaltungs-Ziele + Reihenfolge (ersetzt weiche Nutzen-Formulierungen)

M-Wortlaute: "Wir brauchen korrekte Daten für die umsatsteuer voranmeldungen, basierend auf den verkäufen, nach land getrennt." · "Wir brauchen eine GUV, ich habe theoretisch die Kreditkarten abrechnung ist ich buchen kann und wir haben ausgaben die über das konto laufen" · "wir brauchen eine bestand bertung." · "wir sind schon jetzt konfrm wir senden e-rechnungen jetzt, das müsste in der dokumentation sein. XML Aufbeahrung müssen wir noch regeln." · "Barverkaufe kasse haben wir nicht." · "wir wollen die dokumentation auch erstellen." · "wir wollen erstmal die buchhaltung richtig stellen, dann ankkonten abgleich, dass es auf die reichtigen konten kommt, e-rechnung laufen, können wir jedoch noch prüfen, dann können das sinnvoll locken." Ziele: Z1 USt-VA-Zulieferung aus Odoo-Verkaeufen NACH LAND · Z2 interne GuV inkl. Ausgabenseite (Kreditkarten-Abrechnung buchbar machen + Ausgaben ueber Bankkonto kontieren — Praezisierung zu D-055: Eingangs-BELEGE bleiben extern, Kosten-BUCHUNG fuer interne GuV kommt nach Odoo) · Z3 Bestandsbewertung · Z4 Verfahrensdokumentation. Reihenfolge: (1) Buchhaltung richtigstellen → (2) Bankkonten-Abgleich auf die richtigen Konten (B4) → (3) E-Rechnung verifizieren (laeuft laut M bereits; XML-Aufbewahrung noch regeln) → (4) Festschreibung ("sinnvoll locken", B7 zuletzt — deckt Katalog §9). Weitere Festlegungen: KEINE Kasse/Barverkauf → KassenSichV/TSE n.a. · Gate G2 gilt mit diesem Ziel-Entscheid als ABGENOMMEN.

D-057 · 2026-08-08 · Amazon-Waechter-Programm (Folge aus Incident B005DYM42A)

M: "ja das machen wir" zur Staffelung. R1 sofort: taegliche 2-Minuten-Routine Seller Central (Account Health + Fallprotokoll, Punkt in der Morgenlage) + M prueft/fixt Benachrichtigungs-Einstellungen (kritische Kategorien → amazon@w6-wertarbeit.de). R2 diese Woche: Bestell-Fluss-Anomalie-Waechter aus Odoo (n8n, read-only, je Tag×Kanal×Top-SKU, Alarm bei 0 im Erwartungsfenster) + Mail-P0-Waechter fuer als Mail eintreffende Warnungen. R3 Dauerzustand: SP-API-Listing-Waechter "amw" (stuendlich Status je ASIN, Issue-Notifications, Telegram-P0, Minuten-Latenz); M erzeugt einmalig LWA-Zugang nach zulieferung/amw/ANLEITUNG_SP_API_ZUGANG.md, Werte NUR in n8n (D-054). Jeder Waechter im D-050-Regime (Registry, ICP-Not-Aus, Board).

D-058 · 2026-08-08 · Eindeutige Uebergabeorte + Sprint-Anmeldung (FLEET_REGELN v1.5)

M-Anlass (Wortlaut gekuerzt): "die agenten muessen eindeutig sein, klar erkennbar, festes abholen von aufgaben, rueckgaben an eindeutigem ort und das zusammenspiel auf dem internen agilen plan; fleet regeln und github memory aktualisieren; github memory muss ueber mkdocs immer den live entwicklungsstand und ziele sichtbar machen." Entscheid — genau FUENF Orte (§1b): ABHOLEN = FREIGABEN-Kopfblock "AKTUELLER AUFTRAG" (nur G schreibt) · SPRINT-ANMELDUNG = Kopfzeile in comms/_AKTUELL.md (UEBERNOMMEN/ZURUECKGEGEBEN) · RUECKGABE = comms/_AKTUELL.md ueberschreibend mit §7-Meldekopf (status/ nur noch Heartbeat) · PLAN = planning/ROLLING_PLAN.md (nur G, Standup) · MENSCHEN-SICHT = mkdocs "Entwicklungsstand" (T6 spiegelt Plan + alle _AKTUELL automatisch je Build). SPRINTBOARD.md ersetzt (Stub). CLAUDE.md-Einstieg entsprechend. Skill github-agent-memory um Uebergabeorte/Sprint-Schicht erweitert (v3, an M geliefert). Rollout: Kopfbloecke in allen aktiven FREIGABEN gesetzt; Lane-Neustart-Prompts unveraendert (Kennung reicht — CLAUDE.md routet neu).

D-059 · 2026-08-08 · Live-Entwicklungsstand: mkdocs im fleet-ops-Repo, 1:1 und live

M-Wortlaut: "das entscheidende: es muss bei github, über mk docs die aktuellen stand der entwicklung für personen sichtbar sein! 1:1 und live" Entscheid: (1) Die mkdocs-Site lebt IM w6-fleet-ops-Repo (docs-site/ + mkdocs.yml, Zone T6) — dort liegen alle Quellwahrheiten; der fruehere w6-library-Repo-Blocker entfaellt fuer den Live-Stand (w6-library = spaetere kuratierte Ausbaustufe). (2) 1:1: Generator kopiert Quelldateien wortgetreu in die Site (ROLLING_PLAN → "Entwicklungsstand", comms/_AKTUELL → Lane-Seiten, DECISIONS, Incidents, FLEET_REGELN) — keine Redaktion, kein Handabschrieb. (3) live: Cloudflare-Pages-GitHub-Integration baut bei JEDEM Push auf main (Lanes pushen ohnehin nach jeder Runde → Site ist minutenaktuell). (4) privat*: hinter Cloudflare Access (Geschaeftszahlen!); oeffentliches GitHub Pages ausgeschlossen. T6-R1 entsprechend neu zugeschnitten und ENTBLOCKT.

D-060 · 2026-08-08 · GitHub Issues als M-Fehlereingang; Projects zurueckgestellt

M: "ich würde auch die fehler über github projects einreichen, geht es?" Entscheid: JA fuer Issues (github.com/thetha/w6-fleet-ops/issues): M reicht Fehler/Wuensche als Issue ein (auch mobil per GitHub-App); Abholung im Standup/der Abholrunde; G uebersetzt in F-Befunde bzw. FREIGABEN-Auftraege, antwortet im Issue, schliesst nur mit Beleg. NEIN (vorerst) fuer Projects-Boards: der Plan hat genau eine Wahrheit (planning/ROLLING_PLAN.md, D-058), sichtbar fuer Menschen ueber die mkdocs-Seite (D-059) — ein zweites Board waere Doppelpflege. Technik: gh fehlt auf der Cowork-Bruecke → Abholung via Mac-Lanes (einmalig brew install gh && gh auth login durch M, falls nicht vorhanden); Ausbaustufe: n8n-GitHub-Flow mit PAT NUR-Issues-Scope (D-054) meldet neue Issues automatisch.

D-061 · 2026-08-08 · Incident-Klassifikation + Status-Sicht aus GitHub; Alarm-Page nach Accounting

M: Incident-Historie muss auf der Status-Seite oeffenbar sein (Problem, Diagnose, Loesung, von wem), Incidents klassifiziert, CRITICAL zuoberst, Quelle GitHub; die (Alarm-)Status-Page kommt NACH Accounting; SP-API-Einreichung startet jetzt. Entscheid: (1) Pflicht-Kopfzeile in jeder Incident-Datei: Severity (CRITICAL/HOCH/MITTEL/GERING, Skala im Template) · Status (OFFEN/BEOBACHTEN/GELOEST) · Entdeckt/Diagnose/Loesung mit Akteur — Template + 3 Bestandsdateien nachgezogen. (2) T6-Doku-Sektion "Status & Incidents": Generator parst Kopfzeilen, CRITICAL+OFFEN zuoberst, Detailseite je Incident — 1:1 aus GitHub (D-059-Prinzip). (3) Die LIVE-Alarm-Status-Page (D-049: Ampeln, Jobqueue, Push) = neuer Plan-Strang 6, bewusst geparkt bis nach der Accounting-Phase (M-Reihenfolge). (4) SP-API: M reicht Entwickler-Registrierung jetzt ein (Anleitung zulieferung/amw/), R3-Bau nach Freischaltung + "drin"-Meldung.

D-062 · 2026-08-08 · ERSTES ZIEL: Live-Doku-Kreis (Morning Kickoff + Update-Befehl)

M-Wortlaut (gekuerzt): "ich will morning kickoff durchfuehren, dann werden einmal alle rueckmeldungen gezogen, mkdocs wird aktualisiert, dann kann ich ueber github zu der webadresse gelangen und sehe das entwicklungsboard. falls nicht, arbeite das ganze in unsere skills ein. das ist das erste ziel: live und up to date dokumentation. ich will auch via befehl mitten am tag ein update fahren." Entscheid: Kickoff-Zyklus verbindlich (FLEET_REGELN §7.6): "Morning Kickoff"/"Update" → G: Abholrunde + Plan rollen + Briefing → M: stehender Auftrag T-SYNC-PUSH (neu: ablauf/T-SYNC-PUSH_STANDARD.md, immer derselbe Prompt) → Push → Cloudflare baut → Website = Entwicklungs-Board aktuell. Fertig-Kriterium: Website zeigt den neuen Stand (bis T6-R1+Cloudflare live sind: GitHub-Dateiblick als Uebergang). Skill w6-morning-standup v2 (Befehle + Kreis) an M geliefert. ROLLING_PLAN traegt das ERSTE ZIEL im Kopf.

D-063 · 2026-08-08 · Dev-Setup-Abgleich mit Anthropic-Best-Practices; Wochen-Retro etabliert

Offizielle Claude-Code-Guidance gegen unser Setup gestellt (Volltext-Abgleich: zulieferung/W6_DEV_SETUP_EMPFEHLUNGEN_2026-08-08.md). Kern: Unser Datei-/Git-Protokoll entspricht der Empfehlungslinie (Skills statt CLAUDE.md-Bloat, Evidence-Pflicht, Explore→Plan→Code, Fresh-Context-Review, Parallel-Sessions). UEBERNOMMEN: w6push-Alias (headless claude -p fuer SYNC-PUSH) · Subagent-Review vor jedem Gate + Recherche-Subagents (§5) · ausfuehrbarer Check je Kopfblock · Worktrees bei Code-Parallelarbeit · Korrektur-Hygiene. ABGELEHNT/VERTAGT: Supabase als Dev-Koordination (bleibt Runtime-Gedaechtnis; Ergaenzung FLEET-MIRROR n8n→Board nach Accounting) · eigener MCP-Server (kein Engpass) · Agent-Teams-Feature (beobachten, Experiment nach Accounting) · Hooks (Retro-Kandidat). NEU §7.7: Freitags-Retro, max 3 belegte Verbesserungen/Woche → Regeln/Skills/Hooks; so fliessen Wochen-Learnings dauerhaft ins Setup (Ms Auftrag "uns selbst verbessern").

D-064 · 2026-08-08 · Mac-Umzug im laufenden Thread

M: neuer Mac; 100% Git-Commit, Uebergabe/Memory 100% korrekt auf Git, dann Setup — im gleichen Thread. Verfahren (docs/SETUP_NEUER_MAC.md): Phase 0 alter Mac (SYNC-PUSH bis git status leer + G-Bestaetigung mit SHA; Konto-Skills pruefen) → Phase 1-3 neuer Mac (CLT/brew/git/gh/node/iTerm2, gh auth, Claude Code, Desktop-App, Clone, Profile, w6push) → Phase 4 Abnahme im selben Thread (Ordner verbinden, "neuer Mac verbunden", G-Preflight ueber Bruecke, T2-Kennungstest) → erst dann Alt-Mac stilllegen. Nichts ausser Git+Konto wandert: Keys leben in n8n/Plattformen (D-054), Repo ist der Koffer. Bruecken-Rebind ist der einzige Testpunkt; Plan B dokumentiert (Thread bleibt cloud-seitig arbeitsfaehig, G-Schreibungen via Lanes).

D-065 (2026-08-09) — eintauschaktion-mehr-modell: Teil-2-Freigabe

M-Wortlaute: „sofort, ist sofort: der kunde ist jetzt bereit zu kaufen" → V8 = Webhook-Sofort-Trigger (Express-Angebot <1 min; Shared Secret nur n8n, HMAC-Pruefung, Dedupe, D-043-Leitplanken, eigener Schalter; Polling-Variante gestrichen). „R1. ok / R2 ok / R3 ok, das muss gespeichert werden, am besten in odoo, dafuer gibt es schon infos, er kann sich dann selbst drueber auch abmelden. / R4 ok" → R-3: Einwilligung/Widerspruch in Odoo inkl. Selbstabmeldung; Tabelle=Spiegel; Versand-Gate prueft Odoo; AP0 erhebt Odoo-Opt-out-Bestand (V9). „Sonntag nach Tag+5, 09:00 also es muss morgens kommen." → R2-Erinnerung 09:00, R1 = T+3 12:00; Klueger-machen-Logging bestaetigt. Offen: Modell-Liste (B) · Wortlaut-Einzelfreigaben · Rechtsblick R-2 · Startfreigabe AP0. Quelle: planning/PLAN_EINTAUSCH_MULTIMODELL.md Par.12.

D-066 (2026-08-09) — eintauschaktion-mehr-modell: Scope-Fixierung + Planungsmodus

M-Wortlaute: „Du Sollst nichts bei Jotform aufsetzen. wir aendern nur die Struktur auf eine Modulare, Wir arbeiten AB der Google Spread Sheet Tabelle BIS ODOO“ · „Jotform wird erst dann aufgesetzt, wenn es wirklich eine Eintauschaktion gibt. Wir BEREITEN es nur vor … das laeuft in die gleiche Google Spreadsheet Tabelle rein“ · „jedoch wollen wir alles vorbereiten und das neue Konzept auf die 868 und 868-S schon anwenden“ · „noch keinen Code schreiben! Es geht nur um die Planung der Entwicklung, dann die Einordnung des Projekts in unser Gesamtkonzept.“ → Baubereich = Sheet→Script→Mail→Odoo→EIA. Jotform ausschliesslich M (je Aktion, laeuft ins selbe Sheet); Jotform-Feld-Sync aus Par.13 gestrichen, _CONFIG/Mapping wird Ms Ablese-Vorlage. Umstieg MIT 868/868-S. Modus bis Baufreigabe: reine Planung (AP0-R1-Reads als Bestandsaufnahme gefahren, nichts veraendert). Einordnung: Strang 7, nach Odoo-Core. Quelle: planning/PLAN_EINTAUSCH_MULTIMODELL.md Par.14.

D-067 (2026-08-09) — Fleet: Worktree-Isolation + verstaerkte Ordner-Identitaet (A+C)

M: „die trennung muss absolut klar sein, dass es nicht zur einer vermischung kommt … welche optionen haben wir?" · Wahl im Frage-Dialog: „Worktrees + Ordner-Identitaet" · „ordner identität auch verstärken. recherciere online, dazu" · „also a+c und recherche". Recherche-Ergebnis (offizielle Claude-Code-Doku): native Worktree-Isolation wird von Claude Code selbst erzwungen (Blocks Richtung Haupt-Checkout inkl. git-Umwege); SessionStart-Hooks injizieren Identitaet automatisch (auch nach resume/compact); PreToolUse-Hooks koennen fremde Writes hart verweigern. → Vier-Schichten-Stack: Worktree je Lane · .lane+SessionStart-Hook · Zonen-Waechter (Stufe 2 nach G-Review) · Profil mit Startverzeichnis. Aktivierung NUR an sauberem Punkt (Mo, nach T2-Abnahme+Push); Skript verweigert sonst. Skill parallel-dev-fleet v2 geliefert. Quellen: code.claude.com/docs/en/worktrees + /docs/en/hooks. Dateien: ablauf/worktree-isolation/ · FLEET_REGELN Par.0c · CLAUDE.md-Sektion · PROMPTS v3 · ITERM2-Nachtrag.

D-068 (2026-08-09) — PPWR als eigener Entwicklungsstrang, Prioritaet nach Buchhaltung

M: "erfasse das projekt als PPWR das ist ein separates Entwicklung Projket das kommt nach Buchhaltung." → ROLLING_PLAN Strang 8: Odoo nur Pflege-Oberflaeche (Master GitHub+Airtable), kein Addon, keine Altdaten; Pakete P1–P3 geplant, Meldeauszug nach Weg 3 (rechnerisches FIFO, Stoerung keine). Artefakte: zulieferung/ppwr/ (Pruefantwort 1 + 2 + P1-Baublatt). Bau erst nach Accounting UND separatem Startbefehl "P1 bauen".

D-069 (2026-08-10) — PPWR-P1 startet PARALLEL zum Accounting · Lane T7 gegruendet

M: "P1 bauen" + "ich habe eine terminal agenten T7 PPWR vorbereitet" (nach G-Empfehlung: P1 ist rein additiv, beruehrt weder Buchungen noch Verkauf/Versand noch die B3/B4-Zone; PPWR-Leitstand hatte das Vorziehen notiert). Lockert D-068 NUR fuer P1; P2/P3 + Meldewege-Phase-B bleiben hinter dem Accounting. Vollzugsweg D-054-konform: T7 (Werkbank, kein Odoo-Key) liefert Manifest/Import-Vorlagen/Verifikations-Paket → G legt Modelle+Felder per gact an (auditiert, Allowlist-Erweiterung ir.model/ir.model.fields dokumentiert) → G-Verifikation per gread → M macht Studio-Platzierung (Phase B) → T7-Abnahme. Ablauf: ablauf/T7-01_ppwr/.

D-070 — Versand-Agent (VSA) als eigene Entwicklungslinie (2026-08-10)

Der Versand-Agent wird eigener Strang mit EIGENEM Board (versand.w6web.app), EIGENER Supabase und Sicherheitsstruktur identisch zu agents@w6web.app (Cloudflare Access, Secrets nur n8n/Plattform D-017/D-054, Kill-Switch w6.vsa.enabled, kundenwirksam=M-Klickweg). Aufgaben: DHL-Tracking-API Entstehung->Auslieferung, Stuck-/nicht-raus-Erkennung, Amazon-Geschwindigkeitsdaten je PLZ-Region (Prime/Standard-Lieferzeiten), Suchleiste, Odoo-Deeplinks + Daumen hoch/runter. Abgrenzung: VSA ueberwacht, behebt NICHT die Carrier-/Modul-Luecke (=Option A, separater Strang). Phasen P0 Monitoring read-only -> P1 Stuck -> P2 Speed/PLZ -> P3 Kundenkontakt. Spez: SPEZ_VERSAND_AGENT_v0.2.md (Chat geliefert).

D-071 — T8 Versand als eigene Lane (2026-08-10)

Der Versand wird eigene Lane T8 (Strang 9). Buendelt Carrier/Modul-Fix (A, config_w6-Planung) UND Versand-Agent (C, VSA — eigenes Board versand.w6web.app + eigene Supabase, D-070). Phase: nur Planung (M "erstmal planung"), kein Bau ohne Einzelfreigabe. Sicherheit = agents@w6web.app. FREIGABEN: ablauf/T8-01_versand/FREIGABEN.md. Werkbank T8 von M vorbereitet (analog T7).

D-072 — Compliance-Paket + Sub-Paket Garantielabel (2026-08-10)

W6 fuehrt ein Compliance-Paket (compliance/) als Sammlung von Richtlinien mit Evidenz + protokolliertem Testlauf; jede Richtlinie ein Sub-Paket. Erstes Sub-Paket: garantielabel/ (RICHTLINIE, EVIDENZ, TESTPROTOKOLL). Prinzip D-020 (Beleg statt Behauptung). Befund: vor Fix nur 2 von 19 Geraeten mit Label am product.template; 17 zu setzen; 6 ohne Label (M-Entscheid). Sequenz: Fix (M haengt Labels an, kundenwirksam) -> Test je Modell -> Log. Compliance-Paket wird erst nach echtem Fix+Test als "erfuellt" gefuehrt.

D-073 — Eintausch-Erweiterung aufgeteilt: Gratis-Wechsel + Paletten-Stand vorgezogen (2026-08-10)

M-Auftrag 10.08. abends: Die Erweiterung der Eintauschaktion wird AUFGETEILT. Vorgezogen vor Multimodell: (1) AP-G — Gratis-Beigabe zentral tauschbar (Garn W-G-0015 laeuft aus; nur der gratis[]-Teil aus §15, Preis/Schnaeppchen bleiben bis AP1 hart; Sofort-Bruecke definiert, falls der Bestand vorher endet), (2) AP-P — Paletten-Stand fuer die Werkstatt: Dashboard (aktuelle Palette setzen, Paletteninhalt sehen, Druckblatt, Recycling-Reiter; Felder Name/Vorname/Ankunft/Recycling/Tel/Mail) + base.automation bei Stufe->40 (Palette aus ICP w6.palette.aktuell + Datum in den Titel, idempotent) + EIA liest Palette vom Ticket (ein Schreiber). Stoerungsfrei-Prinzip Plan-§3 gilt fuer alle Teile; Bau weiterhin erst je M-Einzelfreigabe. Details + offene Entscheide G1-G5: PLAN_EINTAUSCH_MULTIMODELL.md §16.

D-074 — Entnahmestrategie: E-AB1 kaufmaennisch abgebildet (2026-08-13)

config_w6 bringt die eigene Entnahmestrategie priority mit, scharf auf allen 5 Lagerorten. M-Entscheid: kaufmaennisch abbilden — Ansage "alte Ware zuerst" per Zuruf an den Logistiker; removal_strategy_id wird NICHT angefasst. Die PPWR-Alt/Neu-Trennung laeuft ueber Bestandsarten (L1/L2/L3) und Kennzeichnung, nicht ueber die Kommissionierreihenfolge. Beleg: comms/odoo/BEFUND_LAGER_VORABPRUEFUNG_2026-08-13.md.

D-075 — Modul-Register als Pflichtwerk vor jeder Aenderung (2026-08-13)

M-Wort: Alle Custom-Module werden erfasst, dokumentiert und versioniert; jede Implementierungs-Aenderung wird VOR Umsetzung gegen das Register geprueft; je Modul ein eigenes Git, Sub-Repos nach SUBMODULE_PLAN. Stand register-1.1.0: 7 Module, Doku generiert (Doku ist erzeugt, nie von Hand), Pruefliste 13 Fragen (Q13: misst die Kennzahl das, was sie messen soll?), CI-Probe PASS. Upgrade-Reihenfolge: patches_to_server ZUERST (Minenfeld-Karte). Transfer: module_src/w6-odoo-modul-register_repo-1.1.0_2026-08-13.tar.gz.part00–02 (SHA-256 dfe588e5…, REASSEMBLE_ANLEITUNG.md).

D-076 — Projekt STAGING-HETZNER-TEST-PATCHES-REMOVE angelegt (2026-08-13)

Codename von M. Ziel: Auf Staging belegen, ob die 4 Server-Patches aus patches_to_server noch gebraucht werden (Hetzner-Ticket: postgres ist via UNIX-Socket erreichbar — die Manifest-Begruendung "no postgres maintenance DB" traegt nicht) und ob der Restart-Loop reproduzierbar ist (Befund queue_job_lock = 0 Zeilen). Stufen S0–S4 einzeln umkehrbar, Ergebnisse E1–E6, Zugang bevorzugt Weg A (Werkbank-Terminal, Schluessel bleibt bei M). START ERST nach V1–V5; V3 (Shopify auf Staging abgeklemmt?) ist die einzige echte Gefahrenstelle. Kein Schritt beruehrt die Produktion. Blatt: planning/PROJEKT_STAGING_HETZNER_TEST_PATCHES_REMOVE.md.

D-077 — Artikelsystematik W-/WS- verbindlich, Verkauf schlaegt Praefix (2026-08-13)

M-Klarstellung: W- = offizieller Shop-Artikel (268 aktive Vorlagen) · WS- = Ersatzteil zum Verbauen (1.097), kann gelegentlich an Kunden verkauft werden · numerisch = Maschinen-Stammartikel. Folge: "kein Verkauf in 24 Monaten" ist bei WS- der NORMALFALL — die echte Auslauf-Liste sind 10 W-Artikel, nicht 973 (Korrektur einer Governor-Fehldeutung; Zahlen stimmten, Deutung nicht). Fuer PPWR zaehlt nachgewiesener Verkauf, nicht das Praefix (135 verkaufte WS-Artikel sind meldewirksam-faehig); Vorschlag E-KOMP5 liegt beim Leitstand. Beleg: comms/odoo/KORREKTUR_ARTIKELSYSTEMATIK_W_WS_2026-08-13.md.