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/c2s/C2S-ART-EKon/teams/Team-Konnex.md

@@ -0,0 +1,42 @@
+# Team Konnex
+
+Version: 9 | Last modified: 2026-06-09T14:22:12.145+02:00
+Source: confluence page ID 546397210
+
+---
+
+Team Konnex ist ART SuN angegliedert, um zu unterstützen und fachlichen Input zu geben
+Organisationell gehört das Team aber nicht zum ART SuN
+Unser TAKT Tester Team kann über folgenden Email-Verteiler erreicht werden: C2S.Konnex@deutschenbahn.com 
+
+Name
+ | Rolle
+ | 
+
+Matthias Hüller
+ | Team-Lead
+ | 
+
+Matthias Wilke
+ | 
+
+Test/QA
+ | 
+
+Annemarie Wensel
+ | 
+
+Test/QA
+ | 
+
+Alexander Ebner
+ | 
+
+Test/QA
+ | 
+
+Tobias Dreißig
+ | 
+
+Test/QA
+ |

bahn/Analyse-O2C-C2S/sources/c2s/C2S-ART-EKon/teams/Team-Nordstern.md

@@ -0,0 +1,14 @@
+# Team Nordstern (Konzeption Legacy-Ablöse)
+
+Version: 11 | Last modified: 2026-06-15T14:54:01.673+02:00
+Source: confluence page ID 602312796
+
+---
+
+Links zur Dokumentensammlung in unserem iVö (BSV)-TeamroomRoot-Verzeichnis
+TTTneo - C2S | Capacity2Schedule | LS - ariJa Confluence: TTTneo Ablaufdiagramme
+DokumenteZielbild VÖ_v0.pptx
+
+JiraUV | Nordstern - DB InfraGO ITD Lifecycle Management Tool
+C2S | Capability Backlog - Structure - DB InfraGO ITD Lifecycle Management Tool
+Railmap C2S ‒ Conceptboard

bahn/Analyse-O2C-C2S/sources/c2s/C2S-ART-EKon/teams/Team-Rules.md

@@ -0,0 +1,112 @@
+# Team Rules
+
+Version: 11 | Last modified: 2026-05-21T00:57:52.845+02:00
+Source: confluence page ID 318903955
+
+---
+
+Neben unseren Vereinbarungen wir der DoD&DoR oder unserem Ticket-Workflow entstehen sukzessive im Rahmen unserer Retroa oder anderen Workshops Regeln für unser Team, die wir auf dieser Seite dokumentieren. 
+
+Thema | Nr. | Regel | 
+ 
+ 
+ 
+ 
+ 
+ 
+Board, Workflow & Tickethandling
+ 
+ 
+ 
+ | 1
+ | Wir verwenden das Scrum Board, um unsere Arbeit und Fortschritte, die auf das Sprintziel einzahlen, für alle sichtbar zu machen.
+ | 
+2
+ | Sobald eine Person ein Ticket aus dem Sprint Backlog zieht, trägt sie bis zur Fertigstellung die Hauptverantwortung dafür.
+ | 
+3
+ | Falls ein Ticket blockiert ist, sprechen wir dies proaktiv im Daily an und hinterlassen einen Kommentar am Ticket, um den Grund für die Blockade zu dokumentieren.
+ | 
+4
+ | Sollte ein Ticket innerhalb eines Sprints nicht abgeschlossen werden können, benennen wir die Gründe dafür proaktiv im Daily.
+ | 
+5
+ | Wir arbeiten nach dem Prinzip "Stop starting, Start finishing"
+ | 
+6
+ | Es sind sich alle einige im Team, dass sich Anforderungen/AKs während des Sprints durch externen Einfluss verändern können.
+Falls diese Fall eintritt, prüfen wir als Team, ob das Sprint Commitment dadurch beeinflusst wird. Wenn ja, wird ein Folgeticket für den nächsten Sprint erstellt oder gleichwertiges Ticket aus dem Sprint entfernt, um den Sprint Scope konstant zu halen.
+Sollten sich Anforderungen/AKs verändern, werden diese immer am Ticket in Jira festgehalten.
+ | 
+7
+ | Nach Fertigstellung eines Tickets (Ticket ist in "In Review") gibt die Entwickler*in per Jira Kommentar eine Einschätzung ab, ob die Schätzung valide war.
+ | 
+8
+ | Wir streben als Team eine hochwertige Storyqualität an, damit diese effizient und effektiv abgearbeitet werden kann.
+ | 
+9
+ | Wir beginnen die Umsetzung von Anforderungen (Features, Enabler, User Stories) erst, wenn ihr Nutzen für die Benutzer:innen und das Geschäft klar und nachvollziehbar ist.
+ | 
+10
+ | Sobald ein ART-Feature den Status "Ready" im Rahmen des ART-Feature-Refinement erhält, wird dieses im Team-Refinement vom PO oder BE vorgestellt.
+ | 
+11
+ | Bis eine höhere Entwicklungsumgebung verfügbar ist für deployment der Anwendung, wird mit dem DoD Punkt 5, "höchstmögliche Umgebung", die INT-NEXT, gemeint.
+ | 
+ 
+ 
+ 
+ 
+ 
+Meetings & Dokus
+ | 12
+ | Wir sagen Termine zu oder ab. 
+ | 
+13
+ | Bei der Festlegung von Terminen beschreiben wir klar das Ziel und geben Anweisungen zur Vorbereitung für die Teilnehmenden.
+ | 
+14
+ | Wir bereiten uns entsprechend den Zielen und der Agenda eines Termins vor.
+ | 
+15
+ | Die anwesenden Personen haben die Befugnis, Entscheidungen zu treffen, auch wenn nicht alle Mitglieder des Teams anwesend sind.
+ | 
+16
+ | Bei Abwesenheiten wird eine Vertretung für wichtige Meetings organisiert.
+ | 
+17
+ | Wir dokumentieren Ergebnisse, die für das gesamte Team relevant sind. 
+ | 
+18
+ | Der Single Point of Truth für fachliche Dokumentationen ist Confluence.
+ | 
+19
+ | Der Single Point of Truth für technische Dokumentationen ist GitLab.
+ | 
+20
+ | Vor Abwesenheiten (1 Tag oder mehr) informieren wir das Team im Daily und im Chat. 
+ | 
+21
+ | Nach einer Abwesenheit informieren wir uns proaktiv über das Geschehene (Holschuld).
+ | 
+22
+ | Vor Abwesenheiten stellen wir sicher, dass wegen meiner Abwesenheit keine Arbeiten im Rahmen des Sprints blockiert werden. 
+ | 
+ 
+
+Kommunikation & Kultur
+
+ 
+ | 23
+ | Wir kommunizieren proaktiv an welchen Aufgaben wir arbeiten.
+ | 
+24
+ | Jedes Teammitglied fühlt sich für das Produkt verantwortlich.
+ | 
+25
+ | Es wird im Team offen und ehrlich Feedback gegeben.
+ | 
+26 | Bei Konflikten werden diese direkt und wertschätzend kommuniziert.
+ | 
+27 | Bei wichtigen Entscheidungen (z.B. Veränderung der Teamstruktur) müssen alle Mitglieder die Möglichkeit haben abstimmen zu können. Das jeweilige Vorgehen wird individuell im Team abgestimmt.
+ |