context: "Regelwerk für das Erstellen von Notizen im Vault. Die 'Source of Truth' für Autoren. Inkludiert WP-24c Phase 3 Agentic Edge Validation, automatische Spiegelkanten, Note-Scope Zonen und WP-26 Section Types mit Intra-Note-Edges."
1.**Atomare Gedanken:** Eine Notiz = Ein Thema. Vermischung führt zu "Context-Pollution", wodurch die KI unpräzise berät.
2.**Explizite Typen:** Der `type` im Frontmatter ist der wichtigste Hebel. Er entscheidet über die mathematische Gewichtung im System.
3.**Semantische Links:** Nutze das Vokabular aus der `01_edge_vocabulary.md`. Ersetze einfache Verweise durch funktionale Beziehungen wie `caused_by` oder `based_on`.
4.**Werte & Ziele definieren:** Ohne explizite Kriterien (`type: value`) fehlt dem System der Maßstab für eine Bewertung.
5.**Emotionales Bridging:** Dokumentiere deine Gefühle. Begriffe wie „Druck“ oder „Euphorie“ sind die Schnittstelle für die Empathie-Logik.
6.**Narrative Tiefe (Fleisch am Knochen):** Ein „Was“ ohne „Warum“ ist für die KI nur ein Fakt, für dich als Mensch aber bedeutungslos. Dokumentiere die Intention hinter deinen Taten.
Mindnet ist mehr als eine Dokumentablage. Es ist ein vernetztes System, das deine Persönlichkeit abbildet. Die Markdown-Dateien in deinem Vault sind die **einzige Quelle der Wahrheit** ("Source of Truth"). Was nicht im Markdown steht, existiert für das System nicht.
---
## 2. Note-Struktur & Frontmatter
Jede Notiz benötigt einen YAML-Header (Frontmatter).
### **2.1 [NEU] Naming Convention: Intuitiv vs. Technisch**
Für die Benutzerfreundlichkeit und die intuitive Navigation in Obsidian wird die Nutzung von **menschenlesbaren Titeln** bevorzugt (z. B. `Mein Persönliches Leitbild 2025` statt `leitbild_identity`).
- Die technische Eindeutigkeit wird primär über die `id` im Frontmatter sichergestellt.
- Die KI nutzt die Semantik des Dateinamens als zusätzlichen Kontext-Vektor.
In 95% der Fälle setzt der `type` (z.B. "concept") automatisch die richtigen Einstellungen. In Spezialfällen kannst du diese manuell im Frontmatter überschreiben, um das Verhalten der KI zu erzwingen.
#### A. `retriever_weight`: Die Sichtbarkeit steuern
Dieser Faktor (Default: 1.0) ist ein Multiplikator für das Ranking in der Vektorsuche. Er entscheidet, welche Notiz "gewinnt", wenn zwei Texte inhaltlich ähnlich sind.
* **Standard (1.0):** Normale Wichtigkeit.
* **Boost (1.2 - 2.0):** "Das hier ist die Wahrheit."
* *Einsatz:* Finale Entscheidungen, Kernprinzipien, die "Single Source of Truth".
* *Effekt:* Verdrängt weniger wichtige Notizen (z.B. Meeting-Protokolle) aus dem Kontext-Fenster der KI.
* **Deboost (0.5 - 0.8):** "Nur Kontext, keine Fakten."
* *Effekt:* Die Notiz wird nur gefunden, wenn man sehr spezifisch danach sucht.
#### B. `chunking_profile`: Die Zerstückelung steuern
Das Profil bestimmt, wie der Text für die Datenbank zerschnitten wird. Falsches Chunking zerreißt den Kontext. Wähle das Profil basierend auf der **Struktur** deines Textes.
| **`sliding_standard`** | Sliding Window | **Der Allrounder.** Für Fließtexte (Tagebuch, Artikel). Der Text wird in überlappende Fenster geschnitten. Gut, wenn der Inhalt von oben nach unten fließt. |
| **`sliding_short`** | Sliding Window (Klein) | **Für Dichte.** Für Texte mit sehr hoher Informationsdichte (Glossare, Task-Listen), wo jeder Satz wichtig ist. Erzeugt viele kleine Chunks. |
| **`sliding_smart_edges`** | Sliding + AI | **Der Intelligente.** Wie Standard, aber das LLM analysiert jeden Chunk zusätzlich auf implizite Querverweise. Standard für `concept` und `project`. |
| **`structured_smart_edges`** | Heading Split (Soft) | **Für Strukturierte Texte.** Trennt an Überschriften (H2). *Besonderheit:* Wenn ein Abschnitt sehr kurz ist, wird er mit dem nächsten verschmolzen ("Soft Mode"), um den Kontext zu wahren. |
| **`structured_smart_edges_strict`** | Heading Split (Hard) | **Für Listen & Kataloge.** Trennt *zwingend* an jeder H2-Überschrift. Verhindert das Verschmelzen. <br>**Wichtig für:** `decision` (Option A darf nicht mit Option B verschmelzen), `value`, `profile`. |
**Beispiel für ein Override:**
```yaml
---
title: Sammlung meiner Passwörter-Regeln
type: list
# Wir erzwingen eine strikte Trennung, damit Regel 1 nicht mit Regel 2 vermischt wird.
| **`stable`** | **Geprüftes Wissen.** Die Notiz ist inhaltlich korrekt, finalisiert und verlässlich (Gold-Standard). | **🚀 Bevorzugt (Bonus):** Die KI vertraut diesen Inhalten mehr (+20% Relevanz-Score). Bei widersprüchlichen Infos gewinnt `stable`. |
| **`active`** | **Standard.** Aktuelle Arbeitsnotizen, Projekte oder Dokumentationen (Default, wenn leer). | **🔵 Neutral:** Standard-Gewichtung (Faktor 1.0). |
| **`draft`** | **Entwurf.** Brainstorming, unstrukturierte Mitschriften oder rohe Ideen. | **🔻 Gedämpft (Malus):** Die KI nutzt diese Infos nur, wenn es keine besseren Treffer gibt (Relevanz auf 50% reduziert). Reduziert "Rauschen" in den Antworten. |
| **`system`** | **Intern.** Konfigurationsdateien, technische Logs oder Admin-Skripte. | **❌ Ignoriert (Hard Skip):** Die Datei wird **nicht** in den Suchindex aufgenommen und ist für den Chat unsichtbar. |
| **`template`**| **Vorlage.** Leere Gerüste für neue Notizen (z.B. für Obsidian). | **❌ Ignoriert (Hard Skip):** Verhindert, dass leere Vorlagen als Suchergebnisse auftauchen. |
### Wann nutze ich welchen Status?
1.**Ideenfindung:** Setzen Sie neue Ideen immer auf **`draft`**. So können Sie frei schreiben, ohne dass die KI sofort "Halbwissen" als Fakten verkauft.
2.**Finalisierung:** Sobald eine Entscheidung getroffen oder ein Konzept fertig ist, ändern Sie den Status auf **`stable`**.
3.**Konfiguration:** Nutzen Sie **`system`** für Dateien wie die `01_edge_vocabulary.md`, damit die KI nicht die Definition der Kanten zitiert, wenn Sie eigentlich nach Inhalten suchen.
Das optionale Feld `aliases` erlaubt es dir, einer Notiz alternative Titel oder Synonyme zu geben. Dies ist ein mächtiges Werkzeug für die Usability und die Suche.
Gib einer spezifischen Notiz niemals einen Alias, der ein allgemeines Wort ist.
* *Schlecht:* Alias `[Meeting]` für `2025-10-JourFixe`.
* *Folge:* Jedes Mal, wenn du das Wort "Meeting" tippst, schlägt Obsidian dir diesen einen alten Jour Fixe vor. Das zerstört den Schreibfluss.
* ❌ **Keine Plural-Wahn:**
Mindnet und Obsidian finden meist auch den Plural (Fuzzy Search). Du musst nicht `[Prinzip, Prinzipien, Prinzips]` anlegen. Ein Stammbegriff reicht oft.
**Section Types** ermöglichen es, innerhalb einer Note unterschiedliche Typen für verschiedene Abschnitte zu definieren. Dies erlaubt präzisere semantische Verarbeitung und Intra-Note-Verbindungen zwischen Chunks.
**Kernkonzept:**
- Eine Note hat einen **Note-Type** (im Frontmatter: `type: experience`)
- Abschnitte innerhalb der Note können einen eigenen **Section-Type** haben (z.B. `insight`, `decision`)
- Der **effektive Typ** eines Chunks ist: `section_type` falls vorhanden, sonst `note_type`
- Der Section-Type gilt ab der Überschrift bis zur nächsten Überschrift **gleicher oder höherer Ebene**
- Das `[!section]`-Callout kann **an beliebiger Stelle** innerhalb des Abschnitts stehen (muss nicht direkt unter der Überschrift sein)
- Das `[!section]`-Callout ist **unabhängig** von `[!edge]`-Callouts und kann separat platziert werden
- Bei Fehlen eines `[!section]`-Callouts gilt der Note-Type als Fallback
- Valide Section-Types müssen in `types.yaml` definiert sein
**Automatische Section-Erkennung:**
Sobald eine Section auf einer bestimmten Überschriften-Ebene eingeführt wurde (z.B. H2), beginnt bei **jeder weiteren Überschrift auf dieser Ebene automatisch eine neue Section**– auch ohne explizites `[!section]`-Callout.
**Beispiel:**
```markdown
## Situation ^sit
> [!section] experience
Text A... → type = "experience" (explizit)
## Reflexion ^ref
<!-- KEIN [!section] Callout -->
Text B... → type = "experience" (note_type Fallback)
→ ABER: Neue Section erkannt, neuer Chunk!
## Learnings ^learn
> [!section] insight
Text C... → type = "insight" (explizit)
```
**Body-Section:**
Textblöcke, die **vor dem ersten `[!section]`-Callout** stehen, erhalten:
-`section: "body"`
-`type: note_type` (Fallback)
-`section_type: None`
### 4.0.2 Intra-Note-Edges (Verbindungen innerhalb einer Note)
**Block-References als Link-Format:**
Das bevorzugte Format für Intra-Note-Links:
```markdown
> [!edge] derives
> [[#^block-id]]
```
**Fallback (mit Einschränkungen):**
```markdown
> [!edge] derives
> [[#Section-Name]]
```
**Vollständiges Beispiel:**
```markdown
## Situation ^sit
> [!section] experience
Die Geschichte...
## Reflexion ^ref
> [!section] insight
> [!edge] derives
> [[#^sit]]
Was ich daraus lerne...
```
**Ergebnis:**
- Chunk der Reflexion (`#ref`) erhält eine `derives`-Kante zum Chunk der Situation (`#sit`)
- Beide Chunks sind in derselben Note → `is_internal: true`
- Scope ist `chunk` (nicht `note`)
**Automatische Backlinks:**
Für alle Intra-Note-Edges werden automatisch inverse Backlinks erzeugt:
Das System trennt automatisch den Note-Namen (`Mein Leitbild`) vom Abschnitts-Namen (`P3 – Disziplin`), sodass mehrere Links zur gleichen Note möglich sind, wenn sie auf verschiedene Abschnitte zeigen.
Callout-Blocks mit mehreren Zeilen werden korrekt verarbeitet. Das System erkennt automatisch, wenn mehrere Links im gleichen Callout-Block stehen, und erstellt für jeden Link eine separate Kante (auch bei Deep-Links zu verschiedenen Sections).
Wenn Kanten bereits via `[!edge]` Callout vorhanden sind, werden sie nicht mehrfach injiziert. Das System erkennt vorhandene Kanten unabhängig vom Format (Inline, Callout, Wikilink).
In Mindnet musst du Kanten **nicht** manuell in beide Richtungen pflegen. Das System erzeugt automatisch **Spiegelkanten** (Invers-Kanten) im Hintergrund.
**Wie es funktioniert:**
1.**Du setzt eine explizite Kante:** Z.B. `[[rel:depends_on Projekt Alpha]]` in Note A
- Schreibst du in Note A: `[[rel:next Projekt B]]`, erzeugt das System automatisch: `Projekt B prev: Note A`
- Schreibst du in Note B: `[[rel:derived_from Note A]]`, erzeugt das System automatisch: `Note A resulted_in: Note B`
- Schreibst du in Note A: `[[rel:impacts Projekt B]]`, erzeugt das System automatisch: `Projekt B impacted_by: Note A`
**Wichtig:**
- **Explizite Kanten haben Vorrang:** Wenn du bereits beide Richtungen explizit gesetzt hast, wird keine automatische Spiegelkante erzeugt (keine Duplikate)
- **Höhere Wirksamkeit expliziter Kanten:** Explizit gesetzte Kanten haben höhere Priorität und Confidence-Werte als automatisch generierte Spiegelkanten
- **Schutz vor Manipulation:** System-Kanten (`belongs_to`, `next`, `prev`) können nicht manuell überschrieben werden (Provenance Firewall)
**Vorteil:** Keine redundante Datenpflege, kein "Link-Nightmare", volle Konsistenz im Graphen. Beide Richtungen sind durchsuchbar, was die Auffindbarkeit von Informationen verdoppelt.
* **Ziel:** Das System soll abwägen: "Passt Tool X zu mir?"
* **Vorgehen:** Erstelle Notizen mit `type: value` oder `type: goal`.
* **Effekt:** Wenn du fragst "Soll ich Notion nutzen?", lädt die Engine diese Notiz und antwortet: *"Nein, Notion ist SaaS ohne E2E. Das verletzt dein Prinzip der Datensparsamkeit."*
### Szenario B: Empathie (`EMPATHY`)
* **Ziel:** Das System soll dich verstehen.
* **Vorgehen:** Erstelle `type: experience` mit **emotionalen Brückenwörtern**.
**Beispiel Notiz:**
```yaml
---
type: experience
title: Erfahrung: Der Durchbruch nach der Krise
tags: [krise, hoffnung, grau, angst]
---
Es gibt Projektphasen, da wirkt alles **sinnlos** und **grau**.
Ich habe gelernt: Das ist oft das Zeichen kurz vor dem Durchbruch.
```
* **Effekt:** Bei "Alles ist grau" findet das System diese Notiz und spiegelt die Lektion zurück.
Setze bewusst Links auf Dateien, die noch nicht existieren (z.B. `[[Die beste Version meiner selbst]]`). Die KI erkennt diese semantischen Lücken und stellt im Chat proaktive Fragen, um diese Felder mit dir zu füllen.
### 5.5 Szenario D: Narratives Gedächtnis
Dokumentiere das "Warum" (Fleisch am Knochen). Wenn du schreibst: *"Ich wähle Disziplin, weil ich Willkür als Kind schmerzhaft erlebt habe"*, versteht die KI die emotionale Kausalität und kann dich in Krisen an diesen Ursprung erinnern.
