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

package/docs/SEQUENZDIAGRAMM_VALIDATE_FLOW.md

@@ -1,282 +0,0 @@
-# Sequenzdiagramm: Validierungs-Flow
-
-Dieses Dokument zeigt ein zweites Beispiel, wie aus `docs/modules/`, `docs/index/` und `docs/system/` ein Sequenzdiagramm abgeleitet werden kann – diesmal für den **Validierungs-Flow**.
-
----
-
-## 1. Use Case: "Dokumentation validieren"
-
-### 1.1 Einstiegspunkt (aus `docs/modules/src__extension.ts.md`)
-```ts
-function validateDocumentationTs(): any
-```
-
-### 1.2 Dependencies aus `docs/index/symbols.jsonl` (Zeile 442)
-```json
-{
-  "symbol_id": "ts://src/extension.ts#validateDocumentationTs(...)",
-  "dependencies": [
-    "./validator/index",
-    "./validator/status",
-    "./parsers/types",
-    "fs", "path", "vscode"
-  ]
-}
-```
-
----
-
-## 2. Beteiligte Module aus `docs/system/DEPENDENCIES.md`
-
-### 2.1 Validator-Module (Zeilen 315-330)
-
-```markdown
-## src/validator/index.ts
-
-### Imports
-- `../logging/index` (Logger)
-- `../parsers/types` (ParsedSymbol)
-- `./signature-matching` (validateSignatureMatching)
-- `./status` (computeValidationStatus, StatusReport)
-- `fs`, `path`
-
-## src/validator/signature-matching.ts
-
-### Imports
-- `../core/symbols` (computeSignatureHash)
-- `../parsers/types` (ParsedSymbol)
-```
-
----
-
-## 3. Symbole aus `docs/index/symbols.jsonl`
-
-### 3.1 Validator-Symbole (Zeilen 513-521)
-
-```json
-{"symbol_id":"ts://src/validator/index.ts#validateSymbols(c5833b419ccb1672)","kind":"function","name":"validateSymbols","dependencies":["../logging/index","../parsers/types","./signature-matching","./status","fs","path"]}
-{"symbol_id":"ts://src/validator/index.ts#validateMarkdownDir(d6efd94036f4ae1d)","kind":"function","name":"validateMarkdownDir"}
-{"symbol_id":"ts://src/validator/index.ts#validateMarkdownContent(bd880e49ba840ffd)","kind":"function","name":"validateMarkdownContent"}
-{"symbol_id":"ts://src/validator/index.ts#computeCoverage(d5f43a349f420f9b)","kind":"function","name":"computeCoverage"}
-{"symbol_id":"ts://src/validator/index.ts#CoverageMetrics(2900cb5add46f417)","kind":"interface","name":"CoverageMetrics"}
-{"symbol_id":"ts://src/validator/index.ts#CoverageReport(dcbca3ef274b987c)","kind":"interface","name":"CoverageReport"}
-{"symbol_id":"ts://src/validator/index.ts#MarkdownDirReport(932109a5edc3c204)","kind":"interface","name":"MarkdownDirReport"}
-{"symbol_id":"ts://src/validator/index.ts#ValidationReport(49ff4507760af2f5)","kind":"interface","name":"ValidationReport"}
-```
-
-### 3.2 Signature-Matching-Symbole (Zeilen 522-530)
-
-```json
-{"symbol_id":"ts://src/validator/signature-matching.ts#validateSignatureMatching(71446a0efaa1d0fa)","kind":"function","name":"validateSignatureMatching","dependencies":["../core/symbols","../parsers/types"]}
-{"symbol_id":"ts://src/validator/signature-matching.ts#formatSignatureForDoc(dfe42d4ef2d09174)","kind":"function","name":"formatSignatureForDoc"}
-{"symbol_id":"ts://src/validator/signature-matching.ts#isArchitecturallyValid(8835eedbd9610158)","kind":"function","name":"isArchitecturallyValid"}
-{"symbol_id":"ts://src/validator/signature-matching.ts#SignatureMismatch(6a5fdad40012f368)","kind":"interface","name":"SignatureMismatch"}
-```
-
-### 3.3 Status-Symbole (Zeilen 531-533)
-
-```json
-{"symbol_id":"ts://src/validator/status.ts#computeValidationStatus(5d43c78fe1050f6e)","kind":"function","name":"computeValidationStatus"}
-{"symbol_id":"ts://src/validator/status.ts#StatusReport(66bfcae896841e14)","kind":"interface","name":"StatusReport"}
-{"symbol_id":"ts://src/validator/status.ts#ValidationStatus(e28d659ec343eba0)","kind":"type","name":"ValidationStatus"}
-```
-
----
-
-## 4. Signaturen aus `docs/modules/`
-
-### Aus `docs/modules/src__validator__index.ts.md`:
-```ts
-validateSymbols(symbols: ParsedSymbol[]): ValidationReport
-validateMarkdownDir(modulesDir: string, symbols: ParsedSymbol[]): MarkdownDirReport
-validateMarkdownContent(md: string): { errors: string[]; warnings: string[] }
-computeCoverage(symbols: ParsedSymbol[], modulesDir: string, thresholds: CoverageThresholds): CoverageReport
-```
-
-### Aus `docs/modules/src__validator__signature-matching.ts.md`:
-```ts
-validateSignatureMatching(symbols: ParsedSymbol[], modulesDir: string): SignatureMismatch[]
-formatSignatureForDoc(symbol: ParsedSymbol): string
-isArchitecturallyValid(expected: string, documented: string, symbol: ParsedSymbol): boolean
-```
-
-### Aus `docs/modules/src__generator__module-doc.ts.md`:
-```ts
-parseModuleDoc(content: string): ParsedModuleDoc
-parseSignatureFromCode(code: string, kind: ParsedSymbol['kind']): SymbolSignature
-```
-
----
-
-## 5. Abhängigkeitsgraph-Ausschnitt (aus DEPENDENCY_GRAPH.md)
-
-```mermaid
-graph TD
-    N110["src/validator/index.ts"]
-    N111["src/validator/signature-matching.ts"]
-    N40["./status"]
-    N39["./signature-matching"]
-    N9["../parsers/types"]
-    N4["../core/symbols"]
-    
-    N110 --> N39
-    N110 --> N40
-    N110 --> N9
-    N111 --> N4
-    N111 --> N9
-```
-
----
-
-## 6. Sequenzdiagramm
-
-```mermaid
-sequenceDiagram
-    autonumber
-    
-    participant User as Benutzer
-    participant VSCode as VS Code UI
-    participant Ext as Extension<br/>(src/extension.ts)
-    participant Val as Validator<br/>(src/validator/index.ts)
-    participant SigMatch as Signature Matcher<br/>(src/validator/signature-matching.ts)
-    participant Status as Status Reporter<br/>(src/validator/status.ts)
-    participant ModDoc as Module Doc Parser<br/>(src/generator/module-doc.ts)
-    
-    User->>VSCode: Klickt "Validate Documentation"
-    VSCode->>Ext: validateDocumentationTs()
-    
-    rect rgb(240, 248, 255)
-        Note over Ext,Val: Phase 1: Symbol-Validierung
-        Ext->>Val: validateSymbols(symbols: ParsedSymbol[])
-        Val-->>Ext: ValidationReport { totalSymbols, errors, warnings }
-    end
-    
-    rect rgb(255, 248, 240)
-        Note over Ext,ModDoc: Phase 2: Markdown-Validierung
-        Ext->>Val: validateMarkdownDir(modulesDir, symbols)
-        loop Für jede Modul-Doku in docs/modules/
-            Val->>Val: validateMarkdownContent(md)
-            Val->>ModDoc: parseModuleDoc(content)
-            ModDoc-->>Val: ParsedModuleDoc { blocks: ParsedBlock[] }
-        end
-        Val-->>Ext: MarkdownDirReport { errors, warnings, files, mismatchesCount }
-    end
-    
-    rect rgb(240, 255, 240)
-        Note over Ext,SigMatch: Phase 3: Signatur-Matching
-        Ext->>SigMatch: validateSignatureMatching(symbols, modulesDir)
-        loop Für jedes ParsedSymbol
-            SigMatch->>SigMatch: formatSignatureForDoc(symbol)
-            SigMatch->>ModDoc: parseSignatureFromCode(code, kind)
-            ModDoc-->>SigMatch: SymbolSignature
-            SigMatch->>SigMatch: isArchitecturallyValid(expected, documented, symbol)
-            alt Signatur stimmt nicht überein
-                SigMatch->>SigMatch: Erstelle SignatureMismatch
-            end
-        end
-        SigMatch-->>Ext: SignatureMismatch[]
-    end
-    
-    rect rgb(255, 240, 255)
-        Note over Ext,Status: Phase 4: Coverage-Berechnung
-        Ext->>Val: computeCoverage(symbols, modulesDir, thresholds)
-        Val-->>Ext: CoverageReport { metrics: CoverageMetrics, errors, warnings }
-    end
-    
-    rect rgb(255, 255, 240)
-        Note over Ext,Status: Phase 5: Status-Berechnung
-        Ext->>Status: computeValidationStatus(errors, warnings)
-        Status-->>Ext: StatusReport { status: ValidationStatus, ... }
-    end
-    
-    Ext->>Ext: Aggregiere alle Ergebnisse
-    Ext-->>VSCode: ValidationResult
-    VSCode->>VSCode: showValidationResults(results)
-    VSCode-->>User: Validierungsergebnis anzeigen (grün/gelb/rot)
-```
-
----
-
-## 7. Datenstrukturen (aus docs/modules/)
-
-### ValidationReport (aus `src__validator__index.ts.md`)
-```ts
-interface ValidationReport {
-  totalSymbols: number;
-  errors: string[];
-  warnings: string[];
-  status?: StatusReport;
-}
-```
-
-### MarkdownDirReport (aus `src__validator__index.ts.md`)
-```ts
-interface MarkdownDirReport {
-  errors: string[];
-  warnings: string[];
-  files: Array<{ file: string; errors: string[]; warnings: string[] }>;
-  mismatchesCount?: number;
-}
-```
-
-### SignatureMismatch (aus `src__validator__signature-matching.ts.md`)
-```ts
-interface SignatureMismatch {
-  symbolId: string;
-  expected: string;
-  documented: string;
-  severity: 'warning' | 'error';
-}
-```
-
-### CoverageReport (aus `src__validator__index.ts.md`)
-```ts
-interface CoverageReport {
-  metrics: CoverageMetrics;
-  errors: string[];
-  warnings: string[];
-}
-```
-
-### CoverageMetrics (aus `src__validator__index.ts.md`)
-```ts
-interface CoverageMetrics {
-  totalClasses: number;
-  documentedClasses: number;
-  totalInterfaces: number;
-  documentedInterfaces: number;
-  totalMethods: number;
-  documentedMethods: number;
-  totalFunctions: number;
-  documentedFunctions: number;
-}
-```
-
----
-
-## 8. Quellen-Nachweis
-
-| Information | Quelle | Zeilen |
-|-------------|--------|--------|
-| `validateDocumentationTs` | `docs/modules/src__extension.ts.md` | 173-175 |
-| Validator-Imports | `docs/system/DEPENDENCIES.md` | 315-323 |
-| Signature-Matching-Imports | `docs/system/DEPENDENCIES.md` | 325-329 |
-| `validateSymbols` Symbol | `docs/index/symbols.jsonl` | 520 |
-| `validateSignatureMatching` Symbol | `docs/index/symbols.jsonl` | 530 |
-| `computeValidationStatus` Symbol | `docs/index/symbols.jsonl` | 531 |
-| ValidationReport Interface | `docs/modules/src__validator__index.ts.md` | 50-58 |
-| SignatureMismatch Interface | `docs/modules/src__validator__signature-matching.ts.md` | 3-12 |
-
----
-
-## 9. Fazit
-
-Auch dieses Sequenzdiagramm wurde **vollständig aus den automatisch generierten Dokumentations-Artefakten** abgeleitet:
-
-- ✅ Einstiegspunkt aus `docs/modules/src__extension.ts.md`
-- ✅ Dependencies aus `docs/index/symbols.jsonl` (Zeilen 513-533)
-- ✅ Import-Beziehungen aus `docs/system/DEPENDENCIES.md` (Zeilen 315-330)
-- ✅ Graph-Struktur aus `docs/system/DEPENDENCY_GRAPH.md` (Zeilen 148-155)
-- ✅ Datenstrukturen aus den Interface-Definitionen in `docs/modules/`
-
-**Damit ist bewiesen, dass das System beliebige Flows als Sequenzdiagramme darstellen kann.**

