# Implementation Plan: Monorepo-Consolidation

## Overview

Inkrementelle Implementierung der Monorepo-Konsolidierung in Python. Die Umsetzung folgt einem Bottom-Up-Ansatz: Zunächst werden die Basis-Komponenten (Ordnerstruktur, Sicherheit, Verschlüsselung) erstellt, darauf aufbauend der Wissensspeicher und die Repo-Verwaltung, dann die Integrationsschicht (Orchestrator-Adapter, Kontextbrücke, Migration), und schließlich die Föderationsschicht (Team-Repos, Synchronisation).

## Tasks

- [x] 1. Projektstruktur und Basiskonfiguration
  - [x] 1.1 Monorepo-Grundstruktur und zentrale Konfigurationsdateien erstellen
    - Erstelle die Ordnerstruktur: `privat/`, `dhive/`, `bahn/`, `shared/` mit Unterordnern `shared/tools/`, `shared/powers/`, `shared/knowledge-store/`, `shared/config/`, `shared/mcp-servers/`
    - Erstelle `monorepo.yaml` mit Kontext-Definitionen, Naming-Regeln, Security- und Encryption-Konfiguration
    - Erstelle `shared/config/access-config.yaml` mit Zugriffskonfiguration pro Kontext
    - Erstelle `shared/config/repos.yaml` als leere Repo-Registry
    - Erstelle `shared/config/scopes.yaml` mit Scope-Mapping für den Wissensspeicher
    - Erstelle `shared/config/machine-context.yaml` mit Maschinenkontext-Mapping
    - Erstelle `shared/config/team-repos.yaml` mit Föderations-Konfiguration
    - Erstelle `.gitignore` mit Patterns für Build-Artefakte, Caches, temporäre Dateien (NICHT für Secrets)
    - Erstelle `.gitattributes` mit Root-Level git-crypt-Regeln
    - _Requirements: 1.1, 1.4, 2.2, 2.4, 2.6, 8.1, 9.5, 9.9, 10.11_


  - [x] 1.2 Python-Paketstruktur und gemeinsame Datenmodelle anlegen
    - Erstelle `shared/tools/monorepo-cli/` mit `pyproject.toml` und `src/monorepo/` Package
    - Definiere Dataclasses: `ProjectInfo`, `RepoEntry`, `MigrationPlan`, `SecurityEvent`, `ScopeConfig`, `MachineContext`, `EncryptionKey`, `PasswordManagerConfig`, `TeamRepoEntry`, `SharedMirrorConfig`, `SyncResult`, `ConflictInfo`, `IsolationReport`, `IsolationLeak`
    - Definiere Enums: `Context`, `RepoMode`, `ArtifactType`, `KeySource`, `SyncDirection`, `SyncFrequency`, `ConflictStrategy`
    - Erstelle `src/monorepo/__init__.py`, `src/monorepo/models.py`, `src/monorepo/config.py`
    - _Requirements: 1.1, 4.3, 9.5, 10.11_

- [ ] 2. Ordnerstruktur-Manager (StructureManager)
  - [x] 2.1 StructureManager-Klasse implementieren
    - Implementiere `StructureManager` in `src/monorepo/structure.py`
    - Methode `validate_name(name: str) -> bool`: Prüfung auf kebab-case, 2-50 Zeichen, Regex `^[a-z0-9][a-z0-9\-]{0,48}[a-z0-9]$`
    - Methode `create_project(context: str, name: str) -> Path`: Erstellt Projektordner, prüft Namenskonflikt, gibt Fehlermeldung bei Duplikat
    - Methode `list_projects(context: str | None) -> list[ProjectInfo]`: Auflistung aller Projekte
    - Methode `resolve_context(project_path: Path) -> str`: Kontexterkennung anhand Pfad
    - _Requirements: 1.1, 1.2, 1.3, 1.5, 1.6_

  - [-] 2.2 Property-Test: Namensvalidierung (Property 1)
    - **Property 1: Namensvalidierung akzeptiert nur gültiges kebab-case**
    - **Validates: Requirements 1.3**

  - [-] 2.3 Property-Test: Namenskollision (Property 2)
    - **Property 2: Namenskollision verhindert doppelte Projekterstellung**
    - **Validates: Requirements 1.6**

  - [-] 2.4 Unit-Tests für StructureManager
    - Teste Erstellung in allen vier Kontexten
    - Teste Fehlermeldung bei existierendem Projektnamen
    - Teste Edge Cases: Minimum-/Maximum-Länge, Sonderzeichen, Unicode
    - _Requirements: 1.1, 1.2, 1.3, 1.6_

