136 lines
5.1 KiB
Markdown
136 lines
5.1 KiB
Markdown
---
|
|
title: "Memory Layer Architecture"
|
|
category: concepts
|
|
tags: [memory, architecture, hindsight, lcm, wiki, separation]
|
|
created: "2026-09-27"
|
|
modified: "2026-09-27"
|
|
---
|
|
|
|
# Memory Layer Architecture — Practical Rules
|
|
|
|
## Übersicht
|
|
|
|
7 Schichten mit klaren, nicht-überlappenden Rollen.
|
|
|
|
| # | Layer | System | Pfad/Ort | Rolle | Wann nutzen |
|
|
|---|-------|--------|----------|-------|-------------|
|
|
| L0 | Hot | MEMORY.md + USER.md | `~/.hermes/memories/` | System-Prompt Injection, komprimierte Facts | Jede Session (automatisch) |
|
|
| L1 | Curated | LLM Wiki | `~/.hermes/memory/` | Browsbares Wissen, git-synced | Wenn Details gebraucht werden |
|
|
| L2 | Semantic | Hindsight | K8s PostgreSQL | Vektor-Suche, semantisches Retrieval | Cross-Session Lookup |
|
|
| L3 | Procedural | Skills | `~/.hermes/skills/` | Wie-geht-es Prozeduren mit Pitfalls | Bei wiederkehrenden Tasks |
|
|
| L4 | Episodic | LCM + session_search | SQLite lcm.db / state.db | Rohe Gesprächsverläufe, Compaction | Innerhalb aktiver Session |
|
|
| L5 | Solutions | Solution Docs | `~/docs/solutions/` | Problem-Lösungs-Paare | Nach substanziellen Tasks |
|
|
| L6 | Project | AGENTS.md | pro Repo | Repo-spezifische Konventionen | Beim Arbeiten in einem Repo |
|
|
|
|
## Was wohin gehört — Entscheidungsbaum
|
|
|
|
```
|
|
Ist es ein Fact über Dominik persönlich?
|
|
→ USER.md (L0)
|
|
Ist es sein Kommunikationsstil, Safety-Rule, oder Workflow-Präferenz?
|
|
→ USER.md
|
|
Ist es ein persönlicher Umstand (Größe, Gewicht, Arbeitgeber)?
|
|
→ Hindsight (L2) — NICHT USER.md
|
|
|
|
Ist es ein Infra-Fakt (IP, Version, Konfiguration)?
|
|
→ LLM Wiki (L1) — systems/ oder reference/
|
|
Braucht er jede Session sofort?
|
|
→ MEMORY.md (L0) als 1-Zeiliger Pointer "→Wiki systems/xyz"
|
|
|
|
Ist es ein "Wie mache ich X"-Prozess?
|
|
→ Skills (L3)
|
|
|
|
Ist es ein "Wir hatten Problem Y, Lösung war Z"-Eintrag?
|
|
→ Solution Doc (L5) + Hindsight-Index (L2)
|
|
|
|
Ist es ein vergangenes Gesprächsereignis?
|
|
→ LCM (L4) kümmert sich automatisch darum
|
|
```
|
|
|
|
## L0 — MEMORY.md vs USER.md
|
|
|
|
### USER.md (1.375 chars max)
|
|
**Nur:** Dominiks Persönliche Präferenzen, Safety-Rules, Kommunikationsstil
|
|
- "NIEMALS ohne Approval löschen"
|
|
- "Action-first, kein Dom"
|
|
- "Crash+Alert statt Silent Skip"
|
|
- "Laya in Sessions nutzen"
|
|
|
|
**NICHT:** Infra-Fakten, IP-Adressen, Versionsnummern, Team-Struktur
|
|
|
|
### MEMORY.md (2.200 chars max)
|
|
**Nur:** Komprimierte Pointer auf Wiki-Seiten + nicht-wikiffähige Quick-Facts
|
|
- `Frigate v0.18 CT151. →Wiki systems/frigate`
|
|
- `Galera:VM300/301/302,VIP .70. →Wiki systems/galera-maxscale`
|
|
- Baufinanz-Zahlen (persönlich, nicht im Wiki)
|
|
- LinkedIn Persona (Workflow, nicht im Wiki)
|
|
|
|
**NICHT:** Vollständige Specs, Konfigurationsdetails, lange Beschreibungen
|
|
|
|
## L1 — LLM Wiki
|
|
|
|
### Wann erstellen/aktualisieren?
|
|
- Bei jeder infrastrukturellen Änderung (Compound-Learning Cycle Phase 4.7)
|
|
- Neue Seite wenn: neues System, neuer Service, neue architektonische Entscheidung
|
|
- Patch wenn: Versionswechsel, IP-Änderung, Known Issue hinzugekommen
|
|
|
|
### Wann NICHT?
|
|
- Procedures → Skills (L3)
|
|
- Problem-Solution Pairs → Solution Docs (L5)
|
|
- Credentials → 1Password
|
|
|
|
## L2 — Hindsight
|
|
|
|
### Was gehört rein?
|
|
- **Semantische Pointer** auf Solution Docs und wichtige Meilensteine
|
|
- **Cross-Session Kontext** der nicht im Wiki steht (z.B. "wir haben am Datum X entschieden...")
|
|
- **Episodisches Wissen** über Projekte, Entscheidungen, Learnings
|
|
|
|
### Was NICHT rein gehört?
|
|
- ❌ Infra-Topologie (→ L1 Wiki)
|
|
- ❌ Aktuelle IPs/Versionsnummern (→ L1 Wiki, werden schnell stale)
|
|
- ❌ Procedures (→ L3 Skills)
|
|
- ❌ Credentials (→ 1Password)
|
|
- ❌ Session-Fortschritt (→ L4 LCM)
|
|
|
|
### Bekanntes Problem: Hindsight Accumulation
|
|
Hindsight hat über Monate Infra-Fakten angesammelt die inzwischen teilweise
|
|
veraltet sind (9 vs 8 Nodes, alte OSD-Counts). Hindsight bietet keine
|
|
Delete-Funktion via Tools. Strategie:
|
|
1. Zukünftig nur noch semantische Pointer + Entscheidungen speichern
|
|
2. Topologie-Fakten nicht mehr via `hindsight_retain` ablegen
|
|
3. Veraltete Einträge ignorieren — Hindsight Ranking bevorzugt neuere Memories
|
|
|
|
## L4 — LCM (Local Conversation Memory)
|
|
|
|
### Rolle
|
|
- **Innerhalb aktiver Session:** Compaction, Summary-DAG, Fresh Tail
|
|
- **Cross-Session (lcm.db):** Rohe Nachrichten + Summary Nodes aller Sessions
|
|
- **Kein manuelles Management nötig** — läuft automatisch
|
|
|
|
### Wann manuell eingreifen?
|
|
- `lcm_status` bei Verdacht auf Compression-Problemen
|
|
- `lcm_grep` um exakte Phrasen in vergangenen Sessions zu finden
|
|
- `lcm_recall` für bedeutungsbasierte Cross-Session-Suche
|
|
- Niemals manuell Daten in LCM schreiben — es ist Auto-Managed
|
|
|
|
## L5 — Solution Docs
|
|
|
|
### Wann erstellen?
|
|
- Nach substanziellem Bugfix (≥5 Tool-Calls)
|
|
- Nach Architektur-Änderung
|
|
- Nach komplexer Migration
|
|
- Nach schwierigem Troubleshooting
|
|
|
|
### Format
|
|
`~/docs/solutions/{type}/{YYYY-MM-DD}-{slug}.md`
|
|
Types: `architecture/`, `bugfix/`, `migration/`, `workflow/`
|
|
|
|
Immer: Hindsight-Index (`hindsight_retain`) nach Erstellung
|
|
|
|
## Related
|
|
- [[systems/hindsight]] — Hindsight Setup, API
|
|
- [[systems/laya]] — Laya Classifier
|
|
- Skill: `memory-sync` — Wiki Maintenance Protocol
|
|
- Skill: `software-development/compound-learning` — Phase 4.7 Wiki Update
|