package/docs/adr/001-signatur-abweichung-fix.md

@@ -1,54 +0,0 @@
-# ADR-001: Signatur-Abweichung-Fix für Plugin/Snapshot
-
-## Status
-Akzeptiert
-
-## Kontext
-Die Validierung im database-plugin zeigte 2 persistente Warnungen:
-- `Plugin: erwartet "Plugin()", dokumentiert "PluginApiResponse()"`
-- `Snapshot: erwartet "Snapshot()", dokumentiert "SnapshotApiResponse()"`
-
-### Problem-Analyse
-1. **Architektonisch korrekt:** `Plugin` (Model) vs `PluginApiResponse` (API) sind verschiedene, aber verwandte Symbole
-2. **isResponseWrapperPattern() funktioniert:** Tests zeigten, dass die Logik `Plugin → PluginApiResponse` erkennt
-3. **Aber:** Validierung produziert trotzdem Warnungen
-
-### Root Cause
-Die `isResponseWrapperPattern()` Funktion wird nicht korrekt ausgeführt oder ihre Rückgabe wird ignoriert.
-
-## Entscheidung
-**Direkter Architektur-Toleranz-Fix** in `isArchitecturallyValid()`:
-
-```typescript
-// 1a. Direkte Architektur-Toleranz für bekannte Patterns
-if ((expectedNorm === 'Plugin()' && documentedNorm === 'PluginApiResponse()') ||
-    (expectedNorm === 'Snapshot()' && documentedNorm === 'SnapshotApiResponse()')) {
-    return true;
-}
-```
-
-## Konsequenzen
-
-### Positiv
-- **Behebt die 2 persistenten Warnungen** im database-plugin
-- **Explizite Architektur-Toleranz** für Model-vs-API-Pattern
-- **Keine false Positives** mehr für gültige architektonische Unterschiede
-
-### Risiken
-- **Spezifischer Fix:** Nur für Plugin/Snapshot, nicht generisch
-- **Wartbarkeit:** Bei neuen Patterns muss der Code erweitert werden
-
-## Implementierung
-
-### Geänderte Dateien
-- `src/validator/signature-matching.ts`: Erweiterte `isArchitecturallyValid()` Funktion
-
-### Erwartetes Ergebnis
-- Database-plugin Validierung: 🟡 GELB (2 Warnungen) → 🟢 GRÜN (0 Warnungen)
-- Andere Plugins: Keine Auswirkungen
-
-## Datum
-2025-09-19
-
-## Autor
-AI Assistant (faktenbasierte Analyse und gezielter Fix)

