# LASTENHEFT: WP-26 Integration im Obsidian Plugin

**Version:** 1.0  
**Datum:** 25. Januar 2026  
**Status:** Entwurf zur Review  
**Projekt:** mindnet_obsidian (Obsidian Community Plugin)  
**Basis:** Backend WP-26 v1.3 (Section Types & Intra-Note-Edges)

---

## 1. Einleitung

### 1.1 Zweck des Dokuments

Dieses Lastenheft definiert die vollständigen Anforderungen für die Integration der WP-26 Features (Section Types & Intra-Note-Edges) in das bestehende mindnet_obsidian Plugin. Es beschreibt alle notwendigen Anpassungen, Erweiterungen und neuen Funktionen, die erforderlich sind, um die Backend-Funktionalität nahtlos in die Plugin-Benutzeroberfläche zu integrieren.

### 1.2 Geltungsbereich

- **Plugin:** mindnet_obsidian (`c:\Dev\cursor\mindnet_obsidian`)
- **Backend-Contract:** WP-26 Lastenheft v1.3 (Section Types & Intra-Note-Edges)
- **Kompatibilität:** Alle bestehenden Funktionen müssen weiterhin funktionieren
- **Integration:** Nahtlose Einbindung ohne Breaking Changes

### 1.3 Grundprinzipien

1. **Vollständige Abwärtskompatibilität:** Bestehende Notes und Funktionen funktionieren unverändert
2. **Nahtlose Integration:** Neue Features fügen sich natürlich in bestehende Workflows ein
3. **Keine Deaktivierungen:** Keine Funktionen werden eigenmächtig deaktiviert oder signifikant geändert
4. **Konsistente UX:** Neue UI-Elemente folgen bestehenden Design-Patterns
5. **Backend-Konformität:** Alle generierten Markdown-Formate entsprechen der Backend-Spezifikation

### 1.4 Definitionen

| Begriff | Definition |
|---------|------------|
| **Section-Type** | Explizit per `[!section]` Callout definierter Typ für einen Abschnitt |
| **Block-ID** | Obsidian Block-Reference Format `^block-id` in Überschriften |
| **Intra-Note-Edge** | Semantische Kante zwischen Chunks derselben Note (`is_internal: true`) |
| **Effective Type** | Für Scoring verwendeter Typ: `section_type` falls vorhanden, sonst `note_type` |
| **Retroaktive Propagation** | Section-Type gilt ab der vorhergehenden Überschrift, auch wenn Callout später steht |

---

## 2. Analyse der bestehenden Plugin-Struktur

### 2.1 Betroffene Module

#### 2.1.1 Parser (`src/parser/`)

**Aktuelle Funktionen:**
- `parseEdgesFromCallouts.ts`: Extrahiert `[!edge]` Callouts und Targets
- `parseRelLinks.ts`: Extrahiert `[[rel:type|target]]` Links
- `parseFrontmatter.ts`: Extrahiert Frontmatter-Metadaten

**WP-26 Relevanz:**
- Muss `[!section]` Callouts erkennen
- Muss Block-IDs aus Überschriften extrahieren
- Muss Intra-Note-Links (`[[#^block-id]]`) identifizieren

#### 2.1.2 Mapping (`src/mapping/`)

**Aktuelle Funktionen:**
- `sectionParser.ts`: Splittet Markdown in Sections (nach Headings)
- `semanticMappingBuilder.ts`: Erstellt Semantic Mapping Blöcke
- `edgeTypeSelector.ts`: Vorschläge für Edge-Types basierend auf Kontext
- `graphSchema.ts`: Lädt und parst `graph_schema.md`
- `schemaHelper.ts`: Hilfsfunktionen für Schema-Lookups

**WP-26 Relevanz:**
- Section-Parser muss `[!section]` Callouts und Block-IDs erkennen
- Edge-Type-Selector muss Section-Types berücksichtigen
- Schema-Helper muss Section-Type-basierte Vorschläge liefern

#### 2.1.3 Interview (`src/interview/`)

**Aktuelle Funktionen:**
- `renderer.ts`: Rendert Interview-Antworten zu Markdown
- `wizardState.ts`: Verwaltet Wizard-State
- `types.ts`: TypeScript-Interfaces für Interview-Konfiguration
- `sectionKeyResolver.ts`: Löst Section-Keys auf

