# ADR-001: Structured Memory Blocks

## Status

Accepted

## Kontext

Hermes Memory ist aktuell flaches Key-Value. Der Nutzer speichert manuell:
```
memory: "User prefers tables with │ separators"
```

Das Problem:
- Keine Typisierung (ist das eine Präferenz, ein Fakt, ein Projekt-State?)
- Keine Verknüpfung (welches Projekt? welche Person?)
- Keine Temporalität (wann gespeichert? wann zuletzt genutzt?)
- Keine Confidence (wie sicher ist die Extraktion?)
- Keine automatische Extraktion (Nutzer muss manuell speichern)

## Entscheidung

Wir führen **Structured Memory Blocks** ein:

```yaml
memory_block:
  id: "uuid"
  type: "user_preference" | "project_state" | "learned_pattern" | "entity_relationship" | "procedural"
  category: "formatting" | "workflow" | "tech_stack" | "contact" | "project" | "skill"
  key: "table_style"
  value: "compact with │ separators"
  source: "session_2026-06-03"
  confidence: 0.95
  entities: ["Flo", "waldseilgarten-crm"]
  created_at: "2026-06-03T14:30:00Z"
  updated_at: "2026-06-03T14:30:00Z"
  access_count: 1
  last_accessed: "2026-06-03T14:30:00Z"
```

## Konsequenzen

### Positiv
- Typisierung ermöglicht gezieltes Retrieval ("gib mir alle Präferenzen des Users")
- Entity-Linking ermöglicht Kontext-Navigation ("was wissen wir über Projekt X?")
- Temporalität ermöglicht "letzter Stand"-Abfragen
- Confidence ermöglicht Filterung nach Qualität
- Auto-Extraction kann strukturiert speichern

### Negativ
- Komplexer als Key-Value
- Migration bestehender Memories nötig
- Mehr Speicherplatz pro Memory

## Alternative

Key-Value beibehalten + Tags hinzufügen:
```
memory: "User prefers tables with │ separators"
tags: ["user_preference", "formatting", "Flo"]
```

Abgelehnt: Tags sind nicht strukturiert genug für Entity-Linking und Temporalität.

## Implementierung

1. SQLite-Schema für Memory Blocks
2. Migration bestehender `memory` Einträge
3. Erweitertes `memory` Tool in Hermes
4. Auto-Extraction produziert Blocks statt Strings

## Datum

2026-06-03