# Daily Log — 2026-09-03

## Session-Start 08:14 CEST
- Neue Session gestartet (ID: cc0b137d)
- 08:16 CEST (Session 2ad291f2, Fable 5.1): Brain-Snapshot komplett (12 Sektionen), HEARTBEAT via `git show HEAD:HEARTBEAT.md` (weiterhin root-only). Kurzmeldung an Kais gesendet.
- BEFUND: aria-git-sync.timer laeuft alle 15 Min, scheitert aber still (`git add` -> "Permission denied HEARTBEAT.md" -> "fatal: updating files failed", Service exit 0). Letzter Vault-Commit e4bda39 vom 13.08. Ungesichert: 128 untracked, 46 deleted, 4 modified. Fix root-only (chown), an Kais gemeldet. Muster: Memory timer-runs-does-not-mean-output-arrives.

## Brain-Vault-Sync repariert (08:19 bis 08:28 CEST, Kais TG 11103 "Bitte reparieren")
- URSACHE (belegt): 14.07. Sync-Dienst auf User aria umgestellt (override.conf), aria-deadline-reconcile.service blieb User=root. Reconcile schreibt HEARTBEAT.md per mkstemp+os.replace -> root:root 0600. Git oeffnet nur stat-geaenderte Dateien, deshalb unauffaellig bis 12.08. (HEARTBEAT-Edits committet 11./12.08.); 13.08. 06:20 CEST Reconcile-Rewrite -> seitdem jedes `git add -A` rc=128. aria-git-sync.sh prueften den Rueckgabewert nicht -> 2010x "Push erfolgreich" bei leerem Commit, Timer gruen. Journal reicht nur bis 27.08., Reconcile-Journal fuer aria unsichtbar.
- FIX 1 (Workaround, aria-Rechte): `git update-index --skip-worktree HEARTBEAT.md`. Sync laeuft wieder; HEARTBEAT.md selbst bleibt bis chown auf HEAD-Stand 12.08.
- FIX 2 scripts/aria-git-sync.sh (Backup .bak.20260903-gitadd): git-add-Fehler bricht hart ab (log + return rc); skip-worktree-Flag wird automatisch entfernt, sobald HEARTBEAT.md lesbar ist.
- FIX 3 scripts/aria-deadline-reconcile.py (Backup .bak.20260903-perms): tmp vor os.replace auf 0644, als root chown auf Vault-Ordner-Owner. Wirkt ab naechstem Lauf 04.09. 06:20 CEST. Gegenprobe auf Testdatei: gepatcht 0644, Original 0600.
- SYNC: manuell 08:25 CEST -> Commit 1b28ed0 (130 Dateien, +9434/-1841), Remote verifiziert (ls-remote main = 1b28ed0), Arbeitsbaum sauber. Timer-Lauf 08:25:01 CEST schlug mit neuem Code hart fehl (rc=128, lag vor dem Workaround), Retry 08:26 gruen.
- Secret-Scan vor Push: 131 Dateien mit /usr/bin/grep (rtk-Wrapper hatte 0 gezaehlt), 0 Token-Treffer; llms-full.txt:2066 nur Variablenname.
- Lokal vom Sync ausgenommen (.git/info/exclude, nicht committet): 02-Wissen/rwg-durrani-consent-2026-08-30.eml (Roh-Mail eines Dritten) -> Kais entscheidet.
- NEBENBEFUND: /var/log/aria-runs.jsonl hat seit 14.07. keine git-sync-Records (als aria nicht schreibbar, Wrapper schluckt das) -> Run-Records blind. Root-Fix noetig (chown/ACL oder ARIA_RUN_LOG im Drop-in).
- OFFEN bei Kais (root): a) `chown aria:aria /home/aria/brain/HEARTBEAT.md && chmod 644 ...` (sonst erledigt Fix 3 das morgen 06:20) b) optional Drop-in User=aria fuer aria-deadline-reconcile c) aria-runs.jsonl beschreibbar.
- Diffs (Stufe-2-Pflicht):
```diff
--- aria-git-sync.sh.bak.20260903-gitadd	2026-07-14 17:10:35.866552488 +0000
+++ aria-git-sync.sh	2026-09-03 06:27:12.069339962 +0000
@@ -29,12 +29,28 @@
 
     cd "$path" || { log "$name" "cd $path failed"; return 1; }
 
+    # 03.09.2026 Workaround-Rueckbau: HEARTBEAT.md traegt skip-worktree, solange sie root-owned
+    # und unlesbar ist. Sobald sie wieder lesbar ist, Flag automatisch entfernen — sonst bliebe
+    # die Datei still unversioniert.
+    if [ -r HEARTBEAT.md ] && git ls-files -v HEARTBEAT.md | grep -q '^S'; then
+        git update-index --no-skip-worktree HEARTBEAT.md
+        log "$name" "skip-worktree auf HEARTBEAT.md entfernt (Datei wieder lesbar)"
+    fi
+
     # Keine Aenderungen? Skip
     if [ -z "$(git status --porcelain)" ]; then
         return 0
     fi
 
-    git add -A
+    # 03.09.2026 Fix: git-add-Fehler (z.B. unlesbare root-owned Datei) bricht den Lauf hart ab.
+    # Vorher lief der Sync 3 Wochen mit "Push erfolgreich" weiter, obwohl nichts committet wurde.
+    local add_err
+    add_err=$(git add -A 2>&1)
+    rc=$?
+    if [ $rc -ne 0 ]; then
+        log "$name" "git add fehlgeschlagen (rc=$rc): $add_err"
+        return $rc
+    fi
     # Commit darf "nothing to commit" sagen (exit 1) - das ist OK
     local commit_err
     commit_err=$(git -c user.name="$GIT_AUTHOR" -c user.email="$GIT_EMAIL" \

--- aria-deadline-reconcile.py.bak.20260903-perms	2026-06-03 22:46:53.371660203 +0000
+++ aria-deadline-reconcile.py	2026-09-03 06:27:02.789327964 +0000
@@ -218,6 +218,13 @@
     try:
         with os.fdopen(fd, "w", encoding="utf-8") as f:
             f.write(new_content)
+        # 03.09.2026 Fix: mkstemp legt 0600 an; lief der Dienst als root, war HEARTBEAT.md
+        # danach fuer den aria-User unlesbar und der Vault-Git-Sync scheiterte 3 Wochen still.
+        # Rechte 0644 + Eigentuemer des Vault-Ordners uebernehmen (chown nur als root moeglich).
+        os.chmod(tmp, 0o644)
+        if os.geteuid() == 0:
+            parent_stat = os.stat(path.parent)
+            os.chown(tmp, parent_stat.st_uid, parent_stat.st_gid)
         os.replace(tmp, path)
     finally:
         if os.path.exists(tmp):
```
- 08:40 CEST: Timer-Lauf aria-git-sync end-to-end verifiziert: Commit c9a983c (Daily Log + HANDOFF) selbststaendig gepusht, Remote = lokal, Unit inactive/SUCCESS, Arbeitsbaum sauber. Kais bestaetigt (TG 11106).