- [ ] 3. Sicherheits-Guard (ContextGuard)
  - [x] 3.1 ContextGuard-Klasse mit Zugriffskontrolle implementieren
    - Implementiere `ContextGuard` in `src/monorepo/security.py`
    - Methode `check_access(requesting_context: str, target_path: Path) -> bool`: Prüft Zugriffsberechtigung basierend auf access-config.yaml
    - Methode `load_env(context: str) -> dict[str, str]`: Lädt nur die .env des eigenen Kontexts (entschlüsselt via SecretEncryptionManager)
    - Shared-Zugriff: Nur auf explizit freigegebene Pfade gemäß Konfiguration
    - _Requirements: 2.1, 2.3, 2.6, 2.7_

  - [-] 3.2 AuditLogger und Violation-Protokollierung implementieren
    - Implementiere `AuditLogger` in `src/monorepo/audit.py`
    - Methode `log_violation(event: SecurityEvent) -> None`: Schreibt Zeitstempel, anfragender Kontext, Zielkontext, Ressource in Protokolldatei
    - Konfiguration des Audit-Log-Pfads aus monorepo.yaml
    - _Requirements: 2.5_

  - [x] 3.3 Property-Test: Kontextübergreifender Secret-Zugriff (Property 3)
    - **Property 3: Kontextübergreifender Secret-Zugriff wird verweigert**
    - **Validates: Requirements 2.1, 2.3, 2.5, 2.7**

  - [x] 3.4 Property-Test: Shared-Tool-Isolation (Property 4)
    - **Property 4: Shared-Tool-Isolation**
    - **Validates: Requirements 2.7, 8.5**

  - [x] 3.5 Unit-Tests für ContextGuard und AuditLogger
    - Teste Zugriff innerhalb des eigenen Kontexts (erlaubt)
    - Teste Zugriff auf fremden Kontext (verweigert)
    - Teste Zugriff auf shared-Bereich (erlaubt gemäß Konfiguration)
    - Teste Audit-Log-Format und Vollständigkeit
    - _Requirements: 2.1, 2.3, 2.5, 2.6, 2.7_

- [ ] 4. Secret-Encryption-Manager (SecretEncryptionManager)
  - [-] 4.1 SecretEncryptionManager-Basisklasse mit git-crypt-Integration implementieren
    - Implementiere `SecretEncryptionManager` in `src/monorepo/encryption.py`
    - Methode `encrypt_file(file_path: Path, context: str) -> EncryptionResult`: Verschlüsselt Datei mit Kontext-Schlüssel
    - Methode `decrypt_file(file_path: Path) -> DecryptionResult`: Entschlüsselt nur bei autorisiertem Maschinenkontext
    - Methode `is_authorized(context: str) -> bool`: Prüft Maschinenkontext-Autorisierung
    - Methode `setup_gitcrypt_filters(context: str) -> None`: Installiert git-crypt-Filter pro Kontext (.gitattributes)
    - _Requirements: 9.1, 9.2, 9.3, 9.4, 9.8_

  - [x] 4.2 Maschinenkontext-Verwaltung und Schlüssel-Management implementieren
    - Implementiere `MachineContext`-Logik in `src/monorepo/encryption.py`
    - Methode `get_context_key(context: str) -> Optional[EncryptionKey]`: Schlüsselabruf aus Keyring oder Passwort-Manager
    - Methode `onboard_machine(machine_name, authorized_contexts) -> OnboardingResult`: Einrichtung neuer Maschinen mit autorisierten Schlüsseln
    - Methode `resolve_merge(file_path, ours, theirs) -> bytes`: Merge-Konflikt-Auflösung auf verschlüsselter Ebene
    - Lade Konfiguration aus `shared/config/machine-context.yaml`
    - Passwort-Manager-Integration (Bitwarden, 1Password, KeePass) als optionaler Key-Source
    - _Requirements: 9.4, 9.5, 9.6, 9.7, 9.10, 9.11_

  - [x] 4.3 .gitattributes pro Kontext und git-crypt-Konfiguration erstellen
    - Erstelle `privat/.gitattributes` mit git-crypt-privat-Filter-Regeln
    - Erstelle `dhive/.gitattributes` mit git-crypt-dhive-Filter-Regeln
    - Erstelle `bahn/.gitattributes` mit git-crypt-bahn-Filter-Regeln
    - Definiere Secret-Patterns: .env, *.pem, *.key, *token*, *secret*
    - Dokumentiere Onboarding-Prozess für neue Maschinen
    - _Requirements: 9.1, 9.2, 9.6, 9.9_

  - [x] 4.4 Property-Test: Verschlüsselung nur mit Kontext-Schlüssel (Property 23)
    - **Property 23: Verschlüsselte Secrets können nur mit autorisiertem Kontextschlüssel entschlüsselt werden**
    - **Validates: Requirements 9.3, 9.8**

  - [x] 4.5 Property-Test: Maschinenkontext-Beschränkung (Property 24)
    - **Property 24: Maschinenkontext beschränkt Entschlüsselung auf autorisierte Kontexte**
    - **Validates: Requirements 9.4, 9.5, 9.8, 9.10**

  - [x] 4.6 Unit-Tests für SecretEncryptionManager
    - Teste Verschlüsselung/Entschlüsselung mit korrektem Schlüssel
    - Teste Fehlschlag bei falschem Kontext-Schlüssel
    - Teste Maschinenkontext-Autorisierungsprüfung
    - Teste Fehlermeldung ohne Inhalt-Offenlegung
    - Teste .gitattributes-Generierung pro Kontext
    - Teste Merge-Auflösung für verschlüsselte Dateien
    - _Requirements: 9.1, 9.3, 9.4, 9.8, 9.10, 9.11_