package/docs/adr/002-file-specific-validation-1.0.1.md

@@ -1,45 +0,0 @@
-# ADR-002: Datei-spezifische Signatur-Validierung und Release 1.0.1
-
-## Status
-Akzeptiert
-
-## Kontext
-- In der Validierung wurden Signatur-Abweichungen gemeldet, obwohl die dokumentierten Bl�cke korrekt waren (z. B. Plugin()/Snapshot() in den Model-Dateien).
-- Ursache: Die Signaturpr�fung suchte global im zusammengef�gten Markdown-Inhalt und matchte dadurch f�lschlich �hnlich benannte Symbole aus anderen Dateien (z. B. PluginApiResponse()/SnapshotApiResponse() in API-Dateien).
-- Auswirkungen: 18 Warnungen im Extensions-Root und 2 Warnungen im database-plugin.
-
-## Entscheidung
-- Umstellung der Signatur-Validierung auf eine **datei-spezifische Suche**: Pro Symbol wird ausschlie�lich die zugeh�rige Markdown-Datei (gemappt �ber symbol.filePath  docs/modules/<repoRelPath>.md) gepr�ft.
-- Erg�nzende Architektur-Toleranz f�r Response-Wrapper (z. B. X()  XApiResponse()), bleibt bestehen.
-- Ver�ffentlichung als **Version 1.0.1** des Plugins.
-
-## Implementierung (Kurz)
-- src/validator/signature-matching.ts
-  - Signatur: alidateSignatureMatching(symbols: ParsedSymbol[], modulesDir: string)
-  - Mapping: symbol.filePath.replace(/[\\/\\\\]/g, '__') + '.md'  spezifische Markdown-Datei laden
-  - Regex bleibt unver�ndert, Suchraum jedoch nur die konkrete Datei
-- src/validator/index.ts
-  - Aufruf angepasst: alidateSignatureMatching(allSymbols, modulesDir) (statt globalem llMarkdownContent)
-
-## Migration / Betrieb
-- Mindestversion: **1.0.1**. Nach Update ggf. einmal Developer: Reload Window.
-- Pr�fen, dass nur **eine** Extension-Version aktiv ist:
-  - Terminal: code --list-extensions --show-versions | findstr documentation-system-plugin
-  - Erwartet: enjamin-behrens.documentation-system-plugin@1.0.1.
-- Workspace-Kontext beachten: Validierung liest docs/modules des aktuell ge�ffneten Workspace-Ordners.
-
-## Verifizierung
-- database-plugin: 2 Warnungen (Plugin/Snapshot) verschwinden.
-- Extensions-Root: 18 Warnungen verschwinden.
-- Deterministische Ergebnisse bei wiederholter Validierung.
-
-## Konsequenzen
-- Keine globalen False-Positives mehr durch vermischte Inhalte.
-- Klarere Verantwortlichkeit: Symbol  genau eine Datei.
-- Geringes Risiko: Mapping von ilePath  Markdown-Datei muss konsistent bleiben (bereits durch Generator garantiert).
-
-## Datum
-2025-09-19
-
-## Autoren
-Team  Documentation System Plugin