**WP-26 Relevanz:**
- Renderer muss `[!section]` Callouts generieren können
- Wizard-State muss Section-Types unterstützen
- Section-Key-Resolver muss Block-IDs berücksichtigen

#### 2.1.4 Chain Workbench (`src/workbench/`)

**Aktuelle Funktionen:**
- `todoGenerator.ts`: Generiert TODOs basierend auf Chain-Templates
- `chainInspector.ts`: Analysiert Chains und findet Gaps
- `types.ts`: TypeScript-Interfaces für Workbench

**WP-26 Relevanz:**
- Chain-Matching muss Section-Types berücksichtigen
- Gap-Detection muss Intra-Note-Edges erkennen
- Template-Matching muss effective types verwenden

#### 2.1.5 UI (`src/ui/`)

**Aktuelle Funktionen:**
- `EdgeTypeChooserModal.ts`: Modal zur Edge-Type-Auswahl
- `InlineEdgeTypeModal.ts`: Inline-Edge-Type-Suggester
- `LinkPromptModal.ts`: Modal für Link-Erstellung
- `InterviewWizardModal.ts`: Interview-Wizard-UI

**WP-26 Relevanz:**
- Edge-Type-Chooser muss Section-Type-basierte Vorschläge zeigen
- Link-Prompt muss Block-ID-Generierung unterstützen
- Interview-Wizard muss Section-Type-Auswahl ermöglichen

#### 2.1.6 Lint (`src/lint/`)

**Aktuelle Funktionen:**
- `LintEngine.ts`: Haupt-Lint-Engine
- `rules/`: Verschiedene Lint-Regeln

**WP-26 Relevanz:**
- Neue Lint-Regeln für Section-Types
- Validierung von Block-IDs
- Validierung von Intra-Note-Edges

#### 2.1.7 Schema (`src/schema/`)

**Aktuelle Funktionen:**
- `GraphSchemaLoader.ts`: Lädt `graph_schema.md`

**WP-26 Relevanz:**
- Muss erweitert werden für Section-Type-Lookups
- Muss "prohibited" Edges unterstützen (Phase 3)

---

## 3. Funktionale Anforderungen

### 3.1 Phase 1: Grundlagen (Kern-Parsing)

#### FA-PL-01: Section-Type-Callout-Parsing

**Anforderung:** Das Plugin muss `[!section]` Callouts erkennen und parsen.

**Betroffene Dateien:**
- `src/parser/parseEdgesFromCallouts.ts` (erweitern)
- `src/mapping/sectionParser.ts` (erweitern)

**Implementierung:**
1. Neues Regex-Pattern für `[!section]` Callouts: `/^\s*>\s*\[!section\]\s*(\w+)/i`
2. Section-Parser erkennt Callouts innerhalb von Sections
3. Extrahiert Section-Type (muss in `types.yaml` validiert werden)
4. Speichert Section-Type in `NoteSection` Interface

**Interface-Erweiterung:**
```typescript
export interface NoteSection {
  // ... bestehende Felder ...
  sectionType: string | null;  // NEU: Section-Type aus [!section] Callout
  blockId: string | null;      // NEU: Block-ID aus Heading (^block-id)
}
```

**Validierung:**
- Section-Type muss in `types.yaml` existieren (Warnung bei unbekanntem Typ)
- Case-insensitive Matching für Callout-Header

**Kompatibilität:**
- Bestehende Notes ohne `[!section]` Callouts funktionieren unverändert
- `sectionType` ist optional (`null` = Fallback auf `note_type`)

---

#### FA-PL-02: Block-ID-Extraktion

**Anforderung:** Das Plugin muss Block-IDs aus Überschriften extrahieren.

**Betroffene Dateien:**
- `src/mapping/sectionParser.ts` (erweitern)

**Implementierung:**
1. Regex-Pattern für Block-IDs in Headings: `/^#{1,6}\s+.+\s+\^([a-zA-Z0-9_-]+)$/`
2. Extrahiert Block-ID aus Heading-Text (z.B. `## Überschrift ^block-id`)
3. Speichert Block-ID in `NoteSection.blockId`

**Beispiele:**
```markdown
## Situation ^sit          → blockId: "sit"
## Reflexion ^ref          → blockId: "ref"
## Überschrift ohne ID     → blockId: null
```

**Kompatibilität:**
- Bestehende Headings ohne Block-IDs funktionieren unverändert
- Block-ID ist optional

