286 lines
6.8 KiB
Markdown
286 lines
6.8 KiB
Markdown
# Vault-Einträge
|
||
|
||
Erstelle einen Vault-Eintrag nur, wenn aus dem Gespräch Wissen entstanden ist, das ich in Wochen oder Monaten wiederfinden oder erneut anwenden möchte.
|
||
|
||
## Entscheidungsregel
|
||
|
||
Ein Vault-Eintrag ist sinnvoll bei:
|
||
|
||
* einer wichtigen Erkenntnis,
|
||
* einer nachvollziehbaren Entscheidung,
|
||
* einer getesteten Strategie,
|
||
* einer technischen Lösung oder Diagnose,
|
||
* einem wiederverwendbaren Prozess,
|
||
* einem persönlichen Zusammenhang oder hilfreichen Muster,
|
||
* recherchiertem Wissen mit praktischem Nutzen.
|
||
|
||
Kein Vault-Eintrag für:
|
||
|
||
* bloßen Gesprächsfortschritt,
|
||
* erledigte Aufgaben,
|
||
* kurzfristige To-dos,
|
||
* flüchtigen Projektstatus,
|
||
* Smalltalk,
|
||
* Informationen ohne späteren Nutzwert.
|
||
|
||
Solche Dinge gehören gegebenenfalls ins Bullet Journal oder in eine Projekt-Statusdatei.
|
||
|
||
Bei Unsicherheit: keinen Vault-Eintrag erstellen.
|
||
|
||
## Grundregeln
|
||
|
||
### Ein Thema pro Eintrag
|
||
|
||
Jede Datei behandelt genau eine klar benennbare Erkenntnis, Entscheidung, Lösung oder Strategie.
|
||
|
||
Wenn mehrere eigenständige Themen entstanden sind, trenne sie in einzelne Einträge.
|
||
|
||
### Kontextunabhängig schreiben
|
||
|
||
Der Eintrag muss ohne Kenntnis des ursprünglichen Chats verständlich sein.
|
||
|
||
Vermeide Formulierungen wie:
|
||
|
||
* „Wie oben besprochen“
|
||
* „Das hat funktioniert“
|
||
* „Wir haben festgestellt“
|
||
|
||
Beschreibe stattdessen konkret, was gemeint ist.
|
||
|
||
### Wissen komprimieren
|
||
|
||
Speichere nicht den Gesprächsverlauf, sondern das daraus gewonnene Wissen.
|
||
|
||
Bevorzuge:
|
||
|
||
Problem → Erkenntnis → Anwendung
|
||
|
||
statt:
|
||
|
||
Was im Gespräch nacheinander passiert ist.
|
||
|
||
### Erkenntnisstatus unterscheiden
|
||
|
||
Trenne klar zwischen:
|
||
|
||
* **Fakt:** nachweisbare oder verifizierte Information
|
||
* **Beobachtung:** persönlich oder praktisch festgestellt
|
||
* **Hypothese:** plausible, aber noch nicht bestätigte Erklärung
|
||
|
||
Stelle Hypothesen niemals als Tatsachen dar.
|
||
|
||
Bei technischen Lösungen unterscheide insbesondere:
|
||
|
||
* getestet und bestätigt,
|
||
* plausibel, aber nicht getestet,
|
||
* noch offen.
|
||
|
||
### Hard-won Lessons erhalten
|
||
|
||
Wenn eine Lösung durch Fehlersuche, Irrwege oder einen überraschenden Zusammenhang gefunden wurde, speichere nicht nur die endgültige Lösung.
|
||
|
||
Halte auch den wiederverwendbaren Diagnosehinweis oder das zugrunde liegende Prinzip fest.
|
||
|
||
Beispiel:
|
||
|
||
Nicht nur:
|
||
„firewalld deaktivieren.“
|
||
|
||
Sondern:
|
||
„Wenn UFW korrekt aussieht, Netzwerkverkehr aber weiterhin blockiert wird, prüfen, ob zusätzlich firewalld oder eine andere Firewall aktiv ist.“
|
||
|
||
### Datensparsamkeit
|
||
|
||
Speichere nur persönliche oder sensible Informationen, die für den späteren Nutzen notwendig sind.
|
||
|
||
Keine unbelegten Diagnosen oder unnötigen intimen Details.
|
||
|
||
## Notiztyp wählen
|
||
|
||
Wähle genau einen passenden Typ:
|
||
|
||
* `learning` – allgemeine Erkenntnis oder neues Wissen
|
||
* `decision` – wichtige Entscheidung mit Begründung
|
||
* `troubleshooting` – Problem, Diagnose und Lösung
|
||
* `process` – wiederverwendbarer Ablauf oder Vorgehensweise
|
||
* `personal-strategy` – persönliche Beobachtung oder hilfreiche Strategie
|
||
* `reference` – kompakte Wissens- oder Recherche-Notiz
|
||
|
||
Nutze nur die für den gewählten Typ sinnvollen Abschnitte.
|
||
|
||
Keine leeren Überschriften ausgeben.
|
||
|
||
## Metadaten
|
||
|
||
```markdown
|
||
---
|
||
created: YYYY-MM-DD HH:MM
|
||
updated: YYYY-MM-DD HH:MM
|
||
type: learning
|
||
tags: [tag1, tag2]
|
||
status: verified
|
||
source: chat
|
||
---
|
||
```
|
||
|
||
Regeln:
|
||
|
||
* `type`: einer der definierten Notiztypen.
|
||
* `tags`: 2 bis 5 konkrete, kleingeschriebene Tags.
|
||
* `status`:
|
||
|
||
* `verified` – bestätigt oder getestet
|
||
* `working` – brauchbare persönliche Erkenntnis oder Arbeitsannahme
|
||
* `needs-verification` – noch nicht bestätigt
|
||
* Nutze lokale Systemzeit, wenn verfügbar.
|
||
* Wenn die Uhrzeit nicht zuverlässig verfügbar ist, erfinde sie nicht.
|
||
* `source` nur genauer angeben, wenn eine konkrete Quelle bekannt ist.
|
||
|
||
## Struktur nach Notiztyp
|
||
|
||
### learning
|
||
|
||
```markdown
|
||
# Präziser Titel
|
||
|
||
## Kernerkenntnis
|
||
- Wichtigste Erkenntnis.
|
||
|
||
## Warum das wichtig ist
|
||
- Relevanter Zusammenhang oder Konsequenz.
|
||
|
||
## Praktische Anwendung
|
||
- Regel, Beispiel oder konkrete Nutzung.
|
||
|
||
## Grenzen
|
||
- Ausnahmen oder Unsicherheiten, falls relevant.
|
||
```
|
||
|
||
### decision
|
||
|
||
```markdown
|
||
# Entscheidung: [Thema]
|
||
|
||
## Entscheidung
|
||
- Was wurde entschieden?
|
||
|
||
## Gründe
|
||
- Die wichtigsten Gründe.
|
||
|
||
## Verworfene Alternativen
|
||
- Nur relevante Alternativen und warum sie nicht gewählt wurden.
|
||
|
||
## Konsequenzen
|
||
- Was folgt aus dieser Entscheidung?
|
||
|
||
## Neu bewerten wenn
|
||
- Bedingungen, unter denen die Entscheidung überprüft werden sollte.
|
||
```
|
||
|
||
### troubleshooting
|
||
|
||
```markdown
|
||
# [Problem] – Ursache und Lösung
|
||
|
||
## Symptom
|
||
- Was war konkret zu beobachten?
|
||
|
||
## Ursache
|
||
- Tatsächliche oder wahrscheinlichste Ursache.
|
||
- Kennzeichne Unsicherheit ausdrücklich.
|
||
|
||
## Diagnosehinweise
|
||
- Welche Beobachtung oder welcher Test grenzt das Problem ein?
|
||
|
||
## Lösung
|
||
- Was hat das Problem behoben?
|
||
- Nur bestätigte Schritte als bestätigte Lösung darstellen.
|
||
|
||
## Merksatz
|
||
- Wiederverwendbares Diagnose- oder Präventionsprinzip.
|
||
```
|
||
|
||
Bei Befehlen oder Konfigurationen:
|
||
|
||
* nur relevante Zeilen speichern,
|
||
* getestete Befehle als getestet kennzeichnen,
|
||
* keine erfundenen Pfade, Optionen oder Werte ergänzen.
|
||
|
||
### process
|
||
|
||
```markdown
|
||
# [Prozess]
|
||
|
||
## Ziel
|
||
- Was soll damit erreicht werden?
|
||
|
||
## Vorgehen
|
||
1. Konkreter Schritt.
|
||
2. Konkreter Schritt.
|
||
3. Konkreter Schritt.
|
||
|
||
## Wichtige Regeln
|
||
- Wiederverwendbare Prinzipien.
|
||
|
||
## Stolperfallen
|
||
- Häufige oder bereits erlebte Fehler.
|
||
```
|
||
|
||
### personal-strategy
|
||
|
||
```markdown
|
||
# [Strategie oder Muster]
|
||
|
||
## Beobachtung
|
||
- Was wurde konkret bei mir beobachtet?
|
||
|
||
## Mögliche Erklärung
|
||
- Plausibler Zusammenhang, ausdrücklich als mögliche Erklärung formuliert.
|
||
|
||
## Hilfreiche Strategie
|
||
- Was hilft oder soll getestet werden?
|
||
|
||
## Nächster Test
|
||
- Kleine überprüfbare Veränderung, falls sinnvoll.
|
||
|
||
## Grenzen
|
||
- Wann die Strategie möglicherweise nicht passt.
|
||
```
|
||
|
||
### reference
|
||
|
||
```markdown
|
||
# [Thema]
|
||
|
||
## Kurzfassung
|
||
- Wichtigste Information.
|
||
|
||
## Wichtige Punkte
|
||
- Relevante Fakten oder Zusammenhänge.
|
||
|
||
## Praktische Bedeutung
|
||
- Warum oder wann dieses Wissen gebraucht wird.
|
||
|
||
## Quellen oder Unsicherheiten
|
||
- Nur wenn relevant.
|
||
```
|
||
|
||
## Bestehendes Wissen
|
||
|
||
Wenn im Gespräch eine bereits vorhandene Vault-Notiz bereitgestellt wurde, bevorzuge das Aktualisieren oder Ergänzen dieser Notiz gegenüber einer neuen, nahezu identischen Datei.
|
||
|
||
Erfinde keine vorhandenen Dateien oder Verlinkungen.
|
||
|
||
## Qualitätsprüfung
|
||
|
||
Prüfe vor der Ausgabe:
|
||
|
||
1. Behandelt der Eintrag nur ein Thema?
|
||
2. Ist er ohne Chat-Kontext verständlich?
|
||
3. Enthält er wiederverwendbares Wissen statt Gesprächschronologie?
|
||
4. Sind Fakt, Beobachtung und Hypothese sauber getrennt?
|
||
5. Ist klar, was tatsächlich getestet oder bestätigt wurde?
|
||
6. Enthält er bei einer schwierigen Problemlösung auch die wiederverwendbare Lektion?
|
||
7. Kann Unnötiges noch entfernt werden?
|
||
|
||
Wenn kein ausreichend dauerhafter Lernwert vorhanden ist, gib keinen Vault-Eintrag aus.
|