## RwG Actions Center: 24 von 25 "Disabled" (13:47 bis 13:57 CEST, Kais TG 11108 mit Screenshot)
- Screenshot Sandbox, "Total received inventory", 25 Merchants: 24 RwG-E2E "Disabled", Durrani "Ready", Izmir Kebap Haus ungematcht (MATCH NOW), Alerts-Badge rot.
- Google-Doku (inventory-view): Disabled = "disabled due to technical or policy issues"; Gruende: unmatched, missing future availability, service errors, data quality. Merchant-Ebene.
- Unsere Seite: Feed-Pipeline (upload-feeds.cron -> merchant/services/availability processors, PROCESS_AS_COMPLETE, SFTP) laut Log 01.09. 25/25/118260. Cron 05:00 UTC taeglich. Laeufe 02./03.09. NICHT pruefbar: keine AWS-Creds auf dem Host (aws sts -> NoCredentials, keine ~/.aws, keine AWS_-Keys in env-Dateien).
- Kandidat 1 (Timing): manuelles Matching nach letztem Feed-Import -> Google verknuepft Availability erst beim naechsten Import. Kandidat 2 (Datenqualitaet): services-feed.processor.ts schreibt rating aus reviewsRepository; fetch-reviews.cron ueberspringt Tenants ohne googlePlaceId (Zeile 30) -> die 24 (ohne Place-ID, 31.08.) bekommen rating: {} -> laut Proto-Kommentar (feeds.ts:2276) number_of_ratings required. Durrani: Place-ID + Reviews -> Ready.
- An Kais (TG 11110, 11111): Detailansicht + Feeds-Seite als Screenshot, Matching-Zeitpunkt; Fall 1 warten/AppConfig-Trigger, Fall 2 Rating-Fix auf Go. Consent-Gate fuer Prod unveraendert (01.09.-Direktive).
- KEINE Aenderung an Backend/Feed/Sandbox (Direktive 01.09. gilt, "Kannst du das loesen?" = Frage, Fix nur auf Go).
- 14:06 CEST Kais TG 11112 (Screenshot Inventory Details ALIBABA): Matched Yes, Source Merchant_Feed_staging_1788238800.json (= Lauf 01.09. 05:00 UTC), Service "Dining Reservation" Errors=1, RwG-E2E Disabled, Merchant Issues: (1) "Business listing is not allowed for booking", (2) "All services are disabled". Auftrag: Feed jetzt via AppConfig triggern, autonom.
- 14:13 CEST: AWS-Zugriff via /home/aria/aws-runtime.env (aria-automation, Policy aria-automation-staging-rwg-write noch attached, AppConfig-Read ok). v9 gelesen (4 Cron-Keys, google_feeds 0 0 5). v10 erstellt: NUR google_feeds -> "0 17 12 * * *" (12:17 UTC), Rest byte-identisch (Assertions). start-deployment #35 env 706qxkp Linear50%/30s -> DEPLOYING. Monitor auf CloudWatch /ecs/backend-staging-debug. Reset auf 0 0 5 folgt nach dem Lauf (AllAtOnce). Prod-Profil nicht angefasst.
- Verifiziert (CloudWatch): taegliche Laeufe 02.09. + 03.09. 05:00 UTC je Merchant 25 / Service 25 / Availability 118260, kein Fehler -> Feeds frisch, "Disabled" liegt nicht an fehlender Verfuegbarkeit. Reschedule v10 vom Backend uebernommen 12:11:35 UTC ("Scheduled cron job google_feeds_upload with schedule 0 17 12 * * *"). v11 (= v9-Inhalt, Reset) angelegt, Deploy erst nach dem Feuern.
- FEED-TRIGGER ERGEBNIS (12:17 UTC): Cron gefeuert 12:17:00, count=25; Merchant feed uploaded recordCount=25 (12:17:04); Service feed uploaded recordCount=25 (12:18:04); Availability feed uploaded recordCount=118260 (12:19:09). Kein "Failed to upload". Reset: v11 (= v9-Inhalt) start-deployment #36 AllAtOnce 12:17:50 -> Backend "Configuration updated" + "Scheduled cron job google_feeds_upload with schedule 0 0 5 * * *" 12:17:56 UTC. AppConfig-Versionen: v9 Original, v10 Trigger (0 17 12), v11 Reset (0 0 5, aktiv). Prod-Profil aqc7vab/Env k2c5ver unberuehrt.
- Bericht an Kais 14:19 CEST (TG 11115): Trigger loest die zwei Blocker nicht (Listing-Policy Google-seitig; Service-Fehler Kandidat INVALID_RATING durch rating: {} bei Tenants ohne Reviews). Naechster Schritt bei Kais: Service-Fehler/Feed-Snippet + Alerts-Screenshot; bei INVALID_RATING Fix in services-feed.processor.ts auf Go.
- Temp-Policy aria-automation-staging-rwg-write ist noch attached (Kais hatte sie am 01.09. nicht entfernt); Creds /home/aria/aws-runtime.env (aria-automation). Memory rwg-feed-trigger-and-appconfig-authz um Cred-Pfad ergaenzen.
- 16:25 CEST Kais TG 11116 (Screenshot Service-Ansicht ALIBABA): Service-Issue = "No upcoming availability" (NICHT Rating), Source Service_Feed_staging_1788238860.json, Tab "Future Availability" vorhanden. Rating-Hypothese verworfen.
- Geprueft: Seeder (reservation-seeder.cron.ts) laeuft nur in PRODUCTION (Stage-Guard), CloudWatch 0 "Seeded"-Events -> Tische der 24 sind nicht vollgeseedet. Realtime-Update = Booking-Notification-API, keine Availability -> Durrani "Ready" kommt aus dem Feed. Feed-Seite fuer alle 25 identisch -> Unterschied liegt bei Google am Listing.
- Kategorie-Hinweis: Apetito Grill Apolda bei Google = "Doner kebab restaurant"/Doenerimbiss (Websuche). These: Imbiss/Fast-Food-Kategorien sind fuer Dining-Reservierungen nicht buchbar -> "Business listing is not allowed for booking" -> Google serviert keine Availability -> "No upcoming availability". Durrani (Restaurant-Kategorie) eligible.
- 16:29 CEST: Diagnose an Kais; Pruefweg: Placesheet-Link in Inventory Details -> Kategorie des gematchten Listings; Feeds-Seite Availability-Status; Future-Availability-Tab ALIBABA vs Durrani. Nicht per Feed/Code loesbar; Kategorie aendert nur der Inhaber (Consent-Weg) oder Actions-Center-Support klaert Eignung.

