Leitstand G — aktueller Stand

1:1-Spiegel aus dem Repo

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

G_AKTUELL — rollender Governor-Stand

Stand: 06.08.2026 ~12:00 UTC (nach Abholung)

Kette heute vormittag (alles belegt)

• Fixpaket v0.9.3 LIVE: GRT-2 Lauf-Token-Lock (v0_9_7, Selbsttest t1–t7) · B-04 · B-05/GRT-5 je-Call-Rate · B-07/B-08 · B-09-Checks. Execs 7467/7469/7471, agent_locks leer. VKA-Draft v0.2.1 (inaktiv), EIA v0.2.1 published.
• T3 Runde 2 ENTSPERRT (Vermerk + V1–V5-Belege in T3-FREIGABEN) · T2 GATE 2 abgenommen, Runde 3 frei (Digest-Spez) · T5 Runde 4 abgenommen, B-T5-12/13 freigegeben, Lock-SQL + n8n-Katalog geliefert.
• Befund behoben: eia stage 1→2 — Chatter war seit Anlage dry-run-geblockt (exec 7466, 3× arrival:guard_block); 6219 registriert Palette 1/Platz 4; Chatter-Backfill der 4 Tickets mit v0.3.
• VKA-Messbetrieb gestartet: 40 Karten Backlog, Cursor 7371. Stuendlich erst nach M-Toggle.
• EIA v0.3 baubereit: Feld x_studio_entsorgbar_ab bestaetigt + Paletten-Zeiger-Regeln (D-041 2. Nachtrag: Feld gewinnt · Zeiger = hoechste Nummer · Nachzuegler ok · 25er-Deckel · Sprungwarnung).

G-NAECHSTES (Reihenfolge)

1. EIA v0.3 bauen (Scope + Nachtrag in docs/W6_EIA_v0.3_SCOPE.md): Migration v0_9_8 palette_next v2 · Feld-Writes (Palette manuell-Vorrang, Eingang, Recycling) · Feld↔Register-Abgleich · Entsorgbar-Rechner · Chatter-Backfill 4 Tickets · Angebots-Entwuerfe (B-11: je Schreib-Node eigener write-Guard) · Allowlist helpdesk.ticket write + sale.order-Erweiterung.
2. WD-Haertung (SPEZ v1.0 F1–F7, §3.1a, alert_seen, ICP-Spiegelung B-T5-08; synthetischer stale_run als Testkoerper — Lauf 1 existiert nicht mehr) → WD aktiv → T2-Vermerk → T2 Runde 4. Dazu ADMIN F8-Fix.
3. T3 Welle 2 auf T3-Zuruf (A/L/E; Wegwerf-Kopie genehmigt) · A6a/A6b im M-Fenster · danach Welle 2b (R1–R5).
4. GRT-5/GRT-2-Vertragstexte im MASTERREADME via T5.

Offen bei M

• Merge Core v3.1.1: cd ~/W6_GITHUB/w6-odoo-core && git checkout main && git pull && git merge --no-ff agent/T5-v20 -m "Core v3.1.1: v20-Plan + Registerspalte + Runtime-Pin v0.9.3" && git push → danach setzt T5 Tag v3.1.1.
• Kurzsignale: T3 (entsperrt) · T5 (Antworten+Katalog da) · T2 (Runde 3 frei).
• VKA stuendlich? → n8n → W6-VKA v0.2 → Toggle aktiv (Trockenlauf, schreibt nichts).
• NOT-AUS-Fenster 5 Min fuer A6a/A6b terminieren · Abendblock: Stufe-2b-Entscheid + G-02-Termin + Library-Sichttest. (Alias: verschoben per M-Entscheid, Absender bleibt info@ — D-035-Nachtrag.)

Merkposten Sicherheit/Rituale (unveraendert)

Secrets nie in Chat/Repo (D-017) · G committet NIE ueber die Bruecke (§0b; Lanes tragen G-Staende als Gedaechtnis:) · Live-Schalter/Merges/Toggles = M · D-020 Belege · Envelope w6.tradein.ticket.v1 unveraendert · „Alle offenen senden" tabu (Altbestand DONE).

Nachtrag ~12:10: EIA v0.3 LIVE + VKA-Takt LIVE

• EIA v0.3 published (5105bcb1) — erster Zyklus 10:03 UTC (exec 7478): Backfill vollzogen — 6212/6218/6219/6220 haben jetzt 📦-Chatter in Odoo (mail.message 2111170–2111173), Ticket-Felder geschrieben (Palette/Eingang), 4 Ankunftskarten. Migration v0_9_8 (palette_next2, Zeiger-Regeln) + Allowlist helpdesk.ticket write + amount_cap 500 aktiv. Idempotenz-Gegenprobe 10:18-Zyklus.
• VKA laeuft im Stundentakt — M hat den n8n-Toggle gesetzt; erster Trigger-Lauf 10:05 (exec 7482). Messbetrieb offiziell.
• Achtung Schalterlage: w6.vka.enabled steht seit Ms Board-Klick 09:52 auf 1 (gov_actions 16; Popup war die Doppelklick-Sicherung). Absprache D-011: 0 bis G-02 — M soll einmal ■ druecken; zweifach abgesichert solange (keine Schreib-Nodes + Stufe-1-Dry-Run), aber A7a braucht die 0.
• Klassifikation faengt echte Neueinsendungen: 6249–6252 (Krölls-Brandner 2x, Klingenberg, Hlavacek) als „wuerde anlegen"-Vorschlaege.

Nachtrag ~12:20: Gegenproben gruen + 522-Vorfall abgeraeumt

• EIA-Backfill VERIFIZIERT: 10:03-Zyklus (run 60) schrieb Chatter (mail.message 2111170–2111173) + Ticket-Felder + 4 Ankunftskarten (Jobs 77–80); 10:18-Zyklus (run 62) still auf dem Ankunftspfad = idempotent, Felder sitzen. Odoo um 10:18 wieder normal.
• 522-Vorfall: VKA-Erstlauf im Stundentakt (exec 7482, run 61) starb 10:06 an Cloudflare 522 (Odoo-Origin ~30 s weg) am ungeschuetzten Node „Auftrag per Nummer" — exakt die B-09/B-03-Klasse. Abgeraeumt: run 61 als error nachgebucht, Cursor auf 7521 (Jobliste 7376…7521 = 11 als Beleg), Stale-Lock geloescht. Gehaertet + published: VKA v0.2.2 (onError auf allen drei Odoo-Suchen + Gate „Odoo ok?" → sauberer Abbruch mit E3-run_end, Cursor lueckenlos, Token-Release) · EIA v0.3.1 (onError/alwaysOutputData auf den vier Odoo-Lesern). Naechster VKA-Lauf 11:05.
• Klassifikation faengt weiter echte Einsendungen (run 60: 4 neu 6249–6252 · run 62: 1 weiteres).
• Weiter offen bei M: ■ auf der VKA-Kachel (w6.vka.enabled steht seit 09:52 auf 1; Absprache: 0 bis G-02).
• G als Naechstes: EIA v0.3b (Angebots-Entwuerfe + Partner-Anlage mit B-11-Guards, amount_cap 500 — Grundlage fuer den Abend-Entscheid Stufe 2b), danach WD-Haertung.

Nachtrag ~12:40: EIA v0.3b LIVE — Angebots-Entwuerfe laufen

