# Daily Log — 2026-09-07

## SupplierPulse: David Koenig fragt zu PR #513 (15:40 CEST)
- Seine Frage an Kais: "war der so gewollt? Du beschreibst ja dort das gesamte PMO Feature. Aber irgendwie ist das ja auch Issue content, oder?"
- ZAHLEN NACHGEZAEHLT statt aus der Erinnerung zu argumentieren: Die zwoelf PMO-Tickets verweisen 166 Mal auf die docs/6xx-Dateien, verteilt auf 13 von 15 Bodies. Meistgenutzt: 606-erd (23), 605-domain-model (17), 607-state-machines (13), 610-status-cycle (10), 608-permission-matrix (9). Ohne den PR laufen alle diese Verweise ins Leere.
- ARGUMENTATION fuer die Antwort: Ticket traegt Zuschnitt und Abnahmekriterien, Dokument traegt das Detail, bei Widerspruch gewinnt das Dokument (steht so woertlich in den Bodies). Nicht in die Issues, weil (1) das Material geteilt ist und Kopien driften, (2) der ganze Umbau eine Entschlackung von 20 auf 12 Tickets war, (3) ein Repo-Dokument Historie, Diff und Review hat und ein Issue-Body nicht, (4) die Spezifikation das Ticket ueberlebt, (5) das Repo bereits 101/102/104/110/300/501 fuehrt - der 600er-Block ist kein neues Muster.
- BEWUSST IHM RECHT GEGEBEN, wo er recht hat: Zwei Orte, die dasselbe beschreiben, driften. Wenn man den Einwand wegdiskutiert, fragt er beim naechsten Mal nicht mehr. Angebot in der Antwort: konkrete Doppelung melden, dann kuerzen wir das Ticket.
- BEWUSST ANGEBOTEN, die Spezifikation woanders abzulegen (Wiki o.ae.). Es ist ihr Repository; uns geht es nur darum, dass die 166 Verweise stabil auflaufen. Nimmt der Diskussion die Schaerfe.
- BEWUSST NICHT GESCHRIEBEN: dass die Tickets vorher unlesbar waren. Neutral als "Entschlackung von 20 auf 12" formuliert, damit es nicht nach Kritik an der Vorarbeit klingt.
- LIEFERUNG: antwort-david-pr513.md (TG 11487/11488), Kopie im Vault.

## SupplierPulse: Dave antwortet, ich gebe ihm recht (15:54 CEST)
- Kais hat seine eigene, kuerzere Fassung geschickt (gut, klang nach ihm). Ich hatte nur angemerkt, dass die Zeile "In Zukunft mache ich die Tickets eh anders" eine Frage beantwortet, die Dave nicht gestellt hat, und dass er sie noetigenfalls abgrenzen sollte.
- DAVES ANTWORT: adessos Konvention ist "alles was ein Feature beschreibt, kommt ins Issue", Begruendung Aenderungstempo - waehrend der Entwicklung aendert sich das meiste, ein Issue ist schneller zu aktualisieren als ein PR. Repo nur bei 100 % Revisionssicherheit, "dann sollten wir es aber zur Regel machen".
- BEWERTUNG: Sein Argument ist STAERKER als meins. Aenderungstempo schlaegt Revisionssicherheit fuer Material, das sich waehrend der Umsetzung bewegt. Das habe ich Kais so gesagt, statt meine Entscheidung zu verteidigen.
- ABER die Verweiszahlen zeigen eine saubere Trennlinie: Die Tickets verweisen auf die VERTRAEGE, nicht auf die Prosa.
```
23x ERD | 17x Datenmodell | 13x Rechtematrix + Zustandsautomaten
10x Statuszyklus | 8x Migration, Test, Performance, Sicherheit
--- darunter: 3x Entscheidungsrahmen, 2x Informationsarchitektur, 1x Zielprodukt
```
- VORSCHLAG als Regel, die adesso selbst schon zieht: Beschreibung ins Issue, Vertrag ins Repo. Ihr Repo fuehrt bereits 102-api-contracts, 104-access-control-model, 501-db-schema-user. Praktisch: rund zehn technische Dokumente bleiben im PR, der Rest wandert in die Issues.
- FALLBACK ANGEBOTEN: Wenn Dave "alles ins Issue" sagt, wird der PR geschlossen und alles verteilt. Begruendung an Kais: Dave hat nach einer Regel gefragt, nicht nach einer Verteidigung. Wer eine Regel vorschlaegt und zugleich anbietet, sie fallenzulassen, bekommt sie eher.
- Entwurf: antwort-david-pr513-runde2.md, 135 Woerter, Kopie im Vault.

