mindnet/docs/05_Development/05_WP26_Manual_Testing.md
Lars cc258008dc Refactor provenance handling in EdgeDTO and graph utilities
- Updated provenance priorities and introduced a mapping from internal provenance values to EdgeDTO-compliant literals.
- Added a new function `normalize_provenance` to standardize internal provenance strings.
- Enhanced the `_edge` function to include an `is_internal` flag and provenance normalization.
- Modified the `EdgeDTO` model to include a new `source_hint` field for detailed provenance information and an `is_internal` flag for intra-note edges.
- Reduced the provenance options in `EdgeDTO` to valid literals, improving data integrity.
2026-01-25 16:27:09 +01:00

6.4 KiB

WP-26 Manuelle Testszenarien

Version: 1.0
Datum: 25. Januar 2026
Status: Phase 1 Implementierung abgeschlossen


1. Überblick

Dieses Dokument beschreibt die manuellen Testszenarien für WP-26 Phase 1: Section-Types und Intra-Note-Edges.


2. Voraussetzungen

  1. Python-Umgebung mit allen Dependencies aus requirements.txt
  2. Qdrant-Instanz erreichbar (lokal oder Docker)
  3. Vault mit Test-Note (siehe Abschnitt 3)

3. Test-Note erstellen

Erstelle eine neue Markdown-Datei im Vault mit folgendem Inhalt:

---
id: wp26-test-experience
title: WP-26 Test Experience
type: experience
tags: [test, wp26]
---

# WP-26 Test Experience

## Situation ^sit
> [!section] experience

Am 25. Januar 2026 testete ich das neue Section-Type Feature.
Dies ist der Experience-Teil der Note.

## Meine Reaktion ^react
> [!section] experience

> [!edge] followed_by
> [[#^sit]]

Ich war zunächst skeptisch, aber die Implementierung sah solide aus.

## Reflexion ^ref
> [!section] insight

Diese Erfahrung zeigt mir, dass typ-spezifische Sektionen
die semantische Präzision des Retrievals verbessern können.

> [!abstract] Semantic Edges
>> [!edge] derives
>> [[#^sit]]
>> [[#^react]]

## Nächste Schritte ^next
> [!section] decision

Ich werde:
1. Die Tests ausführen
2. Die Ergebnisse dokumentieren

> [!edge] caused_by
> [[#^ref]]

4. Testszenarien

4.1 TS-01: Section-Type-Erkennung

Ziel: Prüfen, ob [!section]-Callouts korrekt erkannt werden.

Schritte:

  1. Importiere die Test-Note via scripts/import_markdown.py
  2. Prüfe die Chunks in Qdrant via API oder Debug-Skript

Prüfkriterien:

Chunk Erwarteter type Erwarteter note_type Erwarteter section
#c00 experience experience Situation
#c01 experience experience Meine Reaktion
#c02 insight experience Reflexion
#c03 decision experience Nächste Schritte

Prüf-Script:

# scripts/check_wp26_chunks.py
from qdrant_client import QdrantClient

client = QdrantClient("http://localhost:6333")
note_id = "wp26-test-experience"

# Hole alle Chunks der Note
result = client.scroll(
    collection_name="mindnet_chunks",
    scroll_filter={"must": [{"key": "note_id", "match": {"value": note_id}}]},
    with_payload=True,
    limit=100
)

for point in result[0]:
    p = point.payload
    print(f"Chunk: {p.get('chunk_id')}")
    print(f"  type: {p.get('type')}")
    print(f"  note_type: {p.get('note_type')}")
    print(f"  section: {p.get('section')}")
    print(f"  section_type: {p.get('section_type')}")
    print(f"  block_id: {p.get('block_id')}")
    print()

4.2 TS-02: Block-ID-Erkennung

Ziel: Prüfen, ob Block-IDs (^id) aus Überschriften korrekt extrahiert werden.

Prüfkriterien:

Chunk Erwartete block_id
#c00 sit
#c01 react
#c02 ref
#c03 next

4.3 TS-03: is_internal Flag für Edges

Ziel: Prüfen, ob Intra-Note-Edges das is_internal: true Flag erhalten.

Schritte:

  1. Importiere die Test-Note
  2. Prüfe die Edges in Qdrant

Prüfkriterien:

Edge is_internal
#c01 → #c00 (followed_by) true
#c02 → #c00 (derives) true
#c02 → #c01 (derives) true
#c03 → #c02 (caused_by) true
Alle structure edges (next/prev) true

Prüf-Script:

# scripts/check_wp26_edges.py
from qdrant_client import QdrantClient

client = QdrantClient("http://localhost:6333")
note_id = "wp26-test-experience"

# Hole alle Edges der Note
result = client.scroll(
    collection_name="mindnet_edges",
    scroll_filter={"must": [{"key": "note_id", "match": {"value": note_id}}]},
    with_payload=True,
    limit=100
)

for point in result[0]:
    p = point.payload
    kind = p.get('kind', 'unknown')
    source = p.get('source_id', '?')
    target = p.get('target_id', '?')
    is_internal = p.get('is_internal', 'MISSING')
    provenance = p.get('provenance', '?')
    source_hint = p.get('source_hint', '-')
    
    print(f"{source} --[{kind}]--> {target}")
    print(f"  is_internal: {is_internal}")
    print(f"  provenance: {provenance}")
    print(f"  source_hint: {source_hint}")
    print()

4.4 TS-04: Provenance-Normalisierung

Ziel: Prüfen, ob Provenance-Werte korrekt normalisiert werden.

Prüfkriterien:

Altes Provenance Neues provenance source_hint
explicit:callout explicit callout
explicit:wikilink explicit wikilink
structure:belongs_to structure belongs_to
structure:order structure order
edge_defaults rule edge_defaults

4.5 TS-05: Automatische Section-Erkennung

Ziel: Prüfen, ob neue Überschriften ohne [!section] automatisch neue Chunks erstellen.

Test-Note:

---
id: wp26-test-auto-section
type: experience
---

# Test Auto Section

## Section A ^a
> [!section] insight

Content A (insight).

## Section B ^b

Content B (sollte experience sein - Fallback).

## Section C ^c
> [!section] decision

Content C (decision).

Prüfkriterien:

Chunk type Grund
Section A insight Explizites [!section]
Section B experience Fallback auf note_type
Section C decision Explizites [!section]

5. Unit-Tests ausführen

# Im Projekt-Root
cd c:\Dev\cursor\mindnet

# Aktiviere virtuelle Umgebung (falls vorhanden)
# .venv\Scripts\activate

# Führe WP-26 Tests aus
python -m pytest tests/test_wp26_section_types.py -v

Erwartetes Ergebnis: Alle Tests grün.


6. Bekannte Einschränkungen

  1. Block-ID-Stability: Obsidian aktualisiert Block-IDs nicht automatisch bei Umbenennung von Überschriften.
  2. Heading-Links: Links wie [[#Section Name]] werden unterstützt, aber Block-References ([[#^id]]) werden bevorzugt.
  3. Nested Callouts: Verschachtelte Callouts (>> [!edge]) werden korrekt verarbeitet.

7. Nächste Schritte (Phase 2)

Nach erfolgreicher Validierung von Phase 1:

  1. Retriever-Anpassung: Path-Bonus für Intra-Note-Edges
  2. Graph-Exploration: Navigation entlang typical edges aus graph_schema.md
  3. Schema-Validierung: Agentic Validation gegen effektive Chunk-Typen

Ende der Testdokumentation