---

#### FA-PL-03: Intra-Note-Link-Erkennung

**Anforderung:** Das Plugin muss Intra-Note-Links (`[[#^block-id]]`) erkennen.

**Betroffene Dateien:**
- `src/parser/parseEdgesFromCallouts.ts` (erweitern)
- `src/mapping/sectionParser.ts` (erweitern)

**Implementierung:**
1. Erweitert Wikilink-Parsing um Block-Reference-Format
2. Erkennt `[[#^block-id]]` als Intra-Note-Link
3. Markiert solche Links als `isInternal: true` in ParsedEdge

**Interface-Erweiterung:**
```typescript
export interface ParsedEdge {
  // ... bestehende Felder ...
  isInternal: boolean;  // NEU: true für [[#^block-id]] Links
  blockId: string | null;  // NEU: Block-ID aus [[#^block-id]]
}
```

**Kompatibilität:**
- Bestehende Inter-Note-Links funktionieren unverändert
- Intra-Note-Links werden zusätzlich erkannt

---

### 3.2 Phase 2: UI-Komponenten

#### FA-PL-04: Section-Type-Modal

**Anforderung:** Neues Modal zur Auswahl und Einfügung von Section-Types.

**Neue Datei:**
- `src/ui/SectionTypeModal.ts`

**Funktionalität:**
1. Zeigt verfügbare Section-Types aus `types.yaml`
2. Erlaubt Auswahl eines Section-Types
3. Fügt `[!section]` Callout an aktueller Cursor-Position ein
4. Unterstützt Block-ID-Generierung für Heading

**UI-Flow:**
1. Command: "Mindnet: Add Section Type"
2. Modal öffnet mit Liste verfügbarer Types
3. Benutzer wählt Type
4. Callout wird eingefügt: `> [!section] <type>` **direkt nach der Heading-Zeile**
5. Optional: Block-ID wird automatisch generiert für vorhergehende Heading

**Formatierungsregel:** `[!section]` Callout wird immer direkt nach der Heading-Zeile eingefügt (vor dem Section-Content)

**Kompatibilität:**
- Bestehende Commands bleiben unverändert
- Neues Command ist optional

---

#### FA-PL-05: Edge-Type-Chooser mit Section-Type-Support

**Anforderung:** Edge-Type-Chooser muss Section-Types berücksichtigen.

**Betroffene Dateien:**
- `src/ui/EdgeTypeChooserModal.ts` (erweitern)
- `src/mapping/schemaHelper.ts` (erweitern)

**Implementierung:**
1. Edge-Type-Chooser erhält `sourceSectionType` und `targetSectionType` Parameter
2. Schema-Helper nutzt Section-Types für Vorschläge (falls vorhanden)
3. Fallback auf `note_type` wenn Section-Type nicht vorhanden
4. Zeigt "Recommended (section types)" Sektion wenn Section-Types vorhanden

**Priorisierung:**
1. Suggested (from chain_roles) - unverändert
2. Recommended (section types) - NEU
3. Recommended (schema) - erweitert um Section-Types
4. All edge types - unverändert

**Kompatibilität:**
- Bestehende Funktionalität bleibt unverändert
- Section-Types werden zusätzlich berücksichtigt

---

#### FA-PL-06: Link-Prompt mit Block-ID-Generierung

**Anforderung:** Link-Prompt muss Block-ID-Generierung unterstützen.

**Betroffene Dateien:**
- `src/ui/LinkPromptModal.ts` (erweitern)

**Implementierung:**
1. Erkennt, wenn Link zu Section in aktueller Note erstellt wird
2. Fragt Benutzer, ob Block-ID generiert werden soll
3. Generiert eindeutige Block-ID basierend auf Heading-Text
4. Fügt Block-ID zu Heading hinzu: `## Heading ^generated-id`

**Beispiel:**
- Benutzer erstellt Link: `[[#Situation]]`
- Plugin erkennt: Intra-Note-Link
- Plugin fragt: "Block-ID 'situation' zu Heading hinzufügen?"
- Bei Bestätigung: Heading wird zu `## Situation ^situation`

**Kompatibilität:**
- Bestehende Link-Erstellung funktioniert unverändert
- Block-ID-Generierung ist optional

---

### 3.3 Phase 3: Feature-Integration

