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/O2C-Harness/requirements-review.md

@@ -0,0 +1,111 @@
+# Requirements-Review (vor Implementierung)
+
+## Ablauf bei Issue-basierter Aufgabe
+
+Wenn die Aufgabe als GitLab Issue übergeben wird (statt Freitext):
+
+### 1. Issue lesen und analysieren
+
+```bash
+glab issue view {issue-id} --repo {repo}
+```
+
+### 2. Anforderung kritisch reviewen
+
+Prüfe ob folgende Fragen beantwortet sind:
+
+**Fachlichkeit:**
+- Ist die Domäne/der Fachkontext verstanden?
+- Gibt es Fachbegriffe die unklar sind?
+- Welche Business-Regeln gelten?
+- Gibt es Abhängigkeiten zu anderen fachlichen Prozessen?
+
+**Funktional:**
+- Was genau soll das System tun?
+- Wer sind die Nutzer?
+- Welche Ein-/Ausgaben gibt es?
+- Welche Edge Cases gibt es?
+
+**Nicht-funktional:**
+- Performance-Anforderungen (Response-Zeit, Concurrent Users)?
+- Verfügbarkeit?
+- Security-Anforderungen?
+
+**Technisch:**
+- Stack/Framework vorgegeben?
+- Schnittstellen zu anderen Systemen?
+- Deployment-Ziel?
+
+**Akzeptanzkriterien:**
+- Sind Gherkin-Szenarien vorhanden?
+- Wann ist die Aufgabe "fertig"?
+
+### 3. Offene Fragen als Kommentar am Issue
+
+Wenn Informationen fehlen → Kommentar am Issue mit konkreten Fragen:
+
+```bash
+glab issue comment {issue-id} --repo {repo} --body "## Offene Fragen zur Anforderung
+
+Bevor ich mit der Implementierung beginne, bitte folgende Punkte klären:
+
+1. **Performance:** Wie viele gleichzeitige Nutzer werden erwartet? Gibt es Response-Zeit-Anforderungen?
+2. **Validierung:** Welche Felder sind Pflicht? Gibt es Format-Vorgaben (z.B. PLZ nur 5-stellig)?
+3. **Auth:** Soll die API authentifiziert sein oder öffentlich?
+
+Sobald geklärt, starte ich die Implementierung."
+```
+
+### 4. Warten oder selbst entscheiden
+
+- **Wenn Fragen kritisch sind** (Architektur-Entscheidung, unklarer Scope): Warten auf Antwort
+- **Wenn Fragen nice-to-have sind** (Details die man mit Best Practices lösen kann): Selbst entscheiden und dokumentieren
+
+### 5. Implementierung starten
+
+Erst wenn die Anforderung klar ist:
+- Alle kritischen Fragen beantwortet
+- Oder: Agent hat pragmatische Defaults gewählt und dokumentiert
+
+```bash
+echo "PROGRESS: 5% - Requirements-Review abgeschlossen, starte Implementierung"
+```
+
+## Bei Freitext-Aufgabe (kein Issue)
+
+Wenn die Aufgabe als Freitext kommt (über implement_ticket):
+- Selbst ein Issue anlegen mit der Aufgabe
+- Fehlende Infos mit Best Practices/Defaults füllen
+- Entscheidungen als ADR dokumentieren
+- Direkt implementieren (nicht warten)
+
+## Wann sind Anforderungen klar?
+
+- **Keine offenen Fragen** → Anforderungen klar → direkt implementieren
+- **Offene Fragen** → Kommentar am Issue → warten
+
+### Ablauf bei offenen Fragen
+
+```bash
+# 1. Fragen als Kommentar posten
+glab issue comment {id} --body "## Offene Fragen ..."
+
+# 2. Signal geben dass du wartest
+echo "HELP: Warte auf Antwort zu offenen Fragen am Issue #{id}"
+
+# 3. Warten bis Antwort kommt (via send_message vom User/Kiro)
+# → Agent bekommt Nachricht: "Fragen beantwortet, siehe Issue-Kommentar"
+
+# 4. Issue-Kommentare erneut lesen
+glab issue view {id} --comments
+
+# 5. Weiterarbeiten
+echo "PROGRESS: 5% - Requirements klar, starte Implementierung"
+```
+
+### Kiro als Vermittler
+
+Kiro sieht `needs_help: true` + `help_message: "Warte auf Antwort..."` und kann:
+- Den User informieren
+- Selbst die Fragen beantworten (wenn er den Kontext hat)
+- Oder `send_message` an den Agent schicken: "Fragen beantwortet, siehe Kommentar"