@noyrax/documentation-system-plugin 1.0.4-beta.3 → 1.0.4-beta.4

package/docs/adr/021-semantic-api-docs-and-symbol-classifier.md

@@ -1,125 +0,0 @@
-# ADR-021: Semantische API-Doku-Tiefe & SymbolClassifier
-
-**Status:** Implementiert  
-**Datum:** 2025-12-04
-
-## Kontext
-
-Noyrax generiert API-Dokumentation aus einem reichhaltigen Symbolmodell
-(`ParsedSymbol`, `SymbolSignature`) und validiert diese gegen den Code.
-Mit ADR-020 wurde eine zentrale `SignatureFormatter`-Klasse eingeführt
-und Generator/Validator auf diese gemeinsame Signaturlogik ausgerichtet.
-
-Die Validierungsberichte – insbesondere beim Database-Plugin – zeigten
-jedoch weiterhin hunderte Signatur-Abweichungswarnungen, obwohl das
-Symbolmodell korrekt war. Die Ursachen:
-
-- fehlende Unterscheidung zwischen öffentlichen API-Typen und interner
-  Infrastruktur,
-- keine semantischen Rollen (Service-API, Domain-Modell, Konfig),
-- keine konfigurierbare Doku-Tiefe (alle Symbole wurden im Wesentlichen
-  gleich behandelt).
-
-Dies führte dazu, dass viele Symbole nur oberflächlich dokumentiert
-waren (z.B. leere Interfaces, `Name()` ohne Parameter), obwohl der
-Validator die vollen Signaturen kannte.
-
-## Entscheidung
-
-1. Einführung eines zentralen `SymbolClassifier` im `core`:
-
-   - Datei: `src/core/symbol-classifier.ts`
-   - API: `classifySymbol(symbol: ParsedSymbol): SymbolClassification`
-   - Liefert:
-     - `visibility: 'public' | 'internal'`
-     - `role: 'service-api' | 'domain-model' | 'config' | 'infra' | 'other'`
-     - `priority: 'high' | 'normal' | 'low'`
-   - Arbeitet ausschließlich auf `ParsedSymbol` (kein I/O, keine
-     Plugin-spezifischen Abhängigkeiten).
-   - Nutzt deterministische Heuristiken (Namensmuster, Dateipfade,
-     Symbol-Kind), um API-nahe Typen von Infrastruktur zu trennen.
-
-2. Rollenbasierte, tiefere Doku im Generator:
-
-   - Datei: `src/generator/module-doc.ts`
-   - `renderModuleDoc()` verwendet zusätzlich zu
-     `SignatureFormatter.formatForDoc()` jetzt auch
-     `classifySymbol(block.symbol)`, um:
-     - Rolle/Sichtbarkeit/Priorität transparent in der Doku zu zeigen,
-     - strukturierte Tabellen für Parameter und Eigenschaften zu
-       generieren (alphabetisch sortiert),
-     - die bisherige Markdown-Struktur unverändert zu lassen
-       (`# Modul:`, `### kind: name`, ```ts```-Block),
-     - **für Interfaces:** Properties aus `SymbolSignature.parameters`
-       sowohl im Codeblock (`interface X { feld: typ; ... }`) als auch
-       in der „Eigenschaften“-Tabelle zu rendern, sofern im Modell
-       vorhanden,
-     - **für Funktionen/Methoden (inkl. Utility-Klassen):** stets die
-       vollständige Funktionssignatur (Parameter + Rückgabetyp) im
-       Codeblock auszugeben, nicht nur `Name()`.
-
-3. Konfiguration der Doku-Tiefe im VS Code-Config-System:
-
-   - Datei: `package.json` → `contributes.configuration.properties`:
-     - `noyrax.apiDoc.depth: 'full' | 'standard' | 'minimal'`
-     - `noyrax.apiDoc.includeInternal: boolean`
-   - Die Doku-Tiefe wird im Validator bereits berücksichtigt und kann im
-     Generator genutzt werden, um künftig Doku-Umfang abhängig von
-     Konfiguration und Symbol-Rolle zu steuern.
-
-4. Ausrichtung des Validators auf Klassifizierung und Doku-Tiefe:
-
-   - Datei: `src/validator/signature-matching.ts`
-   - Verwendet `classifySymbol(symbol)` zur Bestimmung von
-     Sichtbarkeit/Rolle/Priorität.
-   - `SignatureMatchingOptions` erweitert um `depth?: 'full' | 'standard' | 'minimal'`.
-   - Bewertet Abweichungen abhängig von Rolle und Tiefe:
-     - bei `depth = 'full'` und Rolle `service-api` oder
-       `domain-model` → `severity: 'error'`,
-     - sonst → `severity: 'warning'`.
-   - Erwartete Signatur und Vergleich bleiben über
-     `SignatureFormatter.formatForDoc()` bzw.
-     `SignatureFormatter.compare()` implementiert; Toleranzen und
-     Architektur-Patterns bleiben erhalten.
-
-5. Ergänzung der Pre-Planning-Rule 024:
-
-   - Datei: `.cursor/rules/024-api-doc-depth.mdc`
-   - Neuer Abschnitt zur Symbol-Klassifizierung:
-     - Verweist auf `src/core/symbol-classifier.ts`,
-     - stellt sicher, dass Klassifizierung nur auf `ParsedSymbol`
-       basiert,
-     - dokumentiert die Rollen und Prioritäten.
-
-## Auswirkungen
-
-- Noyrax kann öffentliche Service-/Domain-APIs von interner Infrastruktur
-  unterscheiden und die Doku-Tiefe sowie die Strenge der
-  Signatur-Validierung daran ausrichten.
-- Die generierte Doku in `docs/modules/` ist für priorisierte Symbole
-  deutlich aussagekräftiger (Parameter-/Eigenschaftstabellen, explizite
-  Rolle/Sichtbarkeit).
-- Der Validator meldet Abweichungen für wichtige Public-APIs schärfer
-  (als Fehler), während er interne/Infra-Typen weniger strikt behandelt.
-- Die bestehende Architektur bleibt gewahrt:
-  - `core` (Classifier, SignatureFormatter) → `generator` / `validator`,
-  - keine Imports zurück nach `core`,
-  - keine neuen zirkulären Abhängigkeiten (vgl.
-    `docs/system/DEPENDENCY_GRAPH.md`).
-
-## Alternativen
-
-- Klassifizierungslogik direkt in Generator und Validator duplizieren:
-  - verworfen wegen höherer Wartungskosten und Risiko divergierender
-    Regeln.
-
-- Nur Doku-Templates erweitern, ohne Symbol-Klassifizierung:
-  - verworfen, da dann alle Symbole gleich behandelt würden und eine
-    sinnvolle Priorisierung (Public-API vs. Infra) nicht möglich wäre.
-
-- Strikte Signatur-Validierung für alle Symbole:
-  - verworfen, da dies bei rein technischen Typen (z.B. Cache,
-    Migrations, interne Konfigurationen) faktisch Rauschen erzeugen
-    würde und die wichtigen API-Abweichungen verdeckt.
-
-