- [x] 5. Checkpoint - Basis-Sicherheits- und Verschlüsselungsschicht
  - Ensure all tests pass, ask the user if questions arise.

- [x] 6. Wissensspeicher – ETL-Pipeline und Indexierung
  - [x] 6.1 KnowledgeStore-Basisklasse und YAML-Index implementieren
    - Implementiere `KnowledgeStore` in `src/monorepo/knowledge/store.py`
    - Implementiere `YAMLIndex` in `src/monorepo/knowledge/index.py` mit Methoden: `load()`, `update_entry()`, `search()`, `get_by_scope()`
    - Index-Format gemäß Design: version, last_updated, artifacts-Liste mit id, title, type, tags, scope, summary, path, content_hash, links
    - Progressive-Disclosure: Index liefert nur kompakte Einträge (kein vollständiger Inhalt)
    - _Requirements: 3.13, 3.16, 3.18, 3.19_

  - [x] 6.2 Wissensartefakt-Modell mit YAML-Frontmatter implementieren
    - Implementiere `Artifact` und `ArtifactMetadata` in `src/monorepo/knowledge/artifact.py`
    - YAML-Frontmatter-Parsing und -Generierung (type, title, tags, source_context, created, updated, shareable, links, content_hash)
    - Content-Hash-Berechnung (SHA-256)
    - Scope-basierte Ordnerstruktur: Artefakt-Pfad = `{scope}/{type}/{name}.md`
    - _Requirements: 3.4, 3.6, 3.11, 3.17, 3.19_

  - [x] 6.3 ETL-Pipeline-Grundstruktur und Markdown-Quellstrategie implementieren
    - Implementiere `ETLPipeline` in `src/monorepo/knowledge/etl.py`
    - Implementiere `MarkdownSource` als erste Quellstrategie in `src/monorepo/knowledge/sources/markdown.py`
    - Methode `ingest(source, context) -> list[Artifact]`: Verarbeitet Quelle, erstellt Artefakte mit Metadaten
    - Inkrementelle Verarbeitung: Content-Hash-Vergleich, nur geänderte Inhalte aktualisieren
    - Fehlerresilienz: Bei Quellenfehler → Fehler protokollieren, erfolgreiche Artefakte beibehalten, Retry-Markierung
    - Index-Update im selben Durchlauf
    - _Requirements: 3.2, 3.6, 3.10, 3.12, 3.20, 3.21_

  - [x] 6.4 Volltextsuche und Scope-basierte Filterung implementieren
    - Implementiere `search(query, allowed_scopes) -> list[SearchResult]` in KnowledgeStore
    - Volltextsuche über indexierte Artefakte mit Relevanz-Sortierung
    - Scope-Filterung: Nur Ergebnisse aus autorisierten Scopes zurückgeben
    - Existenz nicht-autorisierter Artefakte nicht offenlegen
    - Timeout-Handling: Abbruch nach 5 Sekunden mit Teilergebnis-Warnung
    - _Requirements: 3.3, 3.7, 3.9_

  - [x] 6.5 Graph-Verknüpfungen zwischen Artefakten implementieren
    - Methode `link_artifacts(source_id, target_id, relation) -> None`
    - Bidirektionale Verknüpfung: Eintrag im YAML-Frontmatter beider Artefakte
    - Aktualisierung des YAML-Index mit Link-Informationen
    - _Requirements: 3.8_

  - [x] 6.6 NoteGraph-Migration und Scope-Konfiguration implementieren
    - Implementiere `NoteGraphMigrator` in `src/monorepo/knowledge/migration.py`
    - Migration der NoteGraph-Verzeichnisstruktur (decisions, inbox, meetings, people, projects)
    - Scope-Konfiguration: Mapping Arbeitskontext → Scope in scopes.yaml
    - Validierung: Alle Artefakte, Metadaten und Verknüpfungen im Zielsystem vorhanden und auffindbar
    - _Requirements: 3.5, 3.14_

  - [x] 6.7 Property-Test: Artefakt-Ingestion erzeugt vollständige Metadaten (Property 5)
    - **Property 5: Wissensartefakt-Ingestion erzeugt vollständige Metadaten im Index**
    - **Validates: Requirements 3.2, 3.4, 3.6, 3.11, 3.13, 3.17, 3.21**

  - [x] 6.8 Property-Test: Suche respektiert Scope-Berechtigungen (Property 6)
    - **Property 6: Suche respektiert Scope-Berechtigungen**
    - **Validates: Requirements 3.3, 3.9**

  - [x] 6.9 Property-Test: Progressive-Disclosure-Index (Property 7)
    - **Property 7: Progressive-Disclosure-Index enthält nur kompakte Einträge**
    - **Validates: Requirements 3.16, 3.18**

  - [x] 6.10 Property-Test: Inkrementelle Verarbeitung (Property 8)
    - **Property 8: Inkrementelle Verarbeitung erkennt Änderungen über Content-Hash**
    - **Validates: Requirements 3.12**

  - [x] 6.11 Property-Test: Volltextsuche (Property 9)
    - **Property 9: Volltextsuche findet indexierte Inhalte**
    - **Validates: Requirements 3.7**

  - [x] 6.12 Property-Test: ETL-Fehlerresilienz (Property 10)
    - **Property 10: ETL-Fehlerresilienz bewahrt erfolgreiche Artefakte**
    - **Validates: Requirements 3.20**

  - [x] 6.13 Property-Test: Graph-Verknüpfungen bidirektional (Property 11)
    - **Property 11: Graph-Verknüpfungen werden in beiden Artefakten reflektiert**
    - **Validates: Requirements 3.8**

