476 lines
29 KiB
Markdown
476 lines
29 KiB
Markdown
# 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"] }
|
||
]
|
||
}
|
||
```
|