package/docs/adr/022-semantic-class-and-constants-rendering.md

@@ -1,82 +0,0 @@
-# ADR-022 – Semantisches Klassen- und Konstanten-Rendering in der Modul-Doku
-
-## Status
-
-Accepted
-
-## Kontext
-
-Mit ADR-020/021 wurden der `SignatureFormatter` und der `SymbolClassifier` eingeführt und
-der Generator so erweitert, dass Interfaces und Funktionen/Methoden mit vollständigen
-Signaturen gerendert werden. Damit sind die fachlichen Signaturen korrekt, die aktuelle
-Darstellung ist aber teilweise noch „flach“:
-
-- Utility-Klassen wie `SnapshotUtils` oder `SnapshotTypeGuards` erscheinen als leerer
-  Klassenkopf, während ihre Methoden separat als einzelne Symbole dokumentiert werden.
-- Komplexe Konstantenobjekte wie `SNAPSHOT_CONSTANTS` werden als lange, schwer lesbare
-  Typ-Signatur gerendert, obwohl sie klar strukturierte Konfigurationsbereiche enthalten
-  (Status, Phasen, Validierung, Defaults).
-- Die `<!-- change: ... -->`‑Kommentare spiegeln beim Übergang vom alten auf das neue
-  Signatur-Rendering viele rein formatter-bedingte Änderungen wider (z.B. von
-  `Snapshot()` zu einer vollständigen Interface-Signatur), was unnötiges Rauschen erzeugt.
-
-Diese Punkte betreffen ausschließlich die Darstellung/Struktur der generierten
-Markdown-Dokumente, nicht das Parsing oder die Signaturmodelle selbst.
-
-## Entscheidung
-
-1. **Klassen-Rendering bleibt symbolbasiert, wird aber semantisch präziser beschrieben**
-   - Klassen (`kind: 'class'`) werden weiterhin als eigenes Symbol mit kurzem
-     Klassenkopf gerendert.
-   - Methoden (`kind: 'method'`) bleiben eigenständige Symbole mit voller Signatur,
-     werden aber explizit mit ihrer zugehörigen Klasse verknüpft (z.B. über
-     `ClassName.methodName` im Titel und begleitenden Text im Klassenblock).
-   - Für Utility-Klassen ohne eigene Properties/Konstruktoren wird der Klassenblock
-     um eine kurze Beschreibung ergänzt („Utility-Klasse mit den folgenden Methoden …“),
-     statt einen pseudo-leeren Klassen-Body zu suggerieren.
-
-2. **Komplexe Konstantenobjekte erhalten eine strukturierte Darstellung**
-   - Für ausgewählte, klar strukturierte Konstantenobjekte (z.B. `SNAPSHOT_CONSTANTS`)
-     wird im Generator ein spezieller Renderpfad eingeführt.
-   - Die Top-Level-Bereiche des Objekts (z.B. `STATUS`, `PHASES`, `VALIDATION`,
-     `DEFAULTS`) werden als eigene Unterabschnitte oder Tabellen dargestellt, damit
-     die Konfiguration auch für Menschen schnell erfassbar ist.
-   - Die Darstellung bleibt deterministisch (sortierte Schlüssel, stabiler Aufbau) und
-     nutzt weiterhin die Signaturdaten als Single Source of Truth; kein manueller
-     Freitext pro Key.
-
-3. **Change-Kommentare werden an die neue Signaturlogik angepasst**
-   - Die Heuristik zur Erzeugung von `<!-- change: ... -->`‑Kommentaren wird so
-     erweitert, dass rein formatter-bedingte Altzustände wie `Name()` ohne
-     Parameter/Felder nicht mehr als bedeutende „old“-Signaturen behandelt werden.
-   - Ziel ist, dass `change:`‑Einträge sich auf echte fachliche Änderungen beziehen
-     (z.B. neue Felder, geänderte Typen), nicht auf den einmaligen Umstieg von
-     Platzhalter- auf Tiefen-Signaturen.
-
-## Konsequenzen
-
-- **Kein Einfluss auf Parser und Signaturmodelle**  
-  Es werden keine Änderungen an `ParsedSymbol` oder `SymbolSignature` vorgenommen.
-  Alle Anpassungen finden im Generator (`src/generator/module-doc.ts`) und in der
-  Change-Kommentar-Logik statt.
-
-- **Verbesserte Lesbarkeit ohne API-Bruch**  
-  Die Markdown-Struktur bleibt kompatibel mit bestehenden Werkzeugen
-  (Überschriften-Layout, ts-Codeblöcke pro Symbol). Die Darstellung für Klassen und
-  Konstanten wird jedoch für Menschen deutlich verständlicher.
-
-- **Reduzierte Rauschen in CHANGE_REPORT**  
-  Beim erneuten Generieren der Doku nach Einführung von ADR-020/021 sollen
-  `change:`‑Kommentare nicht mehr massenhaft alte Platzhalter-Signaturen als
-  „signature-changed“ markieren, sondern sich auf substanzielle Änderungen konzentrieren.
-
-- **Regel-Update erforderlich**  
-  `.cursor/rules/024-api-doc-depth.mdc` wird um Hinweise zur Klassen-/Methoden-
-  Darstellung und zur strukturierten Behandlung komplexer Konstantenobjekte ergänzt.
-
-## Verwandte ADRs
-
-- **ADR-020 – API-Doku-Tiefe und SignatureFormatter**
-- **ADR-021 – Semantische API-Dokus und SymbolClassifier**
-
-

