Inputs — Wie kommen Informationen ins Ground Truth System?

Das System ist nur so gut wie die Disziplin, mit der Wissen reinfließt. Dieses Dokument beschreibt alle Eingabe-Kanäle, wie sie priorisiert sind, und das Kern-Prinzip, das sie zusammenhält.

Für die Entscheidung dazu siehe ../DECISIONS.md D26.

1. Design-Prinzip: One Write Function

Jeder Input-Kanal — ob Mensch, Agent, Import-Skript oder Webhook — endet mit dem einen Aufruf:

await core.brain.write(brain, { source, actor });

Diese Funktion übernimmt:

  1. Schema-Validation (AJV gegen brain.schema.json).
  2. Path-Generation (aus id → Filesystem-Pfad, Kollisionscheck).
  3. Atomarer Commit (git, strukturierte Message, Lock gegen Parallel-Writes).
  4. Audit-Spur (SQLite audit_log mit source, actor, timestamp).
  5. Sync-Invalidation (markiert Connections mit geänderten Feldern als "pending push").

Kanäle sind reine Normalisierer — sie transformieren ihre Quelle in ein gültiges Brain und rufen dann brain.write. Sie schreiben nie selbst Files, validieren nicht selbst, commiten nicht selbst. Das macht Konsistenz und Audit garantierbar.

2. Kanäle (MVP, Phase 3–4)

2.1 Web-UI

Business-Admin und Personal-User haben in Next.js gebaute Formulare:

  • Neues Brain — Typ auswählen, Pflichtfelder füllen, Markdown für Body.
  • Brain editieren — vorhandenes laden, Änderungen eingeben, validieren, committen.
  • Inline-Edit — H2-Sektionen direkt inline editierbar (für häufige Edits).

Im Hintergrund: POST /api/brain → core.brain.write.

2.2 CLI

gts add <brain-id>          # interaktiv: fragt Frontmatter-Felder ab
gts edit <brain-id>          # öffnet $EDITOR, validiert beim Schließen
gts capture "<text>"         # Quick-Capture in Inbox

Gleicher Pfad: CLI → core.brain.write.

2.3 MCP (für Agents)

Agents (OpenClaw, Hermes, Claude Code) reden über MCP mit ihrer eigenen Personal-Instanz:

brain.write(id, frontmatter, body)        # Neues oder komplettes Update
brain.append(id, section, content)        # Content unter einer H2-Sektion anhängen
brain.capture(text, tags?)                # Quick-Capture in Inbox

append ist kein Bypass — intern lädt es das Brain, fügt unter der Ziel-Sektion an, ruft dann write.

2.4 Direktes Filesystem-Editieren

Mensch öffnet brains/slow/werte.md in Cursor/Obsidian/vim, editiert, git add && git commit. Der pre-commit-Hook (installiert durch gts init) läuft core.brain.validate auf geänderte Dateien und blockiert bei Fehlern.

Hier ist core.brain.write nicht involviert — git ist direkt. Deshalb übernimmt der Hook dieselbe Validation (Schema, Link-Check, Orphan). Nur Schreibweg, der nicht durch write() läuft; wird mit denselben Regeln gesichert.

2.5 Quick-Capture Inbox

Die niederschwellige Variante. Niemand will für eine Mini-Idee ein vollständiges Frontmatter erfinden.

gts capture "Kunde X erwähnte Budget von 50k im Q3"

Erzeugt ein Inbox-Brain:

---
id: gustavo.inbox.2026-04-17-22-45-03
type: knowledge
layer: rapid
instance: gustavo
title: "Kunde X erwähnte Budget von 50k im Q3"
created: 2026-04-17
updated: 2026-04-17
tags: [inbox, untriaged]
---

Kunde X erwähnte Budget von 50k im Q3

Triage-Flow:

  • gts inbox list — zeigt alle untriagierten Einträge.
  • gts inbox triage <id> — Assistent: "Ist das ein Kunden-Learning? Ein Projekt-Update? Eine Idee?" — User wählt Ziel-Brain, System verschiebt Content, markiert Inbox-Entry als triaged.
  • Agent kann Triage automatisch machen (gts inbox triage --auto mit LLM-Hilfe) — bleibt aber User-bestätigt im MVP.