- [x] 7. Checkpoint - Wissensspeicher-Kern
  - Ensure all tests pass, ask the user if questions arise.

- [x] 8. Externes-Repo-Manager (RepoManager)
  - [x] 8.1 RepoManager-Klasse mit Subtree/Submodule-Einbindung implementieren
    - Implementiere `RepoManager` in `src/monorepo/repos.py`
    - Methode `add_repo(entry: RepoEntry) -> None`: Bindet Repo via Git-Subtree (Standard) oder Submodule ein
    - Methode `sync(repo_name: str) -> SyncResult`: Aktualisiert auf gepinnte Version, gibt Ergebnismeldung (Erfolg/Misserfolg/unbekannt)
    - Bidirektionale Sync für Upstream-Repos (Pull/Push), Abbruch bei Merge-Konflikten
    - _Requirements: 4.1, 4.3, 4.4, 4.6, 4.7, 4.8_

  - [x] 8.2 Read-Only-Schutzmechanismus implementieren
    - Methode `protect_readonly(repo_path: Path) -> None`: Installiert Git pre-commit Hook
    - Hook verhindert Commits die Dateien im geschützten Verzeichnis ändern
    - Fehlermeldung bei Schreibversuch mit Repo-Name und Read-Only-Status
    - Fehlerprotokollierung bei fehlgeschlagener Synchronisation (Netzwerk, Auth, Merge)
    - _Requirements: 4.2, 4.5, 4.9_

  - [x] 8.3 Property-Test: Read-Only-Repos blockieren Schreibzugriffe (Property 12)
    - **Property 12: Read-Only-Repos blockieren Schreibzugriffe**
    - **Validates: Requirements 4.2, 4.5**

  - [x] 8.4 Property-Test: Fehlgeschlagene Synchronisation (Property 13)
    - **Property 13: Fehlgeschlagene Synchronisation bewahrt lokalen Stand**
    - **Validates: Requirements 4.9**

  - [x] 8.5 Unit-Tests für RepoManager
    - Teste Subtree-Add und Submodule-Add
    - Teste Sync-Ergebnismeldungen (Erfolg, Fehler, unbekannt)
    - Teste Read-Only-Hook-Blockierung
    - Teste Fehlerprotokollierung bei Sync-Fehlschlägen
    - _Requirements: 4.1, 4.2, 4.4, 4.5, 4.9_