package/docs/adr/023-adr-verknuepfung-modul-doku.md

@@ -1,54 +0,0 @@
-# ADR-023: ADR-Verknüpfung mit Modul-Dokumentation
-
-**Status:** Implementiert  
-**Datum:** 2025-01-XX
-
-## Kontext
-
-Die Architecture Decision Records (ADRs) in `docs/adr/` dokumentieren wichtige Architektur-Entscheidungen, aber es fehlte eine Verknüpfung zwischen den ADRs und den betroffenen Modulen in der generierten Dokumentation (`docs/modules/`). Entwickler mussten manuell in den ADRs suchen, um zu verstehen, welche Entscheidungen ein bestimmtes Modul betreffen.
-
-## Entscheidung
-
-1. **ADR-Parser-Modul** (`src/generator/adr-linker.ts`):
-   - Parst alle ADR-Dateien aus `docs/adr/*.md`
-   - Extrahiert automatisch Dateipfade aus ADR-Inhalten (Pattern: `` `src/...` ``, `Datei: src/...`, etc.)
-   - Erstellt Mapping: `filePath → ADR-Nummern[]`
-   - Unterstützt optionale Metadata-Datei (`docs/adr-metadata.json`) für manuelle Overrides und Excludes
-   - Cacht ADR-Metadaten (Nummer, Titel, Dateiname) für effiziente Lookups
-
-2. **Integration in Modul-Dokumentation**:
-   - `renderModuleDoc()` in `src/generator/module-doc.ts` erweitert um optionalen `adrDir`-Parameter
-   - Fügt automatisch "Relevante ADRs"-Abschnitt am Anfang jeder Modul-Doku ein
-   - Format: Markdown-Links zu relevanten ADRs mit Titel und relativen Pfaden
-
-3. **Hybrid-Ansatz**:
-   - Automatisches Parsen der ADRs für Standard-Erkennung
-   - Optionale Metadata-Datei für manuelle Overrides/Excludes bei Bedarf
-
-## Auswirkungen
-
-- **Nachvollziehbarkeit**: Entwickler sehen direkt in der Modul-Doku, welche ADRs dieses Modul betreffen
-- **Kontext**: Architektur-Entscheidungen sind direkt mit dem betroffenen Code verknüpft
-- **Wartbarkeit**: Bei Änderungen sind relevante ADRs schnell auffindbar
-- **Determinismus**: ADR-Mappings sind deterministisch sortiert (nach ADR-Nummer)
-
-## Technische Details
-
-- **Dateipfad-Erkennung**: Unterstützt mehrere Patterns:
-  - Backtick-wrapped: `` `src/core/signature-formatter.ts` ``
-  - Markdown-Listen: `- src/validator/signature-matching.ts`
-  - Mit Doppelpunkt: `Datei: src/parsers/ts-js.ts`
-- **Relative Pfade**: Links von `docs/modules/` zu `docs/adr/` verwenden `../adr/`
-- **Fehlerbehandlung**: Wenn ADR-Linking fehlschlägt, wird die Dokumentationsgenerierung nicht abgebrochen
-
-## Alternativen
-
-- **Nur manuelle Metadata**: Verworfen, da zu wartungsintensiv
-- **Bidirektionale Verknüpfung**: ADRs → Module wurde nicht implementiert (kann später ergänzt werden)
-- **Keine Verknüpfung**: Verworfen, da Entwickler sonst manuell suchen müssten
-
-## Implementierung
-
-- `src/generator/adr-linker.ts` - ADR-Parser und Linker-Logik
-- `src/generator/module-doc.ts` - Erweitert um ADR-Linker-Integration
-- `src/generator/index.ts` - ADR-Pfad-Berechnung hinzugefügt