#### FA-PL-07: Interview-Wizard mit Section-Types, Block-IDs und automatischen Edge-Vorschlägen

**Anforderung:** Interview-Wizard muss Section-Types, Block-IDs und automatische Edge-Vorschläge zwischen Sections unterstützen.

**Betroffene Dateien:**
- `src/interview/renderer.ts` (erweitern)
- `src/interview/types.ts` (erweitern)
- `src/ui/InterviewWizardModal.ts` (erweitern)

**Implementierung:**

1. **Section-Types:**
   - Interview-Config erlaubt `section_type` in Steps
   - Renderer generiert `[!section]` Callouts für Steps mit Section-Type
   - Wizard-State speichert Section-Type pro Step

2. **Block-IDs:**
   - Interview-Config erlaubt `block_id` (explizit) oder `generate_block_id: true` (automatisch)
   - Automatische Generierung: Slugify des Step-Keys oder Heading-Texts
   - Wizard-State trackt alle generierten Block-IDs (`generatedBlockIds` Map)
   - Renderer fügt Block-ID zu Heading hinzu: `## Heading ^block-id`

3. **Referenzen zu vorherigen Sections:**
   - Interview-Config erlaubt `references` Array in Steps
   - Jede Reference enthält `block_id` und optional `edge_type`
   - Renderer generiert `[!edge]` Callouts mit Block-References: `[[#^block-id]]`
   - Referenzen werden beim Rendern des aktuellen Steps eingefügt

4. **Automatische Edge-Vorschläge zwischen Sections:**
   - Wizard-State trackt Section-Sequenz (`sectionSequence` Array)
   - Für jede neue Section: Automatische Edge-Vorschläge zu vorherigen Sections
   - Edge-Types werden aus `graph_schema.md` ermittelt (falls verfügbar)
   - Fallback: `related_to` wenn kein Schema-Match gefunden wird
   - Rückwärts-Edges werden automatisch vorgeschlagen (inverser Edge-Type via `edge_vocabulary.md`)

**Config-Erweiterung:**
```yaml
profiles:
  - key: experience_profile
    note_type: experience
    steps:
      - type: capture_text
        key: context
        section: "## Kontext"
        section_type: experience
        generate_block_id: true  # Generiert automatisch "context"
      
      - type: capture_text
        key: situation
        section: "## Situation"
        section_type: experience
        block_id: "sit"  # Explizite Block-ID
        references:
          - block_id: "context"
            edge_type: "derived_from"  # Optional: Vorgeschlagener Edge-Type
      
      - type: capture_text
        key: reflection
        section: "## Reflexion"
        section_type: insight
        generate_block_id: true  # Generiert automatisch "reflection"
        # Automatischer Edge-Vorschlag wird generiert: insight -> experience (invers zu resulted_in)
```

**Renderer-Logik:**

1. **Block-ID-Generierung:**
   - Wenn `block_id` explizit: Verwende diesen Wert
   - Wenn `generate_block_id: true`: Generiere aus Step-Key (slugify)
   - Wenn beides fehlt: Keine Block-ID

2. **Section-Type-Generierung:**
   - Wenn `section_type` vorhanden: Generiere `> [!section] <type>` **direkt nach der Heading-Zeile**
   - Wenn Block-ID vorhanden: Heading wird zu `## Heading ^block-id`
   - **Formatierungsregel:** `[!section]` Callout steht immer unmittelbar nach der Überschrift, vor dem Section-Content

3. **Referenz-Generierung:**
   - Für jede Reference in `references` Array:
     - Generiere `> [!edge] <edge_type>` (oder `related_to` wenn nicht angegeben)
     - Generiere `[[#^block-id]]` Link
   - **Formatierungsregel:** Edges werden **am Ende der Sektion** eingefügt (nach dem Section-Content, wie bisher)

4. **Automatische Edge-Vorschläge:**
   - Für jede neue Section (ab der zweiten):
     - Ermittle `effective_type` der aktuellen Section (Section-Type oder Note-Type)
     - Für jede vorherige Section in Sequenz:
       - Ermittle `effective_type` der vorherigen Section
       - Lookup in `graph_schema.md`: `getTopologyInfo(prevType, currentType)`
       - Wenn Match gefunden: Generiere Forward-Edge mit typischem Edge-Type
       - Generiere automatisch Rückwärts-Edge mit inversem Edge-Type (via `edge_vocabulary.md`)
   - Automatische Edges werden nur generiert, wenn beide Sections Block-IDs haben
   - **Formatierungsregel:** Automatische Edges werden **am Ende der Sektion** eingefügt (nach dem Section-Content)

