---
task_slug: kar-80-hook-memory-injection
doc_type: analysis-map
kar_issue: KAR-80
related_brain_notes: [[2026-05-12-latentspacepod-openclaws-memory-sucks-and-the-fix-is-si]], [[openclaw-vs-aria-2026-05-08]]
date: 2026-05-12
status: done
---

# Analysis Map — KAR-80 Hook-Memory-Injection (Spike)

## Ziel des Tasks (1 Satz)

Spike: prüfen ob ein UserPromptSubmit-Hook (Claude-Code) das existierende `aria-active-memory.sh` Skript automatisch triggert sodass Aria deterministisch bei jedem Aria-Turn Brain-Context bekommt, statt nur wenn Aria selbst `aria-brain-search` aufruft.

## Stand: Was existiert bereits

| Komponente | Status | Pfad |
|------------|--------|------|
| `aria-active-memory.sh` | ✓ existiert (V5 Sprint 2) | `/root/aria/scripts/aria-active-memory.sh` |
| `aria-brain-search.py` BM25 + Recency | ✓ funktioniert (heute Bug-Fix) | `/root/aria/scripts/aria-brain-search.py` |
| Memory-Files in `/root/.claude/projects/-/memory/` | ✓ 30+ Einträge | siehe MEMORY.md |
| Brain-Vault mit 100+ Notes | ✓ live | `/root/aria/brain/` |
| UserPromptSubmit-Hook | ✓ existiert (telegram-log-in.sh) | `/root/.claude/hooks/telegram-log-in.sh` |

## Stand: Was fehlt

- `aria-active-memory.sh` wird NICHT automatisch aufgerufen — Aria muss es selbst triggern
- Brain-Note formuliert das exakt: "Tool-based Memory ist fragil weil das Modell entscheiden muss zu suchen — Hooks erzwingen Kontext."

## Files die berührt werden

| Pfad | Symbol | Lese/Schreibe | Risiko |
|------|--------|---------------|--------|
| `/root/.claude/hooks/auto-memory-inject.sh` | new | Create | low (separates Hook, kein Conflict) |
| `/root/.claude/settings.json` | UserPromptSubmit hooks array | Add entry | medium (Hook-Reihenfolge wichtig) |
| `/root/aria/scripts/aria-active-memory.sh` | existing | Read only (vielleicht --hook-mode flag) | low |
| `/root/aria/evals/hook-memory-injection/` | new | Create | low (Eval-Setup für Vergleich) |

## Standing Orders / LRNs die greifen

- LRN-20260508-002 — Active Memory bei Telegram-Inbound (genau das was wir auto-trigger machen wollen)
- Memory `feedback_pre_output_critic_lint_cases` — Hook-Pattern in `update-config` Skill richtig handhaben
- Standing Order `pre-output-critic.sh` Pattern (existing Hook der `eval-lint.py` triggert) — gute Referenz für Skript-Struktur

## Cross-References

- [[2026-05-12-latentspacepod-openclaws-memory-sucks-and-the-fix-is-si]] — Quelle (conf 0.82)
- [[openclaw-vs-aria-2026-05-08]] — Vergleich-Doc, Aria-Stand-Heute Memory-Architektur
- KAR-75 (eval-driven-agent-dev) — die Eval-Methodik die ich für den Vorher-Nachher-Vergleich nutze
- KAR-80 (Linear-Issue)

## Risiken / Unbekanntes

1. **Token-Overhead**: Brain-Note nennt <2k Tokens-Budget. Wenn Hook 5k injiziert pro Turn, drückt es Aria's effective context massiv. Hard-Cap nötig.
2. **Latenz**: Hook MUSS schnell sein (<2s) sonst spürt der User Verzögerung bei jeder Reply.
3. **Recall vs Precision**: Falsche Memories injiziert können Aria irrelevant verleiten. Wave-Resonance/BM25 müssen passen.
4. **Stale Profile**: statisches `aria-user-profile.md` ist USER.md bereits. Duplikation oder Pointer?
5. **Hook-Stacking**: existing `telegram-log-in.sh` läuft schon bei UserPromptSubmit. Neuer Hook MUSS unabhängig sein, nicht abhängig von Log-Success.
6. **Test-Mode**: bei Aria-Restart-Smoke darf Hook nicht crashen, nur warn/skip.

## Out of Scope (Spike)

- **KEIN globaler Rollout** — erst Pilot in 1-2 echten Aria-Workflows, dann Decision
- **KEIN neuer Knowledge-Graph** — Brain-Vault bleibt Source-of-Truth
- **KEINE Wave-Resonance-Implementation** — BM25+Recency aus `aria-brain-search.py` reicht für Spike
- **KEINE Forgetfulness-Logik** (das ist Memory-Curator-Job, KAR-Memory-Roadmap)