## Fabrikanalyse-Issues konsolidiert (ab 23:49 CEST, Kais TG 11120 "Issues reduzieren")
- AUFTRAG: Die im BMW-GHE angelegten Fabrikanalyse-Issues von zu vielen Kleinteilen auf wenige entwicklungsfaehige Tickets reduzieren. Nichts darf wegfallen. Erst Analyse, dann Umsetzung. PMO folgt danach.
- Frischer GHE-Export von Kais (Drive, 21:21 UTC) geladen nach input/ghe-export-20260903/ (307 Issues, 1111 Kommentare, 9 Dateien, Groessen gegen Drive verifiziert).
- IST-STAND: Von der Serie #451-#459 + #476 sind nur SECHS wirklich offen. #452 gemergt (PR #479), #453 implementiert aber ungemergt (PR #482, blockiert durch #505), #476 blockiert durch #369 und fremder Owner (Georg-Zepf, adesso). Board-Status aus den supplierpulse-status-sync-Markerkommentaren rekonstruiert: #454-#459 haben keinen Marker, also nie in Arbeit.
- EIGENER FEHLER, korrigiert: Ich hatte Kais gemeldet, lange Issues wuerden im Repo liegenbleiben (13 Prozent Abschlussquote im 6000-12000-Zeichen-Band). Nachgerechnet: 23 der 36 langen offenen Issues sind erst seit 01.09. angelegt (unsere eigene Serie + PMO), die Statistik ist dadurch verzerrt. Gegenbeleg: #452 mit 6975 Zeichen war nach 20 Stunden gemergt, #507 mit 19113 Zeichen nach 43 Minuten geschlossen. Korrektur sofort an Kais (TG 11126). Muster: Trefferliste lesen statt Quote uebernehmen.
- Belastbar blieb nur der Lane-Befund: Issues mit squad:bruce UND squad:natasha schliessen bei p0/p1 in 1 von 5 Faellen, Einzel-Lane in 66 von 115. Kleine Stichprobe, als Indiz kommuniziert.
- DREI FREMDBEFUNDE (Kollisionskarte): (1) #459 beschrieb serverseitige Excel-Erzeugung, die Tony am 02.09. in #265 geprueft und verworfen hat (Server liefert Zeilen, Client baut Datei, Export-Bausteine importieren statt nachbauen) -> Body umgestellt. (2) #454 und PMO-#498 bauen denselben Audit-Minimalvertrag, #498 dreischichtig abgesichert -> Muster uebernommen. (3) #269 und das gemergte #452 modellieren beide supplier_sites ohne Querverweis.
- WIDERSPRUECHE in der Aktenlage: Error-Envelope-Klaerung vom 02.09. nennt ein Schema, das im Repo nicht existiert (dort code/message/details/correlationId in 102-api-contracts Abschnitt 4); Bounded-Context-Entscheidung "zwei Contexts" ist durch die #453-Umsetzung (ein Context) nicht gedeckt; #476 nennt Sync-Spaltennamen, die anders implementiert wurden.
- KAIS-ENTSCHEIDUNGEN (TG 11127, 11129): auf VIER Issues zusammenlegen. Sieben Fachfragen beantwortet, drei davon abweichend von meiner Empfehlung (Entsperren und Protokoll-Lesen auch fuer alle Projektteilnehmer, Sprachabfrage vor dem Export). Konsequenzen benannt (Freeze faktisch von jedem im Projekt aufhebbar; Betriebsrats-Thema bei der Protokoll-Sichtbarkeit), umgesetzt wie entschieden.
- ERGEBNIS-PAKET unter modules/fabrikanalyse/konsolidierung/: vier neue Issue-Bodies (Anker #456, #458, #457, #459), neuer EPIC-Body, vier Umbau-Kommentare, zwei Schliess-Kommentare mit vollstaendiger Kriterien-Zuordnung, EPIC-Kommentar, umbau-kommandos.sh (mit Dry-Run, Schritt-fuer-Schritt-Rueckfrage, gh-Stub-getestet), README-KAIS.md.
- VOLLSTAENDIGKEITSNACHWEIS: kriterien-inventur.csv (113) + substanz-inventur.csv (86) als Vorher-Menge, mapping-alt-neu.csv mit 159 Zuordnungen, pruefe_mapping.py meldet 0 Luecken, 0 Doppelungen, 0 Formfehler. Zusaetzlich eigene Stichprobe ueber 28 kritische Details (alle gefunden) und eine unabhaengige Agenten-Gegenpruefung.
- ANKER-PRINZIP: bestehende Nummern behalten, nur #454 und #455 schliessen. Grund: Georg-Zepf hat am 02.09. alle neun Sub-Issue-Verknuepfungen am EPIC gesetzt; neue Nummern haetten diese Struktur und alle Cross-References zerstoert.
- GEGENPRUEFUNG (eigener Agent, unabhaengig gegen die Original-Bodies): ~205 Aussagen geprueft, 14 Luecken, 7 Abweichungen, 8 Gruppen neuer Inhalte. WICHTIGSTER FUND: Der Bedienvorgang zum Abschliessen und Entsperren waere zwischen FA-2 (schliesst Oberflaeche aus) und FA-3 (deckte nur den #457-Teil ab) durchgefallen. Verortet in FA-3 inkl. Mindestquoten-Warnung. Zweiter Fund gegen mich: Ich hatte das Deployment-Gate fuer den Seed zur Pflicht gemacht, obwohl es im Original ausdruecklich offen war und Kais es nicht entschieden hat - zurueckgenommen auf Vorschlag plus offenen Punkt. Alle 14 Luecken eingearbeitet, Mapping und Kommentare nachgezogen.
- LEHRE Schnittkante: Beim Zusammenlegen von Issues entsteht die Luecke nicht im Inhalt der Tickets, sondern an der neuen Grenze zwischen ihnen. Backend-Ticket schliesst UI aus, UI-Ticket kennt nur seinen alten Umfang, der UI-Anteil des dritten Tickets faellt heraus. Gilt direkt fuer die anstehende PMO-Runde.
- UEBERGABE 00:45 CEST: ZIP deliverables/fabrikanalyse-konsolidierung-20260904.zip (27 Dateien, 92 KB) an Kais (TG 11131-11133), Secret-Scan mit /usr/bin/grep sauber, Skript gegen gh-Stub durchlaufen. Kais fuehrt am Mac aus.
- 00:44 CEST AUSGEFUEHRT von Kais am Mac: Umbau im GHE steht. Verifiziert an seiner Ausgabe: #456/#457/#458/#459 tragen die neuen Titel, #458 von p2 auf p1 angehoben, #459 auf squad:natasha umgehaengt (Kais hat den optionalen Lane-Wechsel mitgenommen), #454 und #455 closed, #451/#452/#453/#476 unveraendert, alle vier Anker weiter go:needs-research. Offen zu pruefen: Sub-Issue-Abhaengung, EPIC-Body, Kommentare (Pruefbefehle A/B/C geschickt).
- FEHLER + FIX in der Uebergabe: Mein Kontrollbefehl ohne --limit lieferte nur 4 statt 10 Zeilen, weil gh issue list per Default nur 30 Issues holt. Sah aus wie ein Repo-Befund, war ein Werkzeug-Default. Korrektur an Kais, Skript gepatcht, Memory tool-limit-vs-real-negative um den Fall erweitert.
- 00:46 CEST ABGESCHLOSSEN + VERIFIZIERT: Sub-Issues am EPIC = 452/453/456/457/458/459/476 (454 und 455 sauber abgehaengt), EPIC-Body traegt den Umbau-Vermerk, alle sieben Kommentare gesetzt. Fabrikanalyse-Konsolidierung damit vollstaendig im GHE. Restpunkte bei Kais: Board-Karten der geschlossenen Issues, Tony wegen go-Neubewertung und Lane-Wechsel #459.
- 00:47 CEST START PMO-Runde: 21 Issues (#484-#504), 135 Akzeptanzkriterien, 20 Sub-Issues am EPIC, kein Board-Status-Marker -> nichts in Arbeit. Vorarbeit liegt unter modules/pmo-konsolidierung/ (Bestandsaufnahme + kriterien-inventur-pmo.csv), Bodies extrahiert nach scratchpad/pmo/.

## PMO-Runde: Analyse (ab 00:47 CEST, 04.09.)
- BEFUND 1 (wichtiger als der Zuschnitt): Die 21 PMO-Tickets verweisen ueber 200x auf Spezifikationsdokumente, die es im BMW-Repo NICHT gibt (nur in unserem pmo-delivery/). 12-erd.md 40x, 11-domain-model.md 24x, 21-security-and-tenant-review.md 16x. Zum Vergleich: nur 29 Verweise auf echte Repo-Pfade. #490 nennt als verbindliche DDL-Quelle 12-erd.md - ein Umsetzungsagent findet sie nicht und muesste die Spalten von 7 Tabellen erfinden. Frage an Kais gestellt (3 Optionen, Empfehlung: die 13 Kerndokumente unter docs/ ablegen).
- Repotauglichkeit geprueft: inhaltlich unbedenklich (Beispieldaten explizit anonymisiert "Projekt Alpha/Werk Nord/Workstream Logistik", keine echten Namen, keine Kennzahlen, keine Foliennamen). Bereinigungsbedarf mechanisch: 13 Frontmatter-Zeilen zum Masterprompt, 6x "Entscheid Aria", ~50 Querverweise, 31x "Kais-Entscheid" -> Rollenbezeichnung. Doku: spezifikation-ins-repo-pruefung.md.
- BEFUND 2: Lane-Labels bilden den Inhalt nicht ab. 7 Tickets tragen squad:bruce, sind aber gemischt oder reines Frontend. Extremfall #504: Label bruce, einziger erlaubter Aenderungsbereich laut Ticket ist apps/web-shell/src/modules/pmo/. Selbst nachgeprueft an #492, #496, #504 - haelt.
- UNTERSCHIED zur Fabrikanalyse: Dort technischer Schnitt (Datenmodell/Berechnung/UI/Protokoll), hier fachlicher Schnitt entlang des Nutzerflusses (anlegen -> Zyklus -> erfassen -> konsolidieren -> veroeffentlichen). Die Kette wird NICHT nach Zustaendigkeit zerschlagen; stattdessen Nachbarglieder buendeln und die falschen Label korrigieren.
- VORSCHLAG an Kais: 20 -> 12. Research 5->3 (487/488/489 zusammen, klaeren nur nicht gebaute Roadmap-Slices), Slice 1 10->7 (490+491, 492+493, 494+495, Rest einzeln), Slice 2 5->2 (Backend 500+503+Routen aus 502, Frontend 501+504+Oberflaeche aus 502).
- ABGERATEN mit Begruendung: 485+486 (zerstoert Trennung Code-Gate/Freigabe-Gate), Fuenferkette 492-496 als ein Ticket (unpruefbarer PR), 497+498 (Sicherheits- vs. Nachvollziehbarkeitsbrille).
- SCHNITTKANTEN-AUFLAGEN aus der Analyse: createproject/[id].astro-Sektion (einziger Fremdcode-Zugriff) bei 492+493 erhalten; Dialog-Fokus-Fix bleibt Eigentum von 494; #265-Blocker bei 501+504 sichtbar halten, sonst wiederholt sich der #459-Fehler; routes.ts-Ein-Schreiber-Regel nicht durch Parallelitaet verletzen.
- Substanzmenge PMO: 135 Akzeptanzkriterien + 113 weitere Festlegungen = 248 Aussagen (Fabrikanalyse: 159).
- WARTET AUF KAIS: (a) wohin mit der Spezifikation, (b) 12 Tickets oder haerter runter. Ohne (a) ist die Ticketgroesse nicht bestimmbar.
- KAIS-GO (TG 11153): Spezifikation ins Repo unter docs/, Zuschnitt 12 wenn gut geschnitten. Abweichung gemeldet und begruendet: 13 statt 12, weil die Dateiablage ein eigenes Ticket braucht (Squad-Regel: keine Dateiaenderung ohne Issue) und die Spezifikation VOR dem Fundament-Ticket liegen muss.
- SPEZIFIKATION AUFBEREITET: 21 Dateien (20 Dokumente + Index) als docs/600-pmo-README.md bis docs/619-pmo-open-decisions.md, 780 KB. Nummernblock 600 war frei (500 = Datenbank, 700 = QAF). Nicht mitgenommen mit Begruendung: Marktvergleich, Ist-Analyse, Issue-Korpus-Auswertung (98 fremde Ticketnummern), Befundliste ausserhalb Scope, Meeting-Governance-Entwurf, Issue-Karte (waere ab Tag 1 veraltet).
- BEREINIGUNG der Dokumente: 621 Querverweise auf neue Pfade gezogen, 110 auf nicht mitgenommene Dokumente entschaerft, 58 doppelte Pfadpraefixe repariert (eigener Ersetzungsfehler, gefunden durch Kontrolllauf), 109 Nennungen des internen Auftragsdokuments neutralisiert, 41 Telegram-Nachrichtennummern entfernt, 31 Kais- und 9 Aria-Nennungen zu Rollenbezeichnungen, 24 lokale Analysepfade repo-relativ gemacht, 18 Titel auf die neue Nummer gezogen. Endkontrolle: 0 Reste in allen Kategorien.
- 13 TICKET-TEXTE gebaut: 6 zusammengefuehrt (487 aus 487+488+489, 490 aus 490+491, 492 aus 492+493, 494 aus 494+495, 500 aus 500+503+Serveranteil 502, 501 aus 501+504+Oberflaechenanteil 502), 6 unveraendert mit aktualisierten Verweisen, 1 neu (Spezifikationsablage).
- VOLLSTAENDIGKEIT: 242 Aussagen (129 AC + 113 Substanz) zugeordnet, pruefe_mapping_pmo.py meldet 0 Luecken/0 Doppelungen. #502 kriterienweise aufgeteilt (3 Server, 5 Oberflaeche); Anzeige der Verknuepfungen und der Historie ausdruecklich der Oberflaeche zugeordnet, sonst waere sie zwischen die neue Grenze gefallen (Lehre issue-merge-boundary-gap).
- 21 Kommentare erzeugt (6 Umbau, 1 Hinweis fuer 6 unveraenderte, 8 Schliess, 1 EPIC), EPIC-Body neu, umbau-kommandos-pmo.sh mit Dry-Run gegen gh-Stub gruen.
- GEGENPRUEFUNG PMO (unabhaengiger Agent, 20 Originale gegen 13 neue): 6 Luecken, 5 Abweichungen, 5 Cluster kaputter Verweise, 2 Cluster interner Begriffe. Urteil: "nichts faellt weg" war NICHT erfuellt.
- ZWEI FUNDE GEGEN MICH: (1) RECHTEAUSWEITUNG - das Original beschraenkt Archivieren/Wiederherstellen ausdruecklich auf Lead/Champion, NICHT auf den Owner; meine Fassung hatte eine undifferenzierte Schreibregel. Ein Agent haette mehr Rechte gebaut. (2) SCHNITTKANTE ERNEUT - die Bedienoberflaeche des Archivierens fiel zwischen #500 (Server) und #501 (Oberflaeche) durch, obwohl ich die Auflage aus der Fabrikanalyse-Lehre notiert und in den Pruefbrief geschrieben hatte. Beides behoben.
- WEITERE BEFUNDE behoben: 21 Funktionsnamen-Nennungen im Original, 0 in meinen Fassungen (transitionActionItem, authorizeModuleProject, assertCan*); 409/412-Unterscheidung verwischt; Performance-Budgets, zwei Kennzahlen und die Sicherheitswarnung vor updateEntryDates() gestrichen; eine als PROPOSED markierte Randfrage als entschieden dargestellt; #265-Nummer fehlte; RLS-Ruecknahmeregel fehlte.
- VERWEIS-CLUSTER behoben: docs/docs-Doppelpfade + kaputte Backticks in 3 Dateien, unuebersetzte Altnummern, bare 05c, Wireframe-Pfade. ENTSCHEIDUNG: 4 zusaetzliche Dokumente aufgenommen (620-623: SharePoint-Bewertung, Abhaengigkeitskarte, Risikoregister, Doku-Vorgaben), weil 5 Tickets sich darauf berufen - sonst haette das Doku-Ticket sein eigenes AC verletzt. Jetzt 25 Dokumente statt 21, Abweichung an Kais gemeldet.
- ENDKONTROLLE: interne Begriffe 0, Verweise ins Leere 0, Backtick-Balance sauber, 242 Aussagen zugeordnet ohne Luecke.
- UEBERGABE 04:15 CEST: deliverables/pmo-konsolidierung-20260904.zip (69 Dateien, 474 KB) an Kais (TG 11155-11157). Secret-Scan sauber, Skript gegen gh-Stub gruen.
- MEMORY: issue-merge-boundary-gap um den Wiederholungsfall erweitert (Notiz allein reicht nicht, Gegenpruefung ist Pflicht); neu prose-rewrite-drops-technical-anchors (Bezeichner bleiben woertlich, Prosa nur fuer Begruendungen).