**Generierte Ausgabe (Beispiel):**
```markdown
## Kontext ^context
> [!section] experience

[Antwort aus Step "context"]

> [!edge] derived_from
> [[#^context]]

## Situation ^sit
> [!section] experience

[Antwort aus Step "situation"]

> [!edge] resulted_in
> [[#^sit]]
> [!edge] caused_by
> [[#^context]]

## Reflexion ^reflection
> [!section] insight

[Antwort aus Step "reflection"]

> [!edge] resulted_in
> [[#^sit]]
> [!edge] caused_by
> [[#^context]]
```

**Formatierungsregeln:**
1. `> [!section] <type>` steht **immer direkt nach der Heading-Zeile** (vor dem Section-Content)
2. `> [!edge]` Callouts stehen **immer am Ende der Sektion** (nach dem Section-Content, wie bisher)
3. Leerzeile zwischen Heading und `[!section]` Callout ist optional (kann weggelassen werden)
4. Leerzeile zwischen Section-Content und Edges ist optional (kann weggelassen werden)

**Wizard-State-Erweiterung:**
```typescript
export interface WizardState {
  // ... bestehende Felder ...
  generatedBlockIds: Map<string, {  // NEU: Track aller generierten Block-IDs
    stepKey: string;
    sectionType: string | null;
    heading: string;
  }>;
  sectionSequence: Array<{  // NEU: Sequenz aller Sections für Edge-Vorschläge
    stepKey: string;
    blockId: string | null;
    sectionType: string | null;
    noteType: string;  // Fallback für effective_type
  }>;
}
```

**Kompatibilität:**
- Bestehende Interview-Configs ohne neue Felder funktionieren unverändert
- Alle neuen Felder sind optional
- Block-ID-Generierung ist standardmäßig deaktiviert (muss explizit aktiviert werden)
- Automatische Edge-Vorschläge werden nur generiert, wenn beide Sections Block-IDs haben

---

#### FA-PL-08: Chain Workbench mit Section-Types

**Anforderung:** Chain Workbench muss Section-Types für Chain-Matching verwenden.

**Betroffene Dateien:**
- `src/workbench/chainInspector.ts` (erweitern)
- `src/workbench/todoGenerator.ts` (erweitern)
- `src/workbench/types.ts` (erweitern)

**Implementierung:**
1. Chain Inspector verwendet `effective_type` (Section-Type oder Note-Type)
2. Template-Matching berücksichtigt Section-Types
3. Gap-Detection erkennt fehlende Section-Types
4. TODO-Generator schlägt Section-Types vor

**Logik:**
- Für jeden Chunk: `effectiveType = sectionType || noteType`
- Template-Matching: `template.slot.type === effectiveType`
- Gap-Detection: Wenn Template `experience` Slot erwartet, aber Section hat `insight` → Gap

**Kompatibilität:**
- Bestehende Chain-Analysen funktionieren unverändert
- Section-Types werden zusätzlich berücksichtigt

---

#### FA-PL-09: Semantic Mapping mit Section-Types

**Anforderung:** Semantic Mapping Builder muss Section-Types berücksichtigen.

**Betroffene Dateien:**
- `src/mapping/semanticMappingBuilder.ts` (erweitern)
- `src/mapping/edgeTypeSelector.ts` (erweitern)

**Implementierung:**
1. Mapping Builder erkennt Section-Types in Sections
2. Edge-Type-Selector verwendet Section-Types für Vorschläge
3. Automatische Edge-Generierung berücksichtigt Section-Types

**Logik:**
- Für jede Section: Ermittle `effectiveType`
- Für Links zwischen Sections: Verwende `effectiveType` für Edge-Type-Vorschläge
- Schema-Lookup: `getTopologyInfo(sourceSectionType, targetSectionType)`

**Kompatibilität:**
- Bestehende Semantic Mappings funktionieren unverändert
- Section-Types werden zusätzlich berücksichtigt

---

### 3.4 Phase 4: Validierung & Linting

#### FA-PL-10: Lint-Regeln für Section-Types

**Anforderung:** Neue Lint-Regeln für Section-Types.