- [x] 9. Kontextbrücke (ContextBridge)
  - [x] 9.1 ContextBridge-Klasse mit Sensitive-Content-Filter implementieren
    - Implementiere `ContextBridge` in `src/monorepo/bridge.py`
    - Methode `share_artifact(artifact_id, user_confirmed) -> ShareResult`: Freigabe nur mit expliziter Nutzerbestätigung
    - Methode `check_sensitive_content(content: str) -> list[SensitiveMatch]`: Regex-basierte Prüfung auf Secrets, Endpoints, PII
    - Methode `revoke_share(artifact_id) -> None`: Entfernt Artefakt aus allen Zielkontexten als Lesereferenz
    - Update-Propagierung: Änderungen im Quellkontext beim nächsten Lesezugriff sichtbar
    - _Requirements: 5.1, 5.2, 5.3, 5.4, 5.5, 5.6_

  - [x] 9.2 Property-Test: Sensitive-Content-Filter (Property 14)
    - **Property 14: Sensitive-Content-Filter blockiert Freigabe**
    - **Validates: Requirements 5.1, 5.3**

  - [x] 9.3 Property-Test: Freigabe-Lebenszyklus (Property 15)
    - **Property 15: Freigabe-Lebenszyklus (Share → Update → Revoke)**
    - **Validates: Requirements 5.2, 5.5, 5.6**

  - [x] 9.4 Property-Test: Explizite Nutzerbestätigung (Property 16)
    - **Property 16: Freigabe erfordert explizite Nutzerbestätigung**
    - **Validates: Requirements 5.4**

- [x] 10. Checkpoint - Repo-Manager und Kontextbrücke
  - Ensure all tests pass, ask the user if questions arise.

- [ ] 11. Migrations-Engine
  - [x] 11.1 MigrationEngine-Klasse mit Git-Historie-Bewahrung implementieren
    - Implementiere `MigrationEngine` in `src/monorepo/migration.py`
    - Methode `migrate(plan: MigrationPlan) -> MigrationResult`: Führt Migration via `git filter-repo` oder `git subtree add` durch, bewahrt alle Commits, Branches, Tags, Autoreninformationen
    - Inkrementelle Migration: Repositories einzeln und unabhängig migrierbar
    - Konflikterkennung: Pfadkollision, Branch-Namenskonflikt, Namenskonvention-Verletzung → Migration pausieren
    - _Requirements: 6.1, 6.3, 6.5, 6.6_

  - [-] 11.2 Migrations-Validierung und Rollback implementieren
    - Methode `validate(repo_name: str) -> ValidationResult`: Prüft Commit-Anzahl, Branches, Tags, Dateibaum-Vollständigkeit, Test-Durchlauf
    - Methode `rollback(repo_name: str) -> None`: Stellt Vor-Migrations-Zustand wieder her, ohne andere Repos zu beeinflussen
    - Dokumentierter Migrationsplan: Für jedes Repo Ziel-Kontext, Reihenfolge, Abhängigkeiten, Einbindungsmodus
    - _Requirements: 6.1, 6.4, 6.7_

  - [-] 11.3 Property-Test: Migrations-Validierung (Property 17)
    - **Property 17: Migrations-Validierung prüft Vollständigkeit**
    - **Validates: Requirements 6.4**

  - [-] 11.4 Property-Test: Migrations-Rollback (Property 18)
    - **Property 18: Migrations-Rollback stellt Vor-Zustand wieder her**
    - **Validates: Requirements 6.7**

  - [x] 11.5 Unit-Tests für MigrationEngine
    - Teste Migration eines einfachen Repos (Commits, Branches, Tags bewahrt)
    - Teste Konflikterkennung (Pfadkollision, Branch-Namenskonflikt)
    - Teste Rollback-Wiederherstellung
    - Teste inkrementelle Migration (parallel funktionsfähig)
    - _Requirements: 6.1, 6.4, 6.5, 6.6, 6.7_

