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.
This commit is contained in:
2026-06-30 20:39:52 +02:00
parent 2f2b295531
commit a5f8fb49ab
1717 changed files with 447332 additions and 0 deletions
@@ -0,0 +1,87 @@
# Team Ains: Migration nach SIC OP
Version: 5 | Last modified: 2026-06-16T14:37:53.062+02:00
Source: confluence page ID 603264161
---
Progress
| BBOA | Kapa-Service | KE-Adapter | KE-Service | Konfliktservice | ZV-Transformation |
Führendes Repo | RedIFP
| GreenSIC OP
| GreenSIC OP
| RedIFP
| RedIFP
| RedIFP
|
Config hinterlegt | UKAINS-2412
|
|
|
|
|
|
SIC OP DEV deployt |
|
|
|
|
|
|
SIC OP IEU deployt |
|
|
|
|
|
|
SIC OP INT deployt |
|
|
|
|
|
|
SIC OP ABN deployt |
|
|
|
|
|
|
SIC OP PROD deployt |
|
|
|
|
|
|
IFP DEV entfernt |
|
|
|
|
|
|
IFP INT entfernt |
|
|
|
|
|
|
IFP ABN entfernt |
|
|
|
|
|
|
IFP PROD entfernt |
|
|
|
|
|
|
LearningsWenn der Build in der Pipeline fehlschlägt, kann es notwendig sein, einmal grdle wrapper auszuführen
@@ -0,0 +1,68 @@
# Team FaMe / Team Fuse - Zusammenarbeitsregeln - final
Version: 24 | Last modified: 2026-02-27T11:08:57.453+01:00
Source: confluence page ID 553962107
---
link10#e2e2e2200coverflex-startcenter center
Zusammenarbeitsregeln erarbeitet am 25.02.2026 mit jeweils 4 mandatierten Vertretern pro Team. Überprüfung und Anpassung der Ergebnisse kontinuierlich bei Bedarf, spätestens nach 6 Monaten. 
link10#d0d0d0900coverflex-startcenter centerKommunikation/MeetingsFür die Abstimmungsthemen existiert ein Teams-Chat für die beiden Teams. 
Zusätzlich gibt es einen Sync-Termin zwischen den BEs beider Teams (Montag 10-10.30, 2-wöchentlich in der Refinement-Woche)
"Planning 3" mit ausgewählten Teamvertretern aus beiden Teams (Prüfung von ggf. kollidierenden Themen für den kommenden Sprint) - Mittwoch, Sprintwechselwoche 13.00 Uhr - 15 Min.
Regelmäßiges, kurzes wöchentliches Meeting, 15 Min., mit harter Timebox und Agenda (Dev-Runde FaMe/Fuse) - Mi-Vormittag (11.30)Inhalte/Themen:Abstimmung von Abhängigkeiten
Prüfung der Themen auf Konfliktpotenziale (wird z.B. an gleichen Modulen oder Codestellen gearbeitet)
Abstimmung möglicher Breaking Changes
Umsetzen/TestingBreaking Changes (API) sind abzustimmen und möglichst Teamübergreifend in den Iterationen zu sammeln und gemeinsam an Team Flux zu kommunizieren
Die umgesetzten Features sollen auch Qualitätsgesichert werdenUnittestabdeckung soll das aktuelle Niveau von mind. 90 % halten
Thunderclienttests sollen bedarfsabhängig erstellt werden (lokal auszuführen)
Vor dem Merge in den Main müssen alle Tests erfolgreich durchgelaufen sein
Fuse und FaMe halten sich an die Coding Guidlines (falls vorhanden) & Architekturrichtlinien (z.B. modulare Struktur)
Die Arbeiten finden in dem Repository in der C2S (SIC OP) Gruppe statt
Technische Entscheidungen werden in kurzen ADRs dokumentiert (Decision, Kontext, Optionen, Impact). 
link10#d0d0d0900coverflex-startcenter centerAbnahme/Review/DokuDie MRs von Fuse bzw. FaMe werden im jeweiligen Team gereviewed und freigegeben. Nur bei konkreter Anfrage schaut das andere Team mit drauf.
Technische und Fachliche Doku ist pro Story/Feature zeitnah, bis zur Abnahme des betreffenden Features, zu erstellen 
Möglichkeit zur gegenseitigen Teilnahme an den Reviews von Fuse bzw. FaMeaktuelle Slots ... Team FaMe - Sprintwechsel-Woche Dienstag 9-10 Uhr ... Team Fuse 10.30 - 11.30 Uhr sind konfliktfrei  
Die DoD/DoR Kriterien beider Teams wurden von den BEs beider Teams verglichen und es wurde eine einheitliche Linie definiert. 
Spezialregeln ...Git-Repo / Umgang mit Merge-KonfliktenTests müssen grün durchlaufen
Jedes Team macht selbstständig Reviews
Vorhergehende Absprachen sollten die Konflikte insgesamt reduzieren
Deployment-RegelnFertige Storys direkt bis INT ausrollen (bei Freeze bis IEU)
Sync-Chat nutzen bei koordinierten Rollouts
Alignment mit Release-Prozess (Team BEAT)
Hot FixesTransparenz über aktuelle Situation in beiden Teams herstellen über entsprechende Posts
Finger weg von Main-Umgebung für alle Devs, die nicht am Fix arbeiten
Gemeinsames Arbeiten am Fix im "virtuellen Büro" - z.B. über den Teams-Chat
Umfassende Code-ÄnderungenVorherige Abstimmung mit dem anderen Team, um Effekte/Auswirkungen zu verdeutlichen und ggf. Maßnahmen ableiten
Deep-Dive nach Review bei Bedarf
Doku zeitnah, bis spätestens zur Featureabnahme, glattziehen
 link10#d0d0d0900coverflex-startcenter center Ownership 
