# Umsetzungsplan: Chain Inspector & Chain Workbench (Section-Type-Integration)

**Version:** 1.0  
**Datum:** 28. Januar 2026  
**Status:** Entwurf  
**Bezug:** 09_Chain_Inspector_Workbench_Lastenheft.md, 06_LH_WP26_Plugin_Integration.md (FA-PL-08), 10_Workbench_Findings_Integration.md, CHAIN_INSPECTOR_V0x_REPORTs

---

## 1. Übersicht

Dieser Umsetzungsplan beschreibt die **detaillierte Implementierungsreihenfolge** für:

1. **Section-Type-Integration** in Chain Inspector und Chain Workbench (FA-PL-08, Lastenheft 09).
2. **Offene Punkte** aus früheren Implementierungsplänen (Findings Integration, Chain Inspector Reports, Lastenheft „Nächste Schritte“).

Die Phasen bauen aufeinander auf; Abhängigkeiten sind explizit genannt.

---

## 2. Offene Punkte aus früheren Plänen (Konsolidiert)

### 2.1 Aus 10_Workbench_Findings_Integration.md

| Offener Punkt | Beschreibung | Integration in Umsetzungsplan |
|---------------|--------------|-------------------------------|
| **Findings → Todos** | Workbench nutzt aktuell nur Template-Matches, nicht Findings (dangling_target, no_causal_roles, etc.). | Phase 4: generateFindingsTodos, buildWorkbenchModel, UI. |
| **Todo-Typen** | DanglingTargetTodo, OnlyCandidatesTodo, NoCausalRolesTodo, MissingEdgesTodo, OneSidedConnectivityTodo. | Types bereits in workbench/types.ts; Generierung in Phase 4. |
| **Priorität Findings vs. Template** | Sollen Findings-Todos höhere Priorität haben? | Entscheidung: Section-Level Issues zuerst anzeigen (LH-CW-05). |
| **Duplikate** | Vermeidung von Duplikaten (z. B. dangling_target vs. missing_link). | Phase 4: Deduplizierung nach Kontext (file, heading, finding.code). |
| **Filterung** | Filter nach Severity (z. B. nur Errors). | Optional: Phase 5 oder später. |
| **Actions** | create_missing_note, retarget_link, promote_all_candidates, change_edge_type, etc. | Teilweise in Fix-Findings-Command (v0.3); no_causal_roles/missing_edges optional Phase 5. |

### 2.2 Aus CHAIN_INSPECTOR Reports (v0.4, v0.4.2)

| Offener Punkt | Beschreibung | Integration |
|---------------|--------------|-------------|
| **Top-K Limit** | Nur Top-1 Match pro Template (K=1). | Optional: K konfigurierbar (z. B. 3) – bereits maxTemplateMatches in Options. |
| **Node-Limit** | Max 30 Candidate-Nodes. | Unverändert; Sicherheit. |
| **slot_type_mismatch** | Finding nicht implementiert. | Optional: Phase 3 oder später; aktuell Matching verhindert Mismatches. |
| **Node-Type = Note-Type** | Template-Matching nutzt nur Frontmatter type. | Phase 1–2: effective_type (Section-Type \|\| Note-Type). |
| **Profile (discovery/decisioning)** | Bereits in v0.4.2. | Unverändert; Section-Type-Integration ergänzt. |

### 2.3 Aus 06_LH_WP26_Plugin_Integration.md (Nächste Schritte)

| Offener Punkt | Beschreibung | Integration |
|---------------|--------------|-------------|
| **Commands sichtbar** | Inspect Chains / Chain Workbench nur bei geöffneter MD-Datei. | Optional: Phase 5 – zusätzliche Commands ohne editorCallback mit Notice. |
| **Notice bei fehlenden Dictionaries** | Chain Roles/Templates nicht geladen → Notice + Abbruch. | Bereits umgesetzt in main.ts; in Lastenheft 09 verbindlich (LH-CI-07). |
| **FA-PL-08** | Chain Workbench mit Section-Types. | Phase 1–3: effective_type durchgängig. |

### 2.4 Aus WP26_Plugin_Interface_Specification.md

| Offener Punkt | Beschreibung | Integration |
|---------------|--------------|-------------|
| **Section-Type in Chain-Matching** | WorkbenchMatch.sectionTypes, MissingLinkTodo.fromSectionType/toSectionType. | Phase 2 (Template-Matching), Phase 4 (Todos). |
| **Intra-Note-Edge-Erkennung** | detectIntraNoteEdges für bessere Chain-Analyse. | Optional: Phase 3 oder später; abhängig von FA-PL-03/Graph-Index. |

---

## 3. Voraussetzungen (Vorbedingungen)