- [ ] 12. Orchestrator-Adapter
  - [x] 12.1 OrchestratorAdapter-Klasse mit Kontextauflösung implementieren
    - Implementiere `OrchestratorAdapter` in `src/monorepo/orchestrator.py`
    - Methode `resolve_context(task: Task) -> str`: Ermittelt Arbeitskontext aus Task-Metadaten (Labels/Projektzuordnung)
    - Methode `create_workspace(task, context) -> Path`: Erstellt Arbeitsverzeichnis unter dem korrekten Kontextordner
    - Methode `build_prompt(task, context) -> str`: Erstellt Agenten-Prompt mit Wissenskontext
    - Fehlerbehandlung: Kein Kontext → Task nicht starten, Fehlermeldung; Out-of-Context-Zugriff → Task abbrechen, protokollieren, Nutzer benachrichtigen
    - _Requirements: 7.1, 7.2, 7.3, 7.5, 7.6_

  - [-] 12.2 Wissensinjection und Env-Loading im Orchestrator implementieren
    - Methode `inject_knowledge(prompt, context) -> str`: Abfrage des YAML-Index, relevante Artefakt-Pfade einfügen
    - Env-Loading: Ausschließlich .env des zugewiesenen Kontexts laden (entschlüsselt via SecretEncryptionManager), keine Umgebungsvariablen anderer Kontexte
    - Integration mit bestehender WORKFLOW.md-Konfiguration: workspace_root pro Task
    - _Requirements: 7.3, 7.4_

  - [-] 12.3 Multi-Harness-Dispatch implementieren
    - Implementiere Harness-Konfiguration: Pro Kontext/Task-Typ den Agent_Harness definieren
    - Einheitliche Schnittstelle: Prompt-Injection, Workspace-Verzeichnis, Env-Übergabe, Agent_Erweiterungen
    - Harness-spezifische Startsequenz (CLI, API, Prozessstart) aus Konfiguration laden
    - Fehlerbehandlung: Harness nicht verfügbar → Task als nicht-ausführbar markieren, Nutzer benachrichtigen
    - _Requirements: 7.7, 7.8, 7.9, 7.10_

  - [x] 12.4 Property-Test: Orchestrator-Kontextauflösung (Property 19)
    - **Property 19: Orchestrator-Kontextauflösung und Workspace-Isolation**
    - **Validates: Requirements 7.1, 7.2, 7.3, 7.6**

  - [x] 12.5 Property-Test: Orchestrator-Kontextverletzung (Property 20)
    - **Property 20: Orchestrator-Kontextverletzung bricht Task ab**
    - **Validates: Requirements 7.5**

  - [x] 12.6 Unit-Tests für OrchestratorAdapter
    - Teste Kontextauflösung aus Task-Labels
    - Teste Workspace-Erstellung im korrekten Kontextordner
    - Teste Env-Isolation (nur eigene .env geladen, via Encryption entschlüsselt)
    - Teste Wissensinjektion in Prompt
    - Teste Task-Abbruch bei Out-of-Context-Zugriff
    - Teste Multi-Harness-Dispatch (Konfiguration, Startsequenz, Fehlerbehandlung)
    - _Requirements: 7.1, 7.2, 7.3, 7.4, 7.5, 7.6, 7.7, 7.9, 7.10_

- [x] 13. Shared Tooling und MCP-Konfiguration
  - [x] 13.1 MCP-Konfiguration-Merge und Shared-Tool-Versionierung implementieren
    - Implementiere `ConfigMerger` in `src/monorepo/shared_config.py`
    - Methode für MCP-Server-Konfiguration-Merge: Shared als Basis, kontextspezifische Überschreibungen mit Vorrang
    - Konflikt-Protokollierung bei Überschreibungskonflikten
    - Shared-Tool-Versionierung: Symlink- oder Import-basierter Mechanismus, sodass Kontexte automatisch die aktuelle Version verwenden
    - Kiro Powers und Skills zentral im shared-Bereich ablegen, Read-Only-Referenz für alle Kontexte
    - Agent-Erweiterungen in harness-unabhängigem Format (Markdown, YAML, Templates) mit Adapter-Mechanismus
    - _Requirements: 8.2, 8.3, 8.4, 8.5, 8.6, 8.7, 8.8, 8.9_

  - [x] 13.2 Property-Test: MCP-Konfiguration-Merge (Property 21)
    - **Property 21: MCP-Konfiguration-Merge mit Kontext-Vorrang**
    - **Validates: Requirements 8.4, 8.6**

  - [x] 13.3 Property-Test: Shared-Tool-Versionierung (Property 22)
    - **Property 22: Shared-Tool-Versionierung ohne manuelle Synchronisation**
    - **Validates: Requirements 8.2**

- [x] 14. Checkpoint - Orchestrator, Shared Tooling und Migration
  - Ensure all tests pass, ask the user if questions arise.

