fkrebs/nexa
1
0
Fork 0
Code Issues 1 Pull Requests Actions Packages Projects Releases Wiki Activity

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

Browse Source 
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.
This commit is contained in:
Claude
2026-05-04 22:08:10 +00:00
parent e1c2ba96e2
commit 0b470b3e12
8 changed files with 100 additions and 36 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/07-workflow-spec.md
+16 -6
View File
@@ -5,12 +5,22 @@
* **Filter:** `payload.content` enthält `- [ ]` ODER `#todo`.
## 2. Intelligence Node (SAIA)
* **Prompt:** "Analysiere folgende Notiz. Gib als JSON zurück: { "context": "work" | "personal", "summary": "string", "urgency": 1-5 }."
* **Prompt:** "Analysiere folgende Notiz. Gib als JSON zurück: `{ "context": "work" | "personal" | "shopping" | "wishes", "summary": "string", "urgency": 1-5 }`."
* **Kontext-Zufuhr:** Lade die letzten 5 Obsidian-Projekttitel aus Qdrant als Referenz hoch.
## 3. Switch Node
* **Route 1:** Context == "work" -> Nextcloud Create Task (List ID: Work).
* **Route 2:** Context == "personal" -> Nextcloud Create Task (List ID: Personal).
## 3. List Resolver (vor dem Switch)
* Lese den Cache `nexa._config.lists` aus Qdrant: `{ "Persönlich": <id>, "DLR": <id>, "Einkaufsliste": <id>, "Wunschliste": <id>, discovered_at: <ts> }`.
* Bei Cache-Miss oder 404 vom nachfolgenden Create-Task → triggere `#nexa:config` (Discovery), update den Cache, retry **einmal**.
## 4. Feedback Loop
* Poste die Task-ID und den gewählten Kontext als Kommentar unter das Original-Memo.
## 4. Switch Node (4-Wege)
* **Route 1:** `context == "work"` → Nextcloud Create Task auf Liste `DLR`.
* **Route 2:** `context == "personal"` → Nextcloud Create Task auf Liste `Persönlich`.
* **Route 3:** `context == "shopping"` → Nextcloud Create Task auf Liste `Einkaufsliste`.
* **Route 4:** `context == "wishes"` → Nextcloud Create Task auf Liste `Wunschliste`.
* **Default (Konfidenz < 0.7):** `Persönlich` (siehe [06](./06-classification-logic.md)).
## 5. Feedback Loop
* Poste die Task-ID und den gewählten Kontext als Kommentar unter das Original-Memo.
## 6. Listen-Diskoverability
Listennamen sind nicht hardgecodet — die Resolver-Step liest sie aus dem Runtime-Config-Cache. Wenn der User in Nextcloud eine neue Liste anlegt (z. B. `Reisen`), erscheint sie nach dem nächsten geplanten `#nexa:config`-Lauf (täglich) automatisch als Routing-Ziel — die System-Prompt der Intelligence Node wird zusammen mit den verfügbaren Listen versorgt, sodass SAIA neue Kontexte vorschlagen kann.