ankn/Orchestrator
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
f3cfacfd1157b630751f7d0668ddb51157ed27b6
Orchestrator/.kiro/specs/monorepo-consolidation/tasks.md
T
ankn 2f2b295531 Initial monorepo structure
2026-06-30 20:37:40 +02:00

29 KiB
Raw Blame History

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

  • 1. Projektstruktur und Basiskonfiguration

    • 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

    • 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)

    • 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)

    • 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

    • 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

    • 3.4 Property-Test: Shared-Tool-Isolation (Property 4)

      • Property 4: Shared-Tool-Isolation
      • Validates: Requirements 2.7, 8.5

    • 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

    • 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

    • 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

    • 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

    • 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

    • 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

  • 5. Checkpoint - Basis-Sicherheits- und Verschlüsselungsschicht

    • Ensure all tests pass, ask the user if questions arise.

  • 6. Wissensspeicher – ETL-Pipeline und Indexierung

    • 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

    • 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

    • 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

    • 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

    • 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

    • 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

    • 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

    • 6.8 Property-Test: Suche respektiert Scope-Berechtigungen (Property 6)

      • Property 6: Suche respektiert Scope-Berechtigungen
      • Validates: Requirements 3.3, 3.9

    • 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

    • 6.10 Property-Test: Inkrementelle Verarbeitung (Property 8)

      • Property 8: Inkrementelle Verarbeitung erkennt Änderungen über Content-Hash
      • Validates: Requirements 3.12

    • 6.11 Property-Test: Volltextsuche (Property 9)

      • Property 9: Volltextsuche findet indexierte Inhalte
      • Validates: Requirements 3.7

    • 6.12 Property-Test: ETL-Fehlerresilienz (Property 10)

      • Property 10: ETL-Fehlerresilienz bewahrt erfolgreiche Artefakte
      • Validates: Requirements 3.20

    • 6.13 Property-Test: Graph-Verknüpfungen bidirektional (Property 11)

      • Property 11: Graph-Verknüpfungen werden in beiden Artefakten reflektiert
      • Validates: Requirements 3.8

  • 7. Checkpoint - Wissensspeicher-Kern

    • Ensure all tests pass, ask the user if questions arise.

  • 8. Externes-Repo-Manager (RepoManager)

    • 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

    • 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

    • 8.3 Property-Test: Read-Only-Repos blockieren Schreibzugriffe (Property 12)

      • Property 12: Read-Only-Repos blockieren Schreibzugriffe
      • Validates: Requirements 4.2, 4.5

    • 8.4 Property-Test: Fehlgeschlagene Synchronisation (Property 13)

      • Property 13: Fehlgeschlagene Synchronisation bewahrt lokalen Stand
      • Validates: Requirements 4.9

    • 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

  • 9. Kontextbrücke (ContextBridge)

    • 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

    • 9.2 Property-Test: Sensitive-Content-Filter (Property 14)

      • Property 14: Sensitive-Content-Filter blockiert Freigabe
      • Validates: Requirements 5.1, 5.3

    • 9.3 Property-Test: Freigabe-Lebenszyklus (Property 15)

      • Property 15: Freigabe-Lebenszyklus (Share → Update → Revoke)
      • Validates: Requirements 5.2, 5.5, 5.6

    • 9.4 Property-Test: Explizite Nutzerbestätigung (Property 16)

      • Property 16: Freigabe erfordert explizite Nutzerbestätigung
      • Validates: Requirements 5.4

  • 10. Checkpoint - Repo-Manager und Kontextbrücke

    • Ensure all tests pass, ask the user if questions arise.

  • 11. Migrations-Engine

    • 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

    • 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

    • 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

    • 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

    • 12.5 Property-Test: Orchestrator-Kontextverletzung (Property 20)

      • Property 20: Orchestrator-Kontextverletzung bricht Task ab
      • Validates: Requirements 7.5

    • 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

  • 13. Shared Tooling und MCP-Konfiguration

    • 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

    • 13.2 Property-Test: MCP-Konfiguration-Merge (Property 21)

      • Property 21: MCP-Konfiguration-Merge mit Kontext-Vorrang
      • Validates: Requirements 8.4, 8.6

    • 13.3 Property-Test: Shared-Tool-Versionierung (Property 22)

      • Property 22: Shared-Tool-Versionierung ohne manuelle Synchronisation
      • Validates: Requirements 8.2

  • 14. Checkpoint - Orchestrator, Shared Tooling und Migration

    • Ensure all tests pass, ask the user if questions arise.

  • 15. Federation-Manager (FederationManager)

    • 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

    • 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

    • 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

    • 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

    • 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

    • 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

    • 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

  • 16. Checkpoint - Föderationsschicht

    • Ensure all tests pass, ask the user if questions arise.

  • 17. Integration und Verdrahtung

    • 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

    • 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

    • 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

    • 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

  • 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

{
  "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"] }
  ]
}
Reference in New Issue View Git Blame Copy Permalink