Initial monorepo structure

.kiro/specs/monorepo-consolidation/requirements.md

@@ -0,0 +1,193 @@
+# Requirements Document
+
+## Introduction
+
+Dieses Dokument beschreibt die Anforderungen für die Konsolidierung von 18+ einzelnen Repositories in eine einheitliche Monorepo-Struktur. Das Ziel ist es, alle Projekte in einem System zu vereinen, dabei klare Sicherheitsgrenzen zwischen Arbeitskontexten (Privat, dhive, Bahn) zu wahren, einen übergreifenden Wissensspeicher aufzubauen, externe Repos als Read-Only einzubinden, Secrets verschlüsselt im Repository zu speichern (statt sie auszuschließen), und eine föderierte Zusammenarbeit mit verschiedenen Teams über eigenständige Team-Repositories zu ermöglichen.
+
+## Glossary
+
+- **Monorepo**: Ein einzelnes Repository, das mehrere Projekte und Arbeitskontexte in einer gemeinsamen Ordnerstruktur vereint
+- **Arbeitskontext**: Eine logische Sicherheitsdomäne, die zusammengehörige Projekte gruppiert (Privat, dhive, Bahn)
+- **Wissensspeicher**: Ein übergreifendes System zur Erfassung, Strukturierung und kontextübergreifenden Abfrage von Wissen (Nachfolger des NoteGraph)
+- **Sicherheitsgrenze**: Eine Konfiguration, die den Zugriff auf Dateien und Geheimnisse eines Arbeitskontexts auf berechtigte Prozesse beschränkt
+- **Externes_Repo**: Ein Repository eines Dritten oder eines Team-Kontexts, das als unveränderbare Referenz oder bidirektionale Synchronisationsquelle in die Monorepo-Struktur eingebunden wird
+- **Kontextbrücke**: Ein Mechanismus, der es erlaubt, Erkenntnisse aus einem Arbeitskontext in einem anderen nutzbar zu machen, ohne Sicherheitsgrenzen zu verletzen
+- **Ordnerstruktur**: Die hierarchische Organisation von Projekten und Modulen innerhalb des Monorepos
+- **Agent_Harness**: Ein AI-Coding-Tool oder -System (z.B. Kiro, Codex, Claude Code, Antigravity), das als Ausführungsumgebung für AI-gestützte Entwicklungsaufgaben dient
+- **Agent_Erweiterung**: Ein Plugin, Skill, Power oder ähnliches Konfigurationsartefakt, das einem Agent_Harness zusätzliche Fähigkeiten verleiht (z.B. Kiro Powers, Claude Code Slash-Commands, Codex-Plugins)
+- **Orchestrator**: Der bestehende AI-Orchestrator-Service, der Tasks aus OrgMyLife verarbeitet und an verschiedene Agent_Harnesses dispatcht, wobei die Harness-Auswahl pro Arbeitskontext oder pro Task konfigurierbar ist
+- **Secret_Encryption**: Die Verschlüsselung von Geheimnissen im Repository mittels git-crypt, SOPS oder age, sodass Secrets verschlüsselt committed werden und nur mit autorisierten Schlüsseln entschlüsselt werden können
+- **Maschinenkontext**: Die einem bestimmten Rechner zugeordnete Kombination aus autorisierten Arbeitskontexten und den entsprechenden Entschlüsselungsschlüsseln (z.B. "dhive-Rechner" hat nur dhive-Schlüssel)
+- **Team_Repo**: Ein eigenständiges Repository, das einem bestimmten Team (dhive, bahn, privat/Familie) gehört und bidirektional mit dem entsprechenden Kontextordner im Monorepo synchronisiert wird
+- **Föderierte_Struktur**: Eine Hub-and-Spoke-Topologie, in der das Monorepo als zentraler Hub fungiert und die Team-Repos als unabhängige Spokes, wobei nur der Hub-Besitzer (Andre) Zugriff auf alle Kontexte hat
+
+## Requirements
+
+### Requirement 1: Einheitliche Ordnerstruktur
+
+**User Story:** Als Entwickler möchte ich alle meine Projekte in einer klar strukturierten Ordnerhierarchie organisiert haben, damit ich schnell navigieren und den Überblick behalten kann.
+
+#### Acceptance Criteria
+
+1. THE Monorepo SHALL alle Projekte in einer flachen Kontext-Hierarchie mit exakt drei Ebenen organisieren: Ebene 1 (Kontextordner) → Ebene 2 (Projektordner) → Ebene 3 (Modulordner), wobei unterhalb der Modulebene keine weitere strukturelle Verschachtelung von Projekten oder Modulen erlaubt ist
+2. WHEN ein neues Projekt angelegt wird, THE Ordnerstruktur SHALL das Projekt genau einem der definierten Kontextordner (privat, dhive, bahn, shared) zuordnen
+3. THE Monorepo SHALL eine einheitliche Namenskonvention in kebab-case für alle Ordner auf Projekt- und Modulebene verwenden, wobei Ordnernamen ausschließlich aus Kleinbuchstaben, Ziffern und Bindestrichen bestehen und zwischen 2 und 50 Zeichen lang sein dürfen
+4. THE Ordnerstruktur SHALL genau folgende vier Kontextordner auf oberster Ebene bereitstellen: privat, dhive, bahn, shared
+5. WHEN ein Projekt Funktionalität bereitstellt, die von Projekten in mindestens zwei unterschiedlichen Arbeitskontexten genutzt wird, THE Ordnerstruktur SHALL das Projekt im shared-Kontext platzieren
+6. IF ein Projektordner-Name bereits im Ziel-Kontext existiert, THEN THE Ordnerstruktur SHALL die Anlage verweigern und eine Fehlermeldung ausgeben, die den Namenskonflikt benennt
+
+### Requirement 2: Sicherheitsgrenzen zwischen Arbeitskontexten
+
+**User Story:** Als Entwickler möchte ich sicherstellen, dass Geheimnisse und sensible Daten eines Arbeitskontexts nicht versehentlich in einen anderen Kontext gelangen, damit die Trennung meiner beruflichen Realitäten gewahrt bleibt.
+
+#### Acceptance Criteria
+
+1. THE Sicherheitsgrenze SHALL verhindern, dass Secrets eines Arbeitskontexts für Prozesse eines anderen Arbeitskontexts über Dateisystemzugriff oder Umgebungsvariablen lesbar sind, wobei die Zugriffskontrolle auf dem Ausführungskontext des Prozesses und den verfügbaren Entschlüsselungsschlüsseln basiert
+2. THE Sicherheitsgrenze SHALL für jeden Arbeitskontext eine eigene .env-Datei im jeweiligen Kontextordner bereitstellen, die ausschließlich die Geheimnisse dieses Kontexts enthält und im Repository verschlüsselt gespeichert wird (siehe Requirement 9)
+3. WHEN ein Prozess in einem beliebigen Arbeitskontext ausgeführt wird, THE Sicherheitsgrenze SHALL den Zugriff auf entschlüsselte .env-Dateien und Secret-Dateien aller anderen Arbeitskontexte unterbinden
+4. THE Sicherheitsgrenze SHALL Secret-Dateien aller Kontexte über Verschlüsselung im Repository schützen (Encryption-at-Rest), wobei die bisherige .gitignore-basierte Ausschlussstrategie durch die kontextspezifische Verschlüsselung gemäß Requirement 9 ersetzt wird; unverschlüsselte temporäre Dateien (Build-Artefakte, Caches) werden weiterhin via .gitignore ausgeschlossen
+5. IF ein Prozess auf Secrets eines nicht-autorisierten Kontexts zugreift, THEN THE Sicherheitsgrenze SHALL einen Eintrag in eine Protokolldatei schreiben, der Zeitstempel, den anfragenden Kontext, den Zielkontext und die angefragte Ressource enthält
+6. THE Sicherheitsgrenze SHALL eine zentrale Konfigurationsdatei bereitstellen, die für jeden Arbeitskontext definiert, auf welche .env-Dateien, Secret-Dateien und shared-Ressourcen dieser Kontext zugreifen darf
+7. WHILE ein Tool aus dem shared-Bereich in einem bestimmten Arbeitskontext ausgeführt wird, THE Sicherheitsgrenze SHALL proaktiv korrekte Autorisierungszustände aufrechterhalten und dem Tool ausschließlich Zugriff auf die Secrets des aktiven Kontexts und auf explizit freigegebene shared-Ressourcen gewähren
+
+### Requirement 3: Übergreifender Wissensspeicher
+
+**User Story:** Als Wissensarbeiter möchte ich einen zentralen Wissensspeicher haben, der auf der bewährten ETL-Architektur der DB-Wissensdatenbank basiert und Informationen aus allen Kontexten aufnimmt, damit ich relevantes Wissen jederzeit kontextübergreifend abrufen kann.
+
+#### Acceptance Criteria
+
+1. THE Wissensspeicher SHALL als Fork/Adaption der DB-Wissensdatenbank-ETL-Pipeline im shared-Bereich des Monorepos implementiert werden
+2. THE Wissensspeicher SHALL Wissensartefakte aus allen Arbeitskontexten aufnehmen und indexieren
+3. WHEN eine Suchanfrage gestellt wird, THE Wissensspeicher SHALL Ergebnisse aus allen Kontexten liefern, für die der Nutzer berechtigt ist, und die Ergebnisliste innerhalb von 5 Sekunden zurückgeben
+4. THE Wissensspeicher SHALL Wissensartefakte mit Metadaten versehen: Quellkontext, Erstelldatum, Tags und verknüpfte Projekte
+5. THE Wissensspeicher SHALL bestehende NoteGraph-Daten migrieren können, wobei die Migration als erfolgreich gilt, wenn alle Artefakte mit ihren Metadaten, Verknüpfungen und der Verzeichnisstruktur (decisions, inbox, meetings, people, projects) im Zielsystem vorhanden und über den Index auffindbar sind
+6. WHEN ein neues Wissensartefakt erstellt wird, THE Wissensspeicher SHALL automatisch den Quellkontext und das Erstelldatum erfassen
+7. THE Wissensspeicher SHALL eine Volltextsuche über alle indexierten Artefakte bereitstellen, die Treffer nach Relevanz sortiert zurückliefert
+8. THE Wissensspeicher SHALL Verknüpfungen zwischen Artefakten unterschiedlicher Kontexte als gerichtete Graph-Kanten im YAML-Frontmatter beider beteiligter Artefakte unterstützen
+9. WHILE ein Wissensartefakt einem vertraulichen Kontext zugeordnet ist, THE Wissensspeicher SHALL den Inhalt nur für berechtigte Abfragen bereitstellen und bei unberechtigtem Zugriff das Artefakt aus den Suchergebnissen ausschließen, ohne dessen Existenz offenzulegen
+10. THE Wissensspeicher SHALL die ETL-Quellstrategien der DB-Wissensdatenbank wiederverwenden (Confluence-Seiten, Webseiten, PDFs, Markdown-Dateien, GitLab-Repos)
+11. THE Wissensspeicher SHALL verarbeitetes Wissen in einer Scope-basierten Ordnerstruktur ablegen, wobei jeder Arbeitskontext einem Scope entspricht (privat, dhive, bahn, shared)
+12. WHEN eine Quelle inkrementell verarbeitet wird, THE Wissensspeicher SHALL nur geänderte oder neue Inhalte aktualisieren, wobei Änderungen anhand von Content-Hashes erkannt werden
+13. THE Wissensspeicher SHALL einen maschinenlesbaren Index bereitstellen, der den gesamten Wissensbestand beschreibt (Dokumente, Metadaten, Content-Hashes)
+14. THE Wissensspeicher SHALL die Scope-Konfiguration um die persönlichen Arbeitskontexte erweitern, wobei das Mapping Arbeitskontext → Scope in einer zentralen Konfigurationsdatei definiert wird
+15. WHERE die DB-Wissensdatenbank als aktives Bahn-Projekt eingebunden ist, THE Wissensspeicher SHALL Upstream-Änderungen der ETL-Pipeline übernehmen können, auch wenn der Wissensspeicher noch nicht vollständig implementiert ist
+16. THE Wissensspeicher SHALL ein Progressive-Disclosure-Indexsystem bereitstellen, das Agenten ermöglicht auf Schicht 1 nur eine kompakte YAML-Index-Datei pro Domäne zu lesen (Titel, Tags, Beziehungen, Kurzbeschreibungen), ohne vollständige Markdown-Dateien laden zu müssen
+17. THE Wissensspeicher SHALL jedes Wissensartefakt mit YAML-Frontmatter versehen, das mindestens Typ, Titel, Tags, Quellkontext und Verknüpfungen zu anderen Artefakten enthält
+18. WHEN ein Agent eine Suchanfrage stellt, THE Wissensspeicher SHALL über den YAML-Index die relevanten Dokumente identifizieren und nur deren Pfade zurückliefern, sodass der Agent gezielt einzelne Dateien nachladen kann
+19. THE Wissensspeicher SHALL sich am Google Open Knowledge Format (OKF) orientieren: ein Konzept pro Datei, Markdown mit YAML-Frontmatter, Cross-Links als Graph-Kanten, index.md pro Verzeichnis für Inhaltsübersichten
+20. IF die ETL-Pipeline bei der Verarbeitung einer Quelle fehlschlägt, THEN THE Wissensspeicher SHALL den Fehler mit Quellidentifikator und Zeitstempel protokollieren, bereits erfolgreich verarbeitete Artefakte beibehalten und die fehlgeschlagene Quelle beim nächsten Durchlauf erneut verarbeiten
+21. WHEN die ETL-Pipeline einen Verarbeitungsdurchlauf abschließt, THE Wissensspeicher SHALL den YAML-Index innerhalb desselben Durchlaufs aktualisieren, sodass neu verarbeitete Artefakte sofort über den Index auffindbar sind
+
+### Requirement 4: Einbindung externer und geteilter Repos
+
+**User Story:** Als Entwickler möchte ich externe Repositories als unveränderbare Referenz, geteilte Repos mit Upstream-Anbindung und Team-Repos mit bidirektionaler Synchronisation in mein Monorepo einbinden, damit ich deren Inhalte nutzen, bei Bedarf Änderungen zurückspielen und mit verschiedenen Teams in ihrem jeweiligen Kontext zusammenarbeiten kann.
+
+#### Acceptance Criteria
+
+1. THE Monorepo SHALL externe Repositories als Read-Only-Referenz einbinden können
+2. WHEN ein externes Repo eingebunden wird, THE Monorepo SHALL dessen Inhalte als unveränderbar behandeln, indem lokale Commits und Dateiänderungen im eingebundenen Verzeichnis durch Git-Hooks oder Dateisystem-Schutzmechanismen verhindert werden
+3. THE Monorepo SHALL eine Konfigurationsdatei bereitstellen, die alle eingebundenen externen Repos mit Repository-URL, gepinnter Version (Git-Commit-SHA oder Tag), Einbindungsmodus (read-only oder upstream) und Zielpfad im Monorepo auflistet
+4. WHEN der Nutzer eine Aktualisierung eines externen Repos auslöst, THE Monorepo SHALL die lokale Kopie auf die in der Konfigurationsdatei angegebene Version aktualisieren und stets eine Ergebnismeldung anzeigen (Erfolg, Misserfolg oder 'Aktualisierung abgeschlossen – Status unbekannt')
+5. IF ein Schreibzugriff auf ein als read-only konfiguriertes Repo versucht wird (Datei anlegen, ändern oder löschen im eingebundenen Verzeichnis), THEN THE Monorepo SHALL den Zugriff blockieren und eine Fehlermeldung ausgeben, die den Read-Only-Status und den Namen des betroffenen Repos benennt
+6. THE Monorepo SHALL Git-Submodules oder Git-Subtrees für die Einbindung externer Repos verwenden
+7. WHERE ein Repo als aktives Upstream-Projekt eingebunden ist, THE Monorepo SHALL bidirektionale Synchronisation mit dem entfernten Repository ermöglichen (Pull von Upstream, Push von lokalen Änderungen), wobei bei Merge-Konflikten die Synchronisation abgebrochen, der Konflikt protokolliert und eine manuelle Auflösung ermöglicht wird; für Read-Only-Repos SHALL das Monorepo Konflikte erkennen und protokollieren, ohne die Synchronisation abzubrechen (da keine tatsächliche Synchronisation stattfindet)
+8. THE Monorepo SHALL die DB-Wissensdatenbank als aktives Bahn-Projekt mit Upstream-Anbindung zum DB-GitLab einbinden können
+9. IF eine Synchronisation mit einem Upstream-Repository fehlschlägt (Netzwerkfehler, Authentifizierungsfehler oder Merge-Konflikt), THEN THE Monorepo SHALL den lokalen Stand unverändert beibehalten, den Fehlergrund protokollieren und den Nutzer über den fehlgeschlagenen Vorgang informieren
+
+### Requirement 5: Kontextübergreifender Wissenstransfer
+
+**User Story:** Als Entwickler möchte ich, dass meine verschiedenen Arbeitskontexte voneinander profitieren können, ohne Sicherheitsgrenzen zu verletzen, damit Erkenntnisse und Patterns wiederverwendbar werden.
+
+#### Acceptance Criteria
+
+1. THE Kontextbrücke SHALL es ermöglichen, Wissensartefakte eines Kontexts in anderen Kontexten als Lesereferenz bereitzustellen, wobei beliebige Artefakte teilbar sind, die Kontextbrücke jedoch Artefakte mit sensiblen Inhalten (kontextspezifische Credentials, Endpoints, personenbezogene Daten) vor der Freigabe filtert und blockiert
+2. WHEN ein Wissensartefakt als "teilbar" markiert wird, THE Kontextbrücke SHALL es in allen Kontexten als schreibgeschützte Lesereferenz bereitstellen
+3. IF ein als "teilbar" markiertes Artefakt kontextspezifische Geheimnisse, Zugangsdaten oder personenbezogene Daten enthält, THEN THE Kontextbrücke SHALL die Freigabe verweigern und eine Fehlermeldung ausgeben, die den Grund der Ablehnung benennt
+4. THE Kontextbrücke SHALL eine explizite Freigabe durch den Nutzer erfordern, bevor Information kontextübergreifend geteilt wird
+5. WHILE ein geteiltes Artefakt im Quellkontext aktualisiert wird, THE Kontextbrücke SHALL die Änderungen beim nächsten Lesezugriff in allen verknüpften Kontexten sichtbar machen
+6. WHEN ein Nutzer die Freigabe eines geteilten Artefakts widerruft, THE Kontextbrücke SHALL das Artefakt aus allen Zielkontexten als Lesereferenz entfernen
+
+### Requirement 6: Migration bestehender Repositories
+
+**User Story:** Als Entwickler möchte ich meine bestehenden 18+ Repositories in die neue Monorepo-Struktur überführen können, ohne Git-Historie oder bestehende Funktionalität zu verlieren.
+
+#### Acceptance Criteria
+
+1. THE Monorepo SHALL die vollständige Git-Historie aller migrierten Repositories bewahren, einschließlich aller Commits, aller Branches, aller Tags und der zugehörigen Autoreninformationen
+2. WHEN ein Repository migriert wird, THE Monorepo SHALL sicherstellen, dass alle existierenden CI/CD-Konfigurationen entweder unverändert lauffähig bleiben oder mit einer dokumentierten Anpassungsanleitung (Grund der Änderung, neue Konfiguration, Testnachweis) versehen werden
+3. THE Monorepo SHALL einen dokumentierten Migrationsplan bereitstellen, der für jedes der 18+ Repositories den Ziel-Kontextordner, die Migrationsreihenfolge, die Abhängigkeiten zu anderen Repositories und den erwarteten Einbindungsmodus (direkt, Submodule, Upstream) beschreibt
+4. WHEN die Migration eines einzelnen Repositories abgeschlossen ist, THE Monorepo SHALL eine Validierung durchführen, die mindestens folgende Prüfungen umfasst: Übereinstimmung der Commit-Anzahl, Vorhandensein aller Branches und Tags, Vollständigkeit des Dateibaums im letzten Commit und erfolgreicher Durchlauf vorhandener Tests, wobei die Validierung für alle abgeschlossenen Migrationen durchgeführt wird (unabhängig davon ob sie erfolgreich waren oder fehlschlugen) und die Migration auch bei Nicht-Ausführbarkeit des Validierungsschritts als erfolgreich gilt, sofern alle zugrundeliegenden Prüfungen bestanden wurden
+5. IF während der Migration ein Konflikt auftritt (Pfadkollision, Branch-Namenskonflikt oder Namenskonvention-Verletzung), THEN THE Monorepo SHALL den Konflikt mit betroffener Datei, Konflikttyp und beteiligten Quell-Repositories protokollieren und die Migration des betroffenen Repositories pausieren, bis eine manuelle Auflösung erfolgt ist
+6. THE Monorepo SHALL die Migration inkrementell unterstützen, sodass Repositories einzeln und unabhängig voneinander überführt werden können, während bereits migrierte und noch nicht migrierte Repositories parallel funktionsfähig bleiben
+7. IF die Migration eines einzelnen Repositories fehlschlägt, THEN THE Monorepo SHALL den Zustand vor der Migration dieses Repositories wiederherstellen können, ohne bereits erfolgreich migrierte Repositories zu beeinflussen
+
+### Requirement 7: Orchestrator-Integration und Multi-Harness-Dispatch
+
+**User Story:** Als Entwickler möchte ich, dass der bestehende AI-Orchestrator nahtlos mit der neuen Monorepo-Struktur zusammenarbeitet und Tasks an verschiedene Agent_Harnesses (Kiro, Codex, Claude Code, Antigravity u.a.) dispatchen kann, damit ich pro Kontext oder Task den optimalen Agenten einsetzen kann.
+
+#### Acceptance Criteria
+
+1. WHEN der Orchestrator einen Task bearbeitet, THE Orchestrator SHALL den zugehörigen Arbeitskontext anhand der Task-Metadaten (Labels oder Projektzuordnung) ermitteln und das Arbeitsverzeichnis des Agent_Harness auf den entsprechenden Kontextordner innerhalb der Monorepo-Struktur beschränken
+2. THE Orchestrator SHALL seinen Workspace-Root-Pfad in der WORKFLOW.md-Konfiguration so auflösen, dass pro Task ein Arbeitsverzeichnis unterhalb des ermittelten Kontextordners (privat, dhive, bahn oder shared) angelegt wird
+3. WHEN der Orchestrator in einem Kontext arbeitet, THE Orchestrator SHALL ausschließlich die .env-Datei des jeweiligen Kontextordners laden und Umgebungsvariablen anderer Kontexte weder lesen noch an den Agent_Harness-Prozess weitergeben
+4. WHEN der Orchestrator einen Task-Prompt zusammenstellt, THE Orchestrator SHALL den YAML-Index des Wissensspeichers abfragen und relevante Artefakt-Pfade als Kontextinformation in den Agenten-Prompt einfügen
+5. IF der Orchestrator einen Dateizugriff oder Secret-Zugriff außerhalb des zugewiesenen Kontextordners versucht, THEN THE Orchestrator SHALL den laufenden Task abbrechen, den Vorfall mit Task-Identifier und Zugriffspfad protokollieren und den Nutzer über den bestehenden OrgMyLife-Benachrichtigungskanal informieren
+6. WHEN kein Arbeitskontext aus den Task-Metadaten ermittelt werden kann, THE Orchestrator SHALL den Task nicht starten und eine Fehlermeldung mit dem fehlenden Kontext-Mapping an den Nutzer senden
+7. THE Orchestrator SHALL eine Konfiguration bereitstellen, die pro Arbeitskontext und optional pro Task-Typ den zu verwendenden Agent_Harness definiert (z.B. dhive → Codex, bahn → Kiro, privat → Claude Code)
+8. THE Orchestrator SHALL eine einheitliche Schnittstelle für alle Agent_Harnesses bereitstellen, die mindestens Prompt-Injection, Workspace-Verzeichnis, Umgebungsvariablen-Übergabe und Agent_Erweiterungen-Konfiguration umfasst
+9. WHEN ein Task einem Agent_Harness zugewiesen wird, THE Orchestrator SHALL die harness-spezifische Startsequenz ausführen (CLI-Aufruf, API-Call oder Prozessstart), wobei die Startsequenz pro Harness in der Konfiguration definiert ist
+10. IF der konfigurierte Agent_Harness für einen Task nicht verfügbar ist (nicht installiert, nicht lizenziert, Netzwerkfehler), THEN THE Orchestrator SHALL den Task als nicht-ausführbar markieren, den Fehlergrund protokollieren und den Nutzer benachrichtigen
+
+### Requirement 8: Shared Tooling und Agent-Erweiterungen
+
+**User Story:** Als Entwickler möchte ich übergreifende Tools, Agent-Erweiterungen (Powers, Skills, Plugins) und Steering-Konfigurationen an einer zentralen Stelle verwalten, damit sie allen Kontexten und allen eingesetzten Agent_Harnesses zur Verfügung stehen und nicht dupliziert werden müssen.
+
+#### Acceptance Criteria
+
+1. THE Ordnerstruktur SHALL einen dedizierten shared-Bereich für kontextübergreifende Tools, Agent-Erweiterungen und Konfigurationen bereitstellen
+2. WHEN ein Tool im shared-Bereich aktualisiert wird, THE Monorepo SHALL sicherstellen, dass alle Kontexte bei ihrer nächsten Ausführung die aktualisierte Version des Tools verwenden, ohne manuelle Synchronisation in den einzelnen Kontexten
+3. THE Monorepo SHALL Agent-Erweiterungen (Steering-Dateien, Prompt-Vorlagen, Kontext-Definitionen, Skills) zentral im shared-Bereich ablegen und harness-agnostisch organisieren, sodass sie von verschiedenen Agent_Harnesses (Kiro, Codex, Claude Code, Antigravity u.a.) genutzt werden können
+4. THE Monorepo SHALL MCP-Server-Konfigurationen zentral im shared-Bereich bereitstellen, wobei kontextspezifische Konfigurationen die zentrale Konfiguration überschreiben (Kontext-Konfiguration hat Vorrang vor shared-Konfiguration)
+5. WHILE ein geteiltes Tool in einem bestimmten Kontext ausgeführt wird, THE Sicherheitsgrenze SHALL sicherstellen, dass das Tool nur auf die Dateien und Secrets des aktiven Kontexts sowie auf den shared-Bereich zugreift; IF die Sicherheitsgrenzen nicht durchgesetzt werden können, THEN SHALL die Ausführung des geteilten Tools verhindert werden
+6. IF ein geteiltes Tool oder eine zentrale Konfiguration einen Konflikt mit einer kontextspezifischen Überschreibung erzeugt, THEN THE Monorepo SHALL den Konflikt protokollieren und die kontextspezifische Konfiguration beibehalten
+7. THE Monorepo SHALL eine Konfigurationsdatei bereitstellen, die pro Arbeitskontext den eingesetzten Agent_Harness und dessen harness-spezifische Konfiguration definiert (z.B. Kiro-Powers-Pfad, Codex-Agenten-Config, Claude-Code-Projektdatei)
+8. THE Monorepo SHALL Agent-Erweiterungen in einem harness-unabhängigen Format ablegen (Markdown-Steering-Dateien, YAML-Konfigurationen, Prompt-Templates), die bei Bedarf in harness-spezifische Formate transformiert werden können
+9. WHEN ein neuer Agent_Harness konfiguriert wird, THE Monorepo SHALL einen Adapter-Mechanismus bereitstellen, der die zentral abgelegten Agent-Erweiterungen für den neuen Harness verfügbar macht, ohne die bestehenden Erweiterungen zu duplizieren
+
+
+### Requirement 9: Verschlüsselte Secrets im Repository
+
+**User Story:** Als Entwickler möchte ich Secrets verschlüsselt im Repository speichern (statt sie via .gitignore auszuschließen), damit das Repo vollständig selbstbeschreibend und portabel über mehrere Maschinen hinweg ist, ohne dass Secrets manuell transportiert oder separat gesichert werden müssen.
+
+#### Acceptance Criteria
+
+1. THE Secret_Encryption SHALL alle Secret-Dateien (.env-Dateien, private Schlüssel, Token-Dateien) verschlüsselt im Repository speichern, sodass sie committet und gepusht werden können, ohne im Klartext im Git-Verlauf oder Working Tree sichtbar zu sein
+2. THE Secret_Encryption SHALL ein bewährtes Verschlüsselungstool (git-crypt, SOPS oder age) für die Encryption-at-Rest verwenden
+3. THE Secret_Encryption SHALL für jeden Arbeitskontext (privat, dhive, bahn) einen eigenen Verschlüsselungsschlüssel verwenden, sodass der Besitz eines Schlüssels nur den zugehörigen Kontext entschlüsseln kann
+4. WHEN eine Maschine einem bestimmten Maschinenkontext zugeordnet ist, THE Secret_Encryption SHALL ausschließlich die Secrets der autorisierten Arbeitskontexte dieser Maschine entschlüsseln
+5. THE Secret_Encryption SHALL eine Konfigurationsdatei bereitstellen, die das Mapping von Maschinenkontext zu autorisierten Arbeitskontexten und Schlüsseln definiert (z.B. "dhive-Laptop" → nur dhive-Schlüssel, "Andre-Hauptrechner" → alle Schlüssel)
+6. WHEN ein neuer Rechner eingerichtet wird, THE Secret_Encryption SHALL einen dokumentierten Onboarding-Prozess bereitstellen, der die Installation der Entschlüsselungsschlüssel für die autorisierten Kontexte beschreibt
+7. THE Secret_Encryption SHALL mit einem Passwort-Manager integrierbar sein, sodass Entschlüsselungsschlüssel sicher gespeichert und bei Bedarf abgerufen werden können
+8. IF ein Entschlüsselungsversuch mangels autorisiertem Schlüssel fehlschlägt, THEN THE Secret_Encryption SHALL den Zugriff verweigern und die betroffenen Dateien im verschlüsselten Zustand belassen, ohne eine Fehlermeldung auszugeben, die den Inhalt der Datei offenlegt
+9. THE Secret_Encryption SHALL die bisherige .gitignore-basierte Ausschlussstrategie für Secret-Dateien ablösen, wobei .gitignore weiterhin für Build-Artefakte, Caches und temporäre Dateien verwendet wird
+10. WHEN ein Nutzer auf einer nicht-autorisierten Maschine das Repository klont, THE Secret_Encryption SHALL alle nicht-autorisierten Secret-Dateien als verschlüsselte Binärdaten im Working Tree belassen, sodass das Repository funktionsfähig bleibt (Code, Konfiguration, Dokumentation sind verfügbar), aber Secrets unzugänglich sind
+11. THE Secret_Encryption SHALL sicherstellen, dass verschlüsselte Dateien problemlos gemergt werden können, indem der Merge auf der verschlüsselten Ebene stattfindet oder ein git-crypt-kompatibler Merge-Treiber verwendet wird
+
+### Requirement 10: Föderierte Repo-Struktur und Multi-Team-Zusammenarbeit
+
+**User Story:** Als Entwickler möchte ich mit verschiedenen Teams (dhive-Kollegen, Bahn-Kollegen, Familie) zusammenarbeiten, wobei jedes Team ein eigenständiges Repository für seinen Kontext hat und nur ich als Hub-Besitzer das kombinierte Monorepo sehe, damit Sicherheitsgrenzen automatisch durchgesetzt werden und Teams unabhängig arbeiten können.
+
+#### Acceptance Criteria
+
+1. THE Föderierte_Struktur SHALL für jeden Arbeitskontext (privat, dhive, bahn) ein eigenständiges Team_Repo unterstützen, das unabhängig vom Monorepo als vollständiges Git-Repository funktioniert
+2. THE Föderierte_Struktur SHALL eine Hub-and-Spoke-Topologie implementieren, in der das Monorepo als zentraler Hub fungiert und jedes Team_Repo als unabhängiger Spoke
+3. WHEN Änderungen in einem Team_Repo vorgenommen werden, THE Föderierte_Struktur SHALL diese Änderungen bidirektional mit dem entsprechenden Kontextordner im Monorepo synchronisieren können
+4. WHEN Änderungen im Monorepo in einem Kontextordner vorgenommen werden, THE Föderierte_Struktur SHALL diese Änderungen zum zugehörigen Team_Repo synchronisieren können
+5. THE Föderierte_Struktur SHALL sicherstellen, dass Team-Mitglieder eines Kontexts ausschließlich Zugriff auf das Team_Repo ihres eigenen Kontexts haben und weder den Inhalt noch die Existenz anderer Kontexte im Monorepo erkennen können
+6. THE Föderierte_Struktur SHALL das Team_Repo als Single Source of Truth für den jeweiligen Kontext behandeln, wobei bei Konflikten zwischen Team_Repo und Monorepo das Team_Repo Vorrang hat
+7. IF eine bidirektionale Synchronisation zwischen Monorepo und Team_Repo einen Merge-Konflikt erzeugt, THEN THE Föderierte_Struktur SHALL die Synchronisation abbrechen, den Konflikt mit betroffenen Dateien und Quellen protokollieren und dem Hub-Besitzer (Andre) eine manuelle Auflösung ermöglichen
+8. THE Föderierte_Struktur SHALL die Synchronisation über Git-Subtrees oder einen vergleichbaren Mechanismus realisieren, der die vollständige Git-Historie des Team_Repos im Monorepo bewahrt
+9. WHEN ein neues Team-Mitglied Zugang benötigt, THE Föderierte_Struktur SHALL ausschließlich Zugriff auf das entsprechende Team_Repo erteilen, ohne Kenntnis des Monorepos oder der Existenz anderer Kontexte preiszugeben
+10. THE Föderierte_Struktur SHALL die verschlüsselten Secrets gemäß Requirement 9 so handhaben, dass in den Team_Repos nur die Secrets des jeweiligen Kontexts enthalten sind (unverschlüsselt oder mit dem Team-Schlüssel verschlüsselt), während das Monorepo alle Kontexte mit kontextspezifischen Schlüsseln enthält
+11. THE Föderierte_Struktur SHALL eine Konfigurationsdatei bereitstellen, die für jeden Arbeitskontext das zugehörige Team_Repo (URL, Branch, Sync-Richtung, Sync-Frequenz) definiert
+12. WHILE die Synchronisation zwischen Monorepo und Team_Repo aktiv ist, THE Föderierte_Struktur SHALL sicherstellen, dass Dateien aus dem shared-Bereich, die für den jeweiligen Kontext relevant sind, optional als Read-Only-Kopie in das Team_Repo gespiegelt werden können