2.6 Import: Nori-Memory

Spezialisierter Adapter für die Nori-Migration:

gts import nori-memory --source /path/to/nori/agent/workspaces/<customer>/

Liest SOUL.md, MEMORY.md, HEARTBEAT.md eines Nori-Customers und mapped auf:

  • kuble.kunde.<slug> (Basis aus Customer-Config)
  • kuble.projekt.<slug> wenn Projects erkennbar
  • Agent-spezifische Inhalte in eine Personal-Brain-Instanz (wenn der User das will)

Nicht "alles importieren" — der Adapter fragt pro Customer, welche Inhalte wohin.

3. Kanäle (Später, Phase 6+)

3.1 E-Mail-Forward

capture@ground.kuble.com → Mail-Server parsed den Body → POST /api/capture mit Absender als Kontext.

3.2 Import-Adapter

Pro externer Quelle eigener Adapter (eigenes Package):

  • @gts/import-gmail — Threads als Brains importieren
  • @gts/import-notion — Notion-Pages → Markdown + Frontmatter
  • @gts/import-linear — Issues → Projekt-Brain-Notes
  • @gts/import-slack — Archivierte Channels → Kundenkontext
  • @gts/import-obsidian — Bestehendes Obsidian-Vault übernehmen
  • @gts/import-meeting — Whisper-Transkription + LLM-Summary → Learnings

Jeder Adapter implementiert ein ImportAdapter-Interface (@gts/core/import):

interface ImportAdapter {
  name: string;
  scan(source: ImportSource): Promise<ImportItem[]>;
  normalize(item: ImportItem): Promise<BrainInput>;
}

Der Adapter normalisiert, dann ruft der CLI-Wrapper core.brain.write für jeden Eintrag.

3.3 Quick-Capture überall

  • iOS-Shortcut → ruft /api/capture mit Geräte-Context (Location, Zeit)
  • Browser-Extension → "Save this page" mit ausgewählter Passage
  • System-weiter Hot-Key auf macOS (Raycast-Extension denkbar)

3.4 Automation

  • Webhooks — externe Services pushen in /api/webhook/<source>, werden nach Regeln (webhooks.yaml) in Brain-Updates übersetzt.
  • RSS/Atom — scheduled Pull, landet in inbox mit tags: [feed, <source>], User triage'd.
  • Agent-Synthese — Scheduled Agent-Job scannt rapid/-Brains, erzeugt Summary-Brains (z.B. "Wöchentlicher Kunden-Radar"). Läuft separat als Phase-7-Feature.

4. Was nicht reinkommt

Explizit ausgeschlossen, um Chaos zu vermeiden:

  • Rohe Dateianhänge (PDFs, Bilder, Audio) — Brain-Repo ist für strukturiertes Wissen. Große Binary-Files liegen in einem separaten Blob-Store (Phase 7+), verlinkt aus Brains via URL.
  • Realtime-Chat-Logs — keine Live-Replikation von Slack/Discord. Nur kuratiert, über Adapter.
  • Auto-Scrape aus Webseiten — passiert nicht automatisch; muss über Capture-Flow gehen (User entscheidet, was Wissen ist).
  • Duplikate ohne Gegen-Check — core.brain.write läuft Dedup-Heuristik (Titel-Similarity, Content-Hash) und warnt.

5. Triage-Qualität

Inbox ist Inbox — sie bleibt nicht ewig. Konvention:

  • Täglich 5 Min Triage (empfohlen, kein Zwang).
  • Agenten dürfen Inbox-Einträge vorschlagen, zu welchem Brain sie gehören, mit Begründung. User bestätigt oder korrigiert.
  • Inbox-Einträge > 30 Tage alt bekommen im UI einen Warn-Hinweis ("vielleicht triagieren?"). Nach 90 Tagen: separate Ansicht "archivierbar".

Inbox ist Ziel-orientiert, nicht als permanenter Speicher gedacht.