- **FA-PL-01 (Section-Type-Callout-Parsing):** `[!section]` muss im Section-Parser erkannt und als `sectionType` in `NoteSection` gespeichert werden.
  - **Aktueller Stand:** `NoteSection` in `sectionParser.ts` hat **kein** Feld `sectionType` bzw. `blockId`. Diese Erweiterung ist **Voraussetzung** für effective_type in Chain Inspector.
- **FA-PL-02 (Block-ID):** Optional für bessere Referenzierung; nicht zwingend für effective_type.
- **FA-PL-13 (Types-Loader):** Optional für Validierung von Section-Types.

Ohne FA-PL-01 (Section-Parser mit sectionType) kann Phase 1 nur mit **Note-Type** (bisherig) arbeiten; effective_type wird dann erst nach Implementierung von FA-PL-01 wirksam.

---

## 4. Phase 1: Section-Parser und effective_type-Grundlage

**Ziel:** Section-Type in der Codebasis verfügbar machen und in Template-Matching als effective_type nutzen.

### 4.1 Tasks

| Nr | Task | Beschreibung | Dateien | Abhängigkeit |
|----|------|--------------|---------|---------------|
| 1.1 | **NoteSection um sectionType und blockId erweitern** | Interface `NoteSection` um `sectionType: string \| null` und `blockId: string \| null` erweitern; in `splitIntoSections` befüllen. | `src/mapping/sectionParser.ts` | – |
| 1.2 | **Parsing von [!section] Callout** | In `splitIntoSections` pro Section nach Zeile mit `> [!section] <type>` suchen (Regex z. B. `/^\s*>\s*\[!section\]\s*(\w+)/i`), Typ extrahieren und in `sectionType` speichern. | `src/mapping/sectionParser.ts` | 1.1 |
| 1.3 | **Parsing von Block-ID in Headings** | In Headings Muster `^#{1,6}\s+.+\s+\^([a-zA-Z0-9_-]+)$` erkennen, Block-ID in `blockId` speichern. | `src/mapping/sectionParser.ts` | 1.1 |
| 1.4 | **Graph-Index: Sections mit sectionType bereitstellen** | `buildNoteIndex` oder eine neue Hilfsfunktion muss Sections inkl. sectionType an Aufrufer liefern (z. B. als Map `file:heading → sectionType` oder erweiterte SectionNode-Struktur). | `src/analysis/graphIndex.ts`, ggf. `chainInspector.ts` | 1.2 |
| 1.5 | **effective_type-Funktion** | Hilfsfunktion `getEffectiveType(file, heading, sectionsWithType, noteTypeByFile): string` – liefert sectionType für (file, heading) falls vorhanden, sonst noteType, sonst "unknown". | `src/analysis/templateMatching.ts` oder neues Modul | 1.4 |

**Ergebnis Phase 1:** Section-Parser liefert sectionType; effective_type ist pro (file, heading) berechenbar.

---

## 5. Phase 2: Chain Inspector – effective_type im Template-Matching

**Ziel:** Template-Matching und Findings nutzen effective_type statt nur noteType.

### 5.1 Tasks

| Nr | Task | Beschreibung | Dateien | Abhängigkeit |
|----|------|--------------|---------|---------------|
| 2.1 | **CandidateNode um effectiveType erweitern** | Interface `CandidateNode` um `effectiveType: string` erweitern (oder `noteType` durch effective_type ersetzen, falls Abwärtskompatibilität gewahrt wird: zusätzliches Feld). | `src/analysis/templateMatching.ts` | Phase 1 |
| 2.2 | **buildCandidateNodes: effective_type setzen** | Beim Aufbau der Candidate-Nodes für jeden Knoten (file, heading) effective_type ermitteln: Section-Type aus geparsten Sections (file muss gelesen, in Sections zerlegt werden; sectionType für passende Section verwenden), sonst noteType aus Frontmatter. | `src/analysis/templateMatching.ts` | 1.5, 2.1 |
| 2.3 | **nodeMatchesSlot mit effectiveType** | Slot-Constraint `allowed_node_types` gegen `node.effectiveType` prüfen (bereits konzeptionell; sicherstellen, dass das genutzte Feld effectiveType ist). | `src/analysis/templateMatching.ts` | 2.2 |
| 2.4 | **TemplateMatch / Report: typeSource optional** | In SlotAssignments optional `typeSource?: "section" \| "note" \| "unknown"` pro Slot für Provenance. | `src/analysis/chainInspector.ts`, `templateMatching.ts` | 2.2 |
| 2.5 | **Gap-Detection: fehlender Section-Type** | Wenn Slot z. B. "experience" erwartet, aber effective_type "unknown" oder nicht in allowed_node_types: Finding oder Todo-Vorschlag „Add Section Type“ / „Set section type to experience“. | `src/analysis/chainInspector.ts`, ggf. `todoGenerator.ts` | 2.3 |

