---
name: always-read-brain-proactively
description: "Standing Order — bei jeder Entscheidung/Antwort aktiv ins Brain UND in den Code-Tree reinlesen, nicht nur Active-Memory-Hits konsumieren"
metadata: 
  node_type: memory
  type: feedback
  originSessionId: a797444d-f638-4793-9109-583ec26e97d3
---

Bei jeder Entscheidung, Antwort oder Implementation die Brain-Notes UND den relevanten Code-Tree aktiv lesen (Read-Tool auf Dateien, ls auf Verzeichnisse), nicht nur die Active-Memory-Top-3-Hits aus `aria-active-memory.sh` konsumieren.

**Why:** Kais hat das 13.05.2026 nach AKP-Briefing-Frage bestätigt mit „Go! Immer mein Brain lesen". Dieselbe Session zeigte das Problem doppelt:
- KAR-75 (Skill `eval-driven-agent-dev`) war schon gebaut — AKP-Briefing wusste es nicht
- KAR-38 (AI-Radar Sprint B) hatte schon ein monolithisches Skript `/root/aria/scripts/aria-radar-fetch.py` (12.05.2026 23:07), aktive systemd-Unit, Bluesky-403-Bug — Aria baute parallel ein modulares Sprint B in `scripts/ai-radar/`, ohne `ls scripts/` zu prüfen

Beide Fälle entstanden weil Aria sich auf Brain-Search/Memory verlassen hat, statt vor Implementation die *tatsächlichen Artefakte* (Skill-Dateien, Skripte, systemd-Units, Linear-Issue-Status) zu prüfen.

**How to apply:** 
- Vor jeder Sparring-Antwort, Empfehlung oder Skill-/Architektur-Entscheidung: relevante Brain-Note(s) per Read-Tool öffnen
- Vor jeder neuen Implementation: 
  - `ls` auf Ziel-Verzeichnis(se) — gibt es schon Code mit gleichem Zweck?
  - Linear-Issue-Status prüfen (Backlog / In Progress / Done)
  - `find` / `grep` nach Schlüssel-Funktionalität
  - bei Aria-Modul: nach Service-Name in systemd suchen
- Bei Audits/Vergleichen (z.B. Skill vs Brain-Erkenntnis): immer Full-Read der Brain-Quelle
- Triff Entscheidungen nicht nur aus Memory-Snippets — Full-Read der Note + Code-Check
- Verwandt: [[feedback_brain_documentation_pflicht]] (Schreiben), [[feedback_research_aria_first]] (Recherche-Fokus)