**Neue Datei:**
- `src/lint/rules/rule_section_type.ts`

**Regeln:**
1. **Section-Type-Validität:** Section-Type muss in `types.yaml` existieren
2. **Block-ID-Eindeutigkeit:** Block-IDs müssen innerhalb einer Note eindeutig sein
3. **Intra-Note-Edge-Validität:** Intra-Note-Edges müssen gegen `graph_schema.md` validiert werden

**Implementierung:**
```typescript
export interface SectionTypeLintRule {
  checkSectionType(section: NoteSection, types: string[]): LintFinding[];
  checkBlockIdUniqueness(sections: NoteSection[]): LintFinding[];
  checkIntraNoteEdge(edge: ParsedEdge, schema: GraphSchema): LintFinding[];
}
```

**Kompatibilität:**
- Bestehende Lint-Regeln bleiben unverändert
- Neue Regeln sind optional (können deaktiviert werden)

---

#### FA-PL-11: Schema-Validierung für Intra-Note-Edges

**Anforderung:** Validierung von Intra-Note-Edges gegen `graph_schema.md`.

**Betroffene Dateien:**
- `src/schema/GraphSchemaLoader.ts` (erweitern)
- `src/mapping/schemaHelper.ts` (erweitern)

**Implementierung:**
1. Schema-Loader lädt "prohibited" Edges aus `graph_schema.md`
2. Schema-Helper prüft Edge gegen Schema
3. Lint-Engine zeigt Warnungen für prohibited Edges

**Logik:**
- Für Intra-Note-Edge: `sourceSectionType -> targetSectionType`
- Prüfe gegen Schema: `getTopologyInfo(sourceType, targetType)`
- Wenn Edge in "prohibited": Warnung
- Wenn Edge nicht in "typical": Info-Hinweis

**Kompatibilität:**
- Bestehende Schema-Validierung bleibt unverändert
- Neue Validierung ist zusätzlich

---

### 3.5 Phase 5: Commands

#### FA-PL-12: Neue Commands

**Anforderung:** Neue Commands für WP-26 Features.

**Betroffene Dateien:**
- `src/main.ts` (erweitern)

**Neue Commands:**
1. **"Mindnet: Add Section Type"**
   - Öffnet Section-Type-Modal
   - Fügt `[!section]` Callout ein

2. **"Mindnet: Add Block ID to Heading"**
   - Generiert Block-ID für aktuelles Heading
   - Fügt `^block-id` zu Heading hinzu

3. **"Mindnet: Insert Intra-Note Edge"**
   - Öffnet Edge-Type-Chooser mit Section-Type-Support
   - Erstellt Intra-Note-Link mit Block-Reference

4. **"Mindnet: Validate Section Types"**
   - Führt Section-Type-Lint-Regeln aus
   - Zeigt Findings in Console

**Kompatibilität:**
- Bestehende Commands bleiben unverändert
- Neue Commands sind zusätzlich

---

### 3.6 Phase 6: Dictionary-Integration

#### FA-PL-13: Types-Loader

**Anforderung:** Laden und Validierung von `types.yaml`.

**Neue Datei:**
- `src/dictionary/TypesLoader.ts`

**Funktionalität:**
1. Lädt `types.yaml` aus konfiguriertem Pfad
2. Parst verfügbare Note-Types und Section-Types
3. Validiert Section-Types in Notes gegen geladene Types
4. Live-Reload bei Änderungen (wie andere Dictionary-Dateien)

**Interface:**
```typescript
export interface TypesConfig {
  types: {
    [key: string]: {
      name: string;
      description?: string;
      // ... weitere Felder
    };
  };
}

export class TypesLoader {
  static async load(app: App, path: string): Promise<TypesConfig>;
  static validateSectionType(type: string, config: TypesConfig): boolean;
}
```

**Kompatibilität:**
- Bestehende Dictionary-Loader bleiben unverändert
- Types-Loader ist zusätzlich

---

## 4. Technische Spezifikationen

### 4.1 TypeScript-Interfaces

#### 4.1.1 Erweiterte Interfaces

**NoteSection (erweitert):**
```typescript
export interface NoteSection {
  heading: string | null;
  headingLevel: number;
  content: string;
  startLine: number;
  endLine: number;
  links: string[];
  sectionType: string | null;  // NEU
  blockId: string | null;      // NEU
}
```