**Ergebnis Phase 2:** Chain Inspector verwendet effective_type durchgängig; Gap-Detection kann fehlende Section-Types melden.

---

## 6. Phase 3: Chain Workbench – Section-Type in Model und Todos

**Ziel:** Workbench-Model und Todo-Typen enthalten Section-Type-Information; Edge-Vorschläge können section-type-basiert erfolgen.

### 6.1 Tasks

| Nr | Task | Beschreibung | Dateien | Abhängigkeit |
|----|------|--------------|---------|---------------|
| 3.1 | **WorkbenchMatch: sectionTypes / effectiveType pro Slot** | WorkbenchMatch (oder TemplateMatch) um optionale Map Slot-ID → effective_type erweitern; beim Aufbau aus TemplateMatch befüllen. | `src/workbench/types.ts`, `workbenchBuilder.ts` | Phase 2 |
| 3.2 | **MissingLinkTodo / MissingSlotTodo: fromSectionType, toSectionType** | Todos um optionale Felder `fromSectionType`, `toSectionType` (bzw. effective_type) erweitern; in todoGenerator aus SlotAssignments/effective_type füllen. | `src/workbench/types.ts`, `todoGenerator.ts` | 2.4, 3.1 |
| 3.3 | **Edge-Type-Vorschläge aus graph_schema** | Wenn fromSectionType und toSectionType vorhanden: `getTopologyInfo(sourceType, targetType)` aus Schema aufrufen und suggestedEdgeTypes daraus ableiten. | `src/workbench/todoGenerator.ts`, `schemaHelper.ts` | 3.2 |
| 3.4 | **Section-Type-Todo „Add Section Type“** | Neuer Todo-Typ oder Erweiterung: Vorschlag „Add Section Type: experience“ bei Gap (vgl. LH-CW-06). | `src/workbench/todoGenerator.ts`, `types.ts` | 2.5, 3.1 |

**Ergebnis Phase 3:** Workbench zeigt Section-Type-Information in Matches und Todos; Edge-Vorschläge nutzen Section-Types wo vorhanden.

---

## 7. Phase 4: Findings-Integration (Workbench Findings Integration)

**Ziel:** Findings aus Chain Inspector werden in Workbench als globalTodos angezeigt; keine Duplikate mit Template-Todos.

### 7.1 Tasks

| Nr | Task | Beschreibung | Dateien | Abhängigkeit |
|----|------|--------------|---------|---------------|
| 4.1 | **generateFindingsTodos implementieren** | Funktion wie in 10_Workbench_Findings_Integration.md: Findings (dangling_target, dangling_target_heading, only_candidates, missing_edges, no_causal_roles, one_sided_connectivity) in WorkbenchTodoUnion übersetzen. | `src/workbench/todoGenerator.ts` | – |
| 4.2 | **buildWorkbenchModel: globalTodos** | Nach Verarbeitung der Template-Matches: `report.findings` an generateFindingsTodos übergeben; Ergebnis in `model.globalTodos` speichern. | `src/workbench/workbenchBuilder.ts` | 4.1 |
| 4.3 | **WorkbenchModel.globalTodos** | Interface `WorkbenchModel` um `globalTodos?: WorkbenchTodoUnion[]` erweitern (falls noch nicht vorhanden). | `src/workbench/types.ts` | 4.2 |
| 4.4 | **Deduplizierung** | Wenn ein Finding und ein Template-Todo dasselbe Problem beschreiben (z. B. dangling_target vs. missing_link für dieselbe Datei/Section): nur eines anzeigen (z. B. Findings-Todo priorisieren oder Template-Todo). | `src/workbench/workbenchBuilder.ts` | 4.2 |
| 4.5 | **ChainWorkbenchModal: Section-Level Issues** | UI: Abschnitt „Section-Level Issues“ (oder „Findings“) mit globalTodos oberhalb der Template-Matches rendern. | `src/workbench/ChainWorkbenchModal.ts` (bzw. wo das Modal lebt) | 4.3 |
| 4.6 | **Findings mit effective_type** | Optional: In generateFindingsTodos Kontext (file, heading) nutzen und effective_type in Todo-Beschreibung oder -Metadaten aufnehmen. | `src/workbench/todoGenerator.ts` | Phase 2 |

**Ergebnis Phase 4:** Workbench zeigt Section-Level Issues aus Findings; Konsistenz mit Chain Inspector; klare Trennung Findings vs. Template-Matches.

---

## 8. Phase 5: UX, Commands, Optionale Erweiterungen

**Ziel:** Sichtbarkeit der Commands, optionale Filter/Actions, Dokumentation.

