M2: 1:1 extraction of monolithic prompts from llm-gateway

Pulled the System-Prompts out of the three .js files in /root/llm-gateway/ on the Stream-Box-VPS, dropped them 1:1 as Markdown personas — no modularisation yet (that is M3). Personas: - personas/main-voice.md ← llm/gemini.js lines 64-172 (SYSTEM_PROMPT_VOICE + SYSTEM_PROMPT_INTRO) - personas/kreuzwort-builder.md ← orchestrator/kreuzwort-orchestrator.js lines 47-100 - personas/lueckentext-builder.md ← orchestrator/lueckentext-orchestrator.js lines 35-68 Plus README.md explaining the target topology (base/ + workflows/ + tools-context/ + personas/) and a skill-index.md stub that M4 will fill. Empty folders kept with .gitkeep so Git tracks the structure even before M3 starts populating them. Reference notes: arch-flow/brainstorm/Sprache/ 2026-06-02 — Master-Synthese — Prompt-Migration-Reihenfolge.md 2026-06-02 — Prompt-Modularisierung — Architektur und Composition.md Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-06-02 15:11:42 +02:00
commit f4f147e519
8 changed files with 640 additions and 0 deletions
@@ -0,0 +1,161 @@
+# parsecapere-prompts
+
+> Modulare System-Prompts fuer die parsecapere.de Voice-LLM-Plattform.
+> Single-Source-of-Truth fuer alles was das LLM als Anweisung liest.
+
+---
+
+## Warum dieses Repo existiert
+
+Bisher standen die System-Prompts als **3000-Token-Monolithen** direkt in den
+`.js`-Files des `llm-gateway`-Services. Drei harte Schmerzpunkte:
+
+| Schmerz                                  | Heute (Monolith)                       | Morgen (dieses Repo)          |
+|------------------------------------------|----------------------------------------|--------------------------------|
+| Reviewable im PR / Diff                  | nein — Template-String ueber 200 Zeilen | ja — Markdown-Diffs           |
+| Versionierbar pro Baustein               | nein — nur ueber gesamte `.js`         | ja — Git-Commit pro Modul      |
+| Hot-Reload ohne Service-Restart          | nein — `systemctl restart` (5s Downtime) | ja — Gitea-Webhook → Cache-Invalidate |
+| Token-Effizienz pro Sub-Agent            | nein — jeder bekommt alles             | ja — nur was er braucht (40-50% Einsparung) |
+
+Architektur-Hintergrund: `arch-flow/brainstorm/Sprache/2026-06-02 — Prompt-Modularisierung — Architektur und Composition.md`
+plus `2026-06-02 — Master-Synthese — Prompt-Migration-Reihenfolge.md`.
+
+---
+
+## Ordner-Struktur (Ziel-Topologie)
+
+```
+parsecapere-prompts/
+├── base/                       # Immer dabei (Boilerplate fuer ALLE Sub-Agents)
+│   ├── identity.md             # Wer bin ich (parsecapere-KI, helfe Sprachlernern …)
+│   ├── style.md                # Antwort-Stil + Sprache (Deutsch, freundlich, kurz)
+│   └── constraints.md          # Sicherheit, Privacy (audience-Feld!), Anti-Halluzination
+│
+├── workflows/                  # Pro Task-Typ relevant (nur einbauen wenn gebraucht)
+│   ├── plan-before-action.md   # record_thought / record_reflection-Disziplin
+│   ├── error-recovery.md       # Retry, Fallback, Backoff
+│   ├── self-correction.md      # Validate-Loop-Pattern (z.B. Kreuzwort-Grid)
+│   ├── sub-agent-discipline.md # KEIN record_*, KEINE Tools ausserhalb des Sets
+│   └── tool-scope-lock.md      # Strikte Tool-Liste, kein Erfinden
+│
+├── tools-context/              # Erklaert dem LLM was Tools tun
+│   ├── brick-creation.md       # createPulse / createView / createRow semantics
+│   ├── user-scoping.md         # audience + ownerUserName (Cookie-K3)
+│   ├── atomic-chain.md         # Strikt-sequenzielle atomic_create_*-Aufrufe
+│   ├── atomic-finalize.md      # Layer+Solution atomar in einem Call
+│   └── trace-viewer.md         # Phase E — trace-events fuer Overwatch
+│
+├── personas/                   # Pro Sub-Agent eine
+│   ├── main-voice.md           # User-Facing Voice (Session-Orchestrator)
+│   ├── kreuzwort-builder.md    # Sub-Agent fuer Kreuzwort-Aufgaben
+│   ├── lueckentext-builder.md  # Sub-Agent fuer Lueckentext-Aufgaben
+│   ├── overwatch.md            # Phase E — Read-Only-Beobachter (geplant)
+│   └── doc-writer.md           # Phase G — Code-Doku (geplant)
+│
+└── skill-index.md              # Discovery-Index — was gibt's, mit welchem Trigger
+```
+
+**Drei Schichten** — von "immer" bis "spezifisch":
+
+```
+[ base/         ] ← immer da, Boilerplate
+[ workflows/    ] ← Task-Typ
+[ tools-context/] ← welche Tools nutzt der Agent
+[ personas/     ] ← wer bin ich konkret  ← Tie-Breaker, kommt zuletzt
+```
+
+> 💡 **Persona kommt zuletzt** im Compose-Output — sie darf alles davor ueberschreiben.
+
+---
+
+## Status-Stand (heute, 2026-06-02)
+
+### Phase M2 — DONE
+- Drei Personas 1:1 aus dem JS-Code extrahiert:
+  - `personas/main-voice.md` ← `llm/gemini.js` (SYSTEM_PROMPT_VOICE + SYSTEM_PROMPT_INTRO)
+  - `personas/kreuzwort-builder.md` ← `orchestrator/kreuzwort-orchestrator.js`
+  - `personas/lueckentext-builder.md` ← `orchestrator/lueckentext-orchestrator.js`
+- `base/`, `workflows/`, `tools-context/` sind **leer** (Ordner existieren als Marker).
+- `skill-index.md` ist ein **Stub** — wird in M4 gefuellt.
+
+### Phase M3 — NEXT (geplant)
+- Diff zwischen den drei Personas → Boilerplate identifizieren.
+- Extraktion in `base/`, `workflows/`, `tools-context/`.
+- Personas auf "wirklich Unique" trimmen.
+- **Jeder Extract = eigener Commit** mit aussagekraeftiger Message.
+
+### Phase M4 — danach
+- Skill-Manifeste im separaten Repo `parsecapere-skills`.
+- `skill-index.md` mit echten Eintraegen befuellen.
+
+### Phase M5 — danach
+- `mcp-gitea`-Service auf LLM-VPS (Tools: `load_skill`, `list_skills`, `load_prompt_module`).
+- STDB-Cache (`gitea_section_cache`-Tabelle).
+- Webhook-Endpoint `/webhook` fuer Cache-Invalidation.
+
+Voller Plan: siehe Vault-Note `2026-06-02 — Master-Synthese — Prompt-Migration-Reihenfolge.md`.
+
+---
+
+## Compose-Order (zukuenftig fuer mcp-gitea)
+
+Wenn ein Skill geladen wird, baut der Composer den finalen System-Prompt
+in **dieser Reihenfolge** zusammen:
+
+```
+1. base/identity.md
+2. base/style.md
+3. base/constraints.md
+4. workflows/*  (deklariert im Skill-Manifest)
+5. tools-context/*  (abgeleitet aus required_tools)
+6. personas/<persona>.md  ← LETZTER, ueberschreibt frueheres
+```
+
+Der Compose-Algorithmus ist im Detail in
+`arch-flow/brainstorm/Sprache/2026-06-02 — Prompt-Modularisierung — Architektur und Composition.md`
+beschrieben.
+
+---
+
+## Cross-Repo
+
+Dieses Repo (`parsecapere-prompts`) liefert die **Prompt-Bausteine**.
+Zwei Schwester-Repos auf demselben Gitea (https://gitea.parsecapere.de):
+
+| Repo                    | Inhalt                                                            |
+|-------------------------|-------------------------------------------------------------------|
+| `parsecapere-prompts`   | dieses Repo — Module + Personas                                    |
+| `parsecapere-skills`    | Skill-Manifeste (welche Module wann zusammensetzen)                |
+| `parsecapere-knowledge` | Lang-laufendes Wissen (z.B. Vokabel-Listen, Wortpool-Snapshots)    |
+
+---
+
+## Architektur-DNA-Bezug
+
+Dieses Repo respektiert:
+
+- **Server denkt, Frontend rendert** — Composition passiert serverseitig im `mcp-gitea`-Service.
+- **STDB als Smart-Cache** — Module werden bei Bedarf aus Gitea geholt + in STDB
+  (Tabelle `gitea_section_cache`) gecached. Webhook invalidiert pro Pfad.
+- **Cookie-K1-K6** — Compose-Endpoint im LLM-Gateway ist intern (Service-Token,
+  nicht User-Cookie). Cross-Server-Auth via Token-Bundling (K5) wenn LLM im
+  Auftrag eines Users handelt.
+- **Hard-Rules STDB-Migrationen** — neue Tabelle `gitea_section_cache` braucht
+  Pre-Backup + additive Migration (siehe `migrations/MIGRATIONS-HARD-RULES.md`).
+- **Skill = Loadable Module** — kein Hard-Coded-Mapping, Discovery via
+  Trigger-Keywords (siehe `2026-06-01 — Skill-Sets als Loadable Modules …`).
+
+---
+
+## Hinweis fuer Tim's Review (M2-Aha-Moment)
+
+Lies die drei `personas/*.md` der Reihe nach. Ziel: zum ersten Mal sehen,
+**was der Voice-LLM bisher als Anweisung bekommen hat** — als reine,
+lesbare Markdown-Texte ohne JS-Drumherum.
+
+Erwartete Beobachtungen:
+- Wieviel Boilerplate steht da drin? (→ M3 zieht das raus)
+- Wo wiederholen sich die drei Personas? (→ M3 macht draus `base/` und `workflows/`)
+- Wo ist Domain-Wissen? (→ bleibt in der Persona)
+
+Notiere was dir auffaellt — das wird der Input fuer M3.