Files

T

Claude 0b470b3e12 Resolve Q6/Q7/Q8/Q9/Q11; pin actual list names; add host tuning suggestions

Verified from screenshots:

- Q6/Q7 → Lists & calendars discovered by NAME, not by ID. Names confirmed:
  "Persönlich" (personal), "DLR" (work), "Einkaufsliste" (shopping),
  "Wunschliste" (wishes). Self-healing: #nexa:config runs daily and on
  cache-miss, so user-added lists become routable without code changes.
  Routing logic in docs/07 expanded from 2-way to 4-way switch with a
  Resolver step that consults the Qdrant _config cache before fanning out;
  default route is "Persönlich" when SAIA confidence < 0.7.
- Q8 → Single Nextcloud Mail account fkrebs@nucli.de. No separate IMAP.
  The "Waiting" folder is honored as a manual user signal — items there are
  excluded from digest.
- Q9 → Pocket-ID SSO is global at the Zoraxy layer; Nexa surfaces inherit
  it. No app-level basic-auth. Q10 folded in.
- Q11 → Capacity confirmed: 22 threads (Core Ultra 7 155H), 62 GiB RAM
  (~32 GiB used, ~24 GiB of which is ZFS ARC), 1.64 TiB disk (0.35%).
  Phase-3 budget (~7 GB) is comfortable; two levers documented (raise
  LXC cap, or cap zfs_arc_max). Earlier "16 CPU" references corrected.

Propagation:
- system_prime.txt rewritten with the four context labels and the new
  list names; legacy NC_LIST_ID_* placeholders removed.
- docs/04 integration matrix uses the German names directly.
- docs/05 documents that #nexa:config also runs scheduled and on
  cache-miss, with the example output reflecting real list IDs.
- docs/09 step 6 mirrors the same flow + lists the Waiting-folder
  semantics.
- CLAUDE.md gets an authoritative block of homelab decisions so future
  agents don't re-litigate any of these.

New section in docs/12 (#17–25): Proxmox host tuning suggestions
based on the live node summary — cap ZFS ARC (frees ~16 GiB),
enable KSM (~1-3 GiB savings across 40 containers), suppress the
no-subscription banner, drop swappiness, verify scrub/SMART/fstrim
timers, NTP via AdGuard.

2026-05-04 22:08:10 +00:00

3.7 KiB

Raw Blame History

05 — Command System (`#nexa:*`)

Nexa "hört" auf folgende Kommandos in Memos-Kommentaren oder als Memo-Inhalt mit Hashtag:

🔧 Konfigurations-Kommandos

#nexa:config

Beschreibung: Triggert Autodiscovery aller Services (Nextcloud Listen/Kalender, Qdrant Collections, LiteLLM-Modelle, Mail-Konto).
Läuft auch automatisch:
- Täglich (cron in n8n) — neue Listen / Kalender werden ohne manuelles Eingreifen aufgenommen.
- Bei Cache-Miss — wenn ein Workflow eine Liste/ID nicht mehr findet, läuft Discovery einmal, dann Retry.
Antwort: Postet Report mit den aktuellen Konfigurationen als Memos-Kommentar.
Speichert: Konfiguration in der Qdrant _config Namespace (nicht in .env).

#nexa:config

Beispiel-Response:

✅ Autodiscovery abgeschlossen (2026-05-04T23:59):
- Nextcloud Listen: Persönlich (id=14), DLR (id=dlr-1), Einkaufsliste (id=…), Wunschliste (id=…)
- Nextcloud Kalender: Persönlich, DLR, Einkaufsliste, Wunschliste
- Mail-Konto: fkrebs@nucli.de (Posteingang, Archiv, Junk, Waiting)
- Qdrant Collection: nexa_knowledge_text (1024 dims, Cosine, 0 Punkte)
- LiteLLM-Modelle: nexa-chat, nexa-embed

#nexa:status

Beschreibung: Zeigt den aktuellen System-Status
Antwort: Uptime, verbundene Systeme, Memory-Stats

#nexa:status

#nexa:sync-obsidian

Beschreibung: Triggert sofortige Synchronisierung mit Obsidian Vault
Optional Parameter: --vault=/path/to/vault oder --force für Neuindexierung

#nexa:sync-obsidian --force

📊 Memory & RAG Kommandos

#nexa:ask [question]

Beschreibung: Semantische Suche in Qdrant (RAG) basierend auf Obsidian + Memos
Antwort: Top-3 Treffer mit Quellen

#nexa:ask Wie implementierten wir das JWT-Middleware-Pattern?

#nexa:learn [topic]

Beschreibung: Explizit neue Information in Qdrant speichern (mit Tags)
Optional: --tag=architecture --source=obsidian/notes/arch.md

#nexa:learn Das Routing-Schema unterscheidet Work vs. Personal via SAIA-Kontext-Analyse --tag=architecture

🎯 Workflow-Kommandos

#nexa:route-test [text]

Beschreibung: Testet die Klassifizierung (Work/Personal) ohne Task zu erstellen

#nexa:route-test Muss morgen die Präsentation für den Client fertigstellen

Response:

💬 Klassifizierung (Test-Mode):
- Kontext: WORK
- Vertrauen: 0.95
- Begründung: "Client-Präsentation → professioneller Kontext"

#nexa:email-digest

Beschreibung: Triggert sofortige Email-Zusammenfassung (sonst tägl. 7 Uhr)

#nexa:email-digest

🔐 Admin-Kommandos

#nexa:reset-config

Beschreibung: Löscht gespeicherte Konfiguration, triggert neuen Autodiscovery
Warnung: Alle benutzerdefinierten Settings werden vergessen

#nexa:reset-config

#nexa:export-state

Beschreibung: Exportiert aktuellen State als JSON (für Backups)

#nexa:export-state

📝 Implementierung in n8n

Ein Command Parser läuft immer mit:

Memos Webhook empfängt alle Memos
Regex Check: Sucht nach #nexa:command
Router: Versendet an entsprechenden n8n-Workflow
Antwort: Postet Reply als Kommentar/Edit

Command Parser Regex:

^#nexa:(\w+)(?:\s+([^\n]*?))?(?:$|\s*--)

Extrahiert: [command, parameters]

🎛️ Dynamische Konfigurationsspeicherung

Statt .env zu editieren:

First Run: #nexa:config speichert zu lokalen Metadata
Speich-Ziel:
- Primary: Qdrant Metadata (als _config Namespace)
- Fallback: nexa-core/config/runtime_config.json (gitignored)
- Notfall: .env (nur initial)
Reload-Logik: Bei jedem Workflow-Start werden Settings aus Qdrant geladen

Das macht Nexa vollständig selbstständig nach dem initialem Setup!

3.7 KiB Raw Blame History

05 — Command System (#nexa:*)