### 8.1 Tasks

| Nr | Task | Beschreibung | Dateien | Abhängigkeit |
|----|------|--------------|---------|---------------|
| 5.1 | **Commands ohne Editor (optional)** | Zusätzliche Commands „Mindnet: Inspect Chains“ / „Mindnet: Chain Workbench“ ohne editorCallback; bei Aufruf ohne geöffnete MD-Datei: Notice „Bitte zuerst eine Markdown-Datei öffnen.“ (FA-PL-12a). | `src/main.ts` | – |
| 5.2 | **Notice bei fehlenden Dictionaries (Bestätigung)** | Sicherstellen, dass Inspect Chains und Chain Workbench bei fehlenden chain_roles/chain_templates mit Notice abbrechen (bereits in main.ts; nur prüfen). | `src/main.ts` | – |
| 5.3 | **Benutzerhandbuch** | Kurzabschnitt: „Inspect Chains“ und „Chain Workbench“ sind nur bei geöffneter Markdown-Datei in der Befehlspalette verfügbar; bei fehlenden Dictionary-Dateien erscheint ein Hinweis. | docs (z. B. 01_Benutzerhandbuch.md) | – |
| 5.4 | **Filter nach Severity (optional)** | Im Workbench Modal Filter „Nur Errors“ / „Errors und Warnings“ für globalTodos. | `src/workbench/ChainWorkbenchModal.ts` | 4.5 |
| 5.5 | **Actions für no_causal_roles / missing_edges (optional)** | Fix-Actions „Edge-Type ändern“ für no_causal_roles, „Add edges to section“ für missing_edges (vgl. 10_Workbench_Findings_Integration.md Phase 5). | `src/commands/fixFindingsCommand.ts`, Workbench UI | 4.1 |
| 5.6 | **slot_type_mismatch Finding (optional)** | Falls gewünscht: Finding ausgeben, wenn zugewiesener Node effective_type hat, der nicht in allowed_node_types liegt (aktuell verhindert Matching das). | `src/analysis/chainInspector.ts` oder templateMatching | Phase 2 |
| 5.7 | **Intra-Note-Edges in Chain-Analyse (optional)** | detectIntraNoteEdges nutzen, um Chains innerhalb einer Note zu erkennen (WP26-Spec). | `src/analysis/chainInspector.ts`, graphIndex | FA-PL-03 |

**Ergebnis Phase 5:** Bessere Auffindbarkeit der Commands, dokumentiertes Verhalten, optionale Erweiterungen umsetzbar.

---

## 9. Abhängigkeitsgraph (Kurz)

```
Phase 1 (Section-Parser, effective_type-Grundlage)
  → Phase 2 (Chain Inspector effective_type)
  → Phase 3 (Workbench Model/Todos Section-Type)
  → Phase 4 (Findings → globalTodos)  [4.1–4.3 unabhängig von Phase 2/3; 4.4–4.6 nutzen Kontext]
  → Phase 5 (UX, Commands, Optionen)
```

- **Phase 4.1–4.3** können parallel zu Phase 1–2 begonnen werden (Findings → Todos ohne Section-Type).
- **Phase 4.4–4.6** (Deduplizierung, UI, effective_type in Findings) profitieren von Phase 2/3.

---

## 10. Test- und Abnahmepunkte

- **Phase 1:** Unit-Tests sectionParser (sectionType, blockId); Integration: buildNoteIndex liefert sectionType-Info.
- **Phase 2:** Unit-Tests templateMatching (nodeMatchesSlot mit effectiveType); Integration: Inspect Chains Report mit effective_type in SlotAssignments.
- **Phase 3:** Workbench zeigt fromSectionType/toSectionType in Todos; Edge-Vorschläge aus Schema.
- **Phase 4:** Workbench zeigt globalTodos aus Findings; keine Doppelung mit Template-Todos; UI „Section-Level Issues“.
- **Phase 5:** Commands ohne Editor zeigen Notice; Doku aktualisiert.

---

## 11. Referenzen

- **09_Chain_Inspector_Workbench_Lastenheft.md** – Alle Anforderungen (LH-CI-xx, LH-CW-xx).
- **06_LH_WP26_Plugin_Integration.md** – FA-PL-01, FA-PL-08, FA-PL-12a.
- **10_Workbench_Findings_Integration.md** – generateFindingsTodos, Todo-Typen, Phasen.
- **CHAIN_INSPECTOR_V04_REPORT.md**, **CHAIN_INSPECTOR_V042_REPORT.md** – Template Matching, Profiles.
- **WP26_Plugin_Interface_Specification.md** – Section-Type in Chain Workbench.

---

**Ende des Umsetzungsplans**