Migrate all repos into monorepo context folders

Bahn: aisupport, Analyse-O2C-C2S, awesome-bahn-mcp-servers, beam-mcp,
      Confluence_Bot, db-planet-mcp-server, O2C-Harness, project-audit,
      Projekt-KIQ-HP, teamlandkarte-mcp
Dhive: Jury-Voting
Privat: CV, NoteGraph (NOTE: NoteGraph needs complete redo after consolidation)
Shared: AI-Orchestrator, OrgMyLife, power_skills_and_more
Shared/references: symphony (read-only)

Bahn repos remain available as independent remotes - this monorepo
pulls them in via subtree, the originals are untouched.

bahn/Analyse-O2C-C2S/sources/o2c/O2C-Einfachbahn/25-Team-Reorganisation-Optionen.md

@@ -0,0 +1,172 @@
+# 25. Team-Reorganisation (Optionen)
+
+Version: 3 | Last modified: 2026-05-07T14:47:08.689+02:00
+Source: confluence page ID 586386850
+
+---
+
+Team-Reorganisation pathOS — Optionen und Bewertung
+Stand: 2026-04-30 | Status: Entwurf zur Diskussion
+
+Dieses Dokument analysiert Optionen fuer die Neuaufstellung der pathOS-Teams. Ziele: Schnellere Umsetzung, weniger Komplexitaet, bessere Qualitaet und Verantwortlichkeit.
+
+Ausgangslage
+
+Team | Personen | Verantwortung | Services | Problem | 
+
+Team 404 | ~10 | Portal UI + Middleware | 2 (68K LoC) | 33% Bug-Rate, steigend | 
+
+Team CIB | ~13 | Prozesse, Backend, Camunda | ~15 (122K LoC) | SV-Monolith (93K, 2214 Smells) | 
+
+Team Zero | ~9 | TAF/TAP Schnittstellen | ~9 (38K LoC) | OPs-Rotation belastet | 
+
+OPs Squad | 2 fest + rot. | Infrastruktur, Betrieb | Infra-Repos | Nur 2 feste Mitglieder | 
+
+DevOps | ~7 | CI/CD, Tooling | Pipelines | Jan Lubenow = 39% SPOF | 
+
+Ziele
+
+Primaer | Nachrangig | 
+
+Schnelle Umsetzungsgeschwindigkeit | Staerkenorientierter Einsatz | 
+
+Weniger Komplexitaet | Wissen breiter verteilen | 
+
+Weniger Abhaengigkeiten | Flexibilitaet bei Prioritaetswechsel | 
+
+Bessere Qualitaet | | 
+
+Bessere Verantwortlichkeit | | 
+
+Option A: OpsDev + Feature-Pool
+Modell
+OpsDev Team (permanent, ~8-10): Betrieb, Bugs, kleine Features. Lead OpsDev ohne PO.
+
+Feature-Pool (~20-25): Entwickler + BAs + Feature-POs. Bilden temporaere Feature-Teams (3-5 Pers.) fuer grosse Features. Nach Abschluss: 1 Dev → OpsDev (Hypercare).
+
+Vorteile | Nachteile | 
+
+Feature-Team ownt end-to-end | Kontextwechsel, Onboarding-Aufwand | 
+
+Keine Cross-Team-Deps fuer Features | Kein stabiles Team, Teambildung leidet | 
+
+Flexibel nach Prioritaet | OpsDev wird Muellhalde fuer Bugs | 
+
+Wissenstransfer durch Hypercare | PO-Overhead (3-4 POs parallel) | 
+
+Option B: Fachlicher Schnitt (4 Varianten)
+
+B1: Bestellen vs. Abwickeln
+
+Team "Bestellen" | Team "Abwickeln" | 
+
+Portal UI + MW, Common Interface, Stammdaten, Kundendaten, TAF/TAP-Konverter | Steuerung Vertrieb (Camunda), Auftrags-Verwaltung, IFP-Connector, Vertragsdaten, Archivierung, Abrechnung | 
+
+Fokus: Was der Kunde sieht | Fokus: Was nach der Bestellung passiert | 
+
+✔ Klarer Kundenfokus | ✘ NAÄ betrifft beide, SV ist Monolith
+
+B4: Trasse vs. Vertrag (bester fachlicher Schnitt)
+
+Team "Trasse" | Team "Vertrag" | 
+
+Trassenanmeldung (Portal+CI), Trassenkonstruktion (IFP), Stammdaten, TAF/TAP | Angebot + Vertrag (SV), Abrechnung, Stornierung, Rahmenvertraege, Vertragsdaten | 
+
+Vom Kundenwunsch bis Konstruktionsauftrag | Vom Angebot bis zur Rechnung | 
+
+✔ Sauberster Schnitt entlang Geschaeftsprozess, Abrechnung hat eigenes Team | ✘ SV muesste aufgeteilt werden, Portal zeigt beides
+
+Option C: Hybrid — EMPFOHLEN
+
+Empfohlenes Modell: OpsDev (permanent) + 2 fachliche Teams (permanent) + temporaere Feature-Squads fuer grosse Themen.
+
+OpsDev (~6 Pers.) | Team "Bestellen" (~12) | Team "Verarbeiten" (~12) | 
+
+Betrieb, Deployment
+Monitoring, Infrastruktur
+Bug-Triage
+Lead: OpsDev-Lead | Portal UI + MW
+Common Interface
+Stammdaten, Kundendaten
+TAF/TAP Konverter
+Click&Ride
+PO + BA + Devs | Steuerung Vertrieb
+Auftrags-Verwaltung
+IFP-Connector
+Archivierung
+Vertragsdaten, Abrechnung
+PO + BA + Devs | 
+
+Bugs: Infrastruktur | Bugs: Portal, CI, STB | Bugs: SV, AV, IFP | 
+
+Fuer grosse Features (GelV, ujBau, NAÄ): Temporaer 2-3 Personen aus beiden Teams zusammenziehen. Nach Abschluss: zurueck + 1 Person Hypercare in OpsDev.
+
+Gesamtbewertung
+
+Option | Speed | Komplexitaet | Deps | Qualitaet | Ownership | 
+
+A: OpsDev + Pool | ⭐⭐⭐⭐ | ⭐⭐ | ⭐⭐⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐⭐ | 
+
+B1: Bestellen/Abwickeln | ⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐⭐⭐ | 
+
+B4: Trasse/Vertrag | ⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐⭐ | 
+
+C: Hybrid (empfohlen) | ⭐⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ | 
+
+D: Spotify | ⭐⭐⭐ | ⭐ | ⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐⭐ | 
+
+Noch zu klaeren
+
+SV aufteilen? — Ist der Monolith (93K LoC) technisch teilbar?
+
+NAÄ als Querschnitt — Dediziertes Feature-Team oder feste Zuordnung?
+
+Portal-Ownership — Portal zeigt Daten aus allen Services. Eigener Querschnitt?
+
+Abrechnung — Eigenes Team wert? Oder bei "Verarbeiten"?
+
+Personelle Passung — Staerken-Mapping der 35 Personen
+
+Uebergangsphase — Dauer, Produktivitaetsverlust?
+
+PO-Struktur — 1 PO pro Team oder uebergreifend + Feature-POs?
+
+Metriken — Bug-Rate, Durchlaufzeit, Deployment-Frequenz als Erfolgsmessung
+
+Fehlende Daten fuer Entscheidung
+
+Git-Contributions pro Person/Service (wer kennt welchen Code?)
+
+Abhaengigkeits-Graph zwischen Services (Kafka-Topics, REST-Calls)
+
+Kundenfeedback: Welche Features werden am meisten nachgefragt?
+
+Camunda-Prozess-Instanzen: Wie oft laeuft welcher Prozess?
+
+Faktor TrassenOrder (Team TraPo) — NEU
+
+TrassenOrder ist ein neues Produkt innerhalb SAB (gleiche Einheit wie pathOS), das den Bestellprozess fuer Gelegenheitsverkehr modernisiert. Entwicklungsstart Jan 2026, Livegang vsl. Q4 2026.
+
+Aspekt | TrassenOrder | pathOS (Click&Ride) | 
+
+Fokus | GelV medienbruchfrei, attraktiver Workflow | GelV kurzfristig (<5 Arbeitstage), Gueterverkehr | 
+
+Phase | EXPLORE (seit Jan 2026) | Produktiv (seit Dez 2025) | 
+
+Livegang | Q4 2026 | Bereits live | 
+
+Team | TraPo (eigenes Team in SAB) | CIB (ADR-72) | 
+
+Jira | TRAPO (systelone) | O2CCIB / O2C404 | 
+
+Implikationen fuer Reorganisation
+
+Abgrenzung klaeren: Was macht TrassenOrder, was macht pathOS/Click&Ride?
+
+Integration: Frontend fuer pathOS-Backend? Oder separates System?
+
+GelV-Ownership: Gehoert GelV kuenftig zu TraPo oder pathOS?
+
+Vereinfachung: Wenn TraPo GelV uebernimmt, kann pathOS sich auf Netzfahrplan + ujBau konzentrieren — vereinfacht den fachlichen Schnitt erheblich
+
+Empfehlung: Vor Reorg-Entscheidung unbedingt mit TraPo-Team abstimmen (Roadmap-Abgleich, Schnittstellen, langfristige Vision).