- [x] 15. Federation-Manager (FederationManager)
  - [x] 15.1 FederationManager-Basisklasse und SubtreeSyncEngine implementieren
    - Implementiere `FederationManager` in `src/monorepo/federation.py`
    - Implementiere `SubtreeSyncEngine` in `src/monorepo/federation.py`
    - Methode `sync_from_team(context) -> SyncResult`: Pull vom Team_Repo via git subtree pull
    - Methode `sync_to_team(context) -> SyncResult`: Push zum Team_Repo via git subtree push
    - Methode `full_sync(context) -> SyncResult`: Bidirektionale Synchronisation mit Konflikt-Erkennung
    - Methode `detect_conflicts(context) -> list[ConflictInfo]`: Erkennt Merge-Konflikte vor Sync
    - Lade Konfiguration aus `shared/config/team-repos.yaml`
    - _Requirements: 10.1, 10.2, 10.3, 10.4, 10.8_

  - [x] 15.2 Team-Isolation und Cross-Context-Leakage-Prüfung implementieren
    - Methode `verify_isolation(team_repo_path, context) -> IsolationReport`: Prüft ob Team_Repo keine Referenzen auf andere Kontexte enthält
    - Prüfung auf: Pfad-Referenzen, Env-Variablen, Config-Referenzen, Kommentare zu anderen Kontexten
    - Methode `prepare_team_repo(context) -> Path`: Erzeugt Team_Repo mit nur eigenem Kontext
    - Secrets-Handling: Team_Repo enthält nur Secrets des eigenen Kontexts (entschlüsselt oder re-keyed mit Team-Schlüssel)
    - Integration mit SecretEncryptionManager für kontextspezifische Secret-Filterung
    - _Requirements: 10.5, 10.9, 10.10_

  - [x] 15.3 Shared-Bereich-Spiegelung und Konflikt-Auflösung implementieren
    - Methode `mirror_shared(context, paths) -> MirrorResult`: Spiegelt shared-Dateien als Read-Only in Team_Repo
    - Methode `resolve_conflict(context, strategy) -> ConflictResult`: Löst Sync-Konflikte auf (Standard: team-wins)
    - Methode `onboard_member(context, member_info) -> OnboardingResult`: Erteilt Zugang nur zum Team_Repo
    - Single-Source-of-Truth-Logik: Team_Repo hat bei Konflikten Vorrang
    - Konfigurierbare Sync-Frequenz: on-push, hourly, daily, manual
    - _Requirements: 10.6, 10.7, 10.9, 10.11, 10.12_

  - [x] 15.4 Property-Test: Team-Repos enthalten nur eigenen Kontext (Property 25)
    - **Property 25: Team-Repos enthalten ausschließlich Inhalte des eigenen Kontexts**
    - **Validates: Requirements 10.5, 10.9, 10.10, 10.12**

  - [x] 15.5 Property-Test: Bidirektionale Synchronisation (Property 26)
    - **Property 26: Bidirektionale Synchronisation bewahrt Git-Historie und löst Konflikte korrekt**
    - **Validates: Requirements 10.3, 10.4, 10.6, 10.7, 10.8**

  - [x] 15.6 Property-Test: Team-Mitglieder-Isolation (Property 27)
    - **Property 27: Team-Mitglieder können die Existenz anderer Kontexte nicht entdecken**
    - **Validates: Requirements 10.5, 10.9**

  - [x] 15.7 Unit-Tests für FederationManager
    - Teste Subtree-Pull und -Push Operationen
    - Teste Konflikt-Erkennung und -Auflösung (team-wins-Strategie)
    - Teste Isolation-Check (Leakage-Erkennung für Pfade, Env-Vars, Config-Refs)
    - Teste Shared-Mirror als Read-Only
    - Teste Onboarding ohne Monorepo-Kenntnis
    - Teste Sync-Abbruch bei Merge-Konflikten mit Protokollierung
    - _Requirements: 10.1, 10.3, 10.5, 10.6, 10.7, 10.9, 10.12_

- [x] 16. Checkpoint - Föderationsschicht
  - Ensure all tests pass, ask the user if questions arise.

- [x] 17. Integration und Verdrahtung
  - [x] 17.1 CLI-Tool (`ctx-guard`) als Wrapper-Script erstellen
    - Erstelle CLI-Einstiegspunkt in `shared/tools/monorepo-cli/src/monorepo/cli.py`
    - Kommandos: `init` (Monorepo initialisieren), `create-project`, `list-projects`, `add-repo`, `sync-repo`, `migrate`, `validate`, `search`, `encrypt`, `decrypt`, `onboard`, `fed-sync`, `fed-status`
    - Verdrahte alle Komponenten: StructureManager, ContextGuard, KnowledgeStore, RepoManager, ContextBridge, MigrationEngine, OrchestratorAdapter, SecretEncryptionManager, FederationManager
    - Konfiguration aus `monorepo.yaml` und `shared/config/` laden
    - _Requirements: 1.1, 1.2, 4.4, 6.3, 9.6, 10.11_

  - [x] 17.2 Git-Hooks und Dateisystem-Schutz integrieren
    - Pre-commit Hook: Prüft Read-Only-Repos nicht verändert werden, unverschlüsselte Secrets nicht committet werden
    - git-crypt-Filter-Integration: Sicherstellt dass Secrets automatisch verschlüsselt/entschlüsselt werden
    - Integriere ContextGuard und SecretEncryptionManager in Hook-Chain
    - Installationsskript für Hooks bei `init`
    - _Requirements: 2.4, 4.2, 4.5, 9.1, 9.9_

  - [x] 17.3 Encryption-Security-Integration verdrahten
    - Integriere SecretEncryptionManager mit ContextGuard: load_env nutzt Entschlüsselung
    - Integriere SecretEncryptionManager mit FederationManager: Team_Repos erhalten nur eigene Secrets
    - Integriere SecretEncryptionManager mit OrchestratorAdapter: Env-Loading via Encryption
    - _Requirements: 2.2, 9.3, 9.4, 10.10_

  - [x] 17.4 Integration-Tests für End-to-End-Workflows
    - Teste: Projekt erstellen → Env verschlüsseln → Env laden → Secret-Zugriff prüfen
    - Teste: Artefakt erstellen → Indexieren → Suchen → Freigeben → Widerrufen
    - Teste: Repo einbinden → Sync → Read-Only-Schutz
    - Teste: Migration → Validierung → Rollback
    - Teste: Secret verschlüsseln → Maschinenkontext wechseln → Entschlüsselung fehlschlägt
    - Teste: Team_Repo vorbereiten → Isolation prüfen → Sync → Konflikt-Auflösung
    - Teste: Shared-Mirror in Team_Repo → Read-Only-Prüfung
    - _Requirements: 1.1, 2.1, 3.2, 4.1, 5.2, 6.1, 9.1, 9.4, 10.3, 10.5, 10.12_