## SupplierPulse: Dave entscheidet, zwei Auftraege (16:01 CEST)
- Kais: "Ich passe mich euch an!! Nicht andersherum" + die Rueckfrage, ob beschreibende Dokumente in die Issues und PR schliessen.
- DAVE: "Ja, dann bitte genauso. Versuche dann dass PMO Issue so zu schneiden, dass es in wenige Tagen Fertig werden kann. Also entweder alles in einem zusammenfassen oder X sinnvolle Tickets."
- ZWEI AUFTRAEGE, die erstmal gegeneinander ziehen: (1) 25 Dokumente in die Issues falten macht sie wieder fett - genau das, was die Konsolidierung abgebaut hat. (2) Gleichzeitig sollen sie klein und in Tagen lieferbar sein.
- MEINE AUFLOESUNG: Nicht alle 25 gehoeren hinein. Was der Umsetzer braucht (Datenmodell, ERD, Rechtematrix, Zustandsautomaten, Migration) wird eingearbeitet; was unser Analysematerial ist (Risikoregister, Abhaengigkeitskarte, Informationsarchitektur, SharePoint-Bewertung, offene Entscheidungen) bleibt bei uns. Wir laden nicht unsere Analyse bei adesso ab.
- ZUSCHNITT-VORSCHLAG: Im Paket haengen zwei verschiedene Dinge.
  KERN (vollstaendiger Statusbericht-Kreislauf, benutzbar): 490 Fundament, 492 Arbeitsraum+Zyklus, 494 Erfassen+Konsolidieren, 496 Veroeffentlichen.
  ANHAENGSEL: 497 Dokument-Links, 498 Protokoll, 499 Teststrategie.
  EIGENES FEATURE: 500+501 Aufgabenliste - das ist LOP/Kanban und hat mit dem Berichtszyklus nichts zu tun. Gehoert aus dem Paket raus.
  Damit vier Tickets fuer etwas BENUTZBARES statt neun fuer etwas Vollstaendiges.
- RUECKFRAGE an Dave vorgeschlagen, weil der Unterschied Faktor zehn ist: jedes Ticket in wenigen Tagen (passt zum jetzigen Schnitt) oder das ganze PMO in wenigen Tagen (heisst Umfang streichen, nicht neu schneiden)?
- AUFWAND ehrlich benannt: halber bis ganzer Tag, kein Nachmittag. Warte auf Kais' Go.

## Dave nennt den Massstab: Anzahl statt Groesse (16:10 CEST)
- "Wenn die Tickets zu gross werden, wird dein AI-Kontextfenster riesig... sind sie zu klein, werden das so viele, dass du sie nicht mehr blickst. Meine Empfehlung waere, nur so viele Tickets anzulegen, wie das Team in der naechsten Woche abarbeiten kann." Dazu selbstkritisch: "aktuell haben wir schon viel zu viele im Backlog".
- DAMIT IST MEINE RUECKFRAGE BEANTWORTET, und zwar besser als sie gestellt war: Der Massstab ist nicht die Ticketgroesse, sondern die ANZAHL gleichzeitig offener Tickets.
- SELBSTKRITIK an Kais weitergegeben: Ich hatte auf "nichts darf herunterfallen" optimiert, daher zwoelf Tickets fuer den ganzen Modulumfang. Dave optimiert auf "nur was diese Woche dran ist". Beides legitim, seins passt zu ihrer Arbeitsweise.
- VORSCHLAG: OFFEN bleiben 490 Fundament, 492 Arbeitsraum+Zyklus, 494 Erfassen+Konsolidieren (die Kette bis "Status erfasst und konsolidiert", zum ersten Mal etwas Anfassbares). SCHLIESSEN und als Fahrplan in den EPIC: 496, 497, 498, 499. RAUS als eigenes Feature: 500+501 Aufgabenliste (LOP/Kanban, gehoert nicht zum Berichtszyklus). Drei offene statt zwoelf.
- Kurze Antwort an Dave mitgeliefert. Warte auf Kais' Go fuer die Umsetzung; die Dokumente werden dabei nur in die drei offenen Tickets eingearbeitet.
- Als Memory gesichert: nur-so-viele-tickets-wie-diese-woche-machbar (beide adesso-Konventionen: Backlog-Groesse und Feature-Beschreibung ins Issue).

