mindnet_obsidian/docs/09_Chain_Inspector_Workbench_Umsetzungsplan.md

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