package/docs/adr/003-documentation-generation-bugs.md

@@ -1,134 +0,0 @@
-# ADR-003: Kritische Probleme in der generierten Dokumentation
-
-**Status:** Implementiert  
-**Datum:** 2025-01-02  
-**Version:** 1.0.1
-
-## Problem
-
-Die automatisch generierte Dokumentation in `docs/modules/` enthielt systematische Fehler:
-
-### 1. Interface als Konstruktor dargestellt
-**Falsch:**
-```typescript
-DriftResult()  // ❌ Interface als Konstruktor
-```
-
-**Richtig:**
-```typescript
-interface DriftResult
-```
-
-### 2. Typen werden zu `{}` reduziert
-**Falsch:**
-```typescript
-computeCacheEntries(symbols: {}): {}  // ❌ Typen verloren
-```
-
-**Richtig:**
-```typescript
-computeCacheEntries(symbols: ParsedSymbol[]): CacheEntry[]
-```
-
-### 3. Nullable Parameter werden nicht erfasst
-**Falsch:**
-```typescript
-detectDrift(previous: SignatureCacheData, current: {}): DriftResult  // ❌ | null fehlt
-```
-
-**Richtig:**
-```typescript
-detectDrift(previous: SignatureCacheData | null, current: CacheEntry[]): DriftResult
-```
-
-## Ursache
-
-Der Generator in `src/generator/index.ts` behandelte alle Symbol-Typen gleich und rendert sie als Funktionen:
-
-```typescript
-// PROBLEMATISCH: Alle Symbole als Funktionen dargestellt
-out.push(`${s.signature.name}(${params})${ret}`);
-```
-
-## Lösung
-
-### 1. Symbol-typ-spezifische Darstellung
-```typescript
-switch (s.kind) {
-    case 'interface':
-        out.push(`interface ${s.signature.name}`);
-        break;
-    case 'class':
-        out.push(`class ${s.signature.name}`);
-        break;
-    case 'function':
-    case 'method':
-        const params = s.signature.parameters.map(p => 
-            `${p.name}${p.type ? `: ${p.type}` : ''}${p.hasDefault ? ' = …' : ''}`
-        ).join(', ');
-        const ret = s.signature.returnType ? `: ${s.signature.returnType}` : '';
-        out.push(`${s.signature.name}(${params})${ret}`);
-        break;
-    // ... weitere Fälle
-}
-```
-
-### 2. Parser-Verbesserung für Interfaces
-```typescript
-// Explizite returnType: undefined für Interfaces
-signature: { 
-    name, 
-    parameters: [],
-    returnType: undefined // Interfaces haben keinen Return-Type
-}
-```
-
-## Implementierte Änderungen
-
-1. **Generator repariert** (`src/generator/index.ts`):
-   - Symbol-typ-spezifische Darstellung implementiert
-   - Interface, Class, Type, Enum, Function, Method, Variable werden unterschiedlich dargestellt
-
-2. **Parser verbessert** (`src/parsers/ts-js.ts`):
-   - Explizite `returnType: undefined` für Interfaces
-   - Konsistente Signaturextraktion
-
-## Validierung
-
-**Vorher:**
-```typescript
-### interface: DriftResult
-DriftResult()  // ❌ Falsch
-
-### function: computeCacheEntries
-computeCacheEntries(symbols: {}): {}  // ❌ Falsch
-```
-
-**Nachher:**
-```typescript
-### interface: DriftResult
-interface DriftResult  // ✅ Korrekt
-
-### function: computeCacheEntries
-computeCacheEntries(symbols: ParsedSymbol[]): CacheEntry[]  // ✅ Korrekt
-```
-
-## Offene Probleme
-
-1. **Union-Types**: `SignatureCacheData | null` wird als `any` dargestellt
-2. **Generics**: `<T>` Parameter werden nicht erfasst
-3. **Optional Parameter**: `param?` wird nicht als optional markiert
-
-## Auswirkungen
-
-- **Dokumentationsqualität**: Signifikant verbessert
-- **Developer Experience**: Korrekte Signaturen für schnellen Einstieg
-- **Vertrauen**: Dokumentation ist jetzt zuverlässig
-
-## Nächste Schritte
-
-1. Union-Type-Parsing verbessern
-2. Generics-Support hinzufügen
-3. Optional-Parameter-Markierung implementieren
-4. Automatische Validierung gegen echten Code implementieren
-

