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/26-Teams-inkl-TrassenOrder.md

@@ -0,0 +1,114 @@
+# 26. Teams inkl. TrassenOrder
+
+Version: 1 | Last modified: 2026-05-07T16:51:18.183+02:00
+Source: confluence page ID 586388763
+
+---
+
+Team-Landschaft pathOS + TrassenOrder
+Stand: 2026-04-30 | Kontext: Reorganisations-Planung
+
+TrassenOrder (TraPo) ist ein Testballon, um zu pruefen ob eine andere Herangehensweise (entkoppelt, UX-first, klein) schneller, besser und sicherer funktioniert als der pathOS-Ansatz (Microservice-Monolith, 167 Repos, 35+ Personen).
+
+Aktuelle Team-Landschaft
+
+Team | Personen | Fokus | Services | Deployment | Besonderheit | 
+
+Team 404 | ~10 | Portal UI + Middleware | 2 (68K LoC) | pathOS Release-Zug | 33% Bug-Rate, kundenseitig | 
+
+Team CIB | ~13 | Prozesse, Camunda, Backend | ~15 (122K LoC) | pathOS Release-Zug | SV-Monolith, Abrechnung | 
+
+Team Zero | ~9 | TAF/TAP Schnittstellen | ~9 (38K LoC) | pathOS Release-Zug | Beste Qualitaet, OPs-Rotation | 
+
+OPs Squad | 2 fest + rot. | Betrieb, Infrastruktur | Infra-Repos | pathOS Release-Zug | Seit PI 39 (ex-STeam) | 
+
+DevOps | ~7 | CI/CD, Tooling, Pipelines | Pipelines, Helm | pathOS Release-Zug | Jan Lubenow = 39% SPOF | 
+
+TrassenOrder (TraPo) | ~5 (klein) | GelV-Portal (UX-first) | 1 (neu) | Unabhaengig! | Testballon, Discovery-Phase | 
+
+TrassenOrder vs. pathOS — Vergleich der Ansaetze
+
+Dimension | pathOS (aktuell) | TrassenOrder (Testballon) | 
+
+Architektur | Microservice-Monolith (synchrone Releases, 167 Repos) | Externes System, eigene Schnittstellen, unabhaengig deploybar | 
+
+Teamgroesse | ~35+ Personen, 5 Teams | ~5 Personen, 1 Team | 
+
+Zielgruppe | Alle EVUs (Experten + Anfaenger) | Kleine EVUs, Ein-Mann-Betriebe ("WhatsApp-Nutzer") | 
+
+UX-Ansatz | 240+ Formularfelder, Experten-Tool | 3 Angaben fuer eine Bestellung, radikal vereinfacht | 
+
+Deployment | Release-Zug (alle Services zusammen) | Unabhaengig, eigener Rhythmus | 
+
+Abhaengigkeiten | Hoch (Kafka, Camunda, 15+ Services) | Minimal (nur API-Schnittstellen zu Primaerquellen) | 
+
+Geschwindigkeit | PI-getaktet (10 Wochen) | Kontinuierlich, Feature-basiert | 
+
+Scope | Netzfahrplan + GelV + ujBau + Abrechnung | Nur GelV (Gelegenheitsverkehr) | 
+
+Phase | Produktiv seit Dez 2025 | Discovery seit Jan 2026, Livegang Q4 2026 | 
+
+Was testet der Testballon?
+Hypothesen
+
+Schneller: Kann ein kleines, entkoppeltes Team schneller liefern als ein grosses im Release-Zug?
+
+Besser: Fuehrt UX-first + radikale Vereinfachung zu besserer Nutzerzufriedenheit?
+
+Sicherer: Reduziert Entkopplung das Risiko (kein Dominoeffekt bei Fehlern)?
+
+Wenn der Testballon erfolgreich ist: Das Modell koennte auf weitere Bereiche uebertragen werden (Netzfahrplan, ujBau). Langfristig koennte TrassenOrder das pathOS-Portal abloesen.
+
+Schnittstellen zwischen pathOS und TrassenOrder
+
+Schnittstelle | Richtung | Zweck | 
+
+Trassenanmeldung API | TraPo → pathOS | Bestellung absetzen | 
+
+Stammdaten API | TraPo ← Primaerquelle | Direkt, NICHT ueber pathOS | 
+
+Angebots-Rueckmeldung | pathOS → TraPo | Ergebnis der Konstruktion | 
+
+Trassenfinder | TraPo ← BVU | Routing, Validierung (Fernziel) | 
+
+Architekturentscheidung: TrassenOrder greift auf Primaerquellen direkt zu — nicht ueber eine pathOS-Zwischenschicht. Das vermeidet Abhaengigkeiten vom pathOS Release-Zug.
+
+Implikationen fuer Team-Reorganisation
+
+Szenario | Auswirkung auf pathOS-Teams | 
+
+TraPo erfolgreich → GelV wandert zu TraPo | pathOS kann sich auf Netzfahrplan + ujBau + Abrechnung konzentrieren. Vereinfacht den fachlichen Schnitt erheblich. Click&Ride (ADR-72) wird obsolet. | 
+
+TraPo erfolgreich → Modell wird uebertragen | Weitere kleine Teams fuer spezifische Domaenen. pathOS wird zum API-Backend-Layer. Portal-Team (404) wird langfristig obsolet. | 
+
+TraPo scheitert → GelV bleibt bei pathOS | Keine Aenderung. Click&Ride Anbindung (ADR-72) wird weiter von CIB gebaut. | 
+
+Offene Fragen
+
+Wann ist der Testballon "erfolgreich"? Welche Metriken? (Time-to-Market, Nutzerzufriedenheit, Bug-Rate?)
+
+Wie wird die Schnittstelle zwischen TraPo und pathOS-Backend definiert und versioniert?
+
+Wer pflegt die Schnittstelle langfristig? (API-Vertrag)
+
+Kann das TraPo-Modell auf Netzfahrplan skaliert werden? (Komplexitaet ist dort 10x hoeher)
+
+Was passiert mit Team 404 wenn TrassenOrder das Portal langfristig abloest?
+
+Team-Kennzahlen (Vergleich)
+
+Metrik | pathOS gesamt | TrassenOrder | Faktor | 
+
+Personen | ~35 | ~5 | 7x | 
+
+Services | ~40 aktiv | 1 | 40x | 
+
+Lines of Code | ~260K | ~0 (Discovery) | — | 
+
+Jira-Projekte | 6 (O2C*, TTTI) | 1 (TRAPO) | 6x | 
+
+Release-Frequenz | ~2x/Monat (KTU) | Kontinuierlich (Ziel) | — | 
+
+Bug-Rate | 20-33% | 0% (noch kein Code) | — | 
+
+Deployment-Abhaengigkeiten | Hoch (17+ Umgebungen) | Keine | — |