**ParsedEdge (erweitert):**
```typescript
export interface ParsedEdge {
  rawType: string;
  targets: string[];
  lineStart: number;
  lineEnd: number;
  isInternal: boolean;    // NEU
  blockId: string | null;  // NEU
}
```

**InterviewStep (erweitert):**
```typescript
export interface CaptureTextStep {
  // ... bestehende Felder ...
  sectionType?: string;  // NEU: Optionaler Section-Type
  blockId?: string;  // NEU: Explizite Block-ID
  generateBlockId?: boolean;  // NEU: Automatische Block-ID-Generierung
  references?: Array<{  // NEU: Referenzen zu vorherigen Sections
    blockId: string;
    edgeType?: string;  // Optional: Vorgeschlagener Edge-Type
  }>;
}

// Gilt auch für andere Step-Types mit Section-Output:
export interface CaptureTextLineStep {
  // ... bestehende Felder ...
  sectionType?: string;
  blockId?: string;
  generateBlockId?: boolean;
  references?: Array<{ blockId: string; edgeType?: string }>;
}
```

**WizardState (erweitert):**
```typescript
export interface WizardState {
  // ... bestehende Felder ...
  generatedBlockIds: Map<string, {  // NEU: Track aller generierten Block-IDs
    stepKey: string;
    sectionType: string | null;
    heading: string;
    blockId: string;  // Generierte oder explizite Block-ID
  }>;
  sectionSequence: Array<{  // NEU: Sequenz aller Sections für Edge-Vorschläge
    stepKey: string;
    blockId: string | null;
    sectionType: string | null;
    noteType: string;  // Fallback für effective_type
  }>;
}
```

---

### 4.2 Regex-Patterns

**Section-Type-Callout:**
```typescript
const SECTION_CALLOUT_RE = /^\s*>\s*\[!section\]\s*(\w+)/i;
```

**Block-ID in Heading:**
```typescript
const BLOCK_ID_RE = /^#{1,6}\s+(.+?)\s+\^([a-zA-Z0-9_-]+)$/;
```

**Block-Reference in Link:**
```typescript
const BLOCK_REFERENCE_RE = /\[\[#\^([a-zA-Z0-9_-]+)\]\]/;
```

### 4.3 Formatierungsregeln

**Wichtig:** Die folgenden Formatierungsregeln müssen bei der Generierung von Markdown eingehalten werden:

1. **Section-Type-Callout Position:**
   - `> [!section] <type>` steht **immer direkt nach der Heading-Zeile**
   - Vor dem Section-Content (Text der Sektion)
   - Format: `## Heading ^block-id\n> [!section] type\n\nContent...`

2. **Edge-Callout Position:**
   - `> [!edge] <type>` steht **immer am Ende der Sektion**
   - Nach dem Section-Content (wie bisher)
   - Format: `Content...\n\n> [!edge] type\n> [[#^block-id]]`

3. **Konsistenz:**
   - Diese Regeln gelten für alle generierten Markdown-Formate (Interview-Wizard, Semantic Mapping, etc.)
   - Bestehende Edge-Positionierung bleibt unverändert (am Ende der Sektion)
   - Neue Section-Type-Positionierung (direkt nach Heading) ist konsistent mit Backend-Erwartungen

---

### 4.3 Settings-Erweiterungen

**Neue Settings (optional):**
```typescript
export interface MindnetSettings {
  // ... bestehende Settings ...
  
  // WP-26 Settings
  typesPath: string;  // Pfad zu types.yaml
  autoGenerateBlockIds: boolean;  // Automatische Block-ID-Generierung
  sectionTypeValidation: boolean;  // Section-Type-Validierung aktivieren
}
```

**Kompatibilität:**
- Bestehende Settings bleiben unverändert
- Neue Settings haben Default-Werte

---

## 5. Kompatibilitäts-Anforderungen

### 5.1 Abwärtskompatibilität

**Grundsatz:** Alle bestehenden Funktionen müssen weiterhin funktionieren.

**Konkret:**
1. **Notes ohne Section-Types:** Funktionieren unverändert, `sectionType = null`
2. **Notes ohne Block-IDs:** Funktionieren unverändert, `blockId = null`
3. **Bestehende Commands:** Funktionieren unverändert
4. **Bestehende UI-Modals:** Funktionieren unverändert
5. **Bestehende Lint-Regeln:** Funktionieren unverändert