package/docs/adr/024-cursor-rules-mehrdimensionaler-raum.md

@@ -1,230 +0,0 @@
-# ADR-024: Cursor Rules Überarbeitung – Mehrdimensionaler Navigationsraum
-
-**Status:** Implementiert  
-**Datum:** 2025-01-XX
-
-## Kontext
-
-Die Cursor Rules (`.cursor/rules/`) erklärten nicht, wie das System als **mehrdimensionaler Navigationsraum** funktioniert, in dem die Docs die Koordinaten und die ADRs die Landkarte sind. Die Pre-Check Rule (`001-pre-check.mdc`) war veraltet und berücksichtigte neue Features wie:
-
-- MCP-Server Integration für strukturierten Agent-Zugriff
-- ADR-Verknüpfung mit Modulen (ADR-023)
-- Change Report als Zeit-Dimension
-- Dynamische Resource-Definitionen im MCP-Server
-
-Agenten (Cursor) wussten nicht:
-- Welche Docs bei Problemen konsultiert werden sollen
-- Wie man bei neuen Dateien den Systemkontext besorgt
-- Wie das Koordinaten-System funktioniert
-- Welche Dimensionen verfügbar sind und wie man darin navigiert
-
-## Entscheidung
-
-### 1. Neue Rule: System-Verständnis (`002-system-context.mdc`)
-
-**Zweck:** Erklärt das System als mehrdimensionalen Navigationsraum und wie Cursor darin navigiert.
-
-**Inhalt:**
-- **Mehrdimensionaler Raum-Konzept** mit 5 Dimensionen:
-  - Modul-Raum (X): `docs/modules/*.md` - API-Dokumentation pro Datei
-  - Symbol-Raum (Y): `docs/index/symbols.jsonl` - Symbole mit Dependencies
-  - Beziehungs-Raum (Z): `docs/system/DEPENDENCY_GRAPH.md` - Modul-Abhängigkeiten
-  - Wissens-Raum (W): `docs/adr/*.md` - Architektur-Entscheidungen (Landkarte)
-  - Zeit-Raum (T): `docs/system/CHANGE_REPORT.md` - Änderungen über die Zeit
-
-- **Navigation im Raum:**
-  - Bei Code-Änderungen: Modul-Doku → Dependencies → Change Report → ADRs
-  - Bei Problemen: System-Docs → Change Report → Impact-Analyse → ADRs
-  - Bei neuen Dateien: Systemkontext besorgen (ähnliche Module, Import-Richtungen, Change Report, ADRs)
-
-- **MCP-Server Zugriff:**
-  - `docs://modules/{path}` - Modul-Dokumentation
-  - `docs://system/graph` - Dependency-Graph
-  - `docs://system/dependencies` - Dependency-Übersicht
-  - `docs://system/changes` - Change Report (Zeit-Dimension)
-  - `docs://adr/{name}` - ADRs
-  - `docs://index/symbols.jsonl` - Symbol-Index
-  - `validation/analyzeImpact` - Impact-Analyse
-
-- **ADRs als Landkarte:**
-  - Module zeigen relevante ADRs automatisch (ADR-023)
-  - ADRs erklären **warum** bestimmte Entscheidungen getroffen wurden
-  - Bei Unsicherheit: Relevante ADRs konsultieren, nicht raten
-
-- **Change Report als Zeit-Dimension:**
-  - Zeigt neu hinzugefügte/geänderte Symbole
-  - Zeigt Dependency-Änderungen
-  - Ermöglicht Änderungsmuster zu erkennen
-
-### 2. Pre-Check Rule aktualisiert (`001-pre-check.mdc`)
-
-**Änderungen:**
-- Verweis auf `002-system-context.mdc` für System-Verständnis
-- Neuer Abschnitt "Bei neuen Dateien: Systemkontext besorgen":
-  - Ähnliche Module in `docs/modules/` finden (Modul-Raum)
-  - Import-Richtungen aus `docs/system/DEPENDENCIES.md` prüfen (Beziehungs-Raum)
-  - Change Report (`docs://system/changes`) für Änderungsmuster konsultieren (Zeit-Raum)
-  - Relevante ADRs aus Modul-Doku konsultieren (Wissens-Raum)
-- MCP-Server als Alternative zu direkten Datei-Zugriffen dokumentiert
-- ADR-Verknüpfung in Schritt "Dokumentation lesen" integriert
-- Change Report in Schritt "Nach der Änderung" erwähnt
-
-### 3. Orchestrator Rule erweitert (`000-orchestrator.mdc`)
-
-**Änderungen:**
-- Workflow um "Systemkontext verstehen" erweitert
-- Abschnitt "Mehrdimensionaler Navigationsraum" hinzugefügt
-- `002-system-context` zur Always-Apply-Rule-Hierarchie hinzugefügt
-- Verbindliche Arbeitsweise um Systemkontext-Nutzung erweitert
-
-### 4. Impact-Analyse Rule aktualisiert (`021-impact-analysis.mdc`)
-
-**Änderungen:**
-- MCP-Server `validation/analyzeImpact` als primäre Quelle dokumentiert
-- Zeit-Dimension (Change Report) in den Workflow integriert
-- Dimensionen-Spalte in Datenquellen-Tabelle hinzugefügt
-- Abschnitt "Navigation im mehrdimensionalen Raum" hinzugefügt
-
-### 5. MCP-Server Resource-Definitionen erweitert
-
-**Problem:** Die Rules erwähnten `docs://modules/{path}`, `docs://adr/{name}` und `docs://index/symbols.jsonl`, aber diese waren nicht in `ListResources` registriert.
-
-**Lösung:**
-- Dynamisches Laden aller Module aus `docs/modules/` (71 Module)
-- Dynamisches Laden aller ADRs aus `docs/adr/` (23 ADRs)
-- Symbol-Index (`docs://index/symbols.jsonl`) hinzugefügt
-- Beschreibungen mit Dimensionen-Hinweisen ergänzt
-
-**Geänderte Dateien:**
-- `mcp/src/server.ts`
-- `packages/doc-system-agent/src/mcp/server.ts`
-
-## Auswirkungen
-
-### Positive Auswirkungen
-
-- **Bessere Navigation:** Agenten verstehen jetzt das Koordinaten-System und können gezielt die richtigen Docs konsultieren
-- **Systemkontext bei neuen Dateien:** Automatische Besorgung des Systemkontexts verhindert Architektur-Verstöße
-- **Zeit-Dimension:** Change Report wird jetzt systematisch genutzt, um Änderungsmuster zu erkennen
-- **ADRs als Landkarte:** Architektur-Entscheidungen sind direkt mit Code verknüpft und werden automatisch konsultiert
-- **MCP-Server Integration:** Strukturierter Zugriff auf alle Resources (98 insgesamt)
-- **Konsistenz:** Rules und MCP-Server sind jetzt vollständig konsistent
-
-### Technische Auswirkungen
-
-- **99 Resources verfügbar:**
-  - 4 System-Resources
-  - 71 Modul-Resources (dynamisch)
-  - 24 ADR-Resources (dynamisch, inkl. ADR-024)
-- **5 Dimensionen vollständig abgedeckt:**
-  - Modul-Raum (X): ✅
-  - Symbol-Raum (Y): ✅
-  - Beziehungs-Raum (Z): ✅
-  - Wissens-Raum (W): ✅
-  - Zeit-Raum (T): ✅
-
-### Wartbarkeit
-
-- **Neue Module/ADRs:** Werden automatisch als Resources verfügbar (dynamisches Laden)
-- **Rule-Updates:** Zentralisiert in `002-system-context.mdc`
-- **MCP-Server:** Konsistente Implementierung in beiden Packages
-
-## Alternativen
-
-### Alternative 1: Statische Resource-Liste
-**Verworfen:** Zu wartungsintensiv, müsste bei jedem neuen Modul/ADR aktualisiert werden.
-
-### Alternative 2: Keine neue Rule, nur Pre-Check erweitern
-**Verworfen:** Pre-Check Rule wäre zu lang und unübersichtlich geworden. Separate Rule für System-Verständnis ist klarer.
-
-### Alternative 3: Keine MCP-Server-Erweiterung
-**Verworfen:** Rules würden auf Resources verweisen, die nicht verfügbar sind. Inkonsistenz zwischen Dokumentation und Implementierung.
-
-## Implementierung
-
-### Geänderte Dateien
-
-**Rules:**
-- `.cursor/rules/002-system-context.mdc` - **NEU**
-- `.cursor/rules/001-pre-check.mdc` - **AKTUALISIERT**
-- `.cursor/rules/000-orchestrator.mdc` - **ERWEITERT**
-- `.cursor/rules/021-impact-analysis.mdc` - **AKTUALISIERT**
-
-**MCP-Server:**
-- `mcp/src/server.ts` - Resource-Definitionen erweitert
-- `packages/doc-system-agent/src/mcp/server.ts` - Gleiche Änderungen
-
-### Test-Dateien
-
-- `.cursor/test-mcp-resources.mjs` - Test-Skript für Resource-Definitionen
-- `.cursor/test-mcp-server.mjs` - **MCP-Server Integrationstest** (testet tatsächliche Implementierung)
-- `.cursor/TEST_PLAN.md` - Test-Szenarien
-- `.cursor/TEST_REPORT.md` - Test-Beispiel
-- `.cursor/TEST_RESULTS.md` - Detaillierte Test-Ergebnisse
-- `.cursor/MCP_SERVER_AUDIT.md` - MCP-Server Audit
-
-### MCP-Server Integrationstest
-
-**Test-Ergebnisse:**
-- ✅ `listModuleDocs()`: 71 Module gefunden
-- ✅ `listADRs()`: 24 ADRs gefunden (inkl. ADR-024)
-- ✅ `readDocsResource()`: Funktioniert für alle Resource-Typen:
-  - System-Resources: ✅ (dependencies: 373 Zeilen, graph: 312 Zeilen, changes: 74 Zeilen)
-  - Modul-Resources: ✅ (Beispiel: 51 Zeilen)
-  - ADR-Resources: ✅ (Beispiel: 55 Zeilen)
-- ✅ Gesamt: 99 Resources verfügbar
-
-### Validierung
-
-- ✅ Build-Tests: Beide MCP-Server kompilieren erfolgreich
-- ✅ Resource-Tests: Alle 99 Resources verfügbar (4 System, 71 Module, 24 ADRs)
-- ✅ Dimensionen-Check: Alle 5 Dimensionen abgedeckt
-- ✅ Konsistenz: Rules und MCP-Server sind konsistent
-- ✅ MCP-Server-Test: `readDocsResource()` funktioniert für alle Resource-Typen
-- ✅ Dynamisches Laden: Module und ADRs werden korrekt zur Laufzeit geladen
-
-## Verweise
-
-- **ADR-023:** ADR-Verknüpfung mit Modul-Dokumentation (Grundlage für Wissens-Raum)
-- **ADR-014:** Rules-Migration und MCP-Integration (Vorläufer)
-- `docs/system/NAVIGATION_SPACE_ANALYSIS.md` - Analyse des Navigationsraums
-- `docs/system/PLUGIN_ECOSYSTEM_STATUS.md` - Plugin-Ecosystem Status
-
-## Template-Aktualisierung für andere Systeme
-
-Damit die neuen Rules in anderen Systemen verfügbar werden:
-
-### ✅ Templates aktualisiert
-
-- `packages/doc-system-agent/templates/cursor-rules/002-system-context.mdc` - **NEU**
-- `packages/doc-system-agent/templates/cursor-rules/000-orchestrator.mdc` - **AKTUALISIERT**
-- `packages/doc-system-agent/templates/cursor-rules/001-pre-check.mdc` - **AKTUALISIERT**
-- `packages/doc-system-agent/templates/cursor-rules/021-impact-analysis.mdc` - **AKTUALISIERT**
-
-### ✅ Konstante aktualisiert
-
-- `packages/doc-system-agent/src/constants.ts`:
-  - `RULES_VERSION`: 1 → 2
-  - `RULE_FILES`: `002-system-context.mdc` hinzugefügt
-
-### Update-Mechanismus
-
-Andere Systeme können die neuen Rules erhalten via:
-
-```bash
-# Automatisches Update
-npx @noyrax/cli update-rules
-
-# Oder manuell aus Templates kopieren
-```
-
-Siehe `docs/system/RULES_UPDATE_GUIDE.md` für detaillierte Anleitung.
-
-## Nächste Schritte
-
-1. **Package-Version erhöhen:** `@noyrax/cli` auf Version 1.1.0 erhöhen (mit neuen Rules)
-2. **Integrationstest:** MCP-Server mit Cursor testen
-3. **Performance:** Bei Bedarf Caching für Resource-Liste implementieren
-4. **Dokumentation:** MCP-Server-Usage in README dokumentieren
-5. **Monitoring:** Prüfen, ob Agenten die neuen Rules korrekt nutzen
-