## PMO-Umbau: Kais gibt Go, Auszug angefordert (18:18 CEST)
- Kais: "Lass es uns machen, aber vorher einen Auszug zum aktuellen Stand in GitHub."
- RICHTIG SO: Mein Stand ist vom 04.09., seitdem koennen Labels, Kommentare und Board-Status sich bewegt haben (Memory handover-snapshot-verify-against-head). Nicht auf einem drei Tage alten Abzug arbeiten.
- AUFRUFFORM NICHT NEU ERFUNDEN, sondern aus umbau-kommandos-pmo.sh vom 04.09. uebernommen: --repo bmw.ghe.com/SupplierPulse/SupplierPulse, --limit 300 (Memory tool-limit-vs-real-negative).
- FUENF BEFEHLE geliefert, je einer pro Block, keine Backslashes (Telegram-Falle), durchnummeriert und nicht spaeter umnummeriert (Memory no-renumbering-during-execution):
  1 Ordner, 2 alle-issues.json, 3 Schleife ueber 484/485/486/487/490/492/494/496/497/498/499/500/501/512 mit body+comments, 4 pr-513.json, 5 Kontrolle (16 Dateien erwartet) und zip.
- WOFUER: alle-issues fuer offene Tickets und Tony-Labels; Detail-Kommentare fuer Aenderungen seit dem 04.09.; EPIC 484 als Ziel fuer den Fahrplan; pr-513 als Stand vor dem Schliessen.
- PLAN nach Daves Regeln: drei Tickets offen (490, 492, 494) und mit dem Noetigen fuellen, vier schliessen (496, 497, 498, 499) und in den EPIC-Fahrplan, Aufgabenliste (500, 501) herausloesen, PR 513 schliessen. Kein Analysematerial abladen.

## PMO-Auszug ausgewertet, Vorschlag verschaerft (18:22 CEST)
- pmo-stand.zip erhalten, 16 Dateien, entpackt nach modules/pmo-konsolidierung/stand-2026-09-07/.
- IST-STAND: 14 Tickets alle OFFEN, NULL Kommentare seit dem 04.09. mittags, PR 513 offen mit 26 Dateien und 0 Reviews (letzte Aenderung 04.09. 09:16 UTC). Niemand von adesso hat seitdem etwas angefasst.
- BODIES GEGENGEPRUEFT statt angenommen: alle 13 Ticket-Bodies sind zeichengleich mit meinen lokalen Dateien (484/485/486/487/490/492/494/496/497/498/499/500/501). Ich arbeite also auf dem echten Stand.
- ENTSCHEIDENDER BEFUND, der meinen Vorschlag aendert: ALLE vierzehn tragen go:needs-research. Tony hat kein einziges freigegeben. Es kann gerade NICHTS umgesetzt werden - die Research-Tickets sind das Tor, nicht die Features. Daves Frage "was schafft das Team naechste Woche" beantwortet sich damit anders: naechste Woche wird geklaert, nicht gebaut.
- NEUER, STRENGERER VORSCHLAG: offen bleiben nur 485 (Capabilities), 486 (Offline/Genehmigung) und 490 (Fundament, startet sobald 485 da ist). Geschlossen werden 487, 492, 494, 496, 497, 498, 499, 500, 501. Drei statt vierzehn.
  487 kommt mit raus, weil es ausdruecklich Slices klaert, die in dieser Serie nicht gebaut werden - nach Daves Regel genau ein Ticket, das noch nicht offen sein sollte.
  490 bleibt, weil es als einziges direkt nach der Recherche starten kann und alles daran haengt.
- ALTERNATIVE angeboten: 492 dazunehmen, dann ist die Kette bis "Arbeitsraum steht" abgedeckt.
- Warte auf Kais' Variantenwahl, dann Befehlspaket.