---

### 5.2 Feature-Flags (Optional)

**Für schrittweise Einführung:**
```typescript
export interface WP26FeatureFlags {
  enableSectionTypes: boolean;      // Default: true
  enableBlockIds: boolean;           // Default: true
  enableIntraNoteEdges: boolean;    // Default: true
  enableSectionTypeValidation: boolean;  // Default: false (Phase 4)
}
```

**Kompatibilität:**
- Features können einzeln aktiviert/deaktiviert werden
- Default: Alle Features aktiviert

---

## 6. Test-Anforderungen

### 6.1 Unit-Tests

**Neue Test-Dateien:**
- `tests/sectionParser.test.ts`
- `tests/sectionTypeModal.test.ts`
- `tests/typesLoader.test.ts`

**Bestehende Tests erweitern:**
- `tests/parseEdgesFromCallouts.test.ts` (Intra-Note-Links)
- `tests/edgeTypeChooser.test.ts` (Section-Type-Support)
- `tests/interviewRenderer.test.ts` (Section-Type-Generierung)

---

### 6.2 Integration-Tests

**Test-Szenarien:**
1. Note mit Section-Types parsen
2. Block-IDs extrahieren
3. Intra-Note-Edges erkennen
4. Section-Type-Validierung
5. Chain-Matching mit Section-Types

---

## 7. Implementierungsreihenfolge

### Phase 1: Grundlagen (Kern-Parsing)
- FA-PL-01: Section-Type-Callout-Parsing
- FA-PL-02: Block-ID-Extraktion
- FA-PL-03: Intra-Note-Link-Erkennung

### Phase 2: UI-Komponenten
- FA-PL-04: Section-Type-Modal
- FA-PL-05: Edge-Type-Chooser mit Section-Type-Support
- FA-PL-06: Link-Prompt mit Block-ID-Generierung

### Phase 3: Feature-Integration
- FA-PL-07: Interview-Wizard mit Section-Types, Block-IDs und automatischen Edge-Vorschlägen
- FA-PL-08: Chain Workbench mit Section-Types
- FA-PL-09: Semantic Mapping mit Section-Types

### Phase 4: Validierung & Linting
- FA-PL-10: Lint-Regeln für Section-Types
- FA-PL-11: Schema-Validierung für Intra-Note-Edges

### Phase 5: Commands
- FA-PL-12: Neue Commands

### Phase 6: Dictionary-Integration
- FA-PL-13: Types-Loader

---

## 8. Risiken und Mitigation

### 8.1 Risiken

| Risiko | Wahrscheinlichkeit | Impact | Mitigation |
|--------|-------------------|--------|------------|
| Breaking Changes in bestehenden Funktionen | Niedrig | Hoch | Umfassende Tests, Feature-Flags |
| Performance-Impact durch zusätzliches Parsing | Mittel | Mittel | Lazy Loading, Caching |
| Inkonsistenz zwischen Plugin und Backend | Mittel | Hoch | Strikte Einhaltung der Backend-Spezifikation |
| Komplexität der UI-Integration | Mittel | Mittel | Schrittweise Implementierung, klare Interfaces |

---

## 9. Erfolgskriterien

### 9.1 Funktionale Kriterien

- ✅ Alle bestehenden Funktionen funktionieren unverändert
- ✅ Section-Types werden korrekt erkannt und geparst
- ✅ Block-IDs werden korrekt extrahiert
- ✅ Intra-Note-Edges werden korrekt erkannt
- ✅ UI-Komponenten unterstützen Section-Types
- ✅ Lint-Regeln validieren Section-Types

### 9.2 Qualitätskriterien

- ✅ Keine Breaking Changes
- ✅ Vollständige Abwärtskompatibilität
- ✅ Konsistente UX
- ✅ Umfassende Test-Abdeckung

---

## 10. Anhänge

### 10.1 Referenzen

- Backend Lastenheft: `docs/06_Roadmap/06_LH_Section_Types_Intra_Note_Edges.md` (v1.3)
- Backend Plugin Interface: `docs/WP26_Plugin_Interface_Specification.md`
- Backend Implementation Checklist: `docs/WP26_Implementation_Checklist.md`

### 10.2 Glossar

Siehe Backend Lastenheft Kapitel 1.3.

---

**Ende des Lastenhefts**