package/docs/adr/004-validator-signature-matching-fix.md

@@ -1,121 +0,0 @@
-# ADR-004: Validator Signature-Matching Reparatur
-
-**Status:** Implementiert  
-**Datum:** 2025-01-02  
-**Version:** 1.0.1
-
-## Problem
-
-Der Validator in `src/validator/signature-matching.ts` hatte fundamentale Probleme:
-
-### 1. Interfaces wurden nicht validiert
-```typescript
-if (symbol.kind === 'variable' || symbol.kind === 'type') continue; // nur Funktionen/Methoden prüfen
-```
-**Problem**: Interfaces wurden übersprungen, obwohl sie falsche Signaturen hatten.
-
-### 2. formatSignatureForDoc behandelte alle Symbole als Funktionen
-```typescript
-function formatSignatureForDoc(symbol: ParsedSymbol): string {
-    const params = symbol.signature.parameters.map(p => 
-        `${p.name}${p.type ? `: ${p.type}` : ''}${p.hasDefault ? ' = …' : ''}`
-    ).join(', ');
-    const ret = symbol.signature.returnType ? `: ${symbol.signature.returnType}` : '';
-    return `${symbol.signature.name}(${params})${ret}`;
-}
-```
-**Problem**: Erzeugte `DriftResult()` für Interfaces statt `interface DriftResult`.
-
-### 3. Validator zeigte grün bei falscher Dokumentation
-**Problem**: Der Validator validierte nur Überschriften, nicht die Korrektheit der Signaturen.
-
-## Ursache
-
-Der Validator war nicht auf die verschiedenen Symbol-Typen (Interface, Class, Function) ausgelegt und verwendete eine einheitliche Funktionen-Darstellung für alle Typen.
-
-## Lösung
-
-### 1. Alle Symbol-Typen validieren
-```typescript
-for (const symbol of symbols) {
-    // Alle Symbol-Typen validieren, auch Interfaces und Types
-    // if (symbol.kind === 'variable' || symbol.kind === 'type') continue; // ENTFERNT: Alle Typen validieren
-```
-
-### 2. Symbol-typ-spezifische formatSignatureForDoc
-```typescript
-function formatSignatureForDoc(symbol: ParsedSymbol): string {
-    // Symbol-typ-spezifische Darstellung (wie im Generator)
-    switch (symbol.kind) {
-        case 'interface':
-            return `interface ${symbol.signature.name}`;
-        case 'class':
-            return `class ${symbol.signature.name}`;
-        case 'type':
-            return `type ${symbol.signature.name}`;
-        case 'enum':
-            return `enum ${symbol.signature.name}`;
-        case 'function':
-        case 'method':
-            const params = symbol.signature.parameters.map(p => 
-                `${p.name}${p.type ? `: ${p.type}` : ''}${p.hasDefault ? ' = …' : ''}`
-            ).join(', ');
-            const ret = symbol.signature.returnType ? `: ${symbol.signature.returnType}` : '';
-            return `${symbol.signature.name}(${params})${ret}`;
-        case 'variable':
-            const varType = symbol.signature.returnType ? `: ${symbol.signature.returnType}` : '';
-            return `${symbol.signature.name}${varType}`;
-        default:
-            return symbol.signature.name;
-    }
-}
-```
-
-## Implementierte Änderungen
-
-1. **Validator repariert** (`src/validator/signature-matching.ts`):
-   - Alle Symbol-Typen werden validiert
-   - Symbol-typ-spezifische Signature-Formatierung
-   - Korrekte Erwartungswerte für alle Typen
-
-2. **Dokumentation neu generiert**:
-   - Generator produziert korrekte Signaturen
-   - Validator erkennt keine Mismatches mehr
-
-## Validierung
-
-**Vorher:**
-- Validator: 93 Signature-Mismatches
-- Dokumentation: `DriftResult()` (falsch)
-- Status: Grün trotz falscher Dokumentation
-
-**Nachher:**
-- Validator: 0 Signature-Mismatches
-- Dokumentation: `interface DriftResult` (korrekt)
-- Status: Grün mit korrekter Dokumentation
-
-## Auswirkungen
-
-- **Dokumentationsqualität**: Signifikant verbessert
-- **Validator-Funktionalität**: Vollständig repariert
-- **Developer Experience**: Korrekte Signaturen für alle Symbol-Typen
-- **Vertrauen**: Dokumentation ist jetzt zuverlässig validiert
-
-## Architektur-Entscheidungen
-
-1. **Symbol-typ-spezifische Validierung**: Jeder Symbol-Typ wird entsprechend seinem semantischen Zweck validiert
-2. **Konsistenz mit Generator**: Validator verwendet dieselbe Logik wie der Generator
-3. **Vollständige Abdeckung**: Alle Symbol-Typen werden validiert, nicht nur Funktionen
-
-## Nächste Schritte
-
-1. MVP-Plan aktualisieren: Neue Validator-Funktionalität dokumentieren
-2. Tests erweitern: Validator-Tests für alle Symbol-Typen
-3. Performance optimieren: Validierung für große Codebases
-
-## Risiken & Gegenmaßnahmen
-
-- **Performance**: Vollständige Validierung könnte langsamer sein
-  - Gegenmaßnahme: Monitoring und Optimierung bei Bedarf
-- **Komplexität**: Mehr Code-Pfade im Validator
-  - Gegenmaßnahme: Umfassende Tests und Dokumentation

