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/Workflow-Testing-Team-XWing.md

@@ -0,0 +1,16 @@
+# Workflow: Testing - Team XWing
+
+Version: 37 | Last modified: 2026-01-13T09:54:01.027+01:00
+Source: confluence page ID 431628888
+
+---
+
+INLINEWorkflow (Siehe Confluence Workflow: Testing - Team XWing - O2C | Order2Cash - ariJa Confluence)
+Entwickler hat Entwicklung abgeschlossen → Entwickler hat Unit Tests geschrieben -> Entwickler schiebt Ticket auf "ReadyForTest" -> Tester testet erfolgreich auf EU -> Tester dokumentiert Test und approved den MR -> MR Review findet durch zweiten Entwickler erfolgreich statt -> Merge erfolgt durch Entwickler auf TU -> (Ggf. je nach Ticket: Tester testet erfolgreich integrativ auf TU (ggf. über UI) und dokumentiert den Retest ->) Tester schiebt Ticket auf "Done"
+Die Rolle des Testers kann natürlich auch von einem Entwickler erfüllt werden hier, aber den Workflow sollten wir hier definitiv beachten. Und es ist essentiell, dass die 3 genannten Rollen von 3 verschiedenen Personen erfüllt werden.
+Dokumentation
+Stories werden durch einen dedizierten Test in XRay samt Execution abgedeckt. Beispiel hier: O2CXW-6485 mit dem Test O2CAP-2911 und der Execution O2CAP-2912. (In diesem Fall ist der Test direkt in O2CAP erstellt worden, weil er direkt als Regressionstest konzipiert wurde. Im Normalfall erstellen wir den Test im selben Projekt der Story)
+Bei Bugs, Enablern und Co. reicht eine Dokumentation in Form von Kommentaren. Dort beschreiben wir das Vorgehen, das Ergebnis und hinterlegen möglichst noch die Testdaten. Manchmal ergibt es auch Sinn, den Bug einmal auf einer betroffenen Umgebung zum Vergleich zu reproduzieren und das nochmal aufzuzeigen. Beispiel hier: O2CXW-6690 (siehe Bild)
+Das folgende Diagramm zeigt den optimalen Ablauf einer Testdurchführung für eine reguläre Feature-Story bzw. einen Bug.
+Der gezeigte Workflow ist rein aus Testersicht gestaltet. Zur Einordnung ist auf den generellen Feature Workflow in  zu verweisen.
+trueMerge Workflow Testingfalseautotoptrue2491113125