Skip to content

07 — Workflow Spec: Phase-2 Task-Router

1. Trigger

  • Typ: Webhook (Memos)
  • Filter: payload.content enthält - [ ] ODER #todo.

2. Intelligence Node (SAIA)

  • 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. 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. 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).

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.