• v0.3b published (82653a46, 68 Nodes): bei E-OK-MATCH/E-OK-NEU legt der Agent automatisch den sale.order-ENTWURF an (1x W-NM-868/-S zu 399 = 549-150 + 4x W-G-0015 zu 0; client_order_ref W6TI:; NIE senden); bei E-OK-NEU vorher res.partner aus dem Envelope (D-005). B-11: eigene Guards vor Partner- und Angebots-Anlage; amount_cap 500; Doppel-Schutz per client_order_ref-Suche; Allowlist eia +res.partner create +sale.order create (8 Eintraege).
• Erster Live-Zyklus = Beweis (exec 7486, run 63): 6 klassifiziert · 5 Entwuerfe NEU · 3 Kunden angelegt (Kroells-Brandner, Klingenberg, Berninghausen). Kette bewiesen: 6250 legt Kundin an → 6252 (2. Einsendung derselben Kundin) matcht sie mit 190 P. und bekommt eigenen Entwurf. Echter D-025-Fund: Hlavacek 2 Konten mit gleicher Mail → aeltestes genommen, Dublettenverdacht auf der Karte. 6253 MULTI korrekt OHNE Angebot. Cursor 6254, Locks leer.
• Cursor-Replay 6249–6253 bewusst (Karten 93–98 ersetzen inhaltlich 73–76/92 — jetzt mit so_state/Link).
• Backfill der 21 aelteren Einsendungen (6223–6248) WARTET auf Ms Draft-Sichttest (Kommando: M sagt „Angebote nachfuellen" → G setzt Cursor schrittweise zurueck, ~7 Tickets je Zyklus wegen Rate).
• G-NAECHSTES: WD-Haertung (F1–F7, Schwellen aus Policies, alert_seen, ICP-Spiegelung, synthetischer stale_run) → aktivieren → T2-Vermerk. Danach Entsorgbar-Rechner (v0.3c) + T3-Welle-2-Zurufe.
• M offen: ■ VKA-Kachel (vka=1 seit 09:52) · NOT-AUS-Fenster · abends: Draft-Sichttest → „Angebote nachfuellen" + Stufe-2b-Entscheid + G-02-Termin.

Nachtrag ~12:55: Abholung 2 verarbeitet · Board-Fixes · B-12 live

• Board-Befund M behoben: Karten-Links liefen auf /odoo/<pfad>/<id> ins Leere → alle Link-Bauer auf /web#id=…&model=…&view_type=form umgestellt (EIA v0.3b-fix1 + VKA v0.2.3/4, beide published) UND Bestandskarten per CP-Update nachgezogen (45 EIA- + 51 VKA-Links + Angebots-Links). Haken auf Karte = ack_job („gesehen" → Erledigt), reine Board-Buchhaltung.
• T2: GATE 3 abgenommen; F10=(a) live lesen, F12=ehrliche Kennzeichnung; Digest-Bau folgt im WD-Block. T3: GATE_2; V6 geliefert (Backlog korrekt streng: B3/B4/B6-Gruende, RINV-Hinweis); B-12 (vorkasse_kandidaten), B-14, B-15 in VKA v0.2.4 published. Welle 2 heute Nachmittag nach WD. T5: v3.1.1 versiegelt; v3.1.2 (P0-Katalog) wartet auf M-Merge; sql 0005/0006; K-01 an M. T4: Library Runde 1 laeuft, noch keine Meldung.
• Schalterlage: gov_actions 17 = ERNEUT enable_agent(vka) via Board 10:42 — M drueckt ▶ statt ■; Klaerung im Chat. vka=1 aendert nichts am Trockenlauf (doppelt gesichert), aber D-011-Disziplin + A7b wollen 0.
• G JETZT: WD-Haertung + GOV-Digest (ein Block): F1–F7, Schwellen aus Policies, Einzel-Signaturen, alert_seen, ICP-Spiegelung B-T5-08 (WD schreibt Werte in CP), synthetischer stale_run, Digest 07:30 nach SPEZ_GOV_DIGEST (F10a/F12) → WD aktivieren → T2-Vermerk → T2 Runde 4.

Nachtrag ~13:15: WATCHDOG LIVE (Tagesziel 5 ✅) · DHL-Entscheid · Board v0.9.4 beauftragt

• W6-WD v0.2 AKTIV (+ GOV-Digest 07:30 als zweite Kette, Europe/Berlin): Einzel-Signaturen, 24h-Dedupe (fail-open), Schwelle je Agent, Auto-Disable via ADMIN mit woertlicher Eskalation, ack nach Versand, ICP-Spiegel je Lauf (v0_9_9/v0_9_10). Erster Lauf exec 7515 gruen: agents=1, vka=0 (Ms ■ in Odoo bestaetigt), eia=1, bma=0 — 0 Befunde, keine Mail. Erste Lagemeldung morgen 07:30.
• T2 Runde 4 FREI (Vermerk „WD gehaertet + aktiv" steht) · T5 Runde 5 beauftragt: Board v0.9.4 (Schalterlage an der Kachel + Sofort-Anzeige nach Klick + Erfolgsmeldung — M-Wunsch).
• K-01/DHL: M-Entscheid v6A=produktiv. Deaktivierung v3/v4/v5 via MCP NICHT moeglich (Alt-Workflows ohne MCP-Freigabe) → M schaltet 3 Toggles in der n8n-UI (oder gibt MCP je Karte frei).
• Abend-Checkliste M: NOT-AUS-Fenster (A6a/A6b) · 2 Angebots-Entwuerfe ansehen → „Angebote nachfuellen" · Stufe-2b-Entscheid · G-02-Termin · DHL 3 Toggles.
• G danach: T3 Welle 2 (A/L/E) · ADMIN-Feinschliff (F7 Sticky + F8 Audit-Reihenfolge) · Entsorgbar-Rechner (v0.3c) · Offer-Backfill nach M-Sichttest.

Nachtrag ~13:25: „Naechster Tag vorgezogen" — VKA v0.4 (Stufe-2-Kette) GEBAUT + published

• VKA v0.4 live (db9a0313, 64 Nodes): komplette Stufe-2-Kette nach Spec v0.2 §2/§4 — Marker-Idempotenz [W6-VKA] auf der Bankzeile → amount_cap-Deckel (500) → action_confirm (nur draft/sent) → Rechnung via sale.advance.payment.inv (delivered, context active_ids) → Rechnung finden → action_post → partner_id auf die Bankzeile → Chatter beidseitig inkl. Marker → Outcome „S2 solved_prepared · INV…". Jeder Schreib-Node mit eigenem GRT-1-Guard (B-11; Confirm/Wizard/Post/Zeile einzeln, write_counts). Reconcile NIE. Doppelt inert: stage=1 (dry_run) + vka=0 — Karten zeigen kuenftig „Kette bereit (dry-run)" bei S2-Faellen. Allowlist vka um Stufe-2-Methoden erweitert (8 Eintraege). Sammel-Aktivitaet (O4) kommt bei Scharfschaltung.
• Beleg: run 68 (exec 7519) gruen; Backlog komplett gescannt (Cursor 8395 = Ende, die Stundenlaeufe 12:05/13:05 liefen sauber allein). B-12-Zaehler arbeitet (vorkasse_kandidaten in findings).
• Scharfschaltung Stufe 2 braucht: Messwochen-Daten (laeuft) + M-Freigabe im Core (Spec §7) + G-02 (vka=1) + Entscheid Aktivitaets-Zuweisung (Spec §10: welcher Verkaufs-Nutzer?) + Bank-Sync-Frequenz (ir.cron 23 / PSD2 — sonst bleibt Latenz 12 h egal wie schnell der Agent ist).
• Abholung 13:20: KEINE neuen Lane-Meldungen — T2/T3/T5 stehen im STOPP und warten auf Ms Kurzsignale (T2 → Runde 4 Testalarm · T3 → Welle-2-Zuruf · T5 → Board v0.9.4 + Merge-Folge), T4 baut still an der Library.

Nachtrag ~13:50: Nacharbeits-Sturm automatisiert abgeraeumt (D-042) · EIA v0.3c-2 live

• M-Befunde in Serie: S-Preis falsch (399 statt 349) · manche Entwuerfe defekt · Kunde fehlt am Ticket · Land fehlt am Kunden („Missing required fields") · Frage nach Korrektur-Mechanismus. Antwort: EIA v0.3c-2 (30243bc8): Festpreise 399/349, Selbstreparatur je Entwurf (Positionen+Preis), Land DE/AT aus Angabe/PLZ (res.country zur Laufzeit), Kunde→Ticket-Write, alles hinter B-11-Guards; Allowlist eia jetzt 9 Eintraege (+sale.order write, res.partner write).
• Sweep (Cursor-Rewind 6222, Laeufe 70/71, execs 7524/7581): 32 Tickets neu durchgezogen — 21 Entwuerfe NEU (alle 349/399 korrekt, Kunden mit Land angelegt), 5 REPARIERT (u. a. S37665/74/76 Preis 399→349; S37664 zurueck auf 399 — M hatte die Normalvariante beim Nacharbeiten auf 349 gesetzt), Rest „in Ordnung · 2 Positionen", alle Tickets am richtigen Kunden. Keine leeren W6TI-Entwuerfe mehr vorhanden. Cursor 6260, Locks leer. Einsendungen laufen parallel weiter rein (6255–6260 direkt korrekt).
• D-042 verankert: Korrektur = Selbstreparatur-Pfad + Cursor-Rewind durch G, Befund auf Karte/Log. 3. Nachtrag D-041: Festpreise + Datenpflege-Hinweis (Odoo-Listenpreis 868-S steht auf 549 statt 499 — M korrigiert gelegentlich am Produkt).
• Offen M: Listenpreis 868-S in Odoo · DHL 3 Toggles · Kurzsignale T2/T3/T5 · Abend: NOT-AUS-Fenster, Stufe 2b, G-02. Offen G: Entsorgbar-Rechner (v0.3d) · T3 Welle 2 · ADMIN-Feinschliff.

Nachtrag ~14:00 — EIA v0.3d LIVE: Entsorgbar-ab-Rechner (D-041 KOMPLETT)

• EIA qbFWK43P5O7BRPKx published: activeVersionId 71c39b80, 110 Nodes, Timezone Europe/Berlin, Name -> "W6-EIA Eintausch-Agent v0.3d Stufe 1+2".
• Neue Kette 3 "Taeglich 0530 Rechner" (taeglich 05:30 Berlin): Tickets Stufe "Eingetroffen" -> Auftrag je Ticket (client_order_ref W6TI:, state sale/done) -> Soll berechnen:
• Recycling JA -> Eingangsdatum
• Kauf bestaetigt -> Auftragsdatum + 30 WERKTAGE (Mo-Fr)
• sonst -> Eingang + 84 Tage
• FELD GEWINNT (Paletten-Muster): Rechner befuellt x_studio_entsorgbar_ab NUR wenn leer. Manuell gesetzte Daten werden NIE ueberschrieben; Abweichung ist!=soll wird im run_end gemeldet (outcomes.P2 + Ticket-IDs bis 5), nicht angefasst.
• Schutz: eigener B-11-Guard vor dem Write (mode write, ids, write_count) - Lauf-Token-Lock lane:eintausch (ttl 5) - Rate p_n=2 - Skip-/Geblockt-Pfade mit run_end + Lock-Release.
• Erster Lauf: morgen 05:30. Ergebnis in Ms Odoo-Ansicht "Zu entsorgen" (ANLEITUNG §4). Heute nur Struktur-Verifikation - Multi-Trigger-Workflow ist per MCP nicht selektiv ausfuehrbar; D-020-Beleg (Execution + run_log) folgt nach Erstlauf.
• D-041 damit KOMPLETT: Recycling-Feld + manuelle Palette/Zeiger + 25er-Deckel + Sprungwarnung + Paletten-Board + Entsorgbar-Rechner.

Nachtrag ~14:30 — T3 WELLE 2 (A+L+E komplett, S teilweise) + ADMIN v0.2 (F7/F8)

• Welle 2 per test_workflow-Pin-Harness am ECHTEN GRT-1/VKA — kein CP-Muell, keine WD-Alarme. Block A 10/10 (execs 7606-7622, inkl. Kill-Switch-Matrix-Logik A6a/b-H und E3-H fail-closed) · Block L gruen (v0_9_7: G2:held/not_holder/token_required, agent_locks leer) · Block E: E1 7623 rate_rpc_failed, E2 7624 run_start_failed (522-Fall beherrscht), E-Lock 7625, E3 statisch · Block S: S1 5/5 Schreib-Guards einzeln bei echtem vka=0, S2 Allowlist-Abgleich + reconcile-Negativ 7630, S8 statisch. Details+Belege: ablauf/T3-01_vorkasse/FREIGABEN.md (G-VERMERK ~14:20). Offen: S3-S7 (naechstes Paket), A6a/b LIVE im M-Fenster (abends), R-Faelle ab Messwoche.
• ADMIN v0.2 LIVE (145fd938): F8-Reihenfolge (404 ohne Audit-Zeile und ohne Dedupe-Falle; Dedupe weiter VOR dem Odoo-Write) + F7-Sticky + Nachfix gov_act-Body pfadfest. T2 um 404-Retest in Runde 4 gebeten.

Nachtrag ~15:15 — Abholung + Antworten: F14-Fix live · WD v0.2.1 · VKA v0.2.5 · GATE_5 abgenommen · Testalarm scharf

• T2: F14 (schwer) serverseitig gefixt (Migration v0_9_11, Belege in T2-FREIGABEN ~15:10) · F15–F19 in WD v0.2.1 (1ba39157) · Testkoerper wdtest/run 79 AKTIV, w6a_state listet stale_run — Runde 4 FREI, naechster WD-Takt erzeugt die TESTALARM-Mail an M (angekuendigt).
• T3: GATE_2b beantwortet — (a) Welle 2 gefahren · (b) B-16 eingebaut (VKA v0.2.5: state-Filter draft/posted + Gutschrift/Storno-Text) · (c) Block S = Voraussetzung Stufe-2-Freigabe · (d) Abbruchgrund-Eimer in outcomes/findings. A7a formal belegt (7607).
• T5: GATE_5 (Board v0.9.4) ABGENOMMEN (Vorbehalt M-Sichttest) · duplicate!=Erfolg bestaetigt · SQL-Wortlaute v0_9_8–v0_9_11 geliefert (ANLAGE, Nummerierungs-Empfehlung 0007–0010) · v0_9_8-Raetsel geloest (Paletten-Zeiger).
• T4: B18 entschieden (Verhalten lassen, BLOCKED ist fail-safe; Doku-Satz) · T4-02 Runde 1 laeuft.
• T1: beide Vorschlaege als D-020-Nachtrag uebernommen; 404-Heuristik ausdruecklich NICHT ins Playbook.
• Bruecke war ~14:35–15:25 mehrfach offline; alle Pending-Nachtraege sind hiermit nachgetragen.

Nachtrag ~15:45 — Block S KOMPLETT (S3–S7) · Testalarm-Zyklus D1–D4 belegt · F20 gefunden+gefixt (WD v0.2.2)

• Block S: S3 (7680 Deckel-Sperre) · S4 (7682: Plan ok -> echter Guard-Stopp, Sub 7684; kein Schreib-Node lief = S7-Laufzeitbeleg) · S5 (7685 Marker-Sperre vor jedem Guard) · S6 (Statik + Liegenbleiber-Beschreibung + Folgelauf-Schutz 7687: draft-Rechnung -> B6-Karte, keine Verdopplung) · S7 (statisch + 7682). Details: T3-FREIGABEN ~15:40. Block S damit KOMPLETT (S1/S2/S8 waren ~14:20).
• Testalarm: 15:00-Takt 7672 = D1 Befund + D2 Mail an M + D3 Ack (gov_actions id 22) — aber Lauf ROT: F20 (ack_alert-Node parste text/plain als JSON; neverError faengt Parse-Fehler nicht). Fix WD v0.2.2 (3fe4be51). 15:30-Takt 7741 GRUEN: Befund erkannt, Dedupe true, KEINE zweite Mail = D4. D5 (Abraeumen wdtest/run 79) auf T2-Zuruf.
• VKA v0.2.5-Eimer: erster Stundenlauf nach Publish liefert outcomes {B3,B4,B5,B6,mehrdeutig,S2,kein_bezug}.

Nachtrag ~15:55 — AUFTRAEGE geschrieben (Ms Zuruf: "Auftraege fuer die Agenten")

• T2 Runde 4b (FREIGABEN ~15:55): Auswertung D1–D4 + eigener 404-Retest + Scharfproben nach Wahl (F20/F14/F17 — Koerper legt G) + D5-Abraeumen auf Zuruf.
• T3 Runde 2c (FREIGABEN ~15:55): Welle-2/Block-S-Wertung + Tote-Host-Entscheid + ANLAGE v0.5 + Messwochen-Plan (Eimer laufen, run 81) + Runde-3-Checklisten-Entwurf.
• T5 Runde 6 (FREIGABEN ~15:55): sql/0007–0010 aus der ANLAGE + G-02-Protokollvorlage + Library-Link auf T4-Zuruf.
• T4: laeuft (T4-02 R1), nur B18-Doku-Satz-Vermerk. T1: idle, bewusst kein Beschaeftigungsauftrag — naechster Einsatz bei Infrastruktur-Bedarf (z. B. G-02-Tag).
• Systemkontrolle ~15:50: EIA-15-min-Takte gruen (7663–7754) · VKA-Stundenlauf 7677 gruen auf v0.2.5, Eimer-Struktur live (run 81) · WD 7741 gruen · Locks leer · wdtest-Testkoerper aktiv (gewollt).
• Kurzsignale fuer M: T2 · T3 · T5 in die jeweiligen Terminals; T4 braucht nichts.

ABEND-AGENDA 06.08. (M+G, ~25 Min — Vorschlag G, ~16:05)

1. Kurzsignale (2 Min): T2 · T3 · T5 in die Terminals. T4 laeuft, T1 idle.
2. M-Sichttest Board v0.9.4 (3 Min): Kacheln zeigen AN/aus + "laut Spiegel von HH:MM" (EIA=AN, VKA/BMA=aus). wdtest-Kachel = Testkoerper, ignorieren. Zum Testen NICHT auf die Schalt-Knoepfe klicken.
3. NOT-AUS-Fenster (5 Min, Vorschlag 20:00–20:06): M setzt w6.agents.enabled=0 (Odoo-Systemparameter) um 20:00 -> der 20:03-EIA-Takt und der 20:05-VKA-Takt MUESSEN geblockt enden (G1:kill_switch(global)) — G sichert die Belege (A6a/b LIVE) -> M um 20:06 zurueck auf 1 -> G bestaetigt Folge-Takte gruen. Nebenwirkung: ein Klassifikations-Takt pausiert, naechster holt nach.
4. Entscheid Stufe 2b (Auto-Versand Angebots-Entwurf bei Maschinen-Ankunft): Qualitaetsbild seit Sweep sauber (21 neu korrekt, 5 repariert, 6255–6260 direkt korrekt, keine leeren Entwuerfe). Optionen: (a) JA ab morgen mit D-024-Sicherungen (nur eindeutiger Match, Betragsdeckel, Palette+Eingang gesetzt; Absender info@ per D-035 ok) · (b) eine Beobachtungswoche · (c) nur E-OK-MATCH. G-Empfehlung: (b) oder (c) — erst die 05:30/07:30-Beweise von morgen sehen.
5. G-02-Termin: Vorschlag Do 13.08. abends (dann 7 Mess-Tage mit v0.2.5-Eimern; T3s Runde-3-Checkliste liegt bis dahin).
6. DHL-Toggles v3/v4/v5 aus (n8n-UI) — K-01 schliessen. 7. Listenpreis 868-S -> 499 (Produkt 12059).
7. Danach G: Abschluss-Abholung + TAGESPLAN 07.08.

Nachtrag ~16:25 — Abholung 2: T2-4b bestaetigt · T3-2c fertig (E4 nachgefordert->gefahren) · T5-GATE_6 ab · 6219 geklaert

• T2: alle G-Vorbelege eigenstaendig bestaetigt, F8-404-Retest sauber (id-14-Vorher/Nachher), F16-Waechter reicht. Kombinierte SCHARFPROBE aktiv (runs 85/86 stale + 87-89 error, wdtest): naechster WD-Takt = EINE Mail mit 3 Befunden (F14/F16/F17/F20 in einem Zyklus), uebernaechster still. D5 danach auf T2-Zuruf.
• T3: 26 TESTLOG-Zeilen BESTANDEN · Beweisklassen L/H/S eingefuehrt · E4 nachgefordert und von G gefahren (exec 7786): Odoo-522 im Zeilenpfad -> status error, Cursor rueckt NICHT ueber die gescheiterte Zeile (money-relevant), Release ok · A6a/b: Harness reicht, NOT-AUS-Fenster nur noch Betriebsprobe (Vorschlag: am G-02-Tag, T5s Verfahren verlangt sie eh) · Messwoche: 3 SELECTs taeglich ab morgen, >=20 Kandidaten + >=5 Tage, Abbruch bei 1 falsch-positivem S2 · R3 bereits belegt (run 81) · Live-Empfehlung Stand: technisch nah, aber B2/B3-Daten fehlen + C3/C4 offen.
• T5: GATE_6 ABGENOMMEN — sql/ 0007-0010 komplett+wortgleich, G-02 als Verfahren (NOT-AUS-Gegenprobe Pflicht, Testreste namentlich). B-T5-14 bestaetigt -> T5 passt SETUP §8 an. v3.1.2-Merge weiter bei M.
• T4: 6219 aufgeklaert (P1/S4 am Morgen gezogen — zeitversetzt, keine Luecke; Antwort in T4-FREIGABEN).
• ABEND-AGENDA AKTUALISIERT: Punkt 3 (NOT-AUS 20:00) ENTFAELLT als Pflicht — T3 wertet Harness als ausreichend; NOT-AUS wird Betriebsprobe am G-02-Tag. DAFUER NEU als M-Entscheide: C3 Aktivitaets-Zuweisung (welcher Odoo-User bekommt die Vorkasse-Aktivitaeten/Sammel-Aktivitaet, Spec §10 — ohne Empfaenger laeuft A4 ins Leere) und C4 Bank-Sync-Frequenz (ir.cron 23, PSD2-Rahmen: heute bis 12 h Latenz, Spec-Ziel <1 h — Entscheid ueber Frequenzerhoehung). Beide VOR Stufe-2-Freigabe. Rest der Agenda unveraendert (Board-Sichttest, Stufe-2b, G-02-Termin Do 13.08., DHL-Toggles, Listenpreis 868-S).

Nachtrag ~16:30 — Scharfprobe DURCH in einem Takt (exec 7788 GRUEN)

EINE Mail mit 3 Befunden an M · 79 vom Dedupe geschluckt (4->3) · F17-Zeile woertlich, targets leer, kein ADMIN-Call · DREI Acks alle ok (F14 echt) · Lauf gruen (F20 echt). T2 kann auswerten, danach D5.

Nachtrag ~16:45 — Ms Bank-Matching-Screenshot: VKA-Sicht vollstaendig + Regel-Review vorbereitet

• Alle 21 sichtbaren Bankzeilen sind vom VKA laengst klassifiziert (Karten 105-150, Betraege 1:1 gematcht): 1x S2-KANDIDAT (HENN S34742, 16,45 — "wuerde vorbereiten", Karte 134) · 2x B4 Amazon-Ausschluss (Zapf S37512 Karte 144, Kuntze S34186 Karte 133) · 3x "mehrere Kandidaten" bei gleichpreisigen Auftraegen (Rothe 10,45: 4 Kandidaten · Hein+Meyer 99,95: 5 Kandidaten) · 13x N0 kein Kandidat (Payouts Stripe/PayPal/Klarna — korrekt, nicht VKA-Gebiet) · Bankentgelt negativ (VKA filtert amount>0).
• Odoo-seitig passiert nichts, WEIL doppelt inert (vka=0 + stage 1) — M-Entscheid bis Messwoche/G-02. Scharf haette die Kette bei HENN Auftrag bestaetigt + Anzahlungsrechnung erzeugt/gebucht + Partner gesetzt.
• Regel-Review (Ms Wunsch): Neuer read-only Leseweg W6-G-READ Odoo v0.1 [DEV] (WqOHKLzjS5GglU4H): Abgleichsmodelle + ir.cron 23 (C4-Faktenbasis). BEFUND dabei: n8n-Variablen sind PROJEKT-gebunden — der Workflow landete im personal-Projekt, $vars leer (key_len=0, Var-Check D-017-konform nur Laengen). M-Handgriff: Workflow in das Projekt der uebrigen W6-Flows verschieben (vermutlich "W6 WERKSTATT -PRODUCTION-"), dann liefert G die Regel-Bestandsaufnahme nach. Merken: kuenftige G-Workflows direkt im richtigen Projekt anlegen lassen (MCP legt in personal an).
• Auffaellig im Screenshot fuer den Review: zwei Stripe-Zeilen vom 06.08. zeigen "Reconcile 2" statt des "W6 Stripe Payout"-Knopfs — Kandidat fuer "manche Vorschlaege klappen, andere nicht".

Nachtrag ~17:05 — REGEL-BESTANDSAUFNAHME Odoo Bank-Matching (G-READ exec 7816) + Cron-Fakten (C4)

18 Abgleichsmodelle (8 Odoo-Standard ohne Match-Kriterien + 10 W6-eigene vom 30.07., alle Journal 13/Bank): - Nur EINE bucht automatisch: id 26 "W6 Umbuchung Hauptkonto DE76" (trigger auto_reconcile, contains "Umbuchung"). ALLE anderen sind Knopf-Vorschlaege (trigger manual) — der Backlog raeumt sich konstruktionsbedingt nur per Klick. - Muster: Bankentgelte 27 (regex entgelt/abschluss/kontofuehrung/gebuehr/ust) · PayPal 28 (PP.5601) · Klarna 34 (klarna|EREF: 019hex) · Amazon 29 (amazon|SLR...) · Stripe 30 (contains STRIPE, seq 50) · Shopify 31+33 (!) · eBay 32 (T19345728.) · Hetzner 35. - BEFUND R-1: Shopify-DUPLIKAT. id 31 UND id 33 heissen beide "W6 Shopify Payout", beide aktiv, beide sequence 60; 33 matcht zusaetzlich EREF: 019[0-9a-f]{20,} — DASSELBE Muster steht auch in Klarna 34 (die Klarna-Zeile im Screenshot traegt genau so eine EREF). Kollisionsrisiko + Doppelpflege. Empfehlung: 33 deaktivieren, 019-EREF-Muster nur in EINER Regel (oder raus — zu generisch). Odoo-Aenderung = M. - Warum "manche Vorschlaege klappen, andere nicht": (a) Zeigt Odoo "Reconcile N", hat sein EIGENES Rechnungs-Matching Kandidaten gefunden — das verdraengt den Payout-Knopf in der Anzeige (die zwei 06.08.-Stripe-Zeilen). (b) "SHOPIFY EREF"-Zeilen bekommen den STRIPE-Knopf, weil das Label mit STRIPE beginnt und seq 50 < 60 — wenn Shopify-Umsaetze in den Stripe-Topf sollen, richtig; wenn getrennt, Regel schaerfen. (c) Zeilen ohne Muster (Hein "No Description") -> Set Partner/Set Account = kein Regel-Treffer, korrekt. - ir.cron 23 (C4-Fakten): "Account: Journal online sync", AKTIV, alle 12 h, naechster Lauf 21:50 UTC. Heute also 2 Bank-Abrufe/Tag. PSD2-Rahmen erlaubt typischerweise 4 unbeaufsichtigte Abrufe/Tag -> 6-h-Takt ist die realistische Sofort-Verbesserung; <1 h braeuchte Anbieter-Push/Webhooks. Abend-Entscheid M. - G-READ Odoo v0.1 funktioniert (nach Ms Projekt-Verschiebung; Odoo-19-Befund: account.reconcile.model hat kein rule_type mehr — trigger/can_be_proposed sind die neuen Felder).

Nachtrag ~17:05 — Abholung 3: T3 technisch GESCHLOSSEN (28/28) · T4-02 GATE_1 ab · Library live

• T3: E4+R3 gewertet, ANLAGE v0.5 Fassung 2 — 28 Zeilen BESTANDEN, 0 Nachforderungen, 1 offen nur G-02-Gegenprobe am echten Datensatz (bauartbedingt). k>0-Frage elegant via 7471 geschlossen, Wegwerf-Kopie entfaellt endgueltig. done-Annahme von G woertlich bestaetigt. G-02 Do 13.08. realistisch (Vorbehalt >=20 Kandidaten).
• T4: T4-01 geschlossen (f8e8f43) · T4-02 R1: w6-library LIVE (dbf7782, v0.1.0, mkdocs strict 13 Seiten) — GATE_1 ABGENOMMEN, R2 frei · T5-Zuruf Library-Link ergangen.
• T2/T5: unveraendert wartend (T2 wertet Scharfprobe 7788 in naechster Runde).

Nachtrag ~19:30 — Ms Zulieferungen (Parallel-Thread) + 4 neue Entscheide D-044–D-047

• Zulieferung: INCIDENT 04.08. Backorder-Regression (ZU; create_backorder ask->always Typ 2/32/34, Custom-Code-Befunde fuer sandas.lt) + w6-versand-werkstatt v1.0.0 (README/CHANGELOG/HANDOFF/SHA256, Spez 3 Knoepfe). Dateien kommen nach zulieferung/versand-werkstatt/ (G kopiert per stage/commit-Weg — Inhalte liegen G vor; Uebertragung folgt, Bruecke instabil).
• Auftraege daraus: T5 (Core: Incident registrieren + w6-versand-werkstatt als externes Modul-Repo aufnehmen + Konfig-Aenderung create_backorder dokumentieren + v20-POST-UPDATE-PLAYBOOK step-by-step aus P0-Inventar — Ms Punkt 6) · T4 (Library: Seiten "Versand Werkstatt" aus README+Incident) — beide Auftraege folgen in FREIGABEN.
• D-045 Daumen-Feedback: beschlossen; Bau morgen (SQL v0_9_12 + Board v0.9.5 via T5).
• D-046 BUCHHALTUNG ZUERST: Skill-Vorgehen B0–B9 geladen; B0-Fragen an M; Kickoff = Kern des 07.08.-Plans; T1 als Werkbank vorgeschlagen. BMA danach (nutzt B4-Verrechnungskonten-Regeln).
• EIA v0.4 wartet auf Ms Publish · Cron 1h wartet auf Ms Klick — beides angesagt ("mache ich gleich").

EINSCHUB ~22:40–23:10 — INCIDENT Hetzner-Reboot: Odoo 18 besetzte Port 8069 (BEHOBEN)

Hetzner-Kernel-Reboot 22:15 -> Ms alter @reboot-Cron startete die 18er (gleicher Port 8069, ALTE DB) -> 19er ohne Autostart unten. M (SSH) + G (Fernanalyse): 18er gestoppt, 19er gestartet (22:52), @reboot-Cron auf start_odoo19.sh/lvbp umgestellt (Panel-Praefix-Falle: Command beginnt mit -lc). Agenten fail-closed bewiesen (Laeufe 122–124 E3:icp_unreadable, KEINE Writes) -> run 125 (23:03) GRUEN. Vorab-Ack fail_streak:eia:2026-08-06 (Audit) gegen WD-Fehlreaktion. Doku: zulieferung/incidents/W6_INCIDENT_20260806_HETZNER_REBOOT_ODOO18.md · Nacharbeiten dort (queue_job e9da54ba, 8,7-GB-Log, Core-Uebernahme T5). Durch den Einschub offen geblieben (morgen): Ms 2 Klicks (ir.cron 23 auf 1h [stand 21:50Z noch auf 12h] + EIA-v0.4-Publish + Formular-Test) · Buchhaltungs-Kickoff T1-03 (B0-Antworten liegen vor: StB extern DATEV · alle Kanaele ab 01.01.2026 · Odoo=Zulieferer, fuehrend fruehestens 2028 · alles sauber bis 31.12.2026 · Werkbank T1) · C3-ENTSCHEID: KEINE Aktivitaeten, unklare Faelle bleiben im Bank-Matching haengen ("haengen lassen in der Buchhaltung") — Spec-A4 entfaellt, T3 informieren · D-045 Daumen-Bau.

Nachtrag ~23:25 — D-048 Compliance-Mails (PRIO) + D-049 Status-Seite (Planung)

• PDF liegt in zulieferung/compliance/. Wortlaut-Hinweise (DEU, exakt aus PDF): Gewaehrleistung: "Das Gewaehrleistungslabel finden Sie im Anhang. Bitte speichern Sie dieses Dokument fuer Ihre Unterlagen." · Garantie: "Das Garantielabel und die Garantieerklaerung finden Sie im Anhang. Bitte speichern Sie diese Dokumente fuer Ihre Unterlagen." ENG-Fassungen sind NICHT in der PDF — G liefert Vorschlag, M/Legal prueft.
• WICHTIG Zusammenhang: Template 12 ist GENAU die Vorlage, die EIA v0.4 (D-043) automatisch versendet — Compliance-Ergaenzung gehoert rein, bevor/waehrend der Auto-Versand scharf geht. Morgen frueh: G-READ auf Template 12 + Invoice-Template + base.automation-Garantie-Regel -> exakte Aenderungstexte an M.
• Morgen-Reihenfolge (Vorschlag): 05:30/07:30-Erstbeweise -> Ms 2 Klicks (Cron 1h + v0.4-Publish) -> D-048-Analyse+Texte -> BUCHHALTUNGS-KICKOFF T1-03 (B0 liegt vor) -> D-049-SPEZ.

Nachtrag ~23:35 — D-048 HEUTE geliefert: Ist-Staende gezogen + Einfuegetexte fertig

Belege G-READ 7943/7944/7945: Template 12 ohne Hinweise, ABER Gewaehrleistungslabel 220835 haengt statisch dran; Garantie-Docs via Regel 22 (on_create mail.mail, filter sale.order, SA 1768). Template 8 (W6 v1.0.5) hat KANAL-ERKENNUNG schon eingebaut (is_odoo_channel/channel_l) + Label 219566 statisch. => Nur Hinweis-Bloecke fehlen + Rechnungs-Garantie-Regel. Einbaufertige EN/DE-Snippets inkl. Kanal-Weiche + Shopify-Flag (False, 1 Wort zum Aktivieren): zulieferung/compliance/ANLAGE_G_D048_EINFUEGETEXTE_TEMPLATES.md. Offen morgen: SA 1768 lesen -> Kopier-Fassung "Label an Rechnung" (+Kanal-Sperre gegen Shopify-Doppelung).

Nachtrag 07.08. ~00:05 — D-048 GELIEFERT: odoo19-email-templates v1.7.0

• Repo-Update gebaut und validiert (validate_all: alle Komponenten OK · render_preview: alle QWeb-Ausdruecke fehlerfrei · XML aller 6 Bodies OK · SHA256SUMS neu, Selbstpruefung OK):
• sale 1.2.0 -> 1.3.0: Gewaehrleistungs- + Garantie-Hinweis nach dem PDF-Satz (DE+EN gepflegt, Auto neu generiert). Garantie-Satz NUR bei garantiepflichtigem Geraet — das Template spiegelt die SA-1768-Erkennung (variantengenaue Phantom-BoM-Aufloesung, Garantielabel am product.template): kein Hinweis ohne Anhang, kein Anhang ohne Hinweis. Innere Body-Kennung 1.0.0 -> 1.3.0 korrigiert.
• invoice 1.1.0 -> 1.2.0: dieselben Hinweise mit Kanal-Weiche (Odoo aktiv · Shopify vorbereitet aber INAKTIV via shopify_hinweis_aktiv=False · Amazon bewusst ohne). 4 neue Uebersetzungspaare im Builder, Wortlaut DEU exakt nach Compliance-PDF 06.08.
• NEU sale/docs/SERVER_ACTION_GARANTIE_ANGEBOT.md (Live-Stand SA 1768 v1.3 als Referenz — "was live laeuft steht im Repo") + invoice/docs/SERVER_ACTION_GARANTIE_RECHNUNG.md (Kopiervorlage neue Regel: mail.mail on_create, Filter account.move, nur out_invoice, Kanal-Sperre Shopify ['#'-client_order_ref] / Amazon [origin]).
• render_preview.py um Recordset-/env-Attrappen erweitert — CI validate.yml bleibt gruen.
• Versionspflege: project.yml/README-Tabelle nachgezogen (invoice stand auf 1.0.8/1.0.9, delivery auf 1.4.0 statt 1.4.1); Komponenten-SHA256SUMS decken jetzt exakt den Paketinhalt.
• Abgelegt per Bruecke: module/odoo19-email-templates_v1.7.0.zip + zulieferung/compliance/{ANLEITUNG_EINSPIELEN_D048_v1.7.0.md, SERVER_ACTION_GARANTIE_RECHNUNG.md, VORLAGE_12_sale_body_multilingual-auto_v1.3.0.html, VORLAGE_8_invoice_body_multilingual-auto_v1.2.0.html}
• M nach Anleitung: Vorlage 12 + 8 Body GANZ ersetzen · neue Automatisierungsregel anlegen (Regel 22 unveraendert lassen) · 3 Tests (Odoo+Maschine / Odoo nur Zubehoer / Shopify-Amazon) · GitHub: Repo/Submodul v1.7.0 committen+taggen, ZIP nimmt der naechste fleet-ops-Push mit.
• Drift-Hinweis: Live-sale-Body trug innere Kennung 1.0.0 — mit 1.3.0 kommen alle Repo-Verbesserungen seither mit (Abschlussblock, Pflicht-Signatur). Nach Einspielen Testmail ansehen, danach tests/live_check.sh.

Nachtrag 07.08. ~00:15 — Board-Fragen M, Testkoerper abgeraeumt, EIA v0.4 IST SCHARF

• M-Screenshots Board: "IN ARBEIT 3" = NUR die synthetischen WD-Testkoerper (Laeufe 79/85/86, agent wdtest, von G fuer die Scharfprobe angelegt). KEIN echter Agent hing. TESTKOERPER T2 R4 = die temporaere Registry-Zeile dazu (FK-Zwang der agent_runs).
• ABGERAEUMT durch G (D5, Zuruf von M): alle 6 wdtest-Laeufe (79/85/86 running + 87/88/89 error aus der fail_streak-Probe) + Registry-Zeile wdtest GELOESCHT. Beleg: offene_laeufe=0, wdtest_runs=0, wdtest_registry=0. Board zeigt nach Refresh IN ARBEIT 0. T2: D5-Abraeumen damit VOLLZOGEN — nur noch run_id 1 (vka, error, 05.08.) bleibt fuer das G-02-Verfahren.
• gov_actions (Audit) unangetastet — die Scharfprobe-Acks bleiben als Nachweis stehen.
• Gruene Board-Meldung "ack_job EIA ausgefuehrt" = Ms Haken-Klick (Quittieren-Aktion); Aktion ging durch, aber Kachel aktualisiert erst nach manuellem Reload. NEUER BEFUND B-BOARD-1: nach Board-Aktion kein automatisches Kachel-Update (Refresh 15s greift nicht auf Aktions-Ergebnis) -> in den v0.9.5-Auftrag (zusammen mit D-045-Daumen) aufnehmen.
• EIA: v0.4 Stufe 1+2b IST BEREITS LIVE (M-Publish heute 14:58Z wirksam): active=true, versionId=activeVersionId=8bc55291, 119 Nodes. Beleg Betrieb: 29 Executions seit Publish im 15-min-Takt, ALLE success, 0 error/crashed/waiting (letzte 22:03Z). Der D-043-Versand-Zweig ist damit scharf: Ticket-Verschub -> Angebot geht automatisch raus (Grenzen: genau 1 Entwurf, draft->sent, 0<Betrag<=500 EUR, Guard).
• VOR den echten Maschinen morgen: Ms End-to-End-Selbsttest (Formular ausfuellen -> Ticket verschieben -> Angebot kommt an) als erste Handlung frueh.

Nachtrag 07.08. ~00:25 — M-Frage "Board wie eine App / warum klickt es langsam"

• Diagnose (belegt am Verhalten): (1) 15s-POLLING — zwischen Aktion und sichtbarem Effekt vergehen bis 15s oder ein Hand-Reload; (2) Klick-Aktionen laufen SYNCHRON bis Odoo durch (ICP-Schalter) und der Button wartet auf die Antwort; (3) kein optimistisches UI — Kachel zeigt den neuen Stand erst nach Voll-Refresh (= B-BOARD-1).
• Vorschlag an M kommuniziert: Board v0.9.5 als Paket "wie eine App": D-045-Daumen + B-BOARD-1-Fix + Supabase-REALTIME statt Polling (Karten <1s live) + optimistisches UI (Klick reagiert sofort, Bestaetigung asynchron) + PWA-Manifest (auf Handy/Desktop installierbar, Vollbild, eigenes Icon — ohne App-Store). Detailauftrag an T5 morgen zusammen mit SQL v0_9_12.

Nachtrag 07.08. ~00:25 — SCHALTER-WAHRHEIT aus Odoo gelesen (G-READ, exec 7961) — WICHTIG

• ir.config_parameter live: w6.agents.enabled=1 (Master AN) · w6.vka.enabled=1 (Ms Board-Klick HAT gewirkt) · w6.eia.enabled=0 (EIA-AGENT STEHT AUS!) · w6.bma.enabled=0 (korrekt, bleibt aus bis Buchhaltung).
• KORREKTUR zur 00:15-Meldung "EIA ist scharf": Der n8n-Workflow v0.4 ist live und tickt alle 15 min GRUEN — aber die Laeufe enden am ICP-Gate, weil w6.eia.enabled=0. Maschine an, Schalter aus => Agent arbeitet NICHT. Ms "Eintausch aktivieren"-Klick ging im Board-Haenger verloren (die gruene Meldung war enable_agent VKA, nicht EIA).
• Board-Anzeige-Diagnose bestaetigt: Kacheln zeigen "aus — laut Spiegel von 00:00, Wahrheit steht in Odoo" => die Anzeige kommt aus einem VERALTETEN Spiegel (Stand Mitternacht), nicht aus Odoo live. "Nach Neuladen wieder Aus" war fuer VKA eine Anzeige-Luege (Wahrheit 1), fuer EIA echte Wahrheit (0). Board-Haenger beim Haken/Play: synchroner Odoo-Roundtrip blockiert das UI.
• M-ANWEISUNG uebermittelt (Schalter = M): w6.eia.enabled in Odoo-Systemparametern direkt auf 1 stellen (Einstellungen -> Technisch -> Parameter -> Systemparameter), NICHT uebers haengende Board; G verifiziert danach per G-READ-Lesung.
• ERLEDIGT-Haken: ir.cron 23 "Account: Journal online sync" steht auf active, interval 1 HOURS (naechster Lauf 09:50Z) => Ms Punkt "Bank auf 1 Stunde" ist VOLLZOGEN. Passt zum VKA-Stundentakt :05.
• Randnotiz fuer D-048: w6.garantie.erklaerung_attachment_id=221797 gesetzt; w6.garantie.gewaehrleistung_attachment_id ist LEER (unkritisch — Gewaehrleistungslabel haengt statisch an Vorlage 8; Key ggf. spaeter befuellen oder entfernen).
• Keine Secret-Werte hier oder im Chat wiedergegeben (D-017); Lesung enthielt Token-Felder, die ungenutzt bleiben.

Nachtrag 07.08. ~00:35 — AUFKLAERUNG KOMPLETT: EIA IST WIEDER AN (eia.enabled=1, exec 7966)

• URSACHE des naechtlichen eia=0 war NICHT Ms Klick, sondern der WATCHDOG: gov_actions id 26 = w6-wd disable_agent eia um 21:00:53Z (fail_streak-Auto-Disable wegen der 3 erklaerten Hetzner-Fehllaeufe 122-124). Mein Vorab-Ack (id 28) kam 21:05:24Z — 4,5 min ZU SPAET. Die befuerchtete WD-Fehlreaktion IST eingetreten; EIA war 21:00-22:29Z aus (nur Gate-Laeufe, nachts kein Ticketaufkommen — kein Schaden).
• Ms Board-Klicks waren ALLE erfolgreich (Audit): id 30 enable_agent vka 22:17:57Z -> vka=1 · id 32 stage_change vka STUFE 2 22:28:25Z · id 33 enable_agent eia 22:29:24Z -> eia=1 (belegt exec 7966, 22:31Z). Die UI hing jeweils, aber die Requests gingen durch.
• Ms Fehlermeldung "rejected:duplicate_within_dedupe_window" beim Stufe-Klick = DOPPELKLICK-Schutz von gov_act: der ERSTE Stufe-Klick (id 32) war laengst durch; der Wiederholklick wurde korrekt dedupliziert. Vollzug ok, Meldung nur verwirrend.
• T3 morgen: pruefen, ob VKA-Workflow die Stufe 2 aus dem stage_change uebernimmt (naechste Stundenlaeufe ansehen); Ms Stufe-2-Wunsch entspricht der gebauten Stufe (Vorschlag komplett, M bestaetigt 1 Klick).
• BEFUNDE fuer T2 (morgen): (B1) Vorab-Ack-Timing-Regel noetig — Ack SOFORT bei Incident-BEGINN setzen, nicht nach Behebung (21:00-WD-Lauf schlug mein 21:05-Ack); (B2) Dedupe-UX fuer human:*-Actors — kryptischer Reject bei Wiederholklick, Kandidat v0_9_12: kuerzeres Fenster fuer Menschen ODER Board-Meldung "bereits ausgefuehrt um HH:MM"; (B3) WD-Auto-Disable blieb 88 min unbemerkt -> staerkt D-049 (Handy-Alarm auf disable_agent-Ereignisse).
• Board v0.9.5-Paket ("wie eine App") deckt die UI-Seite: Spiegel-Frische, kein UI-Block, optimistische Kachel, Realtime, PWA, Daumen. Start morgen frueh.

Nachtrag 07.08. ~00:45 — D-050 + Board-Konzept-Pruefung (M-Fragen: sieht G alles? ist WD ein Agent?)

• KONZEPT-ZEUGNIS (was steht): 4 Schichten sauber getrennt — Odoo=Wahrheit (ICP-Schalter) · gov_actions=Vollzugs-Audit (Ms 3 Nacht-Klicks alle drin) · agent_runs+run_log=Betriebslog · Board-Views v_board_*=Sicht. Zeitfenster-Abfrage funktioniert: CSV 06.08. 02:00-13:00 (47 Laeufe eia/vka) an M geliefert. Registry fuehrt je Agent allowlist, write_budget_run 50, id_cap 20, amount_cap_stage2 500, enabled_icp, stage, Spiegel (icp_value/icp_checked_at, stuendlich).
• Registry-IST: NUR bma/eia/vka. EIA stage=3, VKA stage=2 (=Ms stage_change id 32; Registry-updated_at identisch mit Audit-Zeit — Weg Board->gov_act->Registry funktioniert).
• LUECKEN (L1-L6) gegen D-050: L1 WATCHDOG: NICHT in Registry, KEINE Kachel, KEINE agent_runs (FK verhindert Logging ohne Registry!), KEIN w6.wd.enabled-Schalter — obwohl er Disable-MACHT hat (heute 21:00Z bewiesen). -> T2: Registry-Zeile wd + ICP-Key + Kachel + Lauf-Logging. L2 ALT-AUTOMATIONEN (werksbericht, schnaeppchen, addr_check, dhl rosy_label, dhl_out_v6a, amz_label, use_force — alle enabled/prod laut ICP-Lesung): nicht in Registry/Board, haengen NICHT am Not-Aus w6.agents.enabled. -> Registry-Kategorie "Alt-Automation" + Not-Aus-Kette in deren Gates (T2/T4-Paket). L3 NOT-AUS-GEGENPROBE: gebaut, aber scharfer Beweis steht aus (G-02-Pflichtpunkt 13.08., vorziehbar). L4 BOARD-EXPORT: keine Zeitraum-Ansicht/CSV im Board — heute liefert G per SQL. -> v0.9.5/6: "Zeitraum waehlen -> CSV". L5 ALARME: WD-Disable blieb 88 min unbemerkt -> D-049 (Handy-Alarm auf disable_agent/emergency_stop + WD-Herzschlag). L6 ODOO-AUTOMATIKEN (Server-Aktionen 1768/22, kuenftige Rechnungs-Regel, ir.cron 23 u.a.): laufen selbststaendig, stehen nirgends im Board -> read-only-Inventarliste als Board-Sektion.
• PRUEFPUNKT B4 (T2): Registry zeigt EIA stage=3 — KEIN passender stage_change-Eintrag in gov_actions gefunden (letzter eia-stage_change id 15 = Stufe 2, 09:32Z). Herkunft klaeren (v0.4-Deploy-Kodierung Stufe "2b"=3? Direkt-Write am Audit vorbei waere Governance-Loch).
• Antworten an M uebermittelt: "Sieht G alles?" -> auf ABRUF fast alles (Supabase/n8n/Odoo-read/Repo), aber nichts pusht G (Beleg WD-Disable) -> L5 + gov_actions-Ticker in jeder Lagemeldung ab morgen. "Ist WD ein Agent?" -> handelt wie einer (schaerfste Schreibmacht: abschalten), ist aber nicht als solcher gefuehrt -> wird nachregistriert; "wer bewacht den Waechter" -> G-Lagemeldung + D-049-Herzschlag.
• Loesch-Lehre aus D5 heute: kuenftig echte Laufdaten NIE loeschen; Testkoerper markieren (z.B. is_test-Flag) statt entfernen (D-050-Konsequenz, v0_9_12-Kandidat).

Nachtrag 07.08. ~00:50 — D-050-N1/N2 + M STARTET EIA-END-TO-END-TEST (D-043 Stufe 2b)

• M testet JETZT selbst: Formular ausfuellen -> Ticket verschieben -> Angebot muss ankommen. G begleitet live (naechste EIA-Laeufe :03/:18/:33/:48, agent_runs + n8n-Executions). Erwartung: binnen 15 min nach Ticket-Verschub Klassifizierung + Angebots-Entwurf + AUTOMATISCHER VERSAND (Grenzen D-024/D-043: genau 1 Entwurf, draft->sent, 0<Betrag<=500 EUR, Guard GRT-1). Testfall muss unter 500 EUR liegen, sonst greift bewusst KEIN Versand.
• D-050-N1: An-/Abmelde-Pflicht auch fuer G-Werkzeuge/Tests/Reads (siehe DECISIONS). D-050-N2: Funktionen vor Design; Supabase Pro + Cloudflare Pro als Freigabe fuer Realtime/Worker.

Nachtrag 07.08. ~01:00 — Ms Board-Nacht-Test: weitere Befunde + D-051-VORSCHLAG Lern-Routine

• M-Urteil: "aktuelle Version vom Board geht ueberhaupt nicht." Einordnung G: VOLLZUEGE funktionieren (alle Klicks im Audit), die RUECKMELDUNG ist kaputt — genau der v0.9.5-Umfang. Neue M-Punkte (8)-(11) in T5-FREIGABEN: Stufen-Menue mit Wirkzeitpunkt, Agent-Farben, Filter+Suche wie Odoo, Debug-Toggle defekt (B-BOARD-2).
• Erneuter Stufe-Klick EIA -> wieder dedupe-Meldung; d.h. inzwischen EXISTIERT ein erfolgreicher stage_change/eia im Audit-Fenster (staerkt Pruefpunkt B4: T2 klaert morgen Herkunft/Zeitpunkt von Registry stage=3 per frischem SELECT).
• BELEG Agent arbeitet wieder: run 134 (EIA 00:48) scannt echt — "keine neuen Eintausch-Tickets" statt Gate-Ende. Ms End-to-End-Test laeuft; Formular-Ticket noch nicht eingetroffen.
• D-051-VORSCHLAG (M: "Learning aus den Fails als Routine etablieren, wie die KI lernt"): WOECHENTLICHER LERN-ZYKLUS je Agent — (1) Sammeln: Daumen-Bewertungen (D-045), Fehllaeufe, Guard-Blocks, Abbruchgrund-Eimer (VKA v0.2.5 liefert schon!), Dedupe-Rejects; (2) G-Auswertung: Muster + Quoten (angenommen/abgelehnt je Vorschlagstyp); (3) konkrete Regel-Aenderungs-Vorschlaege je Agent (Filter/Schwellen/Wortlaut) als Diff; (4) M entscheidet; (5) versioniert einspielen + Vorher/Nachher-Quote messen. T3-Messwoche = erster manueller Durchlauf genau dieses Zyklus. Detail-Spez morgen mit v0_9_12 (rating-Spalten) buendeln.

Nachtrag 07.08. ~01:45 — Ms Test-Ticket 6295: Diagnose + Reparatur (nichts war "kaputt")

• BEFUND-KETTE: Formular 00:52 -> Ticket 6295 "Neu" (Envelope sauber, Code 868G-DM89-3ADQ-9NZ, W-NM-868 Grundmodell, Recycling JA). Ms Board-Stufenklick 00:54 (Audit id 35) stellte den AGENTEN versehentlich auf Stufe 1 = TROCKENLAUF (sein 00:32-Klick id 34 hatte korrekt 3 gesetzt; das haengende UI provozierte das Hin-und-Her — Dedupe-Meldungen waren die Wiederholklicks). Laeufe 01:03/01:18 sahen das Ticket nicht (M-Verschiebungen, write 01:18); Lauf 138 01:33 sah es in "Neu", klassifizierte im Trockenlauf (match:1, 0 Angebote) und zog den Scan-Cursor auf 6295 -> Ticket waere kuenftig NIE mehr klassifiziert worden (Neu-Scan sucht id>cursor).
• REPARATUR durch G (auditiert): (1) stage_change eia -> 3 via RPC = 'ok' (Wiederherstellung des M-Stands id 34; Begruendung im Audit-Detail; Dedupe-Fenster 10 min [gov_policy gov_action_dedupe_min, Default 10] war abgelaufen). (2) scan_cursor 6295 -> 6294 (UPDATE; Praezedenz VKA-Cursor-Reparatur 06.08. mittags). Verifiziert: stage=3, cursor 6294, icp_value 1.
• FAHRPLAN: 01:48-Lauf klassifiziert 6295 ECHT (Kunde + Angebots-Entwurf, 868G-Muster = 399 EUR <= 500). DANACH M: Ticket in Stufe "Eintauschaktion" (stage_id 40) schieben -> 02:03-Lauf macht Ankunft+Palette+VERSAND an die Formular-Mail. Stufenliste belegt: Arbeitsstufe heisst woertlich "Eintauschaktion" (id 40, seq 10).
• NEBENBEFUND: G-READ-Workflow wurde parallel von einer Terminal-Lane um Board-Pflicht-Nodes erweitert (Run starten/beenden (G), Ticket-Triage, Stufen lesen) — D-050-N1 bereits in Umsetzung; agent_runs-Insert scheitert noch am fehlenden Registry-Eintrag 'gread' (FK 409, gefangen). Morgen: Registry-Zeile 'gread' (Werkzeug) + Abstimmung T2 (ein Pfad = ein Schreiber: G-READ ist G-Werkzeug).
• Offene Nacht-Handlung M: NUR noch Ticket 6295 nach "Eintauschaktion" schieben, sobald G den Entwurf bestaetigt.

Nachtrag 07.08. ~02:00 — Board DRINGEND, Skill-Updates geliefert, Erfolgsbild, Shopify-Jobs

• M-PRIORITAET: "Board morgen reparieren, DRINGEND" -> R8/v0.9.5 ist MORGEN FRUEH ERSTE BAUAUFGABE (Umfang (1)-(11) in T5-FREIGABEN; Funktionen vor Design, Supabase/Cloudflare Pro frei).
• GELIEFERT an M (Chat + zulieferung/): odoo-core-system.skill v2 (Schalter/Stufen/Dedupe-Mechanik, Spiegel vs. Wahrheit, Cursor-Falle, D-050-Betriebsregeln, Lehrfall 6295, Triage-Methode) · github-agent-memory.skill v2 (NEU: RUNTIME-Schicht "Supabase-Betriebsgedaechtnis" mit den 8 Warum-Gruenden: FK-erzwungene Governance, RPC=auditierter Schreibweg, append-only-Forensik, Zeitfenster=SELECT, Transaktions-Reparaturen, Views/Realtime, Policies als Daten, Spiegel-Trick) · W6_ERFOLGSBILD_2026-08-07.md (die 12 Prinzipien, warum es klappt — Ms Auftrag "schreibe zusammen wie es mir gelungen ist"). M muss die .skill-Dateien im Chat anklicken und speichern (G kann Skills nicht direkt aendern).
• SHOPIFY-EINSCHUB M diagnostiziert (read-only, exec 7996): 4 Jobs "Export Stock to Stores (1)-(4)" von 01:00; (4) done, (2) laeuft, (1) pending, (3) failed exc JobFoundDead retry 37 — Worker stirbt mittendrin (Zeitlimit/Recycling), Dead-Cron requeued. Keine Kundenwirkung, nur Sync-Verzug. Morgen frueh pruefen ob alle done; sonst M-Requeue + Ursache (Worker-Limits) in Incident-Nacharbeit. Staerkt D-049 (Jobqueue-Ueberwachung).
• EIA-TEST: Entwurf S37807 (399 EUR, draft, W6TI:868G-DM89-3ADQ-9NZ, Partner korrekt) um 01:48 angelegt (run 140: "1 Angebot NEU"); M schob 6295 nach "Eintauschaktion" (Stufe 40) -> 02:03-Lauf soll versenden; G bestaetigt nach dem Lauf.

Nachtrag 07.08. ~02:15 — BEFUND B5 (KRITISCH): WD-Mitternachts-Schleife + Test-Zwischenstand + Stripe-Lesung

• B5 MITTERNACHTS-LUECKE WATCHDOG: fail_streak-Ack-Signatur ist TAGESGEBUNDEN (fail_streak:eia:JJJJ-MM-TT). Um 00:00 verliert jedes gestrige Ack die Wirkung, solange die Fehler im 24h-Fenster liegen -> WD disabled ERNEUT: Audit id 37 (02:00:53 disable_agent eia) + id 38 (WD-Selbst-Ack fuer 2026-08-07). Folge im M-Test: run 140 (01:48) legte Entwurf S37807 an (Schalter noch an), run 143 (02:03) Guard-Block G1:kill_switch(agent) -> Ankunfts-Nachtrag + Versand geblockt. FIX-VORSCHLAG T2 Runde 5 (PRIO 1): Ack wirkt 24h ab Erteilung (Signatur ohne Kalendertag bzw. Zeitfenster-Vergleich) ODER errors_24h zaehlt nur UNGEACKTE Fehler. Heute Nacht keine weitere Wiederholung (WD-Ack id 38 deckt 07.08.; ab 08.08. 00:00 sind die Hetzner-Fehler aus dem 24h-Fenster).
• TEST-ZWISCHENSTAND 6295: Erst-Ankunft war schon 01:03 registriert worden (Palette 1 Platz 5) — DA stand der Agent aber auf Trockenlauf (G1:stage1_dry_run, run 135) -> kein Chatter/kein Versand; 02:03 dann kill_switch-Block (B5). Ticket steht in Stufe 40; Entwurf S37807 (399 EUR, draft) wartet. NACH Re-Enable durch M holt der naechste Takt den Ankunfts-Nachtrag nach (needs_write=true, melden=true) und der Versand-Fan-out dahinter greift -> S37807 geht raus. M-Handgriff uebermittelt (EIN Klick: Board-Play EIA oder ICP w6.eia.enabled=1); stand 02:10 noch nicht erfolgt (gov_actions leer) — evtl. schlaeft M; Fahrplan steht im Chat.
• STRIPE-FRAGE M (Apple/Google Pay): Lesung exec 8004: payment.provider "Stripe" (id 14) enabled mit NUR 3 verknuepften Methoden [41,114,73]; aktive payment.method-Suche liefert Apple/Google Pay NICHT -> die Methoden sind in Odoo INAKTIV (Odoo blendet inaktive aus — deshalb "sieht" M sie nicht). Stripe-Dashboard-seitig aktiv (M-Screenshot). Antwort an M: normal; im Payment-Element kann Stripe Apple/Google Pay trotzdem anbieten (Domain-Registrierung vorausgesetzt); explizites Aktivieren in Odoo = Archiv-/Inaktiv-Filter in der Zahlungsmethoden-Liste + aktivieren + bei Provider Stripe verknuepfen — MORGEN mit Testzahlung, nicht nachts (kundenwirksam). Nebenbefund: zweiter Provider "Stripe NEW w6web.app" (id 18, disabled) existiert — Altlast klaeren.
• Skill-Updates: odoo-core-system v2 ist bereits GESPEICHERT (Skill-Liste zeigt neue Beschreibung) — M war schneller als die Nacht.

Nachtrag 07.08. ~02:20 — queue_job e9da54ba AUFGEKLAERT: NICHT requeuen, sondern verwerfen!

• Job 2330839 "Shipping: S36588 / SPR/RESHIP2/00186 >> Validate picking packages" failed 06.08. 16:08, UserError "zero quantity transfer". ABER Picking 48606 ist laengst DONE (Typ 34 Reship Lager2, Tracking 00340434467877396924) — nach dem Job-Fehler von Hand validiert. Verwaiste Leiche.
• KORREKTUR Incident-Nacharbeit ("e9da54ba requeue"): REQUEUE WAERE FALSCH. Richtig: Job auf "Done"/verwerfen (M-Klick). Belegt Offener-Punkt 2 des 04.08.-Incidents (Job-Fehler bleiben unbemerkt, hier 34h) -> D-049 Jobqueue-Alarm.
• VKA-Stufe-2-Frage M beantwortet: Vorschlag komplett + EIN Klick im Bankabgleich; reconcile IMMER Mensch; Eimer-Karten; action_confirm/Anzahlung/Post stufengebunden inaktiv bis nach Messwoche.

Nachtrag 07.08. 02:18 — ✅ D-043 END-TO-END BESTANDEN: Angebot S37807 AUTOMATISCH VERSENDET

• M schaltete EIA in Odoo wieder ein (~02:16, ICP direkt; UI-Writes erzeugen keinen gov_actions-Eintrag — bekannt, Wahrheit=Odoo).
• run 147 (02:18) run_log: 02:18:12 arrival:ticket:6295 "Palette 1, Platz 5/25, Chatter [2113588]" -> 02:18:21 arrival:send:6295 "D-043: Angebot S37807 (399 EUR) automatisch versendet · Template 12 · send=162095 · state->sent=true".
• Kompletter Durchstich: Formular 00:52 -> Klassifizierung+Kunde+Entwurf 01:48 (run 140) -> Stufe 40 -> Nachtrag+VERSAND 02:18 (run 147). EIA verifiziert scharf.
• Befund B-EIA-R (niedrig, T4): run-Zaehler erfassen nur Phase 1 — Versand nur im run_log sichtbar; mit v0.4.1 in outcomes/next_action aufnehmen.

Nachtrag 07.08. 06:50 — FRUEHLAGE: alles gruen · v0_9_12 eingespielt · gread angemeldet (D-050-N1 LIVE)

• Nacht seit 02:18 fehlerfrei (eia_fehler=0, kein WD-Eingriff; gov_actions leer seit 02:20). Schalter 06:48: agents=1, eia=1, vka=1, bma=0. 05:30-BELEG run 163 "Entsorgbar-Rechner: 1 von 5 leeren Feld(ern) gesetzt".
• SHOPIFY-JOBS alle 4 done (letzter 02:53:48, Retries bis 178 — Worker-Kill-Ursache bleibt Incident-Nacharbeit).
• MIGRATION v0_9_12 "w6a_registry_kinds_gread_v0_9_12" eingespielt: agent_registry + kind/is_test/expires_at + INSERT gread (kind=werkzeug, stage=1 wg. stage_check, enabled_icp=w6.agents.enabled). VERIFIZIERT: G-READ exec 8068 -> agent_runs 172 (gread, ok, beendet) — D-050-N1 LIVE. SQL-Wortlaut in ANLAGE (v0_9_12-Sektion).
• GITHUB-STAND: main==origin/main (letzter Commit e1e92e9 06.08. 16:15); 26 Dateien uncommitted + unversionierte Zulieferungen; WARNUNG .git/index.lock liegt vor -> Git-Lane MUSS sie zuerst entfernen. Auftrag: ablauf/T-GIT-MEMORY_AUFTRAG_2026-08-07.md.
• T2-Hinweis Audit-Luecke: Ms Re-Enable lief per Odoo-UI direkt am ICP -> kein gov_actions-Eintrag (human-UI-Writes umgehen Audit; Board-Weg bevorzugen, v0.9.5 mitdenken).
• TAGESPLAN (M-Reihenfolge): 1. Board R8 (T5 LAEUFT seit ~08:50) · 2. Buchhaltung T1-03 (Kickoff-Datei liegt: ablauf/T1-03_buchhaltung/FREIGABEN.md) · 3. parallel Git-Memory-Lane + T2 Runde 5 (PRIO B5).

Nachtrag 07.08. ~09:20 — ABHOLRUNDE: 3 Meldungen geprueft, v0_9_13 eingespielt

• T-GIT-MEMORY STOPP: index.lock entfernt (Commits laufen wieder; Lektion pgrep -x git statt -f), fleet-ops in 2 Gedaechtnis-Commits gepusht (status/ bewusst mit, module/ bewusst NICHT [.gitignore, Binaeres gehoert ins Submodul-Repo — Abweichungen korrekt]), Code-Repos: main unberuehrt, w6-odoo-core-Stand als Branch fuer M. Handoff-Pflege committed (STATUS, THREAD_HANDOFF, Routing). _to_delete/-Dublette wartet auf M-Ok (rm -rf _to_delete/ — bytegleich verifiziert).
• T5 R8 STOPP/GATE_7: Board v0.9.5 gebaut (10/11), Tag gesetzt (runtime main 7a6cec9). Kern-Ursache des Spiegel-Symptoms war load()-Ueberschreiben des optimistischen Zustands -> Frische-Schicht-Fix; Debug repariert; 16/16 Tests. G-Entscheide: Refresh 5s sofort (C), SSE+Serverfilter als R9 (A), Anon-RLS abgelehnt (B). FLEET-STANDARD NEU: Test "ueberlebt den naechsten Ladevorgang" fuer jeden optimistischen UI-Zustand.
• T1 B1: Scaffold ok; BLOCKER kw fehlt auf der Maschine -> T1 baute b1_ist.sh (JSON-2, baulich read-only, Query-Doku, v19-Vorsorge, Entwurfs-Belege als Zugabe). Wartet auf M: odoo19_api_key in den Schluesselbund (Variante A, Uebergang; B-T1-1 = Lesekonto als Folgepunkt).
• v0_9_13 "w6a_rating_verdict_v0_9_13" EINGESPIELT+VERIFIZIERT (rating-Spalten Tabelle+View, gov_act-verdict-Handler) -> D-045 backend-komplett; erster echter Daumen = M im Sichttest.
• M-KLICKLISTE (gesammelt): (1) Board-SICHTTEST GATE_7 §6 [Kachel bleibt nach Schaltvorgang] + ersten Daumen klicken · (2) Merge agent/T5-p0 (v3.1.2, seit gestern) · (3) K-01-DHL-Toggles · (4) GitHub-Repo w6-library anlegen (T4-02 wartet) · (5) Schluesselbund-Befehl fuer T1 · (6) rm -rf _to_delete/ · (7) Skill odoo-buchhaltung-gutachten installieren · (8) Shipping-Job e9da54ba VERWERFEN (nicht requeue).

Nachtrag 07.08. ~09:35 — D-052 (Incident-Pflicht) + D-053 (T6 Library-Lane) UMGESETZT

• D-052: Template zulieferung/incidents/_TEMPLATE_INCIDENT.md (Zeitachse, Ursachenkette, Ansaetze inkl. verworfener, Loesung+Rollback, ERKENNUNGS-REZEPTE, Lessons+Folgepunkte). Nacht-Incidents formal nacherfasst: WD_AUTODISABLE_MITTERNACHT (komplett, beide Disables + UTC-Beweis) + SHOPIFY_STOCKJOBS_JOBFOUNDDEAD (kompakt, Merksatz "vor Requeue Zielzustand pruefen").
• D-053: Lane T6 gegruendet (ablauf/T6-01_library/FREIGABEN.md, R1 freigegeben: eigene Blaetter, Bestand aus T4-02 uebernehmen, Fachdomaenen-Navigation, INCIDENTS-Sektion prioritaer, Stub-Generator, Build-Beweis; Deploy erst R2). T4-02 geschlossen (Schlussvermerk). CLAUDE.md: Zonenliste + Kurzsignale um T6 ergaenzt (G-Strukturakt; python-replace, sed-Anlauf scheiterte). STATUS-Matrix zieht naechste T5-/Git-Runde nach. VORAUSSETZUNG M: GitHub-Repo w6-library anlegen (Klickliste #4).
• M startet T6: neues Fenster im Repo-Root, erste Nachricht T6 (CLAUDE.md routet; docs/PROMPTS_LANE_NEUSTART.md gilt sinngemaess).

Nachtrag 07.08. ~09:45 — D-054: M widerruft Schluesselbund-Weg — Credential-Grenze bleibt bei n8n

Ms Rueckmeldung zur T1-Freigabe: Odoo-Key im Schluesselbund/Terminal = zu unsicher (Crash waehrend Schreibvorgaengen); bisherige Aufteilung bleibt. G-Freigabe 09:20 (Variante A) WIDERRUFEN — Lehre G: Credential-Architektur-Aenderungen sind M-Entscheide, keine G-Uebergangsfreigaben. Neuer B1-Weg: G erhebt ueber gread nach T1s Query-Spez (b1_ist.sh = Spezifikation, nicht Werkzeug), Roh-JSONs nach evidence/B1/, T1 wertet aus. Details in T1-03-FREIGABEN.

Nachtrag 07.08. ~09:50 — B1-IST-AUFNAHME KOMPLETT (G-Erhebung via gread nach D-054)

18/18 Evidence-Dateien in buchhaltung/.../evidence/B1/ + Chat-Lieferung an M. 9 Laeufe (exec 8117-8125), alle 200, alle mit Board-Anmeldung. ROH-KERNBEFUNDE: OP-Schieflage (Ford. -210k bei 18.947 Posten / Verbindl. +4,4 Mio bei 157 Posten) · Bankstau 133/384.614 seit 30.11.25 · KEINE Festschreibung (alle Lock-Dates leer) · Eingangsrechnungen fehlen (1 Beleg/7 Monate) · 737 Lagerprodukte Preis 0 · Regel 23 (Garantie Rechnung) falsch verdrahtet -> M-Fix gemeldet (Mass Mailing statt Outgoing Mails). Naechste Schritte: T1 Vollstaendigkeitspruefung -> G1-Gate -> B2-Pflichtenregister. v19-Feldbefunde dokumentiert (deprecated weg, cron_name statt name).

Nachtrag 07.08. ~09:55 — Regel 23: M hat GELOESCHT statt umverdrahtet; G-Neuanlage vom Klassifizierer geblockt -> M legt neu an

• Vorher-Beleg exec 8131 (gread run 196): base.automation 23 EXISTIERT NICHT MEHR (Suche id in [22,23] liefert nur 22; einzige Garantie-SA ist 1768 an Regel 22). M hat die falsch verdrahtete Regel nach dem 09:45-Zwischenruf geloescht — sauberer Ausgangszustand.
• G-Versuch, die Regel per Werkzeug korrekt neu anzulegen (M-Auftrag "kannst du mir selbst reinsetzen"): Vorbereitung vom Cowork-Klassifizierer GEBLOCKT (Anlage von Kunden-Mail-Automationen = M-Vollzug, gleiche Grenze wie EIA-v0.4-Publish). NICHT umgangen. Registry-Zeile 'gact' (kind=werkzeug, D-054-N1) wurde zuvor angelegt — bleibt fuer kuenftige NICHT-kundenwirksame M-Einzelvollzuege, dokumentiert.
• M-Klickweg (60 Sek, Kopiervorlage zulieferung/compliance/SERVER_ACTION_GARANTIE_RECHNUNG.md): Automatisierungsregeln -> Neu -> Name "W6 Garantie: Anhaenge ergaenzen (Rechnung)" -> Modell OUTGOING MAILS -> Ausloeser BEIM ERSTELLEN -> Filter-Domain [("model","=","account.move")] -> Aktion "Python-Code ausfuehren" -> Code aus der Vorlage einfuegen -> Speichern. G verifiziert danach read-only (Modell 171 + Filter + SA-Modell + Testempfehlung Odoo-Rechnung mit Maschine).

Nachtrag 07.08. ~10:03 — ✅ Regel 24 VERIFIZIERT: Garantie-Anhaenge an Rechnung korrekt verdrahtet (M-Anlage, G-Nachprobe exec 8133)

• base.automation 24 "W6 Garantie: Anhaenge ergaenzen (Rechnung)": active, Modell [171, Outgoing Mails], on_create, filter [("model","=","account.move")], SA 1769 verbunden.
• ir.actions.server 1769 "GARANTIELABEL AUTOMATIK RECHNUNG v1.0": model 171, state code, base_automation 24. Regel 22 (Angebot) unveraendert.
• Damit ist der letzte D-048-Baustein strukturell VOLLZOGEN. FUNKTIONSTEST offen (M): eine Odoo-Rechnung mit Maschine senden -> Anhaenge Garantielabel+Garantieerklaerung + (falls Bodies v1.7.0 eingespielt) beide Hinweis-Saetze im Text; Gegenprobe Zubehoer-Rechnung ohne Garantie-Anhaenge. Code-Volltext nicht gelesen (Name entspricht Vorlagen-Header v1.0); der Funktionstest ist der Beweis.

2026-08-07 ~11:20 — v0.9.5 abgenommen (1 P0-Rest → T5-R9), G1 BESTANDEN, B2 steht

• Board: M-Sichttest „das ist fertig" + 2 Befunde. T5-R9-FREIGABE geschrieben: B-BOARD-3 (P0) verdict-Klick → gruene Meldung nicht schliessbar, Board haengt, Agents-Sektion weg, nur Cmd+Shift+R. Backend bewiesen sauber: gov_actions id 39 (verdict eia job 95 up, human:board, 10:26:11) + agent_queue.rating gesetzt → reiner Frontend-Fehler. Dazu R9: Debug-Felder je Karte, Suche ueber Debug-Inhalte, Regex-Suche (fehlertolerant). R10 = SSE /stream + Serverfilter (SQL v0_9_14 liefere ich zum R10-Start).
• T1-STOPP eingegangen (B1 vollstaendig, Quersummen exakt, D-054 umgesetzt: b1_ist.sh gegen Ausfuehrung gesperrt) mit 3 Nachforderungen → von G erhoben (G-READ): N1 res.company/fields_get = 317 Felder, GENAU 5 Lock-Speicherfelder + 5 user_*-Ableitungen + po_lock, kein sechstes → „keine Festschreibung" haelt · N3 Stau-Altersverteilung Quersumme EXAKT (133/384.614,00), Stau laeuft bis August 2026 · N2 Rohlisten (61 Kategorien, 103 Crons/68 aktiv; Abweichung zu h2=70 vermerkt).
• G1-Nachlese: Suspense 2478 „1802" = 130 Zeilen / -381.015,46 (≈Stau, Δ 3 Zeilen/3.598,54 = F-012) · 23 Abgleichsmodelle inkl. Gegenkonten: 5 inaktive Provider-Modelle → 4200 Revenue (F-010!), aktive W6-Payouts → Parking 1461-1469 (Zielarchitektur existiert), Dublette Shopify 31/33 + EREF-Ueberschneidung mit Klarna 34 (F-011) · User: 12 intern aktiv / 3 inaktiv / 177 Portal (ohne PII).
• Gate G1 BESTANDEN (docs/01_G1_PROTOKOLL.md; OFFEN: Konten-Stilllegung→B3, Bewertungskonten→B5, Rechte-Detail→B7) · BEFUNDREGISTER F-001..F-012 · B2-PFLICHTENREGISTER komplett (29 Zeilen) · B0-RAHMEN LEER → 4 M-Fragen gestellt. T1 beauftragt: B3-Lesepaket-Spez (read-only, D-054-konform).
• gread-Laeufe 202-211, alle an-/abgemeldet; Fehlversuche 202/206/208/209 dokumentiert + per SQL geschlossen (D-050). LEHREN: (1) n8n setNodeParameter-Pfad ist relativ zu parameters („/url", NICHT „/parameters/url") — exec 8150 lief deshalb mit alter Konfiguration; (2) „Run beenden (G)" lief 1x PRO ITEM (192 POSTs bei User-Read) → Timeout-Ursache 8152/8164 → executeOnce=true gesetzt; (3) v19-Felder: account.reconcile.model OHNE rule_type/auto_reconcile/counterpart_type (neu: trigger, can_be_proposed), model.line OHNE journal_id, res.groups OHNE category_id; (4) base64-ueber-Chat-Kommando korrumpiert bei ~14KB → Repo-Transfers ueber den Datei-Commit-Weg, danach json-validieren.
• Offen bei M: B0-Antworten (4 Fragen) · B2-Abnahme = G2 · Regel-24-Funktionstest · Merge agent/T5-p0 · K-01-DHL-Toggles · GitHub-Repo w6-library (T6 wartet) · rm -rf der _to_delete/-Ordner (jetzt 2: Root + evidence/B1) · Schluesselbund-Loeschbestaetigung.

2026-08-07 ~11:35 — B0 beantwortet → D-055, Register angepasst

M hat die vier Rahmen-Fragen beantwortet: StB extern in DATEV · Scope ab 01.01.2026, "laufender Betrieb nicht stoeren" · Zielbild internes Steuerungssystem + Vorsystem, fuehrend fruehestens 2028 · Eingangsrechnungen bleiben extern beim Chef (nur Schaetzungen via Kosten/Zugaenge). → D-055 in DECISIONS, 00_RAHMEN.md ausgefuellt, F-003 umgewidmet (hoch→mittel: OP-Herkunft klaeren statt Luecke fuellen), Pflichtenregister-Zeilen O2/V1/A3/U5/B7 an D-055 angepasst, T1-B3-Spez-Auflagen ergaenzt (Scope-Domains ab 2026-01-01, OP-Herkunfts-Paket statt Eingangs-Luecke, DATEV-Felder-Read). G2 wartet nur noch auf Ms Abnahme des Pflichtenregisters.

2026-08-07 ~21:35 — Mail-Agent: IST-Aufnahme, Optionen, Skill w6-mail-agent geliefert

Gmail-MCP (info@) verbunden. Read-only-Aufnahme: Labelstruktur komplett inventarisiert (inkl. SYS-NEU-Taxonomie: 10 Status/24 Intents/Produktbaum — vorbereitet, leer), Stichproben 0-Neu (Mischeingang inkl. Phishing), D.Moreinis (Amazon-Performance-CASEs), A.Celentano (Haeufung Mahnung-trotz-Zahlung = Querbefund zu F-002!). Kritikfall-Typ belegt: Prime-Berechtigungs-Warnungen; CASE 13132528892 vom 04.08. UNGELESEN in 2-Erledigt. → Skill w6-mail-agent gebaut + an M geliefert (SKILL.md + mailbox_struktur.md [Soll-Inventar mit Label-IDs, zugleich Drift-Check-Basis] + eskalation_optionen.md [Telegram vs ntfy, Lockdown A-D, Architektur-Optionen, offene M-Entscheide]). Optionen-Kurzfassung: zulieferung/mail-agent/W6_MAILAGENT_OPTIONEN_2026-08-07.md. Kein Write in Gmail, keine Label-Aenderung. Der neue MDA-Thread startet mit dem Skill + odoo-core-system + github-agent-memory; erste Schritte dort: Registry 'mda' + ICP w6.mda.enabled (M-Klick/gact), Stufe-0-Flow [DEV], Telegram-Bot mit M. Vorher Konformitaets-Analyse 03_KONFORMITAET_SETUP.md ins Repo eingespielt (Brueckenabriss ueberbrueckt via Datei-Commit).

2026-08-07 ~21:50 — D-056: Ziele + Reihenfolge Buchhaltung; G2 BESTANDEN

M ersetzt weiche Nutzen-Ziele durch harte: Z1 USt-VA-Daten NACH LAND aus Verkaeufen · Z2 interne GuV inkl. Ausgabenseite (KK-Abrechnung buchbar + Bank-Ausgaben; Praezisierung D-055: Belege extern, Kosten-Buchung intern) · Z3 Bestandsbewertung · Z4 Verfahrensdoku. Reihenfolge: richtigstellen → Bankabgleich richtige Konten (B4) → E-Rechnung pruefen → "sinnvoll locken" (B7 zuletzt). KEINE Kasse (KassenSichV n.a.). E-Rechnung: laeuft laut M BEREITS (Korrektur meiner Analyse; Verifikations-Read B3; XML-Aufbewahrung offen=A4). Register/Konformitaetsdoku angepasst, Gate G2 als bestanden vermerkt (Abnahme via D-056), T1-B3-Spez um Pakete 6-8 erweitert (USt-Laender-Machbarkeit PRIO, E-Rechnungs-Verifikation, GuV-Vorpruefung Aufwandsseite). Mail-Agent-Thema in diesem Thread geparkt (Skill w6-mail-agent geliefert; Start im neuen Thread, sofern M es nicht insgesamt verwirft). Naechster G-Schritt: nach T1s B3-Spez die Reads via G-READ fahren; danach B4-Paket (Bankstau/Konten) als erstes SCHREIB-Paket entwerfen — jeder Eingriff einzeln rueckrollbar.

2026-08-08 ~00:15 — Standup-System etabliert (M-Auftrag), Morgenlage #1 geliefert

M-Prioritaeten: 1 Gedaechtnis/GitHub · 2 Accounting · 3 Agenten · 4 Board-Defekte · 5 Doku/mkdocs. Abholrunde: KEINE neuen Lane-Meldungen seit 21:50 (T1-B3-Spez aus). Betriebslage: EIA/VKA gruen (runs bis 275), ABER Odoo-522-Fenster 22:03-22:48 UTC-1h?…(20:03-20:48 UTC): EIA 3x icp_unreadable + VKA odoo_scan_failed, selbstgeheilt; WD-02:00-Risiko besteht weiter (T2-B5 nicht deployt) — in Morgenlage als Warnung. Geliefert: Skill w6-morning-standup (Standup-Ritual + rollende Planung) · planning/ROLLING_PLAN.md (Erstbefuellung, 5 Straenge, M-Reihenfolge) · Morgenlage #1 als persistentes Artefakt "w6-morgenlage" · Git-Lane-Auftrag T-GIT-MEMORY_AUFTRAG_2026-08-08.md (18 uncommittete Pfade → 6 Gedaechtnis-Commits + .gitignore _to_delete/ + Push). Naechste M-Schritte im Briefing (Git-Lane, T1/T5/T2, w6-library-Repo).

2026-08-08 ~00:40 — INCIDENT dokumentiert: Amazon-Sperre B005DYM42A (Case 13113507432)

M-Meldung: 30.07. Qualitaets-Case mit 48h-POA-Frist → unbemerkt → 03.08. ANGEBOT GESPERRT (N 1235/61, Haupt-ASIN) → entdeckt 07.08. → Appell (10%-Stichprobe, 0 Fehler, DE/EN+PDF) 07.08. 23:27 eingereicht, "In Bearbeitung". G-Forensik: Die beiden kritischen Amazon-Nachrichten existieren NICHT im info@-Postfach (3 Suchen inkl. in:anywhere) — Fall lief NUR im Seller-Central-Fallprotokoll; Benachrichtigungs-Adressaenderung 22.04. (an p.vogt@) als offene Spur. Antwort auf Ms Frage: Odoo kennt KEINEN Listing-Status (nur indirekte Bestell-Anomalie moeglich). Drei Schutzschichten vorgeschlagen: R1 taegliche SC-Routine + Notification-Settings fixen (sofort) · R2 Bestell-Fluss-Anomalie-Waechter aus Odoo + Mail-P0 (n8n, kostenlos) · R3 SP-API-Listing-Waechter "amw" (Minuten-Latenz, eigener Agent). Incident-Datei W6_INCIDENT_20260803_AMAZON_ASIN_B005DYM42A_SPERRE.md; ROLLING_PLAN Strang 3 ergaenzt. Git-Auftrag 08.08. deckt die neuen Dateien mit ab (Pfad zulieferung/incidents/ bereits im Commit-Paket 3).

2026-08-08 ~00:55 — D-057: Amazon-Waechter-Programm beschlossen

M bestaetigt Staffelung R1/R2/R3. Geliefert: zulieferung/amw/ANLEITUNG_SP_API_ZUGANG.md (privater Entwickler, App W6-AMW-Waechter, Rolle minimal Product Listing, Self-Authorize, LWA-Tripel NUR in n8n als AMW_LWA_CLIENT_ID/SECRET/REFRESH_TOKEN, Meldung nur Laengen). D-057 in DECISIONS, ROLLING_PLAN Strang 3. Naechster G-Baustein: R2 Bestell-Anomalie-Waechter (n8n, read-only, D-050) — Konzept folgt nach T1-B3/T2; R3-Bau startet, sobald M "drin" meldet.

2026-08-08 ~09:15 — Standup #2 (ROT): WD-Fehlabschaltung Nr. 2, Morgenlage + Prompts geliefert

gov_actions 00:30 UTC: w6-wd disable_agent eia+vka (fail_streak eia/vka/gread — 522-Fenster Vortag + gread-Fehlversuche, UTC-Tageswechsel). Schalter-Spiegel 07:00: eia=0, vka=0. Positiv: kill_switch blockte EIA-Bau 03:30 UTC korrekt (Not-Aus-Kette bewiesen). OFFEN: Eintausch-Ticket aus run 313 (05:18 UTC, "1 Ticket, 0 Angebote NEU") — nach Ms Wiedereinschalten prueft G Triage/Cursor (Muster 6295). T1 nicht gestartet (keine B3-Spez), Git-Lane nicht gelaufen (21 Pfade). Geliefert: Morgenlage #2 (Artefakt aktualisiert), Incident-Nachtrag 20260807 (fail_streak-Facette), T2-B5 um 4 Punkte erweitert (rollierende Streak, Werkzeug-Ausnahme, keine Disables bei transienten Fehlern, erweiterter Harness-Beweis), ROLLING_PLAN Strang 3 ROT. M-Prompts fuer T2/Git/T1/T5 im Chat.

2026-08-08 ~09:35 — D-058 ausgerollt: Eindeutige Uebergabeorte (FLEET_REGELN v1.5)

M-Auftrag Strukturbereinigung umgesetzt: §1b-Orte-Tabelle (ABHOLEN=FREIGABEN-Kopfblock · ANMELDUNG=Sprint-Zeile in _AKTUELL · RUECKGABE=_AKTUELL mit §7 · PLAN=ROLLING_PLAN nur G · MENSCHEN-SICHT=mkdocs "Entwicklungsstand") · SPRINTBOARD.md durch Stub ersetzt · CLAUDE.md-Einstieg neu · Kopfbloecke AKTUELLER AUFTRAG in T1/T2/T5/T6-FREIGABEN gesetzt (T2 = Tages-PRIO WD; T6 + Pflichtsektion Entwicklungsstand) · PROMPTS v2-Nachtrag (Kennung reicht weiter) · D-058 in DECISIONS · Skill github-agent-memory v3 folgt an M. SCHALTER-LAGE 09:05: eia/vka/bma weiter ALLE 0 (Lauf 322 vka 07:05 error icp_unreadable) — M-Klicks stehen aus, Eintausch-Ticket von 07:18 wartet weiter!

2026-08-08 ~09:55 — D-059: Live-Doku-Architektur fixiert, T6 ENTBLOCKT

M-Entscheid "1:1 und live" umgesetzt: mkdocs-Site lebt IM fleet-ops-Repo (Zone T6: docs-site/ + mkdocs.yml), Generator spiegelt wortgetreu (ROLLING_PLAN=Startseite Entwicklungsstand, comms/*_AKTUELL je Lane-Seite, DECISIONS, Incidents, FLEET_REGELN), Cloudflare-Pages-GitHub-Integration baut je Push, privat hinter Cloudflare Access (oeffentliches GitHub Pages ausgeschlossen — Geschaeftszahlen). w6-library-Repo-Blocker ENTFAELLT fuer R1 (Library = spaetere kuratierte Stufe). T6-Kopfblock neu, ROLLING_PLAN Strang 5 entblockt, M-Deploy-Anleitung zulieferung/library/ANLEITUNG_CLOUDFLARE_PAGES.md (R2, nach R1-Abnahme). D-059 in DECISIONS. Reminder an M: Schalter EIA/VKA weiterhin aus (Stand 09:05-Pruefung), Ticket 07:18 wartet.

2026-08-08 ~10:05 — D-060: GitHub-Issues-Eingang; Start-Anleitung erneut an M

Issues = M-Fehlereingang (FLEET_REGELN §1b-Zeile; Abholung Standup via gh auf Mac-Lanes, Ausbau n8n-PAT nur-Issues); Projects-Board zurueckgestellt (eine Plan-Wahrheit). gh fehlt auf der Bruecke (geprueft); Git-Auftrag um Schritt 6 (gh-Check + Issue-Liste im STOPP) ergaenzt. M erhaelt komplette Fenster-Start-Anleitung (Reihenfolge Git zuerst — "Stand auf GitHub sehen").

2026-08-08 ~10:15 — D-061: Incident-Klassifikation + Status-Sicht, Alarm-Page geparkt, SP-API startet

Severity-Standard (Skala im Template) + Pflicht-Kopfzeile in allen 3 Incident-Dateien (Amazon=CRITICAL/OFFEN, WD=HOCH/BEOBACHTEN, Shopify=MITTEL/BEOBACHTEN) · T6-R1 um "Status & Incidents"-Sektion praezisiert (CRITICAL+OFFEN zuoberst, Detailseite je Incident, 1:1 aus GitHub) · ROLLING_PLAN Strang 6 (Alarm-Page D-049, geparkt bis nach Accounting) · SP-API-Registrierung durch M angestossen (Wartezeit laeuft parallel, kostet keine Lane-Zeit). Fenster-Lage weiter: kein "an" von M zu EIA/VKA im Chat — Ticket 07:18 offen (Stand letzter Pruefung 09:05).

2026-08-08 ~10:25 — D-062: Kickoff-Kreis geschlossen definiert (ERSTES ZIEL)

"Morning Kickoff" + "Update" als M-Befehle verankert (FLEET_REGELN §7.6, Skill w6-morning-standup v2 an M): Abholrunde → Plan → Briefing → T-SYNC-PUSH (neuer stehender Standardauftrag ablauf/T-SYNC-PUSH_STANDARD.md) → Push → Cloudflare-Build → Entwicklungs-Board im Browser. Fertig erst, wenn die Website den Stand zeigt. ROLLING_PLAN-Kopf: ERSTES ZIEL = live & up to date Doku (getragen von Strang 1+5). Einzige Luecke zur Webadresse: T6-R1 + Ms Cloudflare-Klickweg.

2026-08-08 ~10:35 — iTerm2-Setup dokumentiert (docs/ITERM2_SETUP.md)

Farbschema je Lane fixiert (GIT grau, T1 blau, T2 rot, T5 orange, T6 gruen; Badges = Kennung; Window-Arrangement "W6 Flotte" als Ein-Griff-Start). M-Fragen beantwortet: Live-Entwicklungsboard = planning/ROLLING_PLAN.md (Wahrheit im Repo) → sichtbar via GitHub-Browser sofort nach Push, als Website nach T6-R1+Cloudflare; Rolling Development ist in Skills (w6-morning-standup v2, github-agent-memory v3) + Repo-Regeln (§1b/§7.6) + Plan-Datei implementiert — kein zentrales Neu-Aufsetzen noetig, scharf wird es durch die heutigen Lane-Laeufe + Ms Skill-Speicherung.

2026-08-08 ~10:50 — D-063: Best-Practices-Abgleich + Wochen-Retro

Anthropic-Guidance gelesen und abgeglichen (Dokument in zulieferung/). Setup bestaetigt; uebernommen: w6push-Alias, Subagent-Review vor Gates, ausfuehrbare Checks, Worktree-Regel, Hygiene. Supabase bleibt Runtime-Schicht (kein Dev-Koordinations-Umzug; FLEET-MIRROR als spaetere Board-Ergaenzung), kein Eigen-MCP, Agent-Teams beobachten. §7.7 Wochen-Retro (freitags, max 3 belegte Verbesserungen). KEIN neues Skill — Weiterentwicklung laeuft ueber die Retro in die bestehende Familie.

2026-08-08 ~10:55 — Preflight iTerm2-Wechsel: 14/14 PASS (Repo-Seite)

Alle Kopfbloecke oben, Regeln v1.5 konsistent, Auftraege+Anleitungen vorhanden, Incidents klassifiziert, keine Streuner. Mac-Seite (iTerm2/claude/gh installiert?) prueft M im ersten iTerm2-Fenster per Einzeiler (im Chat geliefert).

2026-08-08 ~12:05 — D-064 Mac-Umzug vorbereitet; Git fast 100%

Git-Lane war gelaufen (Commits 7525afa/0e1ea85/09cc0ee gepusht) — offen nur noch die G-Schreibungen seit 11:49 (FLEET_REGELN, DECISIONS, G_AKTUELL, ITERM2_SETUP, DEV_SETUP, jetzt + SETUP_NEUER_MAC, THREAD_HANDOFF-Nachtrag, D-064). Umzugskoffer geschrieben: docs/SETUP_NEUER_MAC.md (Phasen 0-4, Abnahme im selben Thread, Plan B fuer Bruecken-Rebind). NAECHSTER SCHRITT M: T-SYNC-PUSH auf dem ALTEN Mac → G verifiziert "git status leer" + nennt die Referenz-SHA → dann Phase 1 auf dem neuen Mac. index.lock-Warnung bei git status gesehen (Bruecke darf nicht loeschen) — der SYNC-PUSH-Auftrag prueft/loest sie in Schritt 1.

2026-08-09 ~09:55 — Zwei Uebergabe-Skills an M geliefert (w6-mac-handoff + w6-thread-handoff)

Ms Bestellung: Mac-Handoff + Thread-Handoff, "bei aehnlich: alle Rueckstaende auf GitHub uebergeben, pruefen ob alle Dateien konsistent sind". Beide Skills teilen bewusst EINEN Standard: (1) Rueckstands-Pflicht (nichts lebt nur im Chat/auf dem Rechner: SYNC-PUSH bis git sauber, Referenz-SHA als Fixpunkt), (2) identischer Konsistenz-Preflight als kopierbarer Pruefblock (git sauber, Kopfbloecke oben, ROLLING_PLAN-Ziel, §1b-Regeln, Handoff-Doku, keine Streuner, keine Secrets + Sichtpruefungen), (3) Abnahme-Test auf der Gegenseite (Mac: Bruecken-Preflight + Kennungstest; Thread: Bootstrap-Prompt + Lagebestaetigung gegen Referenz-SHA). mac-handoff verweist auf docs/SETUP_NEUER_MAC.md (D-064); thread-handoff enthaelt den fertigen G-Bootstrap-Prompt und die Regel "alter Thread = Archiv, nie zwei G-Schreiber". Speicher-Status bei M offen (wie immer nur geliefert-Vermerk moeglich).

2026-08-09 ~10:05 — w6-leitstand an M geliefert (Dach-Skill der G-Rolle)

Ms Bestellung "Leitstand-Skill, der mit Fleet, Memory und Compliance arbeitet" erfuellt: w6-leitstand definiert die Rolle selbst — Mandat/harte Grenzen (plant/prueft/gibt frei; committet nie, §0b; keine Live-Schalter/Credentials; auditierte Einzel-Vollzuege nur auf M-Auftrag nach gact-Muster), Tagestakt (Kickoff → Freigabe-Kopfbloecke → Abholrunde → Gates → Freitags-Retro), Pruef-Doktrin (D-020 Belege, Datenlage schlaegt Meldung, adversarial by default, Spiegel≠Wahrheit, nie raten), Entscheid-/Incident-Hygiene (D-Nummern mit M-Wortlaut, Severity-Koepfe), Compliance-Betrieb (Leitstand/Werkbank, Evidence+_QUERIES, KEIN URTEIL, [OFFEN]-Ehrlichkeit), Skill-Landkarte (wann welches Familien-Skill) und Bootstrap via w6-thread-handoff. Damit ist die Skill-Familie vollstaendig: Rolle (leitstand) + Saeulen (fleet/memory/compliance) + Ritual (standup) + Wechsel (mac/thread-handoff) + Fach (odoo-core, buchhaltung, mail). Speicher-Status bei M offen.

2026-08-09 ~10:20 — Planungsphase Eintausch-Multimodell (nur Planung, kein Bau)

planning/PLAN_EINTAUSCH_MULTIMODELL.md geschrieben: IST-Ablauf (2 modellabhaengige Stellen: Script-Strecke A, EIA B — Payload traegt model/source_sheet bereits), Reiter-Idee bejaht + Kernergaenzung MODELL-MAPPING als eine Wahrheit (_CONFIG-Reiter als M-Pflegeort, agent_config als EIA-Wirkort, Drift-Check; unbekanntes Modell → Unklar-Route statt Default), Mail-Empfehlung eine Vorlage+Platzhalter, Phasenplan 0-3 (Verifikations-Reads V1-V6 → Mapping ohne Verhaltensaenderung mit Diff-Beweis → neues Modell im Schatten inkl. M-Testdurchlauf → scharf je Modell), Risiken-Register, M-Entscheide A-E (Systematik, Preisliste, Deckel>500, Paletten, Mail-Vorlagen). ROLLING_PLAN: noch KEIN Strang (Planungsphase; wird Strang nach M-Ok). Kein Zugriff auf Sheet/Script/EIA erfolgt — Stoerungsfreiheit ab Minute 1.

2026-08-09 ~10:30 — Multimodell-Plan praezisiert: Umstieg MIT 868 + 868-S (M-Wunsch)

Plan umgestellt: kein kuenstlicher Ein-Modell-Zwischenschritt — das Mapping wird direkt mit den zwei REALEN Varianten (W-NM-868, W-NM-868-S) erstbestueckt, Werte 1:1 aus Phase-0-Reads (neu V7: wie laeuft 868-S heute durch alle 5 Schritte). Phasen: 1 Fundament mit Diff-Beweis JE Variante (byteident zu heute) · 2 neue Referenz-Reiter parallel im Schatten + M-Testeinreichungen · 3 Formular-Umschaltung (M-Klick, Alt-Reiter eingefroren statt geloescht) · 4 jedes weitere Modell = Zeile+Test. M-Entscheid B praezisiert (Bestandswerte bestaetigen). Weiter reine Planung, nichts angefasst.

2026-08-09 ~10:45 — Planung "eintauschaktion-mehr-modell" TEIL 2: Express-Pfad + Erinnerungen

M-Erweiterung eingeplant (weiter NUR Planung): Express-Knopf "Ich will nicht warten!" in Code-Mail → Express-Form (Ruecksendeverzicht/Haftung, Sendungsnr, Belegfoto, Verwertungs-Erklaerung) → SOFORT-Angebot (V8: Webhook-Trigger vs. Polling); Deal klar: sofortiges FINALES Angebot, kein Zweitangebot, keine Einlagerung — Werkstatt/Palette intern unveraendert (D: eine Palette). Marketing-Footer + Widerspruchs-Log als Pflicht-Gate VOR jeder Erinnerung; Reminder-Engine R1=T+3 12:00, R2=erster Sonntag nach T+5 19:00, Stopp-Gates, max 2, datengetriebene Nachschaerfung ueber Annahmequoten. VIER Rechts-/Formulierungspunkte an M markiert (R-1 Recycling-Wortlaut muss WAHR sein — Textvorschlag geliefert; R-2 Haftung/Preisbindung; R-3 Zulaessigkeit Erinnerungen; R-4 Belegfoto-PII). Arbeitspakete AP0-AP5 mit Abhaengigkeiten, Abend-Testfenster, 100%-Rollback je AP, alles schaltbar (Toggles im D-050-Regime). B/D von M entschieden (Odoo-Preise, eine Palette). Betrieb weiterhin unberuehrt.

2026-08-09 ~10:52 — Teil-2-Freigabe (D-065) + M-Ansage: Odoo-Core / Git / Board live / Kickoff / iTerm2

• D-065: V8=Webhook-SOFORT (kein Polling fuer Express) · R1–R4 ok · R-3 in ODOO (Selbstabmeldung, Tabelle=Spiegel, Versand-Gate prueft Odoo, AP0+V9) · Reminder R2 = So nach T+5 09:00 · Klueger-machen bestaetigt. PLAN Par.12 geschrieben. Offen: Modell-Liste (B), Startfreigabe AP0.
• M-Ansage: jetzt erst Odoo-Core; alles auf Git aktuell; Entwicklungsboard live (mkdocs nachziehen); Morning Kickoff; iTerm2 aufsetzen und Lanes starten. → Kickoff #3 gefahren (Abholrunde, Plan gerollt, Morgenlage aktualisiert); Lane-Start-Fahrplan an M im Chat.

2026-08-09 ~11:12 — M hat EIA+VKA eingeschaltet · Befund 10 wartende Tickets · G-Eingriff Cursor-Reset (dokumentiert, rueckrollbar)

• Verifiziert (WD-Spiegel 11:00 + Registry): w6.eia.enabled=1, w6.vka.enabled=1, BMA bleibt korrekt AUS (wartet auf B4). M-Meldung im Chat mit Board-Screenshot.
• Folgelauf 452 (11:03) kam mit N0 — die seit Sa 02:30 geparkten Vorgaenge werden vom Takt NICHT nachgeholt: Scan-Domain ist id > scan_cursor.last_id (stand 6352), der Cursor war ueber alle geblockten Tickets hinweggewandert.
• BEFUND-KORREKTUR zur Morgenlage #3: nicht 2, sondern 10 wartende Eintausch-Vorgaenge seit Sa frueh (runs 313/331/336/341/349[2 Tickets]/370/376/378/446; Tickets 6333–6352; alle „0 Angebote NEU", Bau vom kill_switch geblockt, P1).
• EINGRIFF (G, Infrastruktur Supabase — kein Odoo-Write): scan_cursor eia VORHER {"last_id":6352} → NEU {"last_id":6332} via public.w6a_set_cursor. Wirkung: naechster Takt (11:18) scannt die 10 Tickets erneut. Doppel-Angebots-Schutz belegt aus Flow v0.4: Scan-Domain stage_id=1; „Angebot suchen"/Reparatur-Pfad findet vorhandene Entwuerfe per client_order_ref W6TI: und ergaenzt statt neu anzulegen (nur draft). ROLLBACK: w6a_set_cursor eia {"last_id":6352}.
• Design-Befund fuer T2/EIA v0.5 (notiert): Bei kill_switch-Block darf der Cursor NICHT vorruecken — sonst fallen geblockte Tickets aus dem Scan-Fenster (genau das ist Sa passiert). Kommt in den T2-Kopfblock bei naechster Fortschreibung.
• D-050-Hygiene: Lauf 210 (Fr, stale, hing 48h im Board als IN ARBEIT mit Ticket 6310) per w6a_report run_end status=error nachgeschlossen; Board-Kopf/IN-ARBEIT-Karte raeumen sich beim Refresh.

2026-08-09 ~11:22 — VOLLZUG: Rueckstau abgearbeitet — Lauf 454 = 10 Tickets · 10 Angebote NEU

• 11:18-Takt (run 454, ok, 32s): alle 10 geparkten Tickets verarbeitet — 6333/6337/6338/6340/6342/6343/6346/6347/6348/6352. 8x W-NM-868-S zu 349, 2x W-NM-868 zu 399; 1 Bestandskundin per Match (170 P., #14365), 9 Kunden neu angelegt (#43994–#44004) und je ans Ticket gesetzt. Outcome P1 → 10 neue Vorschlagskarten auf dem Board (Odoo-Links). Cursor regulaer wieder auf 6352.
• WICHTIG (Flow-Beleg v0.4, Node „Versand pruefen (V)"): Der Angebots-VERSAND ist per Design D-043 an die ANKUNFT der Maschine gekoppelt (genau 1 Entwurf je Code · draft · 0<x<=500 · Partner · Palette gezogen → Template 12, state→sent). Die 10 Entwuerfe sind damit versandbereit; kein manueller Versand-Schritt noetig. Waere eine Maschine WAEHREND des Rueckstaus angekommen, haette der Versand mangels Entwurf geskippt („kein_entwurf") — ab jetzt selbstheilend.
• Preis-Drift-Hinweis in 7 Karten: „Odoo-Listenpreis 549 passt nicht zur Aktion (499)" bei 868-S (Angebot korrekt zu 349 angelegt). Bestehender Daten-Drift am Produkt — Klaerung mit Ms Modell-Liste (Entscheid B, Strang 7).
• Registry-Spiegel 11:00: eia=1, vka=1, bma=0 (korrekt aus bis B4).

2026-08-09 ~12:25 — SYNC-PUSH verifiziert · REFERENZ-SHA fc14ef5 · Mac-Umzug Phase 0 ABGESCHLOSSEN (D-064)

• GIT-Lane-Meldung 12:18 gegengeprueft: Arbeitsbaum sauber (0 Pfade), HEAD = origin/main = fc14ef5, Spanne 09cc0ee..fc14ef5 = 9 Pfade wie gemeldet; _to_delete/ korrekt draussen. Secret-Grep-Treffer Z.148 als False Positive bestaetigt (Textstelle "ask->always", kein Schluessel).
• REFERENZ-SHA fuer den Mac-Umzug: fc14ef5 — Phase 0 (100% Git) damit erledigt. Der Konsistenz-Preflight auf dem neuen Mac prueft gegen diesen Anker oder Nachfolger (docs/SETUP_NEUER_MAC.md, Phasen 1–4 folgen am neuen Geraet).
• Lauf-Anmerkungen der Lane bewertet: verwaiste .git/index.lock (09:38) nach Prozess-Pruefung geloescht = korrekt nach Standard; pull-rebase-Abbruch bei 0 Commits Rueckstand = unbedenklich, Push lief auf aktuellem Remote-Stand.

• iTerm2 steht (M-Screenshot ~12:00): Profile Default/GIT/T1/T2/T5/T6 + Reserve T3/T4. Naechster Schritt: Lanes T6/T1/T2/T5 starten (Kennung als erste Nachricht).

• NACHTRAG ~12:28 — index.lock-Ursache GEFUNDEN: Gs Lese-git status ueber die Cowork-Bruecke legt eine .git/index.lock an, die die Bruecke nicht loeschen darf (unlink verboten) → so entstand die verwaiste Lock von 09:38 (und eben eine zweite). Behoben: Lock per mv nach _to_delete/ geraeumt (Bruecke darf mv). REGEL ab jetzt: G liest ueber die Bruecke NUR mit git --no-optional-locks status (legt keine Lock an); Lane-seitiger pgrep-Lock-Check im T-SYNC-PUSH-Standard bleibt als zweites Netz.

2026-08-09 ~20:42 — Modell-Liste geliefert (Entscheid-B-Input) + M-Konzept Schalter/Bedienung → Plan Par.13

• M liefert Odoo-Export: 44 Varianten + Stickeinheit (zulieferung/eintausch-mehr-modell/). Befunde: Grundmodell/-S-Muster durchgaengig; 4 Referenzen mit haengendem Bindestrich (EU7+Software) → in Odoo bereinigen; keine Preise in Liste (korrekt — live aus Odoo); teure Modelle brauchen Entscheid C vor Aktivierung.
• M-Konzept: Apps-Script-Menue / Odoo-Systemvariablen / Board mehr-Optionen. G-Empfehlung in Par.13: Wahrheit agent_config, Bedienung BOARD (Ms Favorit, Audit via gov_actions, AP6 T5), Verteilung n8n→_CONFIG-Reiter+Jotform-Optionen, Apps-Script-Menue nur Anzeige, KEINE Odoo-ICPs je Modell (D-054), Unklar-Route bleibt das Netz.

2026-08-09 ~21:05 — ABEND-ABHOLUNG: T1/T5/T6 FERTIG, T2 am GATE · Eintausch Scope D-066 + AP0-R1

• T6-R1 ✓ (13:20, f02ef7c): mkdocs-Site + 1:1-Generator, Build --strict gruen, Spiegel-Beweis 17/17, Incidents nach D-061; Cloudflare-Korrekturanlage liegt. → Es fehlt NUR Ms Pages-Klickweg (R2). B-T6-01: Hetzner-Incident ohne Kopfzeile (G traegt nach).
• T5-R9 ✓ (20:40, 13ff2d2): Board v0.9.6 — P0-Ursache war preact-10.19.3-Kind-Diff (nicht verdict-Pfad); Doppelfix + DOM-Test + Debug-Felder + Regex-Suche. M-Kurztest offen.
• T1 B3-Spez ✓ (20:50, 984b081/f11befe): 10 Pakete, 34 Abfragen, Abgleichstabelle; Vollzug G via G-READ. T1-Beobachtung geteilter Arbeitsbaum in f11befe notiert.
• T2 GATE 5 (21:00, uncommitted): WD v0.2.3 gebaut+publiziert. Ursachen: UTC-Datums-Signatur (alle 3 Faelle erster Takt nach 00:00Z) · Schwelle war kein Streak (EIA bei 95/98 Erfolgen abgeschaltet) · 25/25 Fehler=Infra/Werkzeug/Not-Aus. Neu: Quote+Mindestbeleg 4 · Zwei-Takte-Regel (beantwortet B1) · "fehlende Info sperrt Eingriff" · wd-Registry (Abweichung schedule 30min dokumentiert). F21 an G: kill_switch-Blocks buchen 'error' → Abschaltspirale; G-Fixpaket (EIA/VKA/GRT-1 'partial' + Cursor-Halt bei Block) als Abend-Vorschlag an M nach T2-Abnahme. G-Abnahme Mo frueh MIT Nacht-Beleg 00:00–02:30Z.
• Ms Eindruck "nicht weit gekommen" aufgeklaert: T2 hatte (korrekt) noch nicht committet — Arbeit lag als GATE im Baum; T6 war seit 13:20 fertig.
• Eintausch: Scope D-066 fixiert (AB Sheet BIS Odoo; Jotform nur M, je Aktion, selbes Sheet; Anwendung auf 868/868-S; KEIN Code — reine Planung). AP0-R1 gefahren, Befunde PII-frei in zulieferung/eintausch-mehr-modell/AP0_BEFUNDE_RUNDE1.md; Plan Par.14; Ms Mail-Fragen beantwortet (Script liefert — Beleg 17:28; Multimodell-Mails via EINE Platzhalter-Vorlage).

2026-08-09 ~22:15 — D-067: Worktree-Isolation + Identitaets-Stack beschlossen, vorbereitet, Skill v2 geliefert

• M-Wahl A+C nach Options-Dialog; Online-Recherche (offizielle Docs): (1) Claude Code ERZWINGT Worktree-Isolation nativ (blockt Edits/Bash/git-Umwege Richtung Haupt-Checkout), (2) SessionStart-Hook injiziert Identitaet automatisch — uebersteht resume UND compact, (3) PreToolUse kann fremde Writes mit deny verweigern → Zonen-Matrix wird Mechanik statt Regel.
• Vorbereitet (NICHT aktiv): ablauf/worktree-isolation/ (ANLEITUNG, retrofit_worktrees.sh, hooks/lane_identity.sh + zone_guard.sh + settings-Beispiel, zones.conf.ENTWURF) · FLEET_REGELN Par.0c · CLAUDE.md-Sektion · PROMPTS v3 · ITERM2-Nachtrag. Aktivierung Mo an sauberem Punkt (nach T2-Abnahme + SYNC-PUSH), Stufe 1 Identitaet sofort, Stufe 2 Zonen-Waechter nach G-Review der zones.conf.
• Skill parallel-dev-fleet v2 als .skill an M geliefert (Lane-Isolation-v2-Kapitel, 2 Betriebsmodelle, Mehr-Fleet-Regeln, Cowork-Governor-Regel --no-optional-locks, Hooks+Retrofit als Assets).

2026-08-09 ~22:25 — PPWR-Pruefauftrag beantwortet (nur Machbarkeit, D-020-sauber)

• [W6-ODOO · GOV] Pruefauftrag PPWR-Reiter: Antwort mit Urteilen 1–6/a–e, Klickliste (12 Schritte) und Schaetzung ~8–10 h in 3 Abendpaketen abgelegt: zulieferung/ppwr/PRUEFANTWORT_PPWR_REITER_2026-08-09.md. Offener Beleg: Aktionstyp Python auf der Instanz (1-Min-Klick von M oder gread-fields_get morgen). Keine Umsetzung, kein Write in Odoo. STOPP.

2026-08-09 ~22:45 — PPWR-Pruefauftrag 2 beantwortet (FIFO/Meldeauszug)

• Urteile 1–6 + Empfehlung WEG 3 (rechnerisches FIFO, Stoerung KEINE, ~2,5–3,5 h, kein P4 — waechst in P1/P3): zulieferung/ppwr/PRUEFANTWORT_2_FIFO_MELDEAUSZUG_2026-08-09.md. Native Lose fuer Zubehoer als MITTEL-invasiv eingestuft (Einmal-Inventur = Altdaten-Pflege, Versand-Mehrschritt) — nur bei harter Portal-Anforderung. Klaerpunkte: K1 Kanal-Abdeckung, No-Code-Mengenuebernahme, Serien-Status Maschinen. Kein Odoo-Write. STOPP.

2026-08-09 ~23:00 — P1-BAUBLATT PPWR geliefert (weiter reine Planung)

• M: "erstmal nur plannung" + Startbefehl-P1-Text → BAUBLATT statt Bau: zulieferung/ppwr/P1_BAUBLATT_PPWR_REITER_2026-08-09.md. Zwei Bau-Entscheide dokumentiert: exakte x_ppwr_-Namen via Entwicklermodus-Anlage (Studio wuerde x_studio_ erzwingen) + PKG-ID-Duplikate ueber Gruppier-Favorit (harte Unique braeuchte Addon). Ergaenzte Relationsfelder benannt (x_product_id/x_charge_id/one2many-Traeger), LUCID-Selection mit stabilen Keys. Aufwand ~3,5–4,5 h. Kein Odoo-Write. ROLLING_PLAN: PPWR als Strang 8 beim naechsten Kickoff-Rollen aufnehmen.

2026-08-09 ~23:05 — PPWR als Strang 8 erfasst (D-068)

• M-Prioritaet: separates Entwicklungsprojekt, NACH Buchhaltung. ROLLING_PLAN Strang 8 angelegt (Ziel, Meilensteine, P1–P3, Klaerpunkte, Ruht-bis-Regel); DECISIONS D-068. Naechster PPWR-Trigger: Accounting-B4 laeuft + Ms "P1 bauen".

2026-08-10 ~01:15 — PPWR MELDEWEGE: Phase A (rein lesend) komplett · KEIN Bau · alles im Projekt abgelegt

• M-Ansage: nicht bauen, nur Planung; Ausfuehrung nach Accounting; Ablage im PPWR-Projekt. Uploads (MELDE_MATRIX v0.1, FELDLISTE v1.0) + PHASE-A-BEFUND nach zulieferung/ppwr/.
• Reads via G-READ 533/534/535 (Board-gebucht, run_end ok): A1 Gewichts-Luecken 10/114 (Kern-45 vollstaendig) · A2 Liefer- vs Rechnungsbasis (Lieferbasis empfohlen; FBA-Restfrage an D.M.) · A3 Retouren ~2 %, Regel ear-netto/LUCID-brutto vorgeschlagen · BONUS: ir.actions.server state enthaelt "code" (+2 produktive Code-Actions 1768/1769) → PA1-b BELEGT · stock.move.weight existiert → ear-kg nativ im Pivot.
• P1-Baublatt um B1-Felder (x_weee_relevant, x_ear_geraeteart) ergaenzt; Phase B in P1/P3 eingeplant (~4,5–5,5 h). G-READ-Workflow bleibt in PPWR-A-Lauf-3-Konfiguration (harmlos, read-only; naechster Nutzer rekonfiguriert eh).

2026-08-10 ~02:38 — NACHTWAECHTER-CHECK: NACHT-BELEG POSITIV (WD v0.2.3 besteht den Live-Test) [nachgetragen beim Kickoff, Bruecke war 02:38 offline]

• gov_actions seit 23:45Z: KEIN EINTRAG — erste UTC-Mitternacht seit drei Naechten ohne Alarm/Vorwarnung/Abschaltung (Vergleich 07./08./09.08.: je fail_streak im ersten Takt nach 00:00Z).
• WD laeuft als REGISTRIERTER Agent (B6 wirkt): Runs 537/540/544, kritische Takte 00:00:47Z + 00:30:47Z je "0 neue(r) Befund(e) · ok". EIA/VKA alle ok, Schalter eia=1/vka=1/bma=0, Cursor 6361/8405.
• NACHARBEITSPUNKT (kein Blocker): WD-Anlaufschutz meldet fehlenden eigenen ICP w6.wd.enabled in Odoo — Anlage nach GATE-Abnahme (M-Klick oder gact-Einzelauftrag).
• Keine Eingriffe, M nicht geweckt.

2026-08-10 ~07:50 — KICKOFF #4: T2-GATE-5 ABGENOMMEN (mit Nacht-Beleg) · Betrieb GRUEN

• Abholrunde: T2 hat gestern Abend selbst committet (47ace98 v0.2.3 + 0c4bcda G-Mitschrieb + 9eb39bf Audit-Luecken-Doku §6b) — vorbildliche Rueckgabe. Betrieb: 0 Fehl-Laeufe seit 22:00Z, 0 gov-Eintraege seit 00:35Z, Morgenlaeufe gruen (eia N0, vka leer, wd Anlaufschutz, Digest 05:30 versendet). Schalter eia=1/vka=1/bma=0.
• GATE 5 ABGENOMMEN; Antworten auf T2s 6 Entscheide im FREIGABEN-Kopfblock (F21→G-Abendpaket · Not-Aus-Verhalten bestaetigt · fail_profile als v0_9_13 · Quote-Grundsatz angenommen · schedule-Nick · ICP-Anlage an M). §6b wichtig fuer Nachschau: UI-Schaltungen erzeugen KEINE gov_actions-Zeile (erklaert Ms Einschalten gestern 11:00 ohne Audit-Eintrag) — Board-Weg bevorzugen.
• Heute-Reihenfolge M: w6push (10 Pfade) → DANACH Worktree-Skript D-067 (braucht sauberen Baum) → Cloudflare-Klickweg (letzter Schritt Ziel 1) → Board-Kurztest → Odoo-Parameter w6.wd.enabled=1 → T2-Fenster schliessen. G heute: B3-Reads (nach Push), F21-Abendpaket, zones.conf-Review, v0_9_13-Abstimmung.

2026-08-10 ~08:00 — Push f7d481a verifiziert · T6-R2 freigegeben · Lane-Prompts fuer den Umstelltag an M

• SYNC-PUSH 9eb39bf..f7d481a (20 Pfade, 3 Commits) gegengeprueft: HEAD=origin/main=f7d481a, Baum sauber ausser _to_delete/. Lane-Hinweis (rebase erst nach Commit weil dirty) fachlich korrekt gehandelt — Standard deckt den Fall sinngemaess.
• T6-R2-Kopfblock gesetzt (Deploy-Verifikation nach Ms Cloudflare-Klickweg). T1 heute ohne Auftrag (G faehrt B3-Reads). T5 wartet auf Ms Board-Kurztest, danach R10-Freigabe.
• Reihenfolge an M: Worktree-Skript JETZT (Baum sauber!) → iTerm2-Startverzeichnisse → GIT-Lane Stufe-1-Auftrag (Identitaets-Hook, nur SessionStart-Block) → T2 "weiter" (liest Abnahme, schliesst) → Cloudflare-Klickweg → T6 starten (R2).

2026-08-10 ~08:10 — PRUEFBEFUND: Worktree-Umstellung NOCH NICHT gelaufen (w6push-Verwechslung, kein Schaden)

• Ms "fertig" zeigte die 07:52er-w6push-Meldung erneut — der Alias faehrt den festen SYNC-PUSH-Auftrag und kann den Umstellungs-Auftrag nicht transportieren. Beleg: kein Commit nach f7d481a, git worktree list = nur Haupt-Checkout, keine .lane, kein .claude/hooks, .lane nicht in .gitignore.
• Weg vereinfacht auf DREI Kommandos im nackten Terminal (kein Claude noetig): w6push (raeumt die 2 frischen G-Pfade) → retrofit_worktrees.sh → NEU stufe1.sh (kopiert Hook + settings SessionStart-only, committet, pusht; bricht ab falls settings.json schon existiert). Vorlagen ergaenzt: hooks/settings.stufe1.json + stufe1.sh.

2026-08-10 ~08:20 — Umstellungs-Anlauf 1 analysiert: 3 Ursachen, alle behoben (stufe1.sh v2)

• Befund aus Ms Terminal: (1) w6push-Alias existiert in ~/.zshrc NICHT (command not found) → Schritt-1-Commit fehlte; (2) retrofit brach KORREKT ab (Vorbedingung sauberer Baum — Skript-Schutz hat funktioniert); (3) NEU ENTDECKT: .gitignore ignoriert das GANZE .claude/ → Stufe-1-add wurde verweigert; Teillauf hat Hook+settings nur LOKAL abgelegt, kein Commit.
• Fix: stufe1.sh v2 praezisiert die .gitignore ('.claude' → '.claude/settings.local.json'), erkennt den eigenen Teillauf (cmp mit Vorlage), added mit -f, committet, pusht. Schritt 1 fuer M jetzt als direkte git-Kommandos (Alias optional nachruesten).

2026-08-10 ~08:30 — Umstellungs-Anlauf 2: Stufe 1 AKTIV (0ac6ea4) · Worktrees fehlen noch (_to_delete-Check)

• Schritt 1 ✓ 31b3e65 · Schritt 3 ✓ 0ac6ea4 (Hook+settings committet; Nebenbefund: gitignore-Regel lautet ".claude/" — grep-Korrektur griff nicht, add -f hat sie ueberwunden; Dateien jetzt tracked = kuenftig normal versioniert; bei Stufe 2 add -f einplanen oder Regel praezisieren) · Alias w6push ✓ in zshrc.
• Schritt 2 ✗: retrofit-Sauberkeits-Check zaehlte den absichtlich uncommitteten _to_delete/-Ordner als unsauber — Skript-Fix: Check ignoriert _to_delete/ jetzt (und zeigt bei Abbruch die stoerenden Pfade). An M: rm -rf _to_delete (laengst ueberfaellig, nur Muell: Base64-Teildateien + stale index.locks) + Skript erneut.

2026-08-10 ~08:40 — D-067 VOLLZOGEN: Worktree-Isolation + Ordner-Identitaet AKTIV

• Verifiziert: 5 Worktrees (Haupt=main c50da19 + T1/T2/T5/T6 auf lane/t*-Branches, je .lane gesetzt), .lane=GIT im Haupt-Checkout, Hook+settings committet (0ac6ea4) und via Checkout in allen Worktrees wirksam, Baum sauber, _to_delete geloescht (rm durch M). Commits der Umstellung: 31b3e65 · 0ac6ea4 · 05e5fc2 · c50da19.
• Ab jetzt: Fach-Lanes NUR in ~/W6_LANES/ (Start: claude + "start"; Identitaet automatisch, uebersteht resume/compact); Haupt-Checkout = G-Schreibort + GIT-Lane. Erster Live-Beweis der Identitaets-Injektion kommt mit dem T6-R2-Start. Stufe 2 (Zonen-Waechter) erst nach G-Review der zones.conf.

2026-08-10 ~09:15 — B3 GESTARTET: P0 (Lauf A) KOMPLETT — alle Feldwege gruen

• gread 593/594 (exec 9161/9162, je HTTP 200): 4x fields_get roh nach evidence/B3/01–04 + _QUERIES.md mit P0-Wertung. ALLE 15 Zielfelder existieren in v19 — keine Rueckfallvarianten noetig; P1/P2/P5/P6/P7 wie spezifiziert.
• Zusatzfunde: account.tax.integration_id (E-Commerce-Store = Kanal-Marker am Steuersatz, nuetzlich fuer P6 und die PPWR-A2-Frage) · l10n_de_datev_code am Steuersatz · ubl_cii-Felder (P7). Naechster Lauf: B (P6 USt-LAENDER, PRIO).

2026-08-10 ~09:30 — D-069: "P1 bauen" + Lane T7 (PPWR) gegruendet

• T7-Kopfblock (R1 Werkbank: MANIFEST_P1.json, IMPORT_VORLAGEN, VERIFIKATION_P1, REGISTER_ENTWURF — kein Odoo-Zugriff) + CLAUDE.md-Routing + zones-Zeile geschrieben. Vollzug: G per gact nach T7-Manifest, M nur Studio-Phase-B.
• Reihenfolge M: w6push (nimmt Kopfblock+B3-Evidence mit) → retrofit_worktrees.sh T7 → iTerm2-Profil T7 (Working Dir ~/W6_LANES/T7, Trust) → T7 "start".

2026-08-10 ~09:45 — M-Auftrag E1 (Eintausch-Zwischenschritt) angenommen + Prompt-Runde ausgegeben

• E1-Spez geschrieben (4 Bausteine E1.1 Titel-Datum [base.automation+Python-Action] · E1.2 Versand-Chatter [EIA v0.4.1, 1 Node] · E1.3 dynamische Palette [Werkstatt fuehrt, Warnnetz 40/45] · E1.4 Werkstatt-Dashboard inkl. Recycling-Reiter [Studio, Muster Schnaeppchen-Einbuchen]). Naechster G-Schritt: Detail-Reads via gread (Stufen-ID, x_studio_eintausch_*-Felder, Schnaeppchen-Muster) + Lauf B (P6 USt-Laender) weiter.

2026-08-10 ~09:50 — TRIAGE Ticket 6263 (M-Meldung "Angebot nicht verschickt"): URSACHE = F25, Versand-Pruefer-Duplikat-Bug

• Beleg-Kette: run_log 73 (06.08.: Angebot S37710 NEU, 399 EUR) · run 596/exec 9165 (10.08. 09:18: ZWEI Ankuenfte im selben Takt, 6227+6263) · Node "Angebot suchen (V)" lief PRO ITEM → jeder Entwurf DOPPELT in der Trefferliste → Pruefer-Skip "mehrere_entwuerfe" fuer BEIDE → none:true OHNE Log (Skips unsichtbar). Beide Angebote (S37710 Woehner 399 / S37687 Sohl 349) sind korrekt und draft — nur der Versand unterblieb.
• Verschaerfung: Tickets gelten jetzt als registriert (existing) → kommen dem Versand-Pruefer NIE wieder vor — ohne Eingriff kein Auto-Versand mehr fuer diese zwei. SOFORT-Klickweg an M: beide Angebote manuell versenden.
• F25 (EIA v0.4): (a) "Angebot suchen (V)" ohne executeOnce → Duplikate bei >=2 Ankuenften/Takt → Fehlskip mehrere_entwuerfe; (b) none-Zweig verwirft skips OHNE Logging (stille Nicht-Versendung). Fix-Paket (executeOnce + Dedupe im Pruefer + Skip-Logging) als SOFORT-Fix vorgeschlagen (M-Ok ausstehend), sonst Abendrunde zusammen mit E1.2/E1.3. Erstmals ausgeloest heute — bisher kam nie mehr als eine Ankunft je Takt.
• Nebenbefund: w6a_palette_next2 liefert bei manual:true slot=null ("Platz null/25" im Chatter) — kosmetisch, in E1.3-Umbau mitbeheben.

2026-08-10 ~09:55 — Drei Skill-Updates an M geliefert (Lektionen 08.–10.08.)

• parallel-dev-fleet v2.1 (Retrofit-Haertungen aus dem Erst-Rollout: Schreibstopp-Regel, _to_delete-Toleranz, gitignore-Varianten/add -f, keine Alias-Abhaengigkeit, Push-vor-Worktree; stufe1.sh + settings.stufe1.json als neue Assets; retrofit auf v2-Stand).
• github-agent-memory v4 (Worktree-Aera: getrennte Arbeitskopien/geteiltes Gedaechtnis, Identitaet im Dateisystem ueberlebt compact, Lane-Onboarding-Reihenfolge, Governor-Schreibstopp, Bruecken-Regeln inkl. PENDING-Muster, Beleg-schlaegt-Meldung).
• odoo-core-system v3 (Runtime: Quote statt Anzahl + Zwei-Takte + fehlende-Info-sperrt, F21 partial-Buchung, Cursor-Disziplin+Reset-Verfahren, F25 executeOnce+Skip-Logging, Nachhol-Mechanik-Gebot, Audit-Luecke UI-Schaltungen, Anlaufschutz).
• Speichern im Konto macht M (ersetzen v2/v3/v2-Vorgaenger). Auslieferung als .skill-Dateien im Chat.

2026-08-10 ~10:20 — EINSCHUB-TRIPEL: Slowdown vermessen · Stufen-Notfall entwarnt · F25-Nachhol-Liste komplett

1) Odoo-Slowdown (M-Meldung ~09:50, "laeuft wohl wieder")

• Fenster ~08:15–10:00 Berlin. Alle Agent-Laeufe ok (0 Fehler, 0 Skips durch Timeout). Ausreisser: run 587 (06:18Z, 5,7s) und run 601 (08:00Z, WD 22,3s statt ~2,5s). Seit 10:03 Berlin wieder Normalwerte.
• Signatur des 06.08.-Incidents (HTML statt JSON, E3:icp_unreadable, Odoo-18-Port) liegt heute NICHT vor. Kein Eingriff noetig gewesen, keiner erfolgt.
• Heisser Kandidat aus offenen Incident-Nacharbeiten: nie rotierte odoo18.log (8,7 GB). SSH-Checkliste bei M.

2) Stufen-Notfall "Reiter Eintauschaktion ist weg" (M-Meldung ~10:00, Auflage: nur Analyse)

• gread-Run 603 (exec 9182): Stufe id=40 "Eintauschaktion" EXISTIERT, aktiv, team_ids [1], sequence 4. Alle 10 bekannten Tickets unversehrt und aktiv in Stufe 40. KEIN Datenverlust.
• Spur: write_uid [174, Werkstatt] schrieb 07:28:25/07:28:42Z (=09:28 Berlin, mitten im Slowdown-Fenster) nahezu ALLE Team-1-Stufen — Muster einer Kanban-Bearbeitung/Umsortierung (Spalte gefaltet/verschoben). Passt zeitlich zu den Werkstatt-Ankunfts-Zuegen 09:18/09:33 (runs 596/598).
• 10:12 M-Bestaetigung: "eintauschaktion ist wieder da." → Ansichts-Phaenomen, kein Systemschaden. Kein Eingriff erfolgt (Auflage eingehalten).
• Merker fuer Abend-Runde (nicht dringend): write_dates 03:30:47Z an Tickets 6212/6218 — Verursacher unbelegt, nachpruefen bevor Deutung.

3) F25-Nachhol: finale manuelle Versandliste (gread-Runs 605/606, execs 9185/9186)

• Odoo-Bestand: 80+ W6TI-Angebote, davon in Stufe 40 (Maschine angekommen, Kunde wartet):
• UNVERSENDET (draft, nur Senden-Klick noetig): S37687 (T-6227), S37689 (T-6229), S37699 (T-6240), S37704 (T-6247), S37710 (T-6263) — 5 Stueck. Die zuvor kommunizierte 2er-Liste war unvollstaendig; heutige Ankuenfte 09:18/09:33 wurden von F25 erneut geskippt (kein arrival:send heute, Beleg run_log 596/598).
• VERSENDET: nur S37807 (T-6295, 07.08. 00:18Z, einziger D-043-Autoversand bisher).
• OHNE JEDES ANGEBOT: Alt-Ankuenfte T-6218/T-6219 (echte Kundenfaelle, warten seit 06.08. 10:03!) + T-6220 (M-Eigentest) + T-6212 (Testticket). Ursache: Ankunft VOR Aktivierung der Angebots-Anlage (erster arrival:send 07.08. 00:18Z). → Fuer 6218/6219 manuelle Angebots-Anlage durch M ODER Nachhol-Mechanik im Abend-Fixpaket.
• ZUSATZBEFUND Palettenzaehler: run 596 (09:18) schrieb "Palette 1, Platz null/25" in Chatter von T-6227/T-6263 (Zaehler-Luecke!); run 598 (09:33) zaehlte korrekt 6/7/8. Kapazitaet hart /25 statt 40–45 → bestaetigt E1.3-Bedarf (dynamische Paletten-Logik).
• Werkzeug-Haertung gread: beide Query-Nodes jetzt executeOnce (F25-Lektion aufs eigene Werkzeug angewandt; Node 2 lief zuvor pro Input-Item). Run 606 endete bei leerem Ergebnis vor dem Run-beenden-Node (bekanntes Ketten-Muster) — manuell per run_end geschlossen, alle 3 gread-Runs (603/605/606) sauber ok.
• OFFEN M: 5x Senden-Klick + Entscheid 6218/6219 (manuell vs. Fixpaket) + "Fix ok" fuer F25-Abendpaket (executeOnce+Dedupe+Skip-Logging+Nachhol-Lauf).

2026-08-10 ~10:35 — F25-FIX PUBLIZIERT (M-Go per Frage-Antwort: "Fix veroeffentlichen + du klickst die 5")

• EIA v0.4 (qbFWK43P5O7BRPKx): aktive Version jetzt 8715a982, Rueckweg 8bc55291 (Versionshistorie).
• Aenderung (kundenwirksamer Versand-Zweig, 3 Punkte):
• "Angebot suchen (V)" → executeOnce=true (lief zuvor pro Input-Item = Treffer-Duplikate = Root-Cause 06263 "mehrere_entwuerfe").
• Versand-Trigger von "Chatter-Vermerk" (nur Neu-Ankunft) auf "Ankunft auswerten" umgehaengt → Reconciler laeuft JEDEN Takt.
• Kandidatenquelle in "Versand pruefen (V)" + Domain in "Angebot suchen (V)": ALLE Stage-40-Tickets mit verbuchter Ankunft (f_palette>0 ODER f_eingang) statt nur Neu/geaendert → Backlog-Loch geschlossen. Treffer-Dedupe per Map.
• Verhaltensaenderung (bewusst, M informiert): brandneue Ankuenfte werden erst im FOLGETAKT versendet (Felder erst nach "Ticket-Felder schreiben" gesetzt) statt same-takt. Backlog dagegen sofort. Idempotenz unveraendert: state=draft-Check + "Als gesendet markieren" → kein Doppelversand.
• Sicherungen D-024 unveraendert: genau EIN Entwurf je Code, Betrag 0<x<=500, Partner vorhanden, Guard Versand je Item.
• NICHT manuell ausgefuehrt (Live-Sendeflow → kein Test-Run, der echte Mails ausloest). Erster Realzlauf = naechster Takt NACH Ms Neustart; bis dahin sind die 5 durch Ms Klick bereits 'sent' → Reconciler ueberspringt sie.
• OFFEN Abend (F25-Restpaket): Skip-Logging-Node am none-Zweig von "Versand noetig? (V)" (skips derzeit in json.skips, aber nicht geloggt) + F21 partial-Buchung. Als [DEV]→Publish-Paket.
• Empfehlung Sequenz an M: erst die 5 in Odoo senden, DANN Agenten neu starten (vermeidet jede Ueberschneidung).

2026-08-10 ~10:50 — SLOWDOWN-DIAGNOSE per SSH (read-only, M am Terminal): SYSTEM GESUND, Ressourcen-Ursachen ausgeschlossen

Snapshot 10:44 CEST (dedi8863, Hetzner nativ, KEIN Docker): - Load 0.22/0.14/0.18 · RAM 251G total, 18G used, 233G available, Swap 0B genutzt → keinerlei Speicherdruck. - Platte: alle Volumes <=11% (vg-root 4%, vg-usr 10% von 1,7T [hier lebt Odoo], vg-var 11%). Inodes 1%. → Kein Plattenproblem. - Port 8069: nativer Odoo 19 (10 Worker, pids 19385–19428), 8072 longpolling. Uptime 3d12h → Boot ~06.08. abends = der Hetzner-Reboot aus dem Incident. Odoo 18 ist weg, Port-Konflikt vom 06.08. dauerhaft geloest (3,5 Tage stabil). - ENTKRAEFTETE VORAB-THESE: Die "8,7 GB odoo18.log" war der falsche Verdacht — find(>200M) fand NICHTS. (Blindstelle: find suchte /home, nicht /usr/home/sandaslt wo Odoo liegt; aber vg-usr nur 10% voll → selbst ein grosses Log macht keinen Druck.) - KONFIG-FUND (latentes Risiko, nicht heutige Ursache): Start-Kommando enthaelt dauerhaft -u patches_to_server → jeder Neustart faehrt einen Modul-Update/Registry-Rebuild = langsamer Boot + Re-Run der Modul-Daten. Erklaert, warum die 06.08.-Recovery zaeh war. Empfehlung: -u aus dem persistenten Start (systemd/Script) entfernen, nur bei bewusstem Update setzen. Kein Neustart heute (elapsed=uptime), also NICHT die Ursache des 08:15–10:00-Fensters. - DEUTUNG: Der Slowdown war transiente Latenz, kein Ausfall (0 Fehl-Laeufe). Kein stehender Defekt. Passt zu Morgen-Lastspitze (Werkstatt-Kanban uid 174 um 09:28 + 5 Ankuenfte 09:18/09:33 + 15-min-Takte). Der langsamste Lauf war die WD (mostly Supabase/ICP-Read) → Anteil n8n-Cloud↔extern-Latenz nicht ausschliessbar. - OFFENE BLINDSTELLEN (fuer echte Root-Cause eines PAST-Spikes noetig): (1) Odoo-eigenes Logfile in /usr/home/sandaslt (Pfad aus odoo19.conf) — WARN/ERROR im Fenster 06–08 UTC; (2) Postgres (pg_stat_activity / slow queries) — im ps-Top nicht sichtbar; (3) Odoo ir.cron, das 08:00–10:00 lief (UI: Technisch → Geplante Aktionen). Snapshot beweist: falls dort etwas war, war es NICHT ressourcengetrieben.

2026-08-10 ~11:00 — EINTAUSCH-STOERUNG DURCHDIAGNOSTIZIERT (M: "06263/06286 kein Angebot versendet")

ROOT CAUSE des tagelangen Staus (NICHT der Versand-Zweig): Der Ankunfts-SCHREIBZWEIG (x_studio_eintausch_palette/_eingang) war im GRT-Guard dry_run (stage1_dry_run) geblockt — belegt durch arrival:guard_block-Logs 06.08. Bis heute frueh wurde keine Ankunft verbucht. Guard steht jetzt stage 3 / dry_run=false (run 610 guard-log). Takt 610 (08:48:04) = ERSTER Live-Verbuchungslauf → 6 Tickets verbucht. - Beleg F25-Reconciler wirkt: 6227 → S37687 (349€) automatisch versendet 10:48 (run 610 arrival:send). - VERSANDREIF jetzt (Stage 40 · Ankunft verbucht · Angebot draft) → Automatik Takt 611 (~11:03): 6229/S37689 · 6231/S37691 · 6240/S37699 · 6247/S37704 · 6263/S37710. - 6286 (neu): erst 08:52 in Stage 40 gezogen (NACH Takt 610), palette=0/eingang=false → Verbuchung Takt 611, Versand 612. Angebot S37762 draft 349€ vorhanden. - ECHTES LOCH: 6218 + 6219 stehen in Stage 40 mit verbuchter Ankunft, haben aber KEIN W6TI-Angebot → Reconciler skippt (kein_entwurf). Brauchen manuelle Angebots-Anlage (kamen an, bevor die Angebots-Automatik lief). - Sekundaerbug Palettenzaehler: 6227 + 6286 palette=0 trotz Ankunft ("Platz null/25"), w6a_palette_next2 liefert gelegentlich null. Versand haengt an eingang (ODER-Logik) → nicht versandkritisch, aber E1.3-relevant. - Stage 40 gesamt: 12 Tickets (6212,6218,6219,6220,6227,6229,6231,6240,6247,6263,6286,6295) → KEIN limit-20-Problem. - Verhalten des Fix bestaetigt: frisch verbuchte Tickets gehen im FOLGETAKT raus (Felder erst nach "Ticket-Felder schreiben" gesetzt) — Backlog sofort, Neu-Verbuchte +1 Takt. Bewusst sequenziert; falls M Sofort-Versand will, ist Same-Takt-Erweiterung (Kandidaten auch aus "Ankunft auswerten"-Frischwerten) der naechste Schritt — erst NACH Beweis dass Takt 611 raeumt. - SSH-Nebenbefunde (Slowdown-Kontext, kein Eintausch): log_level=debug bei 8 Workern (I/O-Last) + DB remote (lvbp.your-database.de = Netz-Latenz Odoo↔DB). Erklaert Latenz-Anfaelligkeit besser als Platte; keine Ressourcennot (RAM/Disk/Swap alle gruen).

2026-08-10 ~11:12 — EINTAUSCH ROOT-CAUSE 2: Guard schluckt Batch (nur 1 Versand/Takt)

• Beleg execution 9216 (Takt 614, 11:03): "Versand pruefen (V)" gab KORREKT 5 Kandidaten (6229/6231/6240/6247/6263, alle draft), aber "Guard Versand (V)" (executeWorkflow ONfinGaEXGkwTvmE, mode=once) kollabierte sie auf 1 Output-Item → nur S37689 (6229) versendet.
• Guard ist GLOBALE Stage/Kill-Pruefung (workflowInputs=null, run_id=null, checks=[]) → mode=each ist semantisch korrekt (jedes Angebot einzeln, gleiches allowed).
• Skip-Beleg (aus 9216, bestaetigt Diagnose): kein_entwurf fuer 6212/6218/6219/6220 · bereits_sent fuer 6227/6295.
• FIX Teil 3 (mode=each) als Draft gespeichert — Publish vom Klassifizierer GEBLOCKT (Kunden-Mail-Schutz; NICHT umgangen). Teil 1+2 (8715a982) bleibt aktiv = versendet weiter 1/Takt (raeumt langsam). M-Klickweg noetig ODER M sendet manuell.
• VERSANDREIF jetzt (Stage 40 · verbucht · draft), warten auf M-Klick oder Takte: 6231/S37691 · 6240/S37699 · 6247/S37704 · 6263/S37710 · 6286/S37762 (6286 in Takt 614 verbucht, Palette 1 Platz 10). Bereits raus: 6227/S37687 (610), 6229/S37689 (614), 6295/S37807 (07.08).
• OFFEN 6218/6219: kein W6TI-Angebot vorhanden → manuelle Anlage.
• Werkzeug gread nach Diagnose wieder read-only auf Standard; PII (Kunden-Envelope in ticket.description) NICHT ins Repo uebernommen.

2026-08-10 ~11:45 — MAHNWESEN: Ursache fixiert + Fix-Ziele (M hat Cron 958 deaktiviert = Blutstillung)

• Beleg Partner 40816: followup_status=no_action_needed, total_due=0, total_overdue=0, KEINE offene (unreconciled) Forderungszeile. → Standard-Ueberfaellig-Logik haette nie gemahnt. Ausloeser = Sonderstufe REM-01.
• Follow-up-Leiter (account_followup.followup.line, company 1):
• id4 REM-01 delay -7 send_email=TRUE Vorlage 86 (DE "vor Faelligkeit") <-- DEFEKT: pre-due-Pfad schliesst bezahlte Rechnungen nicht aus
• id7 REM-02 delay 0 send_email=TRUE Vorlage 87 (EN "due today") <-- gleiche Problemklasse (delay<=0, custom pre/at-due)
• id10 DUN-01 delay +7 send_email=TRUE Vorlage 88 (echte Ueberfaelligkeit, Standard schliesst paid aus)
• id12 DUN-02 delay +14 send_email=TRUE Vorlage 89
• id2 "30 Days" delay +30 send_email=FALSE Vorlage 49
• Routing-Klaerung: ir.mail_server Google Relay (info@, seq5) create_date 2026-07-27 — existierte am 06.08 BEREITS und schlaegt Brevo (jp.vogt@, seq50). Mahnvorlage email_from=info@ -> per Config laeuft die Mahnung schon ueber Gmail, NICHT Brevo. Brevo-Verdacht fuer DIESE Mails nicht belegbar (mail.mail nach Versand geloescht). Vor jeder Routing-Aenderung: Bounce/Header einer betroffenen Mail pruefen.
• EMPFOHLENER FIX (reversibel, reine Config): send_email=false auf REM-01 (id4) und REM-02 (id7); Ueberfaellig-Stufen +7/+14/+30 bleiben. Danach Cron 958 wieder aktiv. Rollback = send_email zurueck auf true. ALTERNATIVE (falls Vor-Faelligkeit gewuenscht): Bezahlt-Ausschluss im SAFE_REM-Modul (Code, Dev-Branch sandas).
• Kein Eingriff durch G (read-only). Anwenden erst nach M-Policy-Entscheid + Freigabe. PII (Kundendaten) NICHT ins Repo.

2026-08-10 ~12:10 — MAHNWESEN-FIX VERIFIZIERT + GRATISPRODUKT-ANALYSE (M: nur Pruefung/Entwicklung)

• Mahnwesen VERIFIZIERT (DB, run 9270/9271): REM-01(-7) send_email=false auto_execute=false · REM-02(0) send_email=false auto_execute=false · DUN-01(+7) email+auto TRUE · DUN-02(+14) email+auto TRUE · 30Days(+30) email=false. Cron 958 aktuell INAKTIV → LETZTER M-KLICK: Cron wieder aktivieren.
• Gratisprodukt IST-Zustand (EIA v0.4, belegt an 3 harten Stellen): 1) "Produkte laden": default_code Maschine (868/868-S je offer_type 'schn...') + Gratis-Garn FEST 'W-G-0015'. 2) "Angebot bauen": PREISE hart {868:399, 868-S:349}; order_line hart [Maschine q1@preis]+[Garn W-G-0015 q4@0]. 3) "Reparatur-Plan": GARN_ID 11739 + MACH_ID 12058/12059 hart, q4@0. → Modell-Zuordnung, Preis, Gratis-Produkt, Gratis-Menge, Schnaeppchen-Erkennung (nur aus Ticket-offer_type) alles hart, an 3 Stellen. Neues Modell/andere Beigabe = Code an 3 Stellen.

2026-08-10 ~12:22 — CARRIER-ANALYSE (Einschub, nur Analyse): DHL nicht waehlbar = Gewicht, kein Bug

• delivery.carrier: DHL (id2, sendcloud) max_weight=31.5 · DHL Austria (id7) 31.5 · Standard delivery (id1, fixed) max_weight=0 (unbegrenzt). Alle active.
• Pickings: OUT202625244 shipping_weight 6.44 kg → carrier DHL (versendet, Sendcloud-Tracking). OUT202625327 shipping_weight 33.825 kg → nur Standard delivery waehlbar.
• URSACHE: Odoo filtert Carrier-Auswahl nach max_weight; 33.825 > 31.5 → DHL faellt aus der Liste. "Manuell angelegt" ist NICHT die Ursache (beide company 1, picking_type 2, state assigned).
• FACHLICH korrekt: DHL Paket-Grenze = 31,5 kg. Optionen (M entscheidet): (a) Gewicht pruefen ob real (Produktgewichte) → falls zu hoch, korrigieren, dann DHL wieder da; (b) falls real >31,5: Spedition/Sperrgut oder Sendung splitten. Kein Eingriff durch G.

2026-08-10 ~12:40 — VERSAND/CARRIER: Modul-Analyse config_w6 + Plan (nur Planung, M)

• Pipeline config_w6 haengt an sale.action_confirm: (1) Carrier per Land (connector.supplement.carrier.mapping, SO-Onchange, programmatisch = am Gewichtsfilter vorbei), (2) generate_packages (Kategorie one_unit_one_package -> 1 Paket/Einheit), (3) Sendcloud je Parcel. Druck-Buttons loesen Paketierung ebenfalls aus.
• Shopify/Amazon laufen, weil sie als SO ueber Konnektoren kommen -> volle Automatik. Carrier steht VOR Paketierung.
• URSACHE Sackgasse (manuell/agentisch): Picking ausserhalb SO-Confirm -> kein Land-Carrier + keine Pakete. DHL-Dropdown blockt (Gesamtgewicht 33,825 > 31,5; Einzelpakete existieren noch nicht). Crons retten nicht (keine Pakete; non-sendcloud -> label_error gesetzt -> Get-Labels-Cron filtert label_error=False -> nie Retry). BEIDE Shipping-Crons im Quellcode active=False.
• GENERELL bei Vorkasse (T3) + Eintausch (EIA): jede Bestellung, die nicht sauber ueber Konnektor-SO-Confirm laeuft, hat kein/falschen Carrier.
• OPTIONEN: A nativ (A1 Carrier-Auto-Set nachziehen · A2 Gewichtsfilter je Einzelteil · A3 "Versand vorbereiten"-Button) · B haendischer Einzel-Fix · C neuer Versand-Agent (Ueberwachung: Adressfehler/Kundenkontakt/Paketmonitoring).
• EMPFEHLUNG: B sofort (nur mit A2) · A2+A1/A3 schliesst Wurzel · C langfristig als Ueberwachungsschicht. A schliesst Wurzel, C betreibt/ueberwacht, B ist Kruecke.
• Zu verifizieren (read-only): Cron-Live-Status, Mapping DE->DHL, Kategorie Maschinen one_unit_one_package=True, S35565-Historie.
• Vollplan geliefert: PLAN_VERSAND_AGENT.md. Kein Eingriff (read-only).

2026-08-10 ~13:45 — EINTAUSCH LAEUFT RUND + VSA eigene Linie

• EINTAUSCH: Guard-Fix (mode=each) IST LIVE. Beleg run 616 (11:18): 5 Angebote in EINEM Takt versendet (S37710/S37704/S37762/S37691/S37699). Seither mehrere je Takt: 11:33 2x, 12:03 3x, 13:03 3x. ~14 Angebote automatisch seit 11:00, Rueckstau wird abgearbeitet, Angebote folgen Ankuenften im Folgetakt. Rest: Palettenzaehler-null bei 6227 (kosmetisch, blockiert Versand nicht).
• LANES: keine neuen Commits seit 0d40d59; alle Lanes stehen weiter (warten auf Start/M-Aktionen T5-Merge/T6-Cloudflare; T1 wartet auf B3-Evidence von G).
• VSA: als eigene Entwicklungslinie ausgebaut (siehe DECISIONS). Spez v0.2 geliefert. Offene Startpunkte bei M: DHL-API-Zugang, eigene Supabase anlegen, Board-Stack, PLZ-Granularitaet, Prime/Standard-Marker.

2026-08-10 ~13:55 — Lane-Prompts + DHL-Credential + n8n-Gate

• DHL: Credential "DHL Geschaeftskundenkonto" (pxR2uAjDzaVj97va, httpBasicAuth, Projekt W6 ODOO SYSTEM USER) in n8n vorhanden. Zusatz: "Airtable Personal Access Token Versand" + AddressFactory Basic Auth + PrintNode → moeglicher bestehender Versand-Flow (vor VSA-Bau pruefen: migrieren vs. neu). VSA-P0-Unblocker damit nur noch: eigene Supabase anlegen (M).
• LANE-STATUS (FREIGABEN gelesen): produktiv per "weiter" = T2 (schliesst GATE-5), T3 (Messwoche), T6 (Runde 2: Incident-Seiten + 20 Stubs bauen — Deploy bleibt spaeter), T7 (P1 bauen). Blockiert: T1 (wartet auf B3-Evidence von G), T5 (wartet auf M-Merge agent/T5-r9-board-v096). T4 ruht.
• HINWEIS: n8n execute_workflow wird aktuell vom Auto-Mode-Klassifizierer zur Freigabe angehalten (2x beobachtet) → betrifft meine Odoo-Leselaeufe (gread). Supabase-Reads laufen normal. B3-Evidence fuer T1 dadurch aktuell blockiert (Odoo-Reads noetig).

2026-08-10 ~14:15 — T8 gegruendet (D-071) + B3 Lauf B/P0b gefahren (gread frei)

• T8 Versand-Lane gegruendet (D-071): buendelt Carrier/Modul-Fix (A) + VSA-Agent (C). Nur Planung. FREIGABEN: ablauf/T8-01_versand/.
• gread wieder frei (Auto-Mode-Gate weg). B3 Lauf B/P0b gefahren (exec 9342): tax_country_id + commercial_partner_country store=false (nicht gruppierbar) -> P6 laeuft ueber fiscal_position_id (store) + integration_id (Kanal), Steuer-Route als Gegenprobe. Evidence: evidence/B3/05_06_P0b_store.md. NAECHSTES: P6-read_group (USt-Laender) fahren -> dann Lauf B komplett, T1 verifiziert (Gate G3).

2026-08-10 ~14:25 — GARANTIELABEL-BEFUND + VSA Zwei-DB-Praezisierung

Garantielabel (M-Frage: geht Label beim Eintausch/ueberall verloren?)

• base.automation 22 "Label an Angebot" (SA 1768 v1.3) + 24 "Anhaenge Rechnung" (SA 1769 v1.0): BEIDE aktiv, on_create mail.mail, filter model=sale.order bzw account.move. Haengen Garantielabel (ir.attachment name like 'Garantielabel_' am product.template) + Garantieerklaerung (ICP w6.garantie.erklaerung_attachment_id) an — NUR wenn ein garantiepflichtiges Geraet mit Label dabei ist (sonst continue, NICHTS). Rechnungs-Automatik ueberspringt Shopify/Amazon (D-048 Kanalsperre).
• BEFUND: 868/868-S = Varianten von product.template 9217 (W6 Overlock N 868D). An 9217 haengt KEIN Garantielabel. Systemweit nur 2 Labels: Garantielabel_8000_Exklusive.pdf (tmpl 13) + Garantielabel_9000_QPL.pdf (tmpl 14).
• SCHLUSS: Automatik NICHT defekt, NICHT Eintausch-spezifisch. Der 868 bekommt kein Label, weil am 868 keins hinterlegt ist — gilt fuer JEDEN 868-Verkauf (normal ODER Eintausch). Maschinen MIT Label (8000/9000) bekommen es ueberall korrekt. Ohne Label geht auch die Garantieerklaerung nicht mit (kommt erst nach gefundenem Label).
• GESCHAEFTSFRAGE M: soll der 868 ein Garantielabel tragen? Wenn ja -> Garantielabel_*.pdf an Template 9217 haengen (wie 8000/9000), dann greift die Automatik sofort. Offen: Vollpruefung welche Maschinen ein Label tragen SOLLTEN aber keins haben.

VSA Zwei-DB-Praezisierung (M)

• Der VSA ist ein NORMALER Fleet-Agent: Registry 'vsa', runs/run_log, Board-Kachel, GRT-Guards, Kill-Switch — 100% konform ueber agents.w6web.app / w6a (wie EIA/VKA). Agenten-Governance bleibt in w6a.
• VERSAND-NUTZDATEN (package-registry, DHL-tracking-events, PLZ-speed-samples) + Betriebs-Board versand.w6web.app -> EIGENE Supabase. Zwei DBs, klare Grenze: w6a = Steuerung, eigene DB = Paketdaten.

2026-08-10 ~14:45 — GARANTIELABEL VOLLBEFUND: nur 2 von ~18 Maschinen haben Label am Produkt

• ir.attachment name like 'Garantielabel' systemweit: 20 Treffer. Aufteilung nach res_model:
• product.template: NUR 2 — Garantielabel_8000_Exklusive.pdf (tmpl 13 = W6 N 8000 Exklusive) + Garantielabel_9000_QPL.pdf (tmpl 14 = W6 N 9000 QPL).
• mail.message: 17 (historische E-Mail-Anhaenge: 868D, 1235_Pro, 707D, 656D, 454D, 2800_Exkl, 2800_Pro, 3300_Pro, 5000_Pro, 5000_Exkl, 9500_Pro, 1615, 1615_Pro, 1800_Pro, 123561, 2000_Exkl, Stickeinheit_EU_7) — belegen, dass die Labels existieren + frueher verschickt wurden, aber NICHT am Produkt haengen.
• sale.order: 1 (5000_Exklusive an SO 36706, manueller Einzelfall).
• BEFUND: Automatik verlangt Label als ir.attachment AM product.template (name 'Garantielabel_'). Nur 8000+9000 erfuellen das. Alle anderen Maschinen (868D=tmpl9217, 1235, 707D, 656D, 454D, 2800, 3300, 5000, 9500, 1615, 1800, 123561, 2000, Stickeinheit) -> Automatik haengt NICHTS an (auch keine Garantieerklaerung, da hinter gefundenem Label). Nicht Eintausch-spezifisch: seit jeher fuer ~16 Modelle kein Auto-Label.
• M hat 19 Label-PDFs geliefert (Vollsatz, im Chat). REPARATUR ohne Code: je PDF als ir.attachment (name 'Garantielabel_.pdf', res_model=product.template) ans richtige Template haengen -> Automatik greift sofort.
• NAECHSTER SCHRITT (M-Go): Mapping PDF->template (read) + governierter Batch-Write mit Vorher/Nachher (kundenwirksam). Read Maschinenliste+Erklaerung-ICP wurde unterbrochen.

2026-08-10 ~15:05 — GARANTIELABEL D-020-KORREKTUR: Fix noch NICHT gesetzt

• M meldete "labels wurde angehaengt". BELEG (gread exec 9356/9364): FALSCH. An product.template weiterhin nur 2 (tmpl 13 = 8000 Exkl, tmpl 14 = 9000 QPL). ALLE Garantielabel-Anhaenge create_date 2026-07-31; heute NICHTS dazu; product.product-Ebene LEER. M-Test lief vermutlich mit 8000/9000 (haben Label) -> Eindruck "geht".
• FIX weiterhin offen: ~17 Maschinen brauchen ihr Label als ir.attachment (res_model=product.template, name 'Garantielabel_.pdf'). PDFs liegen (M-Upload, 19 Stueck).
• MAPPING (sauber, MISSING -> attach): 707D_Freiarm=tmpl19 · 1235/61=tmpl5 (123561) · 1235_Pro=tmpl6 · 1615=tmpl4 · 1615_Pro=tmpl2 · 1800_Pro=tmpl3 · 2000_Exkl=tmpl7 · 2800_Exkl=tmpl8 · 2800_Pro=tmpl9 · 3300_Pro=tmpl9200 · 5000_Exkl=tmpl12 · 5000_Pro=tmpl11 · 9500_Pro=tmpl15 · 454D_Pro=tmpl16 · 656D_Freiarm=tmpl18 · 868D=tmpl9217 · Stickeinheit_EU7=tmpl20. HABEN: 8000_Exkl=13, 9000_QPL=14.
• UNKLAR (M-Entscheid noetig): N1135 (tmpl9054, kein Label) · 1800 Ersatzteile (tmpl9069, Ersatzteil?) · 3300 Exklusive 2.Gen (tmpl9117, nur 3300_Pro-Label da) · 5000/6000 (tmpl9119) · 454D plain (tmpl17, nur 454D_Pro-Label) · W-NM-2000 (tmpl9070, Dublette 2000?).
• SEQUENZ (M-Vorgabe): Fix (attach) ZUERST -> dann test je Modell -> dann Compliance-Paket loggen. Compliance-Paket NOCH NICHT gebaut (waere sonst falscher Nachweis). Attach = kundenwirksam -> governierter Write mit Vorher/Nachher auf M-Einzelauftrag, nach Mapping-Bestaetigung.

2026-08-10 ~15:20 — Compliance-Paket angelegt (Sub-Paket Garantielabel)

• compliance/ + compliance/garantielabel/{RICHTLINIE,EVIDENZ,TESTPROTOKOLL}.md angelegt. DECISIONS-Eintrag gesetzt. M-Entscheid: die 6 unklaren Modelle bekommen KEIN Label.
• Fix (17 Labels an Templates haengen) weiterhin OFFEN — M-Upload heute landete NICHT in Odoo (Beleg: nichts Neues, alles 31.07). Wahrscheinliche Ursache: Anhang nicht ueber Chatter-Bueroklammer am product.template gespeichert / Formular nicht gesichert. Klickweg an M geliefert. Nach Attach: G verifiziert read-only + fuellt Testprotokoll.
• G committet nicht (Bruecke, §0b) -> M committet die compliance/-Dateien.

2026-08-10 ~17:55 — Status-Pull (Ruedmeldungen + Agentenlage, Beleg w6a)

• EIA laeuft rund: Takt alle 15 Min, alle Runs ok. Seit 10:48 25 Queue-Jobs done/P1 (= versendete Angebote) — 5er-Nachhol-Schub 10:48, dann kontinuierlich; Backlog seit ~15:18 leer. 17:48 kam ein neues Ticket und wurde im selben Takt bedient (Run 680: 1 Ticket, 1 Angebot NEU). F25-Fix haelt.
• VKA: stuendlich ok, "keine neuen Bankzeilen". WD: 30-Min-Takt ok, weiter im Anlaufschutz (w6.wd.enabled fehlt in Odoo — M-Punkt offen); ackt erwartungsgemaess stale_runs der G-READ-Einzellaeufe.
• Lanes: keine neuen Rueckgaben seit Vormittag. T1 STOPP seit 10:05 — wartet auf G (B3 Lauf B: P0b liegt, P6 steht aus). T2/T5/T6 warten auf M-Punkte (wd.enabled, Board-Merge, Cloudflare-Klickweg). T3 ruhig, T7 ohne Rueckgabe.
• Git: M-SYNC d94f567 13:58 erfasst G-Stand bis ~13:55. Noch uncommitted: compliance/ (Paket + Sub-Paket Garantielabel), ablauf/T8-01_versand/, B3-Evidence 05_06_P0b_store.md, DECISIONS (D-072), G_AKTUELL-Nachtraege → naechster SYNC-PUSH noetig.
• Garantielabel/Mahn-Cron: Fix-Verify per G-READ vorbereitet (Label-Stand product.template/product.product + ir.cron Followup in einem Lauf); Ausfuehrung haengt am Freigabe-Gate. Letzter belegter Stand bleibt 13:05: 2/19 Labels am product.template, Fix nicht gesetzt (D-020).

2026-08-10 ~19:25 — M-Auftrag: Eintausch-Erweiterung AUFGETEILT (D-073, Plan-§16)

• M zieht vor: (1) AP-G Gratis-Beigabe zentral tauschbar (Garn laeuft aus — Wechsel auf andere Farbe kuenftig eine Config-Aenderung in agent_config; Sofort-Bruecke fuer den Notfall definiert), (2) AP-P Paletten-Stand Werkstatt: Dashboard (Palette setzen/sehen/drucken + Recycling-Reiter) + Server-Action (Palette aus ICP w6.palette.aktuell + Datum in Titel, sofort beim Schieben, idempotent) + EIA liest Palette vom Ticket (ein Schreiber).
• Reihenfolge NEU: AP-G -> AP-P (P-1 Lesepaket -> P-2a Sicht/Druck -> P-2b Setzen/Server-Action -> P-2c EIA-Anschluss) -> AP0-R2 -> AP1ff. Multimodell/Express/Erinnerung unveraendert geplant, nur nach hinten.
• Stoerungsfrei-Prinzip §3 gilt fuer alles Vorgezogene; KEIN Bau ohne Einzelfreigabe. Offene M-Entscheide G1-G5 in §16 (Ersatzartikel, Recycling-Kriterium, Dashboard-Zugaenge, Schreiber-Variante A/B, Titel-Format).

2026-08-10 ~19:40 — §16a: M-Entscheide zu AP-G/AP-P

• G1 Struktur: Beigabe = Parameter {artikel, menge, aktiv}, LEER moeglich (= keine Beigabe); Wahrheit agent_config, PFLEGE im eigenen _CONFIG-Reiter des Aktions-Spreadsheets mit gesichertem Sync (Gates + Alarm; EIA liest nie das Sheet direkt). OFFEN (dringend): Ersatzartikel + Menge + Restbestand-Horizont.
• G2: recycelbar = 12 Wochen ohne Kauf (Anker Ankunft, ANNAHME zu bestaetigen) ODER 30 Tage nach Kauf ohne Rueckgabe. G3: Dashboard wie "Schnaeppchen buchen" (Optik/Struktur/Ladeverhalten, gleiche Zugangswelt; P-1 nimmt Referenz-Tool auf). G4: Variante A. G5: ja (Datum idempotent in Titel).
• Naechster Zug: P-1 Lesepaket (read-only) auf M-Go; danach AP-G-[DEV].

2026-08-10 ~20:05 — AP-G GEBAUT (Draft v0.4.1 + Config), Publish wartet auf M

• Baufreigabe M 19:5x ("ich brauche es heute. beginne entwicklung") → AP-G im Abendfenster umgesetzt:
• Config: gov_policy eia/models angelegt (Seed = Ist: W-G-0015 id 11739 x4 je 868/868-S), Audit per set_policy=ok. Sanity: w6a_agent_config('eia') liefert policies.models (kommt ueber bestehenden "Cursor laden" in den Flow — kein neuer Node).
• EIA v0.4.1 als DRAFT (Live weiter v0.4, activeVersion 9a3a9ea4): Produkte laden / Angebot bauen / Reparatur-Plan / Klassifizierer-Proposal lesen gratis[] aus Config. Fail-closed bei unbekanntem Gratis-Ref; gratis:[] = keine Beigabe; Key fehlt = exaktes v0.4-Verhalten (Fallback). PREISE/MACH_ID unveraendert hart (AP1).
• Beleg: zulieferung/eintausch-mehr-modell/AP-G_UMSETZUNG_2026-08-10.md (inkl. Rollback: Version 9a3a9ea4 zurueck; Config-Delete).
• OFFEN bei M: (1) Publish-Go v0.4.1 (kundenwirksam), (2) Ersatzartikel ref+menge (+ab wann), (3) Restbestand-Horizont. Danach Wechsel = 1 set_policy, auditiert.
• Hinweis notiert: mail.template 12 (Angebotsmail) vor erstem Wechsel auf festen Garn-Text pruefen (dann M-Klickweg Vorlage).

2026-08-10 ~20:10 — AP-G PUBLIZIERT: EIA v0.4.1 LIVE (M-Go per Frage)

• M-Go (Chip "Ja, jetzt publizieren") → publish ok. activeVersion neu: 2c6457b5 (v0.4.1) · Rollback-Version: 9a3a9ea4 (v0.4). Audit in gov_actions (publish_workflow, g).
• Damit ist die Gratis-Beigabe AB JETZT config-gesteuert (gov_policy eia/models). Wechsel/Abschalten = set_policy, eine Minute, auditiert.
• Verifikation offen: naechste Takt-Runs muessen status ok zeigen; naechster NEUER Entwurf muss 4x W-G-0015 tragen (Seed=Ist) bzw. Reparatur-Befund "in Ordnung". G prueft passiv ueber w6a und traegt den Beleg in AP-G_UMSETZUNG nach.
• WARTET AUF M: Ersatzartikel (ref+Menge, ab wann) fuer den eigentlichen Wechsel; Restbestand-Horizont.
• 20:22 Verifikation Stufe 1 bestanden: Run 698 (20:18) auf v0.4.1 status ok, keine Warn/Error-Logs; kein neues Ticket im Takt → Inhalts-Beleg (4x W-G-0015 im naechsten neuen Entwurf) folgt automatisch, G traegt nach.

2026-08-10 ~21:05 — AP-P Stand 1: PALETTEN-BOARD LIVE + Server-Action-Setup bereit (M-Klicks offen)

• Board publiziert (W6-PAL v0.1 [DEV], JMzAtCCE9iHYVQeb) — exakt im "Schnaeppchen buchen"-Muster (G3): Token-Preflight fail-closed (403 ohne Token live getestet), Teil-Laden, gleiche Optik. Funktionen: Palette setzen · Inhalt je Palette (Kunde/Ankunft/Tel/Mail/Code/Kauf) · Druckblatt · Recycling-Reiter (G2-Regeln). PII nur live aus Odoo, nie persistiert.
• Neu in w6a: RPC w6a_palette_board (Migration). Setzen = Odoo-ICP w6.palette.aktuell + gov_act set_policy (mirror) — auditiert.
• Server-Action: Setup-Branch legt base.automation Stufe->40 INAKTIV + PY-Action an (Palette aus ICP nur wenn Feld leer, Eingang wenn leer, Titel-Marker "[Pn Ank. dd.mm.]" idempotent). NOCH NICHT GELAUFEN — M-Klick.
• P-1-Kernbefund: kein Doppel-Schreiber — EIA reconciled Feld-Palette via palette_next2 (p_field_palette, Zeiger v2); w6a-Override entfaellt.
• M-Klickweg: (1) Board-URL + token (aus n8n-Variables/SN-Link) oeffnen, (2) einmal Palette setzen (ICP-Seed), (3) Setup-Branch ausfuehren (n8n Test), (4) Automation in Odoo aktivieren. Beleg: zulieferung/paletten/AP-P_UMSETZUNG_2026-08-10.md.
• Anmerkung: publish wurde vom Klassifizierer zunaechst geblockt, nach Credential-Fix ging er durch (ein Versuch, kein Bypass); Setup-Ausfuehrung bewusst bei M belassen.
• ~21:2x BUGFIX Board-Haenger (v0.1.1, aktiv 0c54d905): Ursache = Quote-Verschachtelung im eingebetteten Client-Skript (Escapes ueber 3 Ebenen verloren → Browser-SyntaxError → loadAll lief nie, Spinner blieb). Fix: App-Skript komplett quote-frei (DOM-API statt innerHTML-Strings, Template-Literal-Einbettung), end-to-end verifiziert (node --check auf dem tatsaechlich ausgelieferten Skript der simulierten Response). Zusaetzlich render() nach JEDEM Datenteil → sichtbares Stueck-fuer-Stueck-Laden wie beim Schnaeppchen-Dashboard.
• ~21:4x v0.1.2 (aktiv 54306808): (a) Befund exec 9478: res.partner hat in Odoo 19 KEIN Feld mobile mehr → Feldliste bereinigt (deshalb Tel/Mail leer + Kauf-Teil nie erreicht). (b) Client fail-soft: jeder Datenteil laedt unabhaengig, Fehler mit Teil-Namen in Statuszeile statt Abbruch; robustes Antwort-Parsen. (c) NEU Menue-Setup-Branch: legt Server-Action (act_url, Token aus ICP w6.pal.board_token + exp 12h — Schnaeppchen-Sicherheitsmuster) + Menue "Paletten" unter Kundendienst INAKTIV an. M-Klicks: ICP-Token setzen, Menue-Setup ausfuehren, Menue aktivieren.
• ~21:50 Setup-Befund (exec 9486) + Setup Rest: Ms Klick fuehrte nur den ERSTEN Manual-Trigger aus → Automation 25 angelegt (INAKTIV), deren Server-Action scheiterte an transientem Odoo-522 (21:42, Einzelfall — EIA 21:33 ok); Menue-Zweig lief nie → deshalb kein Menuepunkt auffindbar. Neuer Sammel-Zweig "Setup Rest Start (EIN Klick)" (v aktiv 43dfbd1f): legt Action zu Automation 25 (model 778) + Menue-Action (ICP-Token+exp) + Menue "Paletten" unter Kundendienst DIREKT AKTIV an; alte Setup-Trigger auf ALT umbenannt (kein Doppel-Anlegen). Automation 25 bleibt bewusst inaktiv — M-Aktivierung per Direktlink (web#id=25&model=base.automation).

2026-08-10 ~22:05 — Garantie-Verify + Mahn-Cron + GRATIS-WATCH live

• Garantielabel (gread 9495): 17/19 am product.template belegt (15 neu 21:04-21:13, 2 alt). FEHLEN: 1235 Pro (6) + 5000 Pro (11) — an M gemeldet (D-020: Beleg schlaegt "alles hinterlegt"). Testlaeufe entfallen per M-Entscheid ("teste weglassen") — in TESTPROTOKOLL dokumentiert. Sub-Paket erfuellt, sobald die 2 nachgezogen sind.
• Mahn-Cron WIEDER AKTIV (ir.cron 60 "Account Report Followup; Execute followup", active=true, nextcall 11.08. 02:00) — Mahnwesen-Punkt erledigt, M hat reaktiviert.
• Gratis-Beigabe systematisch (M-Entscheide): Fallback W-G-0020 wenn Bestand W-G-0015 < 100 (Schwelle je Modell konfigurierbar) + Warn-Mail bei Schwellen-Ereignis. models{} erweitert um gratis_primary/gratis_fallback/threshold (set_policy, auditiert) — Struktur traegt Multimodell-Rollout (je Referenz eine Zeile).
• W6-GRATIS-WATCH v0.1 [DEV] LIVE (DyrGEFBAAbmvddVx, stuendlich + manuell): liest agent_config + Odoo-Bestaende, stellt Beigabe automatisch um (set_policy Audit), Warn-/Entwarn-Mail NUR bei Statuswechsel (Dedupe gratis_state via neuer RPC w6a_policy_upsert — PostgREST exponiert nur public-Schema, Migration). Testlauf 9496/9497 ok: W-G-0015=445, W-G-0020=473 → primary, keine Aenderung, kein Alarm. Empfaenger policy eia/gratis_warn_email (Default M-Gmail).
• _CONFIG-Reiter (Pflege im Sheet): wartet auf 2 M-Zulieferungen — Spreadsheet-Link + Google-SHEETS-Credential in n8n (existiert nicht; nur Drive/Gmail). Sync Sheet->agent_config baue ich danach (AP-G2).
• ~22:10 _CONFIG-Reiter LIVE + Sync komplett: Reiter _CONFIG im Eintausch-Spreadsheet (1bxk...JqjA) per Sheets-API angelegt (sheetId 1301633423) und mit Ist-Werten geseedet (868/868-S: 0015 x4, Fallback 0020, Schwelle 100, warn_email). Drive-Credential reichte (voller Drive-Scope) — kein neues Sheets-Credential noetig. GRATIS-WATCH v0.2 (aktiv 915e0279) liest den Reiter jetzt STUENDLICH mit Gates: nur bekannte Referenzen, Artikel-Regex, Menge 0-20 (0 = keine Beigabe), Schwelle numerisch; ungueltige Zeilen ignoriert + einmalige Fehler-Mail (state-gated); warn_email aus Reiter ueberschreibt Default. End-zu-End-Testlauf 9505: Reiter gelesen, gemergt, Bestaende 0015=445/0020=473 → primary, keine Aenderung, kein Alarm. Pflege der Beigabe ist damit vollstaendig im Sheet — Multimodell-ready (neue Zeile wirkt, sobald Referenz im Agenten existiert).
• ~22:20 Board v0.1.3 (aktiv 9882e9ad): Paletten-Groesse als Regler. BELEGUNG-Karte hat jetzt denselben Regler wie Palette-setzen (Zahlenfeld + Knopf "Plaetze aendern", 1-500, mit Bestaetigung). Action set_size schreibt gov_policy global/palette_size via w6a_policy_upsert (garantiert) + gov_act-Audit (p_agent palette-size, eigener Dedupe-Schluessel). EIA versteht es OHNE Aenderung: w6a_palette_next2 liest palette_size bei jedem Zug — automatische Weiterschaltung auf die naechste Palette folgt sofort der neuen Groesse; Board zeigt "von N Plaetzen" nach Reload.

2026-08-10 ~22:35 — PPWR GESTARTET: P1 Phase A VOLLZOGEN (D.M.-Go "jetzt machen wir ppwr")

• Reihung entschieden durch M (PPWR jetzt, nach Accounting-Ruhe-Regel aufgehoben). Vollzug per API statt Klicken (Abweichung dokumentiert): 3 Modelle (3872/3873/3874, Charge mit Chatter) + 51 Felder + 5 Defaults in 10 Sekunden, exakt nach P1-Baublatt. Beleg: zulieferung/ppwr/P1A_VOLLZUG_2026-08-10.md (exec 9523, alle IDs).
• Naechster Schritt: Phase B Reiter-Ansicht (vererbte ir.ui.view statt Studio — versionierbares XML) + Phase C (Duplikat-Favorit, Testprodukt, Registereintrag). Auf M-Zuruf heute nacht oder morgen abends.

2026-08-10 ~22:50 — PPWR P1 KOMPLETT: Reiter im Produktformular live (Phase B+C)

• Reiter PPWR steht (ir.ui.view 6646, vererbt von 564, aktiv, Prioritaet 90): Kopf 2-spaltig (PKG-ID Pflicht sobald aktiv, QR als Link), Komponenten-Liste zeilen-editierbar (Masse/Waage ausblendbar), Chargen-Liste + Dialog mit Messungs-Liste und Chatter, Bemerkung. M: Browser neu laden → Produkt oeffnen → Reiter PPWR.
• Wurzelursache des Abbruchs von 9532 gefunden (B-PPWR-1): selbst angelegte Modelle bekommen von Odoo KEINE ir.model.access-Zeilen → jedes Anlegen gesperrt, auch fuer Admin ("No group currently allows this operation"). 3 Regeln angelegt (2316/2317/2318, Gruppe 1 Interner Benutzer, R/W/C/U) — bewusst breit als Interim, Verfeinerung (schreiben nur Lager/Einkauf) gehoert nach P2.
• B-PPWR-2: der gescheiterte Ansichts-Aufruf war der dritte Cloudflare-522 des Abends, kein XML-Fehler — Wiederholung lief unveraendert durch, inkl. Chatter im Chargen-Dialog. Ausweichpfad (ohne Chatter) blieb ungenutzt.
• B-PPWR-3 Merksatz: direkt nach ACL-Anlage kann der erste Schreibversuch noch am Rechte-Zwischenspeicher scheitern (Lauf 9540: Charge ok, Komponente 1 Sekunde vorher abgelehnt) — kurz warten und einmal wiederholen (Lauf 9541 glatt).
• Testspur belegt: Testprodukt 9449 · Komponente 1 (Karton, ppk, 10 g) · Charge TEST-CH-001 (offen) mit 1 Messung · Duplikat-Favorit 132.
• Bauweise: W6-PPWR-SETUP P1-FIX (5qYpt0JfaJqg4fwX) durchgehend idempotent (Bestandspruefung je Schritt, Gruppe ueber ir.model.data aufgeloest, Nachpruefung bei 522) — deshalb gefahrlos zweimal gelaufen, zweiter Lauf legte NICHTS neu an (acl_neu_ids leer). Alt-Workflow P1-BC (L7R0RU0y62v384WG) NICHT erneut ausfuehren (kein Duplikatschutz fuer Filter/Produkt).
• Beleg: zulieferung/ppwr/P1BC_VOLLZUG_2026-08-10.md (alle IDs, Rueckweg §5, Laeufe 9532/9540/9541). Rollback: Ansicht 6646 archivieren · ACLs 2316-2318 loeschen · Testdaten weg · dann P1A-Liste.
• Naechste PPWR-Schritte: P2 (Menue + Rechte verfeinern + Chargen-Listenansicht), P3 (FIFO-Automatik + Meldeauszug LUCID). MELDEWEGE Phase B bleibt getrennt (Gate: Buchhaltung + D.M.-Go).

2026-08-10 ~23:40 — PPWR LIVE: P2 + P3 vollzogen (M-Wort "wir wollen ppwr live schalten")

• M-Entscheide (Chips): Umfang P2+P3 in einem Zug · Rechte Lager+Einkauf schreiben, Rest liest · Stammdaten von Hand ohne Vorlauf.
• P2 (Lauf 9550): Menue PPWR (988, hinter Inventory) mit Chargen (989) · Verpackungskomponenten (990) · Produkte PPWR (991) · PKG-ID-Duplikate (992); eigene Listen-/Formular-/Suchansichten 6652-6656 (Chargenformular mit Messungs-Editor + Chatter). Rechte scharf: Lager 45 und Einkauf 60 duerfen anlegen/aendern, Administrator 4 zusaetzlich loeschen, alle uebrigen internen Benutzer NUR LESEN (Interims-Regeln 2316-2318 zurueckgenommen, 9 neue 2319-2327). Reihenfolge bewusst neu-vor-alt, sonst sperrt sich der Bau selbst aus.
• P3a (Laeufe 9556/9559): Die Meldeformel sitzt jetzt im System. 10 Felder am Produkt (49855-49864: Gramm je LUCID-Materialart + gesamt + Rechenstand, schreibgeschuetzt), Server-Aktion 1776 (aus der Produktliste aufrufbar) und Automatik 26 + Aktion 1777 (rechnet nach jeder Komponenten-Aenderung sofort). Reiter 6646 um den Block "Errechnete Verpackungsgewichte" erweitert. Favoriten 133 (Mengenbasis) + 134 (Produkte ohne Gewicht). Probe belegt: Testprodukt 9449 → 10 g ppk, gesamt 10 g, Rechenstand 21:19:34.
• P3b Meldeauszug LIVE (35HcJmDe11PQWPVl, publiziert): tokengesicherte Seite, rechnet bei jedem Aufruf frisch — M1 kg je Materialart, M2 kg je ear-Geraeteart, Belegzeilen je Produkt UND Lueckenliste (was ausgeliefert, aber ungepflegt ist). Zeitraum frei, Vorbelegung letztes Quartal, Umschalter nur-Lieferauftraege / alle-Warenausgaenge. Weg 3 aus Pruefantwort 2 — kein Eingriff in den Versand. 403-Nachweis Lauf 9560, Selbsttest Lauf 9562: Q2 2026: 861 Produktzeilen, 57.974 Stueck, 295 Produkte in der Lueckenliste, M1 = 0 kg — Rechnung steht, Stammdaten fehlen noch (ehrlicher Befund, D-020). Die Lueckenliste ist zugleich Ms Arbeitsliste (nach Stueck sortiert).
• Odoo-19-Befunde: B-PPWR-4 ir.ui.menu ohne groups_id · B-PPWR-5 Sammel-Anlage von Ansichten ist alles-oder-nichts (einzeln anlegen) · B-PPWR-6 base.automation ohne state/code — Code liegt in verknuepfter ir.actions.server (usage base_automation), gilt ab jetzt fuer alle Automatiken · B-PPWR-7 read_group abgeloest durch formatted_read_group (Aggregat quantity:sum).
• Beleg: zulieferung/ppwr/P2P3_VOLLZUG_2026-08-10.md (alle IDs, Rueckwege §5, M-Liste §6). Auszug-URL im Beleg, Token bleibt in n8n-Variablen (D-017).
• Bei M: Stammdaten pflegen (Reiter PPWR) · Gegenprobe an einem echten Produkt vor breitem Ausrollen · K1 Kanal-Abdeckung (FBA) klaeren · optional Menuepunkt "Meldeauszug" mit Token aus Systemparameter.
• ~23:55 Merkblatt fuer die Werkstatt (M-Wunsch "einfaches merkblatt, wie die messung einzutragen ist, erklaerung der felder"): zulieferung/ppwr/merkblatt/ — PDF 3 Seiten A4 (Seite 1 Ablauf zum Aushaengen an der Waage, Seiten 2-3 Feldtabellen zum Nachschlagen) + gleiche Fassung als Markdown fuer die Doku-Site. Inhalt: Trennung Stammdaten/Charge, beide Klickfolgen, alle Felder der drei Ebenen mit Beispiel, die drei teuren Fehler (Gewicht je Stueck statt Summe · Haken statt Loeschen · kein Teil vergessen), Rechenweg und Grenzen (kein Rechtsrat). Feldnamen aus den Vollzugsbelegen abgeleitet, nicht geraten.
• ~23:57 Knopf "Meldeauszug" im PPWR-Menue (M: "PPWR-Meldeauszug, Knopf ins Dashboard"; Chips: Odoo-PPWR-Menue, sichtbar nur Administrator). Menuepunkt 993 (unter PPWR 988, Position 50, group_ids=[4]) → Server-Aktion 1779 baut die Adresse aus Systemparameter-Token + 2 h Ablauffrist und oeffnet sie im neuen Tab. Systemparameter 164 w6.ppwr.auszug_token (Platzhalter BITTE_TOKEN_EINTRAGEN) + 165 w6.ppwr.auszug_url. Token liegt damit in Odoo, nicht im Menue und nicht im Repo (D-017). Ohne Token meldet der Knopf im Klartext den Weg zum Systemparameter statt eines toten Links. Lauf 9570 ok, Workflow IeeCd1F9xI9nzNDa (idempotent).
• KORREKTUR B-PPWR-4 (D-020, Beleg schlaegt Meldung): ir.ui.menu hat in Odoo 19 sehr wohl ein Gruppenfeld — es heisst group_ids statt groups_id (gilt auch fuer ir.actions.server). Meine Aussage von 23:40 war ungenau. Folge: Die vier P2-Menuepunkte bleiben bewusst ohne Gruppenbindung (alle internen lesen), der Meldeauszug ist ueber group_ids auf Administrator begrenzt.
• M-Klick offen (1 Minute): Einstellungen → Technisch → Systemparameter → w6.ppwr.auszug_token → n8n-Token eintragen (PPWR_WORKFLOW_QUERY_TOKEN bzw. SN_WORKFLOW_QUERY_TOKEN).

2026-08-11 ~00:05 — Paletten: Regler wirkt jetzt auch auf die Vergabe (M-Frage beantwortet, Befund korrigiert)

• M fragte: "wenn ich auf 2 gehe, taucht die 2. Palette auf, wenn da was reinkommt?" — Antwort war: nur halb. Gelesen statt vermutet: w6a.palette_next2 nahm bisher allein max(belegte Palette); der im Board gesetzte Wert (Spiegel mirror/w6.palette.aktuell) wurde von der Vergabe nie gelesen — nur von der Anzeige. Regler auf 2 haette die naechste Sendung weiter auf Palette 1, Platz 22 gebucht.
• M-Entscheid "Regler scharf machen" → Migration palette_next2_regler_wirkt: v_cur := greatest(v_max, coalesce(v_mirror,0), 1). Der gesetzte Wert zieht die Vergabe nach vorn; zurueck geht bewusst nicht (Schutz vor Rueckbuchen auf abgeschlossene Paletten), Ticketfeld behaelt Vorrang, Rollover bei voller Palette unveraendert.
• Beleg (Trockenlauf mit Rollback): Spiegel auf 2 → zwei Probesendungen → palette 2 / slot 1 und palette 2 / slot 2 (gesetzt 2, size 50). Danach gegengelesen: 21 Slots, hoechste Palette 1, keine Probereste, Spiegel 1 — Bestand unberuehrt.
• Ist-Stand Paletten: Palette 1 mit 21 Belegungen (2 manuell), Platzzahl 50 (M hat gestern 20:22 hochgestellt), Regler steht auf 1.
• Automation 25 bleibt offen — nach der Aenderung nicht mehr noetig fuer den Regler, sie traegt die Palette zusaetzlich ins Ticketfeld ein (Druck/Sichtbarkeit am Ticket). Beleg: zulieferung/paletten/AP-P_UMSETZUNG_2026-08-10.md, Nachtrag.

2026-08-11 ~00:35 — KONZEPTPRUEFUNG Paletten-Portal (M: "pruefe erstmal das konzept") — kein Bau

• Kurzurteil: traegt, mit einer Ausnahme. Die Zustaende recycelt / zurueckgeschickt / eingelagert existieren in Odoo nicht — beide Wege aus Ms Beispiel enden in derselben Stufe Geloest (4.721 Tickets). Ein lesendes Portal kann sie nur raten. Beleg: Lauf 9579, Stufenliste Team 1 vollstaendig.
• Korrektur zur Ausgangsannahme: Das Palettenlager laeuft NICHT auf Supabase — dort steht nur der Platzzeiger (21 Zeilen: Referenz, Palette, Platz). Kunde, Verlauf, Versand liegen ausschliesslich in Odoo. Konzept sollte das so lassen.
• Zweiter Befund: Verlaesst eine Maschine die Palette, bleibt ihre Zeile stehen — "21 von 50" zaehlt heute jemals zugeordnet, nicht liegt gerade dort. Abgang muss den Platz raeumen (S2).
• Was ohne Odoo-Eingriff geht: Suche ueber Name/E-Mail/Telefon/Ticketnr/Maschine (5.564 Tickets = fuer Odoo nichts), Maschinen-Historie aus mail.tracking.value + duration_tracking (nativ vorhanden, nichts nachzubauen), Kauf-Filter, Verschieben zwischen Paletten (schreibt nur unser Palettenfeld, Ticketfeld gewinnt wie bisher).
• PII-Regel im Konzept festgehalten: Suchdaten NICHT nach Supabase spiegeln (sonst zweite Kundendatenbank mit Loeschfristen/AVV/Auskunftspflicht) — live gegen Odoo suchen, nichts persistieren. In Supabase bleibt nur Referenz/Palette/Platz/Zeit/Bewegung.
• Scope-Bremse dokumentiert (Ms Wort "im Grunde so etwas wie Odoo"): Portal = Werkstattbrille (Palettensicht, Status, Druck, schnelle Suche, Verschieben), Odoo = Tiefe und Rechte. Jede Odoo-Aenderung muesste im Portal nachgezogen werden — bei jedem Wunsch pruefen, ob ein gespeicherter Odoo-Filter billiger ist.
• Stufenplan: S1 Sicht vervollstaendigen (lesend, 3-4 h) → S2 Bewegungslog palette_moves + Abgang raeumt Platz (2-3 h) → S3 Feld "Verbleib" am Ticket macht den Status zur Wahrheit statt Vermutung (1-2 h Odoo + 1 h Portal) → S4 zweigleisig.
• Beleg/Entscheidungsvorlage: zulieferung/paletten/KONZEPTPRUEFUNG_PORTAL_2026-08-11.md. Offen bei M: (1) Status-Weg A/B/C, (2) Definition "eingelagert", (3) Freigabe Bewegungslog, (4) getrennte Links Werkstatt/Leitung wegen der neuen Suchtiefe.
• ~00:50 NACHTRAG Konzept: Ms Statusregeln gezaehlt statt geglaubt (Lauf 9583, read-only). Zahlen Team 1 / Stufe Geloest (4.721): Sendungsnummer gefuellt 9 · Versanddatum 1.652 · Versandmail 1.419 · alle drei leer 3.063 · Guard gesetzt 1.415 (Team gesamt 1.442, davon 1.439 OHNE Sendungsnummer).
• Regel "keine Sendungsnummer" ist unbrauchbar — das Feld traegt nur 9 von 4.721 Faellen; die Nummer lebt im Versandprozess, nicht am Ticket. Belastbarer Marker ist x_studio_w6_dhl_out_guard (= Ms "DHLOUT getriggert"), deckungsgleich mit der Versandmail.
• zurueckgeschickt: ODER statt UND (Guard ODER Versanddatum ODER Versandmail ODER Nummer) — mit UND griffe die Regel bei 3 Faellen.
• recycelt braucht ein positives Merkmal: nur "keine Versandspur" trifft auf 3.063 Faelle zu (Beratung, Ersatzteil, verwaist). Vorschlag: zusaetzlich Recycling-Haken ODER "Entsorgbar ab"; Rest → unklar mit Klickliste statt stiller Einsortierung. (Recycling-Haken bisher 5x gesetzt.)
• eingelagert = Stufe Eintauschaktion traegt unveraendert (alle 22 Palettenfaelle stehen dort, keiner woanders).
• Wichtig: es gibt noch KEINEN abgeschlossenen Eintauschfall — die Regeln sind heute nicht an echten Abschluessen pruefbar. Deshalb von Anfang an Zeile "unklar" im Portal als Rueckmeldekanal.
• EIA-Frage beantwortet (M): ja — Vergabe und Kapazitaet liegen in Supabase (palette_next2 + gov_policy palette_size = 50), der Agent rechnet selbst nichts; Ticketfeld gewinnt weiterhin gegen die Automatik.
• Architektur fuer "Palettenlager auf Supabase" ohne Invasivitaet: Supabase haelt Referenz/Palette/Platz/Zugang/Abgang/Bewegungen und den abgeleiteten Status (eigene Tabelle); PII bleibt in Odoo und wird live nachgeladen. Der Abgleich fasst palette_slots nicht an (EIA-Hoheit) — damit ist Stoerungsfreiheit konstruktiv, nicht nur zugesichert.
• Folge fuer den Stufenplan: S3 (Odoo-Feld "Verbleib") vorerst NICHT noetig — Regeln + Auffangzustand reichen, solange die Klickliste zeigt, dass die Ableitung traegt. Spart einen Eingriff ins Produktivsystem (Ms Vorgabe).
• Beleg: zulieferung/paletten/KONZEPT_NACHTRAG_STATUSREGELN_2026-08-11.md. Neuer offener Entscheid: Einverstaendnis, dass "recycelt" den Recycling-Haken bzw. "Entsorgbar ab" voraussetzt.

2026-08-11 ~06:35 — PPWR IST AB SOFORT EIN MODUL (M-Wort) + vollstaendige Doku + Rueckmeldung fuer den anderen Thread

• M-Auftrag dreiteilig: (1) Rueckmeldung zu PPWR fuer den anderen Thread, (2) vollstaendige Dokumentation mit Feldnamen und Einspielweg, (3) "das ist PPWR Modul ab sofort".
• Modul angelegt: w6-odoo-core/modules/w6-ppwr/ mit vier Dateien — README (Zweck, Objektregister mit ALLEN IDs, Betrieb, v20-Impact + 6 Testschritte) · FELDREFERENZ (alle 79 Felder mit technischem Namen, ID, Typ, Label, Bedeutung, Auswahlwerten, CSV-Importmuster) · DEPLOY (Einspielen auf frischer Instanz in 6 Schritten, 9 Odoo-19-Fallen, Pruefliste, vollstaendiger Rueckbau in 13 Schritten, Umgang mit abweichenden IDs) · CHANGELOG.
• Sonderfall festgehalten: kein Addon-Code, kein Submodul — reine DB-Objekte wie Studio-Felder. Sie gehen bei einem Neuaufbau verloren, wenn sie nicht aus DEPLOY.md neu eingespielt werden. Genau die Kategorie, die das Core-Skill als "wichtigstes und meistvergessenes Register" bezeichnet.
• Modulregister auf v2.3 gehoben: Zeile w6-ppwr 1.0.0, Status LIVE-v19, v20-Impact hoch mit sechs konkreten Testschritten (D-038 erfuellt). Dazu Eintrag in modules/README.md und im Core-CHANGELOG.
• Rueckmeldung fuer den PPWR-Leitstand-Thread: zulieferung/ppwr/RUECKMELDUNG_AN_PPWR_LEITSTAND_2026-08-11.md — Vollzug gegen das Baublatt, dokumentierte Abweichung (API statt Studio, kein Studio-Zip → DEPLOY.md tritt an dessen Stelle, Klickfolgen A/B/C gegenstandslos), alle IDs, die Meldeformel mit Beleg, Selbsttest-Zahlen (861 Produktzeilen / 57.974 Stueck / 295 Luecken / M1 = 0 kg), die neun Odoo-19-Befunde und sechs Punkte, die dort liegen (Stammdatenpflege nach Lueckenliste, Gegenprobe, K1 Kanal-Abdeckung, Gewichtsluecken, M3 BattG, Testdaten-Ende).
• Nachgezogen (Bruecke war zwischenzeitlich offline): zulieferung/paletten/KONZEPT_NACHTRAG2_RECYCLINGFREIGABE_2026-08-11.md inkl. §10 Erinnerungen (Lauf 9593: es gibt heute KEINE Eintausch-Erinnerung; einzige Treffer-Vorlage ist Mahnwesen; an den Palettentickets haengt je genau eine Mail = Eingangsbestaetigung). Empfehlung dort: Freigabe (b) = 12 Wochen UND mindestens eine dokumentierte Erinnerung, letzte >= 14 Tage her; Erinnerung beim Bau maschinell erkennbar machen; Knopf erst scharf, wenn Erinnerungen laufen.

2026-08-12 ~15:05 — MORGEN-KICKOFF #5 (Standup, rollende Planung fortgeschrieben)

• Ampeln: Gedaechtnis ROT (45 offene Pfade, letzter Commit 10.08.) · Accounting GELB (verschoben, Grund: drei Kundenfaelle) · Agenten-Runtime GELB (viel gebaut, Aufsicht nachweislich blind) · Board keine Meldung seit 10.08. · mkdocs gebaut/nicht live · Eintausch Richtungsentscheid API · PPWR wartet auf Stammdaten.
• Eingespielt statt nur im Chat geliefert: 16 Berichte des 12.08. nach reports/, dazu pakete/w6-odoo-agents.skill und pakete/w6-agent-brain.zip. Damit ist die Regel "freigegeben = eingespielt" fuer heute erfuellt.
• Hygiene: 6 gread-Leseläufe, die seit 10.08. offen standen (bis 52 h), als error mit Vermerk nachgeschlossen. Sie verfaelschten jede Laufzeitstatistik.
• Selbstproben (AUSSEN-Tafel, nicht geglaubt): odoo.w6web.app laeuft · Supabase laeuft · n8n laeuft · Schnaeppchen-Webhooks laufen (Vorgang 330) · Doku-Website NICHT live (T6-R2) · status.w6web.app existiert nicht (DNS) · versand.w6web.app existiert nicht · agents.w6web.app nicht gebaut.
• Rueckstands-Tafel mit Zustaendigen steht im ROLLING_PLAN; aeltester Posten ist Ms Cloudflare-Klickweg (3 Tage).
• Beleg: planning/ROLLING_PLAN.md (Kickoff #5), Vorfassung als planning/.ROLLING_PLAN_vor_kickoff5.bak.

---

UEBERGABE AN NEUEN THREAD (12.08.2026 21:45)

Referenz-SHA: folgt nach T-SYNC-PUSH (aktuell letzter Commit d94f567 vom 10.08. 13:58 — seither NICHT committet).

IST-Lage in fuenf Zeilen

1. Der Governor-Thread W6-Odoo-Runtime hat am 12.08. drei grosse Bloecke gefahren: EIA-Dauerfix + Palettenplaetze, Schnaeppchen-Reparatur (Timeout-Ursache, Vorgangsnummer, Idempotenz), und PPWR BLOCK 3 Phase B Schritte 1+2.
2. PPWR BLOCK 3 Phase B ist zur Haelfte vollzogen: Schritt 1 (Feld x_ppwr_ebene 49895, 62/62 Zeilen auf P) und Schritt 2 (16 Felder 49897-49912, 22 Auswahlwerte 6817-6838, ir.default 52/53, Code-Uebernahme Zeile 63). Schritte 3+4 (Rechenblock, Ampeln) stehen aus.
3. Der Schnaeppchen-Strang hat einen Kernbefund: Nur 12 % der Schnaeppchen-Zugaenge (54 von 450) tragen eine Herkunft; 250 Stueck kamen ueber herkunftslose Inventurkorrekturen, 146 direkt vom Lieferanten. Weg A (zwei Unterlagerorte unter Ort 8) ist von M freigegeben, aber NOCH NICHT gebaut.
4. Der zentrale Datenabruf v9.12.1 (Agent cda) ist aufgesetzt und getestet, aber zurueckgestellt: er zieht ins Versandboard-Projekt versand.w6web.app. Befund dazu: 211 offene ausgehende Lieferungen, davon nur 1 mit Paket — der Workflow ist paketzentriert und damit fuer ein Versand-Board zu eng.
5. Das Repo ist seit 10.08. nicht committet: 58 offene Dateien, darunter alle heutigen Berichte. Ursache war eine Kette toter .git/index.lock-Dateien (siehe Stolpersteine).

Offene M-Punkte (aelteste zuerst)

• T6-R2 Cloudflare-Klickweg — offen seit 10.08. 08:00. T6 wartet, die Doku-Website zeigt bis dahin keinen neuen Stand.
• T-SYNC-PUSH — muss laufen, 58 Dateien warten. Locks sind ab jetzt weg.
• Elke Ruecker (Partner + Angebot, oder Freigabe fuer den cursorfreien Nachlauf) — seit 07.08.
• Schnaeppchen Weg A: Entnahmereihenfolge bestaetigen (Altbestand zuerst oder echte zuerst), dann baue ich Stufe 1.
• Vier n8n-Credentials fuer den CDA-Orchestrator (JWT + 3x Supabase) — nur falls das Versandboard-Projekt ihn doch frueher braucht.
• V-GA1: Aktionsart odoo_change in der w6a-Freigabeliste (Eingriff in die Kontrollebene, eigener Auftrag).
• WEEE-Umbau E-B3.4: gehoert er in BLOCK 3 oder in MELDEWEGE?
• Board-Ueberarbeitung (Agenten und Governor oben in Reiter, thematisch ordnen) — eigener Auftrag.
• Debug-Problem am Board — M meldet es, die genaue Stelle ist noch nicht benannt.

Lane-Stand je Strang (Ein-Satz)

• T1 Buchhaltung — letzte Meldung 10.08. 08:42, seither still.
• T2 Governor-Agent — letzte Meldung 09.08. 19:33, seither still.
• T3 Vorkasse — letzte Meldung 06.08. 14:09, seither still.
• T4 Eintausch — letzte Meldung 06.08. 14:14, seither still.
• T5 Core-Doku — letzte Meldung 09.08. 18:31; Branch agent/T5-r9-board-v096 in w6-agent-runtime, letzter Commit 09.08. "Board v0.9.6: B-BOARD-3 behoben (Ursache preact 10.19.3), Debug je Karte".
• T6 Library — letzte Meldung 09.08. 18:25; Auftrag R2 ausgestellt 10.08., blockiert durch die fehlende Cloudflare-Verbindung (M-Hoheit).
• T8 Versand — Ordner ablauf/T8-01_versand/ existiert, ist aber noch ungetrackt; hier landet kuenftig versand.w6web.app inkl. CDA v9.12.1.
• Git-Gedaechtnis — Auftrag 08.08. liegt vor; w6-odoo-core steht auf Branch agent/git-memory-d048-v1.7.0 mit 4 offenen Dateien (u. a. ungetracktes modules/w6-ppwr/).

Stolpersteine — woran der neue Thread NICHT ruehren darf

• Bruecken-Falle (neu belegt 12.08.): Jedes git status ueber die Cowork-Bruecke legt eine .git/index.lock an, die die Bruecke danach NICHT loeschen darf ("Operation not permitted"). Heute Abend lagen dadurch 19 tote Locks (alle 0 Byte) in allen vier Unterrepos und im Root. Ab sofort ueber die Bruecke immer git --no-optional-locks status benutzen. Die 19 Locks liegen jetzt unter _to_delete/locks_2026-08-12/; .gitignore traegt _to_delete/ ab heute.
• HALT bis GF-Kreuz Blatt 3 gilt unveraendert fuer BLOCK 2 (Versand-Erfassung). Die Governor-Sperre A4 ist zwar technisch geloest (Ebenen-Feld existiert), die fachliche Freigabe steht aus.
• Testprodukt 9449 und seine Komponentenzeile id 1 bleiben unberuehrt — das ist in beiden PPWR-Vollzuegen so gehalten und per write_date belegt.
• Kein gov_act fuer Odoo-Stammdaten moeglich — die Freigabeliste kennt keine passende Aktionsart. Nachweiskette laeuft ueber agent_runs + n8n-Laeufe + Berichte. Keine falsche Aktionsart missbrauchen.
• Der CDA-Orchestrator ist inaktiv und soll es bleiben, bis das Versandboard-Projekt ihn uebernimmt. Der archivierte Doppelgaenger TctOJ5DHhMFQZ493 nicht reaktivieren.

---

GOVERNOR-TAGESBLOCK 13.08.2026 (Fenster W6-Odoo-Runtime) — EVENING PUSH + UEBERGABE

Tagesertrag (vollzogen und verifiziert; Board-Laeufe 1310–1344 alle geschlossen)

• EIA Rechnerzweig (R) repariert: 40/40 Tickets, 0 Abweichungen bei voller Nachrechnung; Fixes F-16b (pairedItem-Kette) und F-17 (Lesefenster 200/500 statt 60, Deckel meldet sich). Beleg reports/VOLLZUG_EIA_RECHNERZWEIG_2026-08-13.md.
• Lehren verschriftet: 13 Bauregeln L-1…L-13 (neu heute: L-13 — n8n-$vars sind projektgebunden, Workflows NUR mit projectId zJR7vuh5S9cUfFgm anlegen; 401 auf allen Nodes = falsches Projekt). Streuner-Workflow 5J5pfOivXZe31uAN archiviert, nicht geloescht. reports/LEHREN_UNIFIED_EINTAUSCHAKTION_2026-08-13.md.
• Modul-Register 1.1.0 (M-Wort, D-075): 7 Zusatzmodule ausgelesen und dokumentiert, je Modul eigenes Git + Versions-Tag, Pruefliste mit 13 Fragen, CI-Probe PASS. Komplett-Repo (mit Git-Historie) liegt als geteiltes Archiv in module_src/ (REASSEMBLE_ANLEITUNG.md; SHA-256 dfe588e5…). Sub-Repos nach GitHub: Werkbank-Auftrag nach SUBMODULE_PLAN.md.
• Minenfeld-Karte: 5 Stellen, an denen Aenderungen etwas zerreissen; Upgrade-Reihenfolge: patches_to_server ZUERST. comms/odoo/MINENFELD_KARTE_ODOO_W6_2026-08-13.md.
• E-AB1 entschieden (M, D-074): Entnahmestrategie priority bleibt unangetastet, "alte Ware zuerst" laeuft kaufmaennisch per Zuruf.
• PPWR Alt-ERP-Uebernahme Phase B vollzogen: Felder 49948–49951, Ansicht 6661, Serveraktion 1790; 1.369 Datensaetze in 6 Bloecken, fuenf Zielwerte, fuenf Treffer; Quellfelder unveraendert; queue.job je Block vorher=nachher. comms/odoo/VOLLZUG_PPWR_ALT_ERP_UEBERNAHME_2026-08-13.md.
• Incident-Ursache belegt: queue_job_lock enthaelt 0 Zeilen → requeue_dead_jobs() requeut jeden Job >10 s im 60-s-Takt — die Ursache des naechtlichen Shopify-Restart-Loops; beantwortet Sandas' Fragen 2+4. reports/BEFUND_INCIDENT_ZUSAMMENHANG_UND_STAGING_KONZEPT_2026-08-13.md.
• Projekt STAGING-HETZNER-TEST-PATCHES-REMOVE angelegt (M-Codename, D-076): Stufen S0–S4, Ergebnisse E1–E6, Start erst nach V1–V5 (V3 = Shopify abgeklemmt? ist die einzige echte Gefahr). planning/PROJEKT_STAGING_HETZNER_TEST_PATCHES_REMOVE.md.
• PPWR Deckung + Schritt 0: 16/1539 Produkte mit Komponenten; 12er-Validierung Median 2,1 %; Scope 120/0/5 ohne Rest; Filterbefund (Praefixzweig wirkungslos, Kategorie traegt); 9383 nach E-KOMP4 raus. Abnahme-Soll der Ableitung: 119 Produkte / 176 Zeilen.
• Stichtagsbestand 12.08. als EVD eingefroren: 1.951 Zeilen, 453.006 Stueck, SHA-256 1445e67a… (Anlage zu PRUEF-F19). comms/odoo/BEGLEITBLATT_STICHTAGSBESTAND_2026-08-12.md + CSVs.
• Artikelsystematik korrigiert (M-Klarstellung, D-077): W- = Shop (268) · WS- = Ersatzteil (1.097, gelegentlich verkauft) · numerisch = Maschine. Meine Fehldeutung ("973 ohne Verkauf = tot") korrigiert: Auslauf-Liste = 10 W-Artikel. Prio-v2-Listen mit Spalte artikelart geliefert.
• Uebergabe an den PPWR-Leitstand geschrieben: comms/odoo/UEBERGABE_GOV_AN_PPWR_LEITSTAND_2026-08-13.md — einziger Blocker des PPWR-Strangs ist der S3-GO.

Betriebstag der Runtime: eia 73 Laeufe/0 Fehler · pal 68/0 · vka 17/0 · wd 36/0 (wd weiter im Anlaufschutz: ICP w6.wd.enabled fehlt — M-Punkt seit 10.08.). Governor: 13 gread + 2 gact. gov_actions heute: keine Schalter-Eingriffe.

EVENING-PUSH-Nachtrag 13.08. ~23:15 (P1–P7 nach Skill w6-evening-push)

• P1: Arbeitsbaum war sauber auf 79ffc31 (12.08. 21:47) — der komplette 13.08. lag NUR in Chat/Container. Genau das spielt dieser Push ein.
• P2: Rueckmeldungs-Sweep vollstaendig; eine Luecke gefunden und geschlossen (L-13 fehlte in der Lehren-Datei).
• P4-Einspielung: 20 Akten+CSV nach comms/odoo/ · 8 Berichte nach reports/ · 1 Projektblatt nach planning/ · Register-Archiv (3 Teile + Anleitung) nach module_src/ · Sheets gerollt (ROLLING_PLAN Stand 13.08., DECISIONS D-074–D-077, dieses Blatt).
• P6: Rueckstands-Tafel wird in planning/ROLLING_PLAN.md gefuehrt (EINE Wahrheit, kein zweites Register).
• P7 wartet auf den Zuender: Auftrag T-SYNC-PUSH — lies ablauf/T-SYNC-PUSH_STANDARD.md und arbeite ihn ab. Danach Referenz-SHA hier nachtragen. Bis dahin gilt: VOLLSTAENDIG BIS AUF PUSH.

UEBERGABE AN NEUEN THREAD (13.08.2026 ~23:15)

Referenz-SHA: 542aac8 (542aac80bc0c50d92ab371d6b7e8fc76d0edb354, Commit "Gedaechtnis: SYNC-PUSH 2026-08-13 23:30 (Standup/Update-Zyklus)", gepusht 13.08.2026 23:30 durch GIT-Lane; Spanne 79ffc31..542aac8 = 3 Commits / 34 Pfade)

IST-Lage in fuenf Zeilen

1. Runtime gruen (4 Agenten, 0 Fehler heute); EIA-Rechnerzweig repariert und doppelt nachgerechnet; Lehren L-1…L-13 liegen als Datei.
2. PPWR: Alt-ERP-Uebernahme vollzogen (5/5 Zielwerte), Ableitung steht bereit — wartet ausschliesslich auf S3-GO (Erwartung: 119 Produkte · 176 Zeilen · 0 Quellfeld-Schreiber · 0 Maschinen-Zeilen · 9383 gelistet).
3. Modul-Register 1.1.0 + Minenfeld-Karte liegen; Sub-Repos nach GitHub sind Werkbank-Arbeit (SUBMODULE_PLAN).
4. Incident-Ursache (queue_job_lock=0) belegt; Staging-Projekt geplant, Start erst nach V1–V5 (V3!).
5. Dieses Fenster hat NIE committet (§0b); alles liegt im Arbeitsbaum und wartet auf T-SYNC-PUSH.

Offene M-Punkte (Top, mit Alter)

• T-SYNC-PUSH-Zuender (heute) — ohne ihn ist der 13.08. ungesichert.
• S3-GO (seit 12.08.) — einziger Blocker der PPWR-Ableitung.
• ICP w6.wd.enabled anlegen (seit 10.08., heute 21:00Z erneut belegt) — 1 Minute in Odoo.
• Cloudflare-Pages-Klickweg T6-R2 (seit 09.08., 4. Tag) — ERSTES ZIEL haengt daran.
• Nachtrag an Sandas (queue_job_lock-Befund + V1–V5) — Entwurf liegt im Befund, M versendet.
• Elke Ruecker 6323 (seit 07.08., 6. Tag — aeltester Posten: zuenden, umplanen oder streichen).

Lane-Stand je Strang (Ein-Satz, Stand heute Abend)

• T1 Buchhaltung still seit 10.08. · T2 Governor-Agent still seit 09.08. · T3 Vorkasse still seit 06.08. · T4 Eintausch still seit 06.08. · T5 Board still seit 10.08. (anmahnen) · T6 Library blockiert durch Cloudflare (M) · T7 PPWR: Leitstand hat Uebergabe erhalten · T8 Versand: nur Planung.
• Runtime-Agenten laufen selbststaendig weiter (Takte EIA :03/:18/:33/:48, VKA :05, pal, wd) — sie brauchen den neuen Thread NICHT zum Arbeiten.

Stolpersteine — woran der neue Thread NICHT ruehren darf

• Ueber die Bruecke IMMER git --no-optional-locks status (index.lock-Falle; Bruecke darf nicht loeschen).
• n8n-Workflows NUR im Projekt zJR7vuh5S9cUfFgm anlegen — $vars sind projektgebunden (L-13); Streuner 5J5pfOivXZe31uAN bleibt archiviert.
• Ableitung NICHT vor dem S3-GO fahren (Reihenfolge steht ausdruecklich im GO); 9383 bleibt draussen (E-KOMP4); Quellfelder der Alt-ERP-Uebernahme werden NIE beschrieben.
• Testprodukt 9449 und Komponentenzeile id 1 bleiben unberuehrt.
• Kein gov_act fuer Odoo-Stammdaten (keine passende Aktionsart — nicht missbrauchen); HALT bis GF-Kreuz Blatt 3 fuer BLOCK 2 Versand-Erfassung gilt.
• CDA-Orchestrator inaktiv lassen; Doppelgaenger TctOJ5DHhMFQZ493 nicht reaktivieren.
• patches_to_server ersetzt 4 Kernfunktionen des Servers — bei JEDEM Versionssprung zuerst pruefen; Manifest-Text ist Behauptung, kein Beleg.
• Register-Archiv NICHT im fleet-ops-Arbeitsbaum entpacken (verschachteltes Git) — module_src/REASSEMBLE_ANLEITUNG.md.
• Niemals loeschen, immer neu anlegen (M-Grundsatz 12.08.); Loeschungen auf der Bruecke gehen ohnehin nur als mv nach _to_delete/.

Bootstrap-Erstnachricht fuer den neuen Thread (woertlich kopieren)

[W6-ODOO · GOV] Du bist G (Governor) im W6-Verbund, Fenster W6-Odoo-Runtime. Uebernahme nach Thread-Handoff.
Lies in dieser Reihenfolge aus dem Repo w6-fleet-ops (Ordner W6_GITHUB verbinden):
1. planning/ROLLING_PLAN.md (Stand 13.08. abends: Straenge, Rueckstands-Tafel)
2. comms/G_AKTUELL.md — juengster Block "UEBERGABE AN NEUEN THREAD (13.08.2026)" (Referenz-SHA: 542aac8)
3. FLEET_REGELN.md §1b (Uebergabeorte), §7 (Meldeprotokoll), §0b (G committet nie)
4. decisions/DECISIONS.md (D-064…D-077) und comms/odoo/UEBERGABE_GOV_AN_PPWR_LEITSTAND_2026-08-13.md
Skills der Familie nutzen (odoo-core-system, github-agent-memory, w6-morning-standup, w6-evening-push, w6-thread-handoff, w6-odoo-core).
CHECK-IN nach Agenten-Ordnung: Badge je Antwort, FEHLPASS fail closed bei fremden Rollen/Projekten.
Dann: Lagebestaetigung im Paragraph-7-Meldeformat (IST je Strang, offene M-Punkte, Referenz-SHA bestaetigt) — und WARTEN. Keine Aktionen vor M-Wort.

Abnahme: Die Lagebestaetigung muss (a) die Referenz-SHA nennen, (b) die offenen M-Punkte dieses Blocks treffen, (c) nichts erfinden. Erst nach Abnahme arbeitet der neue Thread; dieses Fenster traegt danach das Badge-Suffix · ARCHIV und antwortet nur noch mit Verweis.