Beide Teams dürfen alle Bereiche ändern; Verantwortungen sind klar definiert. Unsicherheiten werden in den Regelterminen abgestimmt. 
Repo-Struktur und DomänenschnitteModularer Zuschnitt (Ordner/Packages)
Monorepo-Policies (keine zirkulären Abhängigkeiten, interne APIs statt Querschnitten).
CI/CD und “Stop-the-line”Die Absprache zu Pipeline-Phasen und Ownership (wer pflegt welche Jobs?) erfolgt in den gemeinsamen Regelterminen.
“Always green main”: bei Rot sofort stoppen und fixen; Rotation “Build Sheriff” ist als Standard definiert. 
Artifact Management (Registry, Retention), Wiederholbarkeit (Deterministic Builds), wird durch die SIC OP Pipelines gelöst. 
Deployment-Policies: Wenn DoD erfolgt ist, weitere Prozessierung
ReleaseDeployments werden untereinander abgestimmt
OPS-ThemenVerantwortlichkeit für Security/Renovate-Themen und Findings rollierend pro PI. Beginnend mit PI 40 und Team Fuse.  Sollte Unterstützung notwendig sein, kann diese beim jeweils anderen Team angefragt werden. 
Naming ConventionsKeine "Naming-Conventions", Einzelfallentscheidungen, die in den Austauschrunden geklärt werden
Eskalationen/EntscheidungenLetztinstanzlich liegen Entscheidungen zum KDS beim PO von Team FaMe. Grundsätzliche können Entscheidungen auf Arbeitsebene getroffen werden. Kommt es zum Konflikt wird das Thema zwischen den POs der beiden Teams diskutiert.
@@ -0,0 +1,33 @@
# Team Juice
Version: 9 | Last modified: 2026-05-13T14:48:36.962+02:00
Source: confluence page ID 422183251
---
Name | Rolle |
  | Product Owner |
 
| Scrum Master |
 
| Business Analyst |
 
| Developer |
  | Developer |
 
| Developer |
 
| Developer |
 
| Tester (teamübergreifend) |
 
| Tester (teamübergreifend) |
 
| Tester (teamübergreifend) |
 
| Tester / FBF (teamübergreifend) |
LinksJIRA Board
ART Uj Veröffentlichung | Team Juice | Microsoft Teams
Teamkalender
7063c2bb-82c2-4282-a7be-b862e9f54fcc
@@ -0,0 +1,44 @@
# UjK Team Nexus
Version: 6 | Last modified: 2026-06-03T15:27:28.653+02:00
Source: confluence page ID 419719547
---
Weitere Details zum Team Nexus findet ihr auf unserer Planet Seite hier. 
TeammitgliederName |
| Rolle |
Torsten Helmert
|
| PO |
Ben Schneider |
| Developer |
Bastian Birnbach |
| Developer |
Jerome Möckel |
| Developer |
Marco M Zimmermann |
| Developer |
Maximilian Hauke |
| Developer |
Michael Mi Schmidt |
| Developer |
Pierre Kellmann |
| Developer |
Yvonne Kümmel |
| UX |
Yordan Palov |
| Tester |
Lilly Bunk |
| BE |
Jana Schneegaß |
| ScM |
Alena Rummler |
| BE |
Übersicht RegeltermineTermin | Zeitraum |
Daily | 11:00 - 11:30 |
|
|