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/Team-Rogue-One.md

@@ -0,0 +1,132 @@
+# Team Rogue One
+
+Version: 16 | Last modified: 2026-05-06T13:22:22.709+02:00
+Source: confluence page ID 533429844
+
+---
+
+Termine:
+ | Montag | Dienstag | Mittwoch | Donnerstag | Freitag | 
+09:15 | 
+ | Daily | Daily | Daily | Daily | 
+09:30 | Status Meeting  | 
+ | 
+ | 
+ | 
+ | 
+13:00 | 
+ | Refinement | 
+ | Teammeeting | 
+ | 
+15:00 | 
+ | Retro | 
+ | 
+ | 
+ | 
+
+Teammitglieder:Sebastian.Goendoer@deutschebahn.com (PO)
+Uenal.Dogdu@deutschebahn.com (SM)
+martin.stieglitz@deutschebahn.com (FO)
+Dirk.Di.Wagner@deutschebahn.com (DEV)
+Stefan.St.Werner-extern@deutschebahn.com (DEV)
+Jonas.Monecke-extern@deutschebahn.com (DEV)
+Lukas.Schmiedgen-extern@deutschebahn.com (DEV)
+Fred.Fluegge-extern@deutschebahn.com (DEV)
+
+DoR - Definition of Ready für Feature und Enabler Owner des Feature/Enabler ist bestimmt (Hinweis: Feld Bearbeiter/Assignee des Feature/Enabler in ariJa)
+ Feature/Enabler ist einer Capability zugeordnet
+ Risiken sind dokumentiert und mögliche Maßnahmen definiert
+ Abhängigkeiten sind, soweit bekannt, beschrieben und innerhalb von ariJa verlinkt (ART interne). Externe Abhängigkeiten sind im Feature/Enabler dokumentiert und abgestimmt.
+ Relevante Dokumente sind verlinkt oder angehängt
+ Das Feature/Enabler wurde allen Teams vorgestellt, besprochen und von allen verstanden
+ Feature/Enabler ist innerhalb eines PIs umsetzbar und möglichst unabhängig zu anderen Feature
+ Die Bewertungen zur WSJF Berechnung (Business Value, Time Criticality, RROE) sind eingetragen
+ Feature ist in T-Shirt Sizes geschätzt
+ NEU: Testing ist berücksichtigt.
+DoD - Definition of Done (User Stories, Bugs, Enabler)(Stand: April 2025)
+Akzeptanzkriterien sind erfüllt: die Entwicklung deckt die Akzeptanzkriterien vollständig ab. Falls diese nicht aktuell sein sollten, ist eine Anpassung in Absprache mit dem Ticketersteller erfolgt.
+Reviewer-Approval: der Code wurde gereviewed, einschließlich der Einhaltung von SonarQube-Grenzen, Unit Tests, Sicherheits-Scans und Conventional Commits. Bei Liquibase-Skripten ist ein zusätzliches Review durch Björn oder bei Abwesenheit durch Christian/Adrian erfolgt.
+Tester-Approval: die Regressionstests wurden überprüft und angepasst, progressive Tests auf der EU sind erfolgreich und die Testdurchführung ist dokumentiert.
+Code-Merge: Codeänderungen sind in den Zielbranch (Master- oder Featurebranch für Release Bundles) gemerged.
+Nachtest auf TU: bei Bedarf wurde ein Nachtest auf der Testumgebung durchgeführt.
+Releaseinformationen: Die Lösungsversion im Jira-Ticket und die Deployment-Anmerkungen in Confluence sind gepflegt.
+Die Storie wurde vom PO bzw FO abgenommen
+
+Abstimmung hinsichtlich zukünftiger Tests:                
+Testdriven Development → Bereits im Refinement soll darauf geachtet werden was später getestet werden soll. Teile des Testdesigns würden sich daraus bilden lassen.
+Unit Tests werden von den Entwicklern durchgeführt.
+manuelle Tests sollen von jemandem vorgenommen werden, der an der Entwicklung der Story nicht beteiligt
+Bereits bei der Erstellung der Story werden KI generierte Testszenarien aufgezeigt
+fehlende xray Skills sollen aufgebaut werden → Schulung oä
+Abstimmung zur zukünftigen Releaseplanung            Releasetermine werden im Refinement in´s Ticket geschrieben
+Stories dürfen nur dann gemerged werden, wenn sie bis zum Release noch getestet werden können
+Die Kommunikation was released wird, kommuniziert der PO im ART Sync
+...
+Abstimmung zur Nutzung des KANBAN Boards          Erstellung von Tickets & PriorisierungGrundsätzlich ist der Feature Owner für das Schreiben der Tickets zuständig. Es kann jedoch jedes Teammitglied Tickets erstellen
+Die Nummerierung der Features entspricht der aktuellen Priorität. Bei Bedarf werden auch Stories nummeriert
+Grundsätzlich stellt  die Reihenfolge der Tickets die Priorität dar
+die Priorität wird auch im Ticket selbst hinterlegt. S.h. Abbildung unten
+
+Hierarchie im BoardEbene 1: Feature
+Ebene 2: Story, Enabler, Bug
+Ebene3: Aufgabe
+
+Aktuelle Lanes im KANBAN BoardBlocked | Open | Fachlich geklärt | In Progress | Ready4Test | In Test | Ready4TU | Ready4AU | 
+enthält alle Tickets, die bereits "In Progress" waren und aktuell nicht weiter bearbeitet werden können. | Stellt das Sammelbecken für alle Tickets dar. | Als fachlich geklärt gilt ein Ticket wenn es folgende Eigenschaften erfüllt:
+erfüllt die DoR Kriterien 
+Akzeptanzkriterien sind vollständig
+enthällt eine Beschreibung
+Refinement hat stattgefunden
+enthält Testszenarien
+ | alle Tickets in Bearbeitung
+als Richtlinie gilt: WIP-Limit = 3
+ | Akzeptanzkriterien sind erfüllt
+ | Tests am Laufen
+ | Tests waren erfolgreich, Bugs wurden behoben
+fachliche Bewertung ist erfolgt
+ | alle bisherigen Tests waren erfolgreich
+das Ticket ist fertigentwickelt (done)
+ | 
+
+Offene Todos:
+
+4
+c53c64d8-4a8a-4a70-a57c-c01a5b741410
+incomplete
+Erstellung eines Templates für eine Checkliste
+
+5
+d047a4a8-29ae-42c6-812c-cbf7ee820379
+complete
+Kommunizieren, dass das Team sein Commitment aus dem letzten PI nicht wird halten können.
+
+6
+b165b729-cfb5-44e4-9d56-481c5aab018e
+incomplete
+ 
+
+Der Refinement Prozess   
+Verantwortlichkeiten
+Product Owner / Feature Owner
+Wählt Stories aus dem Backlog für das Refinement aus. Bis spätestens zum Statusmeeting.
+Stellt sicher, dass jedes Ticket die Definition of Ready (DoR) erfüllt
+Team
+Sichtet die Tickets vor dem Refinement
+Notiert offene Fragen und Unklarheiten
+Gibt eine Aufwandsschätzung ab in der sowohl Aufwand als auch Komplexität berücksichtigt werden
+
+Ablauf
+PO/FO wählt relevante Stories aus dem Backlog
+PO/FO priorisiert die Tickets (Top-Ticket ganz oben)
+PO/F prüft die Definition of Ready
+→ nicht erfüllt: Ticket nachschärfen
+Team bereitet sich vor und sammelt Fragen
+Refinement-Meeting:
+Akzeptanzkriterien werden geprüft
+Testszenarien werden ergänzt
+
+Ergebnis des Refinements
+✔ Klar verstandene Tickets
+✔ Vollständige Akzeptanzkriterien
+✔ Ergänzte Testszenarien
+✔ Gute Basis für verlässliche Schätzungen