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-APN/teams/Story-Template-Team-OnePiece.md

@@ -0,0 +1,83 @@
+# Story Template - Team OnePiece
+
+Version: 3 | Last modified: 2025-09-05T10:38:01.964+02:00
+Source: confluence page ID 485040169
+
+---
+
+TitelAPN (Komponente): Titel 
+Titel: Was gemacht wird -> ähnlich zu Git-Commits (Imperativ)
+
+AkzeptanzkriterienDie Akzeptanzkriterien sollen einen bestimmten Zustand oder ein bestimmtes Verhalten der Komponente beschrieben. Im idealen Fall ist jedes einzelne AK unabhängig voneinander testbar und erfüllbar.
+Akzeptanzkriterien sollten möglichst in Gherkin-Schreibweise als testbares Szenario beschrieben sein. Die Formulierung sollte immer im positiv geschrieben sein, selbst bei einem Szenario mit negativem Ausgang. Das hat gleich mehrere Vorteile:
+Bessere Verständlichkeit
+Positive Aussagen sind für Fachbereiche und Nicht-Entwickler leichter zu lesen.
+
+Beispiel:
+Negativ: Then the user is not logged in
+
+Positiv: Then the user stays on the login page
+→ Die zweite Variante beschreibt klarer, was tatsächlich passiert.
+
+Eindeutigkeit
+Negative Formulierungen führen oft zu Interpretationsspielraum („nicht eingeloggt“ – heißt das: Fehlermeldung? Zurück zur Loginseite? Einfach nichts passiert?).
+
+Positive Formulierungen beschreiben ein beobachtbares Ergebnis.
+
+Bessere Testautomatisierung
+Tests lassen sich einfacher prüfen, wenn ein klarer Zustand überprüft wird.
+
+Positiv: Then I see an error message "Invalid credentials"
+
+Negativ: Then I do not see the dashboard
+→ Beim negativen Test könnte der Test "bestehen", auch wenn etwas völlig anderes angezeigt wird (z. B. eine leere Seite).
+
+Weniger kognitive Belastung
+Menschen müssen bei Negationen öfter gedanklich „um die Ecke denken“.
+
+Positiv formulierte Szenarien sind intuitiver nachzuvollziehen.
+
+Eine Schablone dafür wäre:
+Scenario: Komponente XYZ macht etwas
+Given ein bestimmter Input 
+Given eine mögliche Bedingung
+When eine bestimmte Aktion oder Situation geschieht
+Then wird ein bestimmtes Verhalten beobachtet
+Then ist eine bestimmtes Ergebnis eingetreten
+
+Es sollte immer mindestens ein Positiv- und ein Negativ-Beispiel vorhanden sein.
+
+DetailbeschreibungZu klärende Fragen:
+Was soll in der Story geschehen?
+Welche Vorbedingung soll erfüllt sein?
+Was ist der Nutzen, den diese Story kreiert?
+
+Fachliche BeschreibungFachliche Einordung der Anforderung in den Business Kontext
+Gerne auch eine grafische Übersicht mit Figma:
+
+Technische InformationenFür die Umsetzung hilfreiche Informationen, Links etc.
+SST-Beschreibung
+
+Beispiel-Datenset
+AusblickGibt es Auswirkungen auf andere Komponenten?
+
+Out-of-ScopeWas soll nicht getan werden?
+
+NFAVerfügbarkeit?
+Umgang mit Daten?
+Monitoring?
+Skalierbarkeit?
+ReminderDefinition of Ready:Vor Refinement von PO/BA's zu klären:* Die USER-Story ist ins Gesamtprojekt eingeordnet ("Als ... möchte ich, dass..., WEIL..."). Motivation wird erklärt und These über Nutzen der Story aufgestellt.
+* Akzeptanzkriterien sind formuliert (wünschenswert: konkretes BDD given/when/then, Example-Mapping)
+* Zusammenstellung verfügbarer fachlicher Dokumentation (verlinkt oder direkt in der Story)
+* Verfügbarkeit der Testdaten ist geklärt
+* Abhängigkeiten zu anderen Teams im Projekt oder extern sind geklärt
+* Story kann nicht fachlich sinnvoll kleiner geschnitten werden
+
+Vor Schätzung einer Story von den Entwicklern zu klären* Identifikation der betroffenen (Software)-Komponenten (intern und extern)
+* Aktueller Zustand der betroffenen Software-Komponenten
+* Testbarkeit ist abgeklärt
+* Notwendige Zugangsdaten/Tools sind bekannt
+* Abhängigkeiten zu anderen Stories oder Teams
+* Verfügbare technische Dokumentation ist bekannt
+* Story kann nicht technisch sinnvoll kleiner geschnitten werden