- [x] 18. Final Checkpoint - Alle Komponenten integriert
  - Ensure all tests pass, ask the user if questions arise.

## Notes

- Tasks marked with `*` are optional and can be skipped for faster MVP
- Each task references specific requirements for traceability
- Checkpoints ensure incremental validation
- Property tests validate universal correctness properties from the design document (P1-P27)
- Unit tests validate specific examples and edge cases
- Die ETL-Pipeline wird initial nur mit der Markdown-Quellstrategie implementiert; weitere Strategien (Confluence, PDF, Webseiten, GitLab) können später ergänzt werden
- Die DB-Wissensdatenbank-Integration (Requirement 3.1, 3.15, 4.8) wird über den RepoManager als Upstream-Repo eingebunden; die ETL-Pipeline-Fork-Adaption erfolgt im Wissensspeicher
- Git-Remote-Operationen (Push/Pull/Sync) werden in Integration-Tests mit gemockten Repos getestet
- git-crypt-Operationen (encrypt/decrypt) werden in Integration-Tests mit temporären Repos und Test-Schlüsseln getestet
- Team-Repo-Synchronisation wird mit lokalen Bare-Repos als Test-Remotes getestet
- Die Föderationsschicht (Task 15) baut auf dem SecretEncryptionManager (Task 4) auf und setzt diesen als Abhängigkeit voraus
- Passwort-Manager-Integration (Bitwarden, 1Password, KeePass) ist optional und kann durch lokalen Keyring ersetzt werden

## Task Dependency Graph

```json
{
  "waves": [
    { "id": 0, "tasks": ["1.1"] },
    { "id": 1, "tasks": ["1.2"] },
    { "id": 2, "tasks": ["2.1", "3.1"] },
    { "id": 3, "tasks": ["2.2", "2.3", "2.4", "3.2", "4.1"] },
    { "id": 4, "tasks": ["3.3", "3.4", "3.5", "4.2"] },
    { "id": 5, "tasks": ["4.3", "4.4", "4.5", "4.6"] },
    { "id": 6, "tasks": ["6.1", "6.2"] },
    { "id": 7, "tasks": ["6.3", "6.4", "6.5"] },
    { "id": 8, "tasks": ["6.6", "6.7", "6.8", "6.9", "6.10"] },
    { "id": 9, "tasks": ["6.11", "6.12", "6.13"] },
    { "id": 10, "tasks": ["8.1", "9.1"] },
    { "id": 11, "tasks": ["8.2", "8.3", "8.4", "8.5", "9.2", "9.3", "9.4"] },
    { "id": 12, "tasks": ["11.1", "12.1"] },
    { "id": 13, "tasks": ["11.2", "11.3", "11.4", "11.5", "12.2", "12.3", "13.1"] },
    { "id": 14, "tasks": ["12.4", "12.5", "12.6", "13.2", "13.3"] },
    { "id": 15, "tasks": ["15.1"] },
    { "id": 16, "tasks": ["15.2", "15.3"] },
    { "id": 17, "tasks": ["15.4", "15.5", "15.6", "15.7"] },
    { "id": 18, "tasks": ["17.1"] },
    { "id": 19, "tasks": ["17.2", "17.3"] },
    { "id": 20, "tasks": ["17.4"] }
  ]
}
```