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/project-audit/data/confluence-export/pages/556699737_2026-03-03 Smoketests nach Deployments.md

@@ -0,0 +1,62 @@
+# 2026-03-03 Smoketests nach Deployments
+
+> Confluence Page ID: 556699737
+> Version: 2
+> Pfad: /pathOS/Kommunikationskanäle, Termine, Besprechungsnotizen pathOS/Besprechungsnotizen/Sonstige Termine/2026-03-03 Smoketests nach Deployments
+> Labels: meeting-notes
+
+---
+
+## Teilnehmer
+
+-       
+
+
+
+
+
+## Verständnis:
+
+- Smoketest: Validierung, dass die Umgebung nach Deployment eines Artefakts (Release/Hotfix) angekommen ist und Umgebung noch funktioniert
+## Ziel
+
+- Entwurf von Smoketests für Abnahme- und Produktionsumgebungen
+
+
+## Zu entscheidende Fragen:
+
+- Wer soll die ausführen können
+- Jeder der installiert → primär OpsSquad
+- Muss prinzipiell jedem möglich sein (auch PO/PM)
+- Scope: wie weit sollen die gehen, was wollen wir testen? 
+- pathOS+TPN
+- "nur" Kommunikationsweg: wir führen eine Anmeldung durch, die bei uns durchläuft, aber dann in der Eingangsvalidierung scheitert
+- Idee:
+- Kundennummer, die TPN nicht kennt
+- Datenkonstellation, die in TPN fachlich tiefer validiert wird (z.B. ETCS-Ausprägungen, oder Studienausprägungen als Triebfahrzeug)
+- dadurch wissem wir dass Kommunikation bidirektional funktioniert. Erzeugen so auch nur Daten in pathOS.
+- Für Produktion
+- Erzeugen von Daten in pathOS? → OK
+- Rahmenbedingungen (z.B. zu verwendende Kundennummer, Strecke, ...)
+- alles quasi unter dem Aspekt erstmal egal, da wir nur in die Fehlermeldung gehen
+- Welcher Test(s) sehen wir als verpflichtend an?
+- Alle drei Tests verpflichtend für alle Umgebungen (kann bei fachlichen Bedarf auch durch Positivfälle substituiert werden). 
+- Testdokumentation im Rahmen des Releases (Testexecution)? Gegen Checkliste prüfen. TODO
+
+
+## Testfälle:
+
+- Ablage hier: Test Repository - DB InfraGO ITD Lifecycle Management Tool 
+- Testideen:
+- Test im Kanal Portal
+- Trassenanmeldung
+- Case Reference Object anlegen
+- Test im Kanal CI
+- Trassenanmeldung
+- Trassenanmeldung: siehe unten. Einfachster Laufweg etc. → mit Testbausteinen beschreiben ( )!
+
+
+TODOs:
+- Fachliche Konstellation finden, die bei TPN nicht durchgeht →   fragt Stefan →
+- erledigt: nehmen pathOS → Widerspruch in Zugsicherungssystemen, die sich gegenseitig ausschließen. Fällt bei BEP-Prüfung in TPN auf. Weitere Alternativen wären: nichtelektrifizierte Strecke und E-Lok, ...
+- Definition der Testfälle im XRay → Â