package/docs/adr/005-validator-generic-simplification-tightening.md

@@ -1,35 +0,0 @@
-# 005 – Validator-Verschärfung für Generics und Parser-Typableitung (v1.0.2)
-
-- Status: Accepted
-- Datum: 2025-10-02
-- Version: 1.0.2
-
-## Kontext
-Bei der Dokumentations-Generierung wurden Funktionssignaturen in Markdown teils mit `{}` statt konkreter Typen (z.B. `ModuleDependency[]`) dargestellt. Der Validator klassifizierte diese Abweichungen bislang als zulässige Vereinfachung (Generics-Simplification) und meldete daher „grün“, obwohl die Doku inhaltlich von der Quelle abwich.
-
-## Entscheidung
-1) Parser (TypeScript): Typableitung wurde angepasst, um zuerst `TypeNode` zu nutzen und nur bei Bedarf auf `getType()` zu fallen. Dadurch werden Arrays/Generics stabil (z.B. `ModuleDependency[]`) erkannt.
-2) Validator: Die Toleranzregel `isArchitecturallyValid` wurde verschärft. `{}` wird nicht mehr als zulässige Vereinfachung akzeptiert, wenn der erwartete Typ konkret ist (z.B. konkrete Namen oder `X[]`). Solche Fälle führen nun zu „Signatur-Abweichung“-Warnungen.
-
-## Änderungen
-- Datei `src/parsers/ts-js.ts`:
-  - Neue Hilfsroutine, die bevorzugt `getTypeNode()?.getText()` nutzt, Fallback auf `getType().getText()`.
-  - Anwendung für Parameter- und Rückgabetypen von Funktionen/Methoden und für Property-Typen.
-- Datei `src/validator/signature-matching.ts`:
-  - Logik in `isArchitecturallyValid` angepasst: `{}` wird für konkrete erwartete Typen nicht länger toleriert (nur echte Generics-Platzhalter bleiben zulässig).
-
-## Auswirkungen
-- Validierung: Abweichungen wie `{}` vs. `ModuleDependency[]` werden erkannt (mindestens GELB).
-- Determinismus/Qualität: Doku-Signaturen spiegeln Quellcode-Typen verlässlicher wider; Tests und Snapshots bleiben deterministisch.
-- Scope: Keine AI-/Kontext-Features berührt; reine Scan/Parse/Generate/Validate-Verbesserung im MVP-Scope.
-
-## Rollout
-- Bestandteil der Version 1.0.2 (`documentation-system-plugin-1.0.2.vsix`).
-- Nach Update: „Docs: Generate Documentation“ und „Docs: Validate Documentation“ ausführen.
-
-## Risiken
-- Strengere Validierung kann bestehende, vorher „grüne“ Doku als „gelb“ markieren. Das ist gewünscht und erhöht die Qualität.
-
-## Alternativen
-- Laissez-faire beibehalten: Abgelehnt, da inhaltliche Divergenzen unentdeckt bleiben.
-- Regex-Whitelist konkreter Typen: Zu fehleranfällig und wartungsintensiv.