Viaviva Agentensystem 2026 — Strategie-Foundation

Stand: 2026-04-27 Status: Arbeitspapier — Grundlage für alle künftigen Bauentscheidungen Vorgänger: agentensystem-konzept-2026.md (Entwurf v0.1, von Chapaty) Autor dieser Fassung: Claude Code, basierend auf dem Konzept-Entwurf plus Live-Beobachtungen am bestehenden Stack Geltungsbereich: alle Bau-, Migrations- und Betriebsentscheidungen rund um das Agentensystem auf dem Hostinger-VPS

---

0. Vorwort — Was dieses Dokument ist

Das ist die finale Strategie-Foundation, gegen die ab sofort alle Architektur-Entscheidungen geprüft werden. Es ersetzt das Konzept-Dokument als Arbeitspapier. Der Konzept-Entwurf hat den richtigen Geist, lässt aber an entscheidenden Stellen offen, was im Praxis-Test passieren würde — vor allem hardware-seitig und operations-seitig. Diese Fassung schließt diese Lücken und macht harte Entscheidungen, wo der Entwurf noch im Konjunktiv blieb.

Die wichtigste Botschaft vorab: wir bauen nicht das beste denkbare System, sondern das beste betreibbare System mit dem was wir haben. Hardware-Limit, Bus-Faktor 1, Compliance-Risiko — das sind harte Anker, nicht Variablen.

---

1. Bilanz aus zwei Iterationen

V1 (OpenClaw-Stack, gescheitert in der Praxis)

Was kaputt war:

• CPU-Sättigung: ein qwen3:14b-Call blockierte 7 von 8 Kernen für minutenlange Inferenz. Während dieser Zeit war das System für andere Tasks praktisch tot. Beobachtet am 2026-04-27 mit Load-Average 7.34.
• Persona-Inflation: acht Personas (Lenny, Howard, Sheldon, Amy, Raj, Zack, Bernadette, Penny) mit eigenen Prompts und Schablonen-Zuordnungen — funktional waren das aber nur drei Modell-Größen mit unterschiedlichen System-Prompts. Komplexität ohne Gewinn.
• OpenClaw als Engine redundant: alle Funktionen (Telegram-Trigger, LLM-Call, Tool-Dispatch) macht n8n nativ. OpenClaw war ein zusätzlicher Failure-Mode, kein Mehrwert.
• Eigenbau-Wiki + Snippet-Lernschleife: wurde nie produktiv. Standard-Lösungen (pgvector + Markdown-Files) hätten gereicht.

V2 (Konzept-Doc, korrekt erkannt)

Was V2 richtig macht:

• ✅ Verschiebung von "Agent-First" zu "Stack-First mit LLM-Veredelung"
• ✅ Eskalations-Pyramide von "kein LLM" bis "Cloud-LLM"
• ✅ Eigentums-Trennung GFKB ↔ Eigenmarken (Werkstattbuch vs. Lieferschein)
• ✅ Brand-Wiki + Q+A-Wiki als gezielter LLM-Kontext
• ✅ Wegfall von OpenClaw, LiteLLM, media_server.py, Persona-Inflation

Was V2 noch offen lässt oder zu schwach behandelt:

• ❌ Embedding-Modell ist nicht klar benannt (qwen3:1.7b ist generativ, nicht für Embeddings geeignet)
• ❌ Stack-Sprawl: 17+ Komponenten ohne Bus-Faktor-Plan
• ❌ Compliance (HWG) ist als "ungeklärt" markiert, ist aber Phase-Voraussetzung
• ❌ Cloud-LLM-Routing (Kimi vs Codex vs Claude) ohne Regeln
• ❌ Hardware-Upgrade-Trigger ohne konkrete Schwellen
• ❌ Mailcow als Big-Bang-Migration ohne Reputation-Aufbau
• ❌ Plugin v2 als ein Phase-Schritt — realistisch ein eigenes Software-Projekt
• ❌ Migrations-Pfad aus dem aktuellen Stack (/root/templates/, viaviva-sync, 41 Wiki-MDs) nicht beschrieben

---

2. Drei harte Architektur-Anker

Anker 1: Die Hardware ist die Grenze

8 vCPU AMD EPYC, 32 GB RAM, kein GPU. Punkt. Jede Architektur-Entscheidung wird gegen diesen Anker geprüft.

Konkrete Implikationen, gemessen am bestehenden System:

• qwen3:14b auf CPU: ~5–7 Tokens/s, eine 500-Token-Antwort braucht ~80–100 Sek, frisst 7 Kerne
• qwen3:8b auf CPU: ~10–14 Tokens/s, eine 500-Token-Antwort braucht ~40–50 Sek
• qwen3:1.7b auf CPU: ~30–40 Tokens/s, gut für Klassifikation
• Embedding-Modelle (z. B. all-MiniLM-L6-v2, 22M Params): ~200 Embeddings/Sek auf CPU, vernachlässigbar

Daraus folgt das LLM-Verbots-Schild:

• 14B in interaktiven (sub-30-Sek-Latenz) Pfaden: VERBOTEN
• 14B in semi-interaktiven Pfaden (Telegram-Approval-Flow): nur wenn explizit getriggert
• 8B parallel: maximal eine 8B-Inferenz gleichzeitig (sonst RAM-Druck und Throughput-Halbierung)
• 1.7B parallel: maximal zwei gleichzeitig
• Permanent geladenes Modell: maximal eines (8B keep-alive, alle anderen on-demand)

Anker 2: Eine-Person-Operation ist die Grenze

Chapaty allein betreibt das System. Das heißt:

• Maximal ~12 Komponenten zentral. Jede zusätzliche Komponente kostet Wartungs-Aufmerksamkeit. Die Liste im Konzept-Doc (17+ Systeme) muss reduziert werden.
• Jede Komponente muss self-healing oder dokumentiert-debuggbar sein. Wenn etwas hängt, muss in 10 Minuten klar sein wo.
• Bus-Faktor 1 ist akzeptiert, aber abgesichert: Notfall-Doku in Vaultwarden + 2nd-Operator-Liste.
• Build vs. Buy: Open-Source ja, aber zwischen "1 Std Setup" (Listmonk) und "1 Woche Setup + permanente Wartung" (Mailcow) muss bewusst gewählt werden.

Anker 3: LLM ist Veredelung, nicht Engine

Wo immer möglich, lebt der Workflow ohne LLM. LLM kommt erst dazu wenn:

• Sprache verstanden werden muss (Email-Klassifikation, Sentiment)
• Sprache produziert werden muss (Personalisierung, Long-Form-Content)
• Ambige Klassifikation nötig ist (für die Regex/Heuristik nicht reicht)

Reihenfolge in jedem Workflow:

1. Deterministische Regel oder DB-Lookup zuerst
2. Embedding + pgvector-Match zweitens
3. Lokales kleines LLM (1.7B) für Klassifikation
4. Lokales 8B nur wenn Personalisierung nötig
5. Cloud-LLM nur wenn Long-Form oder Reasoning-Tiefe gefragt
6. 14B nur als Batch-Job im Nachtfenster

Anker 4: Bottom-Up, Demand-Driven — das Wachstums-Prinzip

Das System wird nicht im Voraus aufgebaut, sondern wächst aus konkreten Schmerzpunkten.

Konkret bedeutet das:

1. Phase 1 (Stack-Foundation) ist Pflicht — Postgres+pgvector, TEI, Uptime-Kuma, gereinigtes n8n. Das ist Plumbing das jeder Workflow brauchen wird, ohne es geht nichts.
2. Alle anderen Phasen sind Patterns, keine Projekte. Sie werden aktiviert wenn Chapaty sagt: "diesen Flow will ich jetzt automatisiert haben".
3. Reihenfolge: zuerst Projekt sauber aufsetzen (Chapaty + Claude Code, manuell), dann den konkreten manuellen Flow identifizieren der wiederkehrt, dann diesen einen Flow automatisieren.

Anti-Pattern (vermeiden): "Lass uns das gesamte Email-Workflow-Subsystem bauen, weil wir irgendwann Mails automatisch beantworten wollen."

Pattern (anwenden): "Ich beantworte gerade zum dritten Mal die gleiche Frage zu Lakhowsky-Geräten. Bau diesen einen Q+A-Eintrag mit Auto-Reply für genau diesen Fragetypen, andere Mails laufen weiter manuell."

Vorteile dieses Vorgehens:

• Jede Automation ist im Praxiseinsatz validiert bevor sie existiert (Chapaty hat den Flow manuell mehrfach gemacht und kennt die Edge-Cases)
• Keine Phantom-Features die niemand nutzt
• Token-/Latenz-Budgets sind aus realer Erfahrung kalibrierbar, nicht geraten
• Kein "Big-Bang"-Risiko — wenn ein einzelner automatisierter Flow versagt, bricht nicht das ganze System
• Wartungs-Last wächst nur mit echtem Wert

Operatives Vorgehen pro Automatisierungs-Auftrag:

1. Chapaty: "Ich will diesen Flow automatisieren: [konkrete Beschreibung]"
2. Claude Code prüft:
   - Welche Daten/Eingaben?
   - Welcher Output?
   - Welche Bestandsysteme angetastet?
   - Welche LLM-Stufe nötig (siehe Pyramide)?
   - Welche Tabu-Wort-Liste / Compliance-Schicht?
3. Auftragsdokument schreiben — kompakt, aufs Foundation-Doc verweisend
4. Bauen — eng gescopt, ein einziger Workflow
5. Mit Chapaty 5–10 reale Cases manuell durchspielen (Approval-Loop)
6. Wenn Approval-Quote stabil > 80 %: Auto-Pfad freischalten
7. Wenn nicht: Workflow stillgelegt oder Q+A-Wiki-Eintrag verfeinert

Das ist der Pulsschlag. Jede Phase 2-X im roadmap-Sinne ist eine Sammlung solcher Patterns die bei Bedarf aktiviert werden, kein Master-Plan zur Komplett-Realisierung.

---

3. Stack-Entscheidungen final

3.1 Was bleibt aus dem aktuellen Stack

3.2 Was kommt neu rein (priorisiert)

3.3 Was bewusst gestrichen wird gegenüber V2

3.4 Embedding-Modell-Entscheidung

V2 lässt das offen. Hier die Festlegung:

Lokal: intfloat/multilingual-e5-small (118M Params, 384-dim, deutsch+englisch+spanisch). Läuft als Docker-Container text-embeddings-inference (TEI, von HuggingFace). CPU-Performance: ~50–100 Embeddings/Sek bei kurzen Texten. RAM: ~500 MB. Rationale: deutsch-fähig, klein genug, etabliertes Modell.

Cloud (Fallback bei Long-Document-Embeddings): OpenAI text-embedding-3-small ($0.02 / 1M Tokens). Nur wenn lokal nicht reicht (selten — Q+A-Einträge sind kurz).

Vector-Dimension: 384. pgvector-Schema entsprechend.

---

4. Die kanonischen Workflows

Jeder Workflow hat ein Token-/Latenz-Budget, das eingehalten werden muss. Übersteigt der Workflow das Budget, wird er umgeschrieben oder eskaliert.

4.1 Email-Eingang (Standard-Workflow)

Mail kommt rein
 → n8n IMAP-Trigger (latency: ~10s nach Eingang)
 → Spam-Regex/SPF-Check (latency: 50ms, kein LLM)
 → Auftrag-Versuch-Detection (Keywords "möchte beauftragen", "bitte erstellen")
   → Wenn ja: Auto-Reply "Aufträge nur via Telegram", Ende
 → Embedding der Email mit TEI (latency: 200ms)
 → pgvector kNN gegen qa_entries WHERE brand=X (latency: 50ms)
 → Top-Match score:
    > 0.85 + use_count >= 5 + approved → Auto-Reply mit gespeichertem Template, Telegram-Info
    0.70–0.85 → 1.7B-LLM personalisiert das Template, Telegram-Approval
    < 0.70 → Cloud-LLM Draft, Telegram-Approval (ausführlicher)
 → Eintrag in Perfex (für GFKB-Mails: zusätzlich Perfex-GFKB-API-Call)

Budget pro Mail:

• Latenz total bis Versand: < 30 Sek bei Auto-Reply, < 5 Min bei Approval-Pfad
• Tokens lokal: max 1500 (HF-Brand-Voice 800 + Q+A-Vorlage 300 + Email-Inhalt 400)
• Tokens Cloud: max 4000 pro Draft, max 50 Drafts pro Tag (Hard-Cap)

4.2 Newsletter-Versand

Grundsatz: Newsletter ist lokal, weil hier der Agent-Wert sichtbar werden soll. Drafting auf qwen3:8b (notfalls 14B-Batch), Versand über schlanke Mail-Loop.

Telegram: "Newsletter Donnerstag 19h zum Thema X"
 → n8n erstellt Markdown-Auftragseintrag
 → qwen3:8b lokal Draft mit:
    - Brand-Voice-Wiki (max 1500 Token)
    - Compliance-Tabu-Wiki (max 800 Token)
    - 1 Beispiel-Newsletter aus Archiv (max 1500 Token)
    - Briefing (max 500 Token)
   = ca. 4300 Input-Token, ~1200 Output-Token, ~120 Sek lokal
 → Telegram an Chapaty: Draft mit Edit/Approve/Reject
 → Bei Re-Draft mit Korrektur: 2. Iteration ebenfalls 8B
 → Bei nicht-trivialer Komplexität (z. B. Layoutgerechtes HTML mit Variablen): Eskalation auf Kimi K2 (Subscription, kein Per-Token-Cost)
 → Bei Approve: Versand-Pfad wählen
 → Folgetag: Telegram-Report (Open-Rate, Click-Rate)
 → /erledigt/-Eintrag mit Lessons-Learned

4.2.1 Versand-Pfad — zwei Varianten

Pfad A — Listmonk (Standard für > 50 Empfänger):

• Listmonk hat Kampagnen-Engine, Bounce-Handling, Open/Click-Tracking, Subscriber-Management
• Bereits deployed, läuft ohne Aufmerksamkeit
• Empfehlung: Default-Pfad

Pfad B — Pure-SMTP-Loop (Alternative für < 50 Empfänger oder personalisierte 1:1-Mails):

• n8n iteriert über Empfänger, schickt eine Mail nach der anderen via SMTP
• Vorteile: jede Mail wirkt wie eine echte 1:1-Mail (höhere Deliverability, kein Bulk-Flag), keine zusätzliche Software-Wartung, vollständige Kontrolle pro Empfänger
• Nachteile: Open/Click-Tracking muss eigener Pixel + Link-Wrapper sein, Bounce-Handling über IMAP-Read, Unsubscribe-Link selbst implementiert
• SMTP-Rate-Limit beachten (all-inkl: ~100/h, Brevo: 300/Tag, Mailcow: konfigurierbar)
• Empfehlung: für hochwertige B2B-Mails (Lead-Recherche-Outreach), GFKB-Compliance-Mails, oder kleine Mitglieder-Segmente

Entscheidungs-Kriterium:

• Liste > 50 + standardisierter Inhalt → Pfad A (Listmonk)
• Liste < 50 + personalisiert oder reputations-sensitiv → Pfad B (SMTP-Loop)
• Beim Aufsetzen jedes Newsletter-Workflows wird der Pfad explizit gewählt und dokumentiert

Budget pro Newsletter:

• Cloud-Cost: $0 im Standard-Fall (alles lokal, qwen3:8b)
• Bei Eskalation auf Kimi: $0 (Subscription)
• Bei pathologischer Eskalation auf Claude-API: max $1 mit Justification
• Subscription-Quota: 0 Calls im Standard-Pfad
• Latenz Draft-Generierung: ~120 Sek lokal (vs. 30 Sek Cloud — akzeptiert für den Wert)
• Approval-Loop max 3 Iterationen, danach manuell

4.3 Lead-Recherche

Telegram: "Recherchiere 10 Lehrstühle Biophysik DACH"
 → n8n-Workflow startet
 → SearXNG-Suche → Top-30-URLs (latency: 5s)
 → Browser-Use besucht URLs, extrahiert strukturiert (latency: 30s/URL = 15 Min seriell, 5 Min parallel mit 6 Threads)
 → Cloud-LLM filtert, dedupliziert, ranked (~3000 Token Input, 1000 Output, ~$0.05)
 → Telegram-Liste an Chapaty
 → Bei Approve: Pro Lead Anschreiben (Cloud-LLM, ~1500 Token Input/Output, ~$0.02 pro Anschreiben)
 → Versand mit Throttling: max 3 Anschreiben/Tag/Lehrstuhl-Gruppe
 → Tracking in Postgres + Perfex

Budget pro Recherche-Lauf:

• Cloud-Cost: max $1
• Latenz total: ≤ 30 Min bis Liste, < 2h bis Anschreiben-Drafts

4.4 Schlafstudie-Tagesfrage (LLM-frei)

Cron 8:00 Asuncion
 → SELECT FROM studienteilnehmer WHERE active=true
 → Pro TN: Telegram/WhatsApp-Bot mit Inline-Buttons
 → Antworten kommen via Webhook
 → INSERT INTO studienantworten
 → Wenn-Dann-Logik (deterministisch): Antwort=1 → Folgefrage
 → Quartalsweise: Cloud-LLM-Aggregations-Report (separater Workflow)

Budget Standard-Tag: 0 LLM-Calls, 0 Cloud-Cost. Nur Cron + DB.

4.5 HF-Content-Pipeline (Phase 5, eigenes Kapitel)

Wegen Compliance-Last und Komplexität ein separates Foundation-Dokument vor Phase-5-Start. Kurzform: Cloud-LLM Script-Draft, Mensch-Voice-Recording, Remotion-Render, ManuelleApproval, dann YouTube. Voraussetzung: Anwalts-Check des Format-Templates (HWG-Konformität).

4.6 Astro-Sites mit Agent-editierbaren Content-Blocks

Pattern: Claude Code baut die Astro-Site (Layouts, Komponenten, Routing, Build-Pipeline) initial. Inhalte (Texte, Bilder-Captions, CTAs, Headlines) leben als strukturierte Content-Files in src/content/ und werden vom lokalen Modell editiert über eine schmale, sichere n8n-Schnittstelle.

Datei-Struktur

new-project/
├── src/
│   ├── pages/                       (von Claude Code gebaut)
│   ├── layouts/                     (von Claude Code gebaut)
│   ├── components/                  (von Claude Code gebaut, mit <ContentBlock id="..." /> Slots)
│   └── content/                     (vom Agent editierbar)
│       ├── blocks/
│       │   ├── hero-headline.md     (frontmatter: id, type, max_length, last_edited_at, last_edited_by)
│       │   ├── hero-subline.md
│       │   ├── feature-1-title.md
│       │   └── ...
│       ├── pages/
│       │   ├── about.md             (komplettes Markdown, längere Inhalte)
│       │   └── kontakt.md
│       └── meta.json                (Site-globale Settings: title, description, og:image)
├── astro.config.mjs
└── package.json

n8n-Tool-Webhook für lokales Modell

tool/edit-content
  Body:
    project_id: "hf-mini-site"
    block_id: "hero-headline"
    new_content: "Erfahre die Wahrheit über Hochfrequenz."
    reason: "Headline besser auf Zielgruppe ausgerichtet"
  Validierung:
    - block existiert?
    - content respektiert max_length aus frontmatter?
    - keine Tabu-Wörter aus Brand-Compliance-Wiki?
    - reason vorhanden?
  Aktion:
    - Schreibt new_content in src/content/blocks/{block_id}.md
    - Triggert Astro-Rebuild (npm run build, dann rsync ins live-Verzeichnis)
    - Schreibt Audit-Eintrag in /wiki/system/content-edits.md
  Antwort:
    - success: true/false
    - rebuild_status: queued | done | failed
    - preview_url

Sicherheits-Schichten gegen Agenten-Fehler

• Whitelist-only: Nur als editable: true im Frontmatter markierte Blocks sind veränderbar
• Maximum-Length: Pro Block in Frontmatter begrenzt (z. B. headline max 80 Zeichen)
• Compliance-Check vor Schreiben: Tabu-Wort-Liste der jeweiligen Marke (HF: HWG-Tabuwörter)
• Approval-Schwelle: Bei substanziellen Änderungen (> 30% Content-Diff) Telegram-Approval Pflicht
• Auto-Rollback: Wenn Astro-Build nach Edit fehlschlägt, automatisches Revert zur letzten guten Version
• Audit-Trail: Jeder Edit ist in content-edits.md protokolliert (block_id, before, after, reason, timestamp, agent)

Workflow-Beispiel

Telegram: "Auf der HF-Mini-Site Headline persönlicher machen"
 → n8n erkennt: Astro-Site-Edit
 → qwen3:8b liest aktuelle headline + brand-voice + zielgruppe-info
 → generiert 3 Vorschläge
 → Telegram: "Welche?" mit Buttons
 → Bei Wahl: tool/edit-content mit gewählter Variante
 → Astro-Rebuild läuft, ~30 Sek
 → Telegram: "Live unter <preview_url>"

Was Claude Code initial baut, was Agent dann pflegt

Vorteil dieses Patterns: Astro-Site bleibt statisch und schnell, das Agent-Modell kann nicht die Site kaputtmachen (Whitelist + Build-Check), Claude Code wird nur für strukturelle Änderungen geholt, lokales Modell macht den Tagesbetrieb.

---

5. Brand-Wiki als Kontext-Layer

5.1 Struktur

Vier Marken, ein einheitliches Schema:

/wiki/brands/
├── hochfrequenz/
│   ├── _meta.yaml          (token-count, last-update, primary-llm)
│   ├── voice.md            (max 1500 Token)
│   ├── compliance-tabu.md  (max 800 Token)
│   ├── produkt-claims.md   (max 1000 Token)
│   ├── q-a-snippets/       (für Lookup-Zwecke, NICHT in Standard-Prompt)
│   └── studien/            (für Lookup, nicht Standard-Prompt)
├── gfkb/
│   └── … (analog)
├── immovia/
│   └── … (analog)
└── viaviva/
    └── … (analog)

5.2 Token-Budget pro LLM-Call

Standard-Brand-Kontext: voice.md + compliance-tabu.md + produkt-claims.md = max 3300 Token. Plus Aufgaben-Kontext = max 5000 Token Input in Standard-Workflows.

Bei Cloud-LLM: prompt_caching für die Brand-Kontext-Blöcke aktivieren — Anthropic Sonnet/Opus supportet ephemeral_cache, das senkt die Kosten der wiederkehrenden Brand-Voice auf ~10 % nach Cache-Warm.

5.3 Aktualisierungs-Routine

• Jede Marke: 1× pro Quartal Brand-Wiki-Review-Tag
• Bei jeder Korrektur eines LLM-Outputs durch Chapaty: prüfen, ob Brand-Wiki-Update nötig
• Lessons-Learned aus /erledigt/-Aufträgen werden automatisch (Cloud-LLM) zu Brand-Wiki-Update-Vorschlägen aggregiert, Chapaty entscheidet

---

6. Q+A-Wiki Lernschleife

6.1 Architektur in Postgres + pgvector

CREATE EXTENSION vector;

CREATE TABLE qa_entries (
  id SERIAL PRIMARY KEY,
  brand VARCHAR(20) NOT NULL,                    -- hochfrequenz | gfkb | immovia | viaviva
  trigger_phrases TEXT[],                        -- Beispiel-Fragen die zu diesem Eintrag matchen
  embedding VECTOR(384) NOT NULL,                -- multilingual-e5-small
  answer_template TEXT NOT NULL,
  variables JSONB,                               -- erlaubte Personalisierungs-Felder
  confidence_threshold FLOAT DEFAULT 0.85,
  approved_by VARCHAR(50),
  approved_at TIMESTAMP,
  use_count INTEGER DEFAULT 0,
  last_used_at TIMESTAMP,
  edit_history JSONB DEFAULT '[]',
  status VARCHAR(20) DEFAULT 'draft',            -- draft | active | retired
  retired_reason TEXT,
  retired_at TIMESTAMP,
  pii_sensitive BOOLEAN DEFAULT false,           -- bei sensiblen Themen Auto-Reply VERBOTEN
  created_at TIMESTAMP DEFAULT NOW()
);

CREATE INDEX qa_embedding_idx ON qa_entries USING ivfflat (embedding vector_cosine_ops);
CREATE INDEX qa_brand_status ON qa_entries (brand, status);

6.2 Confidence-Schwellen-Modell

6.3 Review-Prozess

• Alle neuen qa_entries entstehen aus Telegram-Approval-Antworten Chapatys
• status='draft' bis use_count >= 3 ohne Korrektur
• Nach 3× erfolgreichem Approval: Auto-Promotion zu status='active'
• Quartalsweise: Cloud-LLM scannt active-Einträge auf Veraltung (z. B. Preis-Änderungen) → Telegram-Review-Liste

6.4 GDPR-Sonderfälle (HF-Gesundheits-Daten)

Email mit Symptom-Beschreibung ist personenbezogenes Gesundheits-Datum nach Art. 9 DSGVO. Sonderbehandlung:

• Einlauf-Mails mit medizinischen Symptomen werden NICHT in qa_entries gespeichert
• Embedding ja, Roh-Text nein — zur Privacy-Wahrung
• Anonymisierte aggregierte Erkenntnisse (z. B. "30 % der Anfragen zu Migräne") landen separat in Brand-Wiki
• Antwort-Templates sind generisch, ohne Zitate aus Original-Mails

---

7. Cloud-LLM-Disziplin

7.1 Provider-Routing — Subscription-First, API-Last

Grundprinzip: kostenpflichtige API-Calls sind die Ausnahme, nicht die Regel. Der Standard-Workload läuft über Subscription-Modelle (Flat-Rate). Nur wo Subscription versagt, kommt API-Token-Verbrauch ins Spiel.

Primär A — Codex (über ChatGPT-Pro-Subscription, OAuth via Openclaw-Provider in Vorgängerstack — Provider-Konfig wandert ab in n8n-HTTP-Node)

• Modelle: gpt-5.4-codex, gpt-5.3-codex, gpt-5.1-codex-mini
• Sweetspot: Coding-Tasks, n8n-Workflow-Generierung, technische Drafts, strukturierte Aufgaben
• Subscription deckt das Volumen — keine Per-Token-Kosten
• Limit: ChatGPT-Pro-Quota (Stand 2026-04: ~150 Codex-Anfragen/3h-Fenster). Reicht für Standard-Operations.

Primär B — Kimi K2 (über NVIDIA NIM, mit kostenlosen Credits + bestehender Subscription/Token-Pool)

• Modell: moonshotai/kimi-k2.5
• Sweetspot: Long-Form-Content, Brand-Voice-Tasks, deutsch-sprachiger Output, Email-Drafts mit Tonalität
• Kosten: durch Subscription/Credits gedeckt
• Stärke: gute Multilingual-Qualität, langer Kontext (200k Token)

Sekundär — Lokales 8B / 14B (qwen3)

• Wenn Subscription-Quotas erschöpft sind oder Datenschutz-relevant
• 8B für interaktive Pfade, 14B nur als Batch im Nachtfenster

API-Last — Claude API (Anthropic, NUR Special-Case)

• Hard-Cost-Cap: $20 / Monat, jeder Call wird einzeln gerechtfertigt
• Nur einsetzbar bei: kritischer Compliance-Review-Task, Tasks die nachweislich an Codex+Kimi+lokal gescheitert sind, oder ausdrücklich von Chapaty freigegeben
• Kein Default-Pfad in irgendeinem Standard-Workflow

Hard-Verbot:

• Cloud-LLM-Call mit GFKB-Daten ohne AVV-Klarheit (jeder Provider)
• Cloud-LLM-Call ohne brand-Kontext (würde generische Antworten produzieren)
• Claude-API-Calls ohne explizite Freigabe pro Anwendung

7.2 Workload-Verteilung Codex vs. Kimi

Wenn die Primär-Auswahl Quota-erschöpft ist, automatisch auf den anderen Subscription-Provider fallback. Erst dann lokal. Erst danach (mit Approval) Claude-API.

7.3 Subscription-Quota-Tracking + Hard-Cost-Cap

Tracking-Tabelle in Postgres:

CREATE TABLE llm_calls (
  id BIGSERIAL PRIMARY KEY,
  ts TIMESTAMP DEFAULT NOW(),
  provider VARCHAR(20),       -- codex | kimi | claude-api | local-8b | local-14b
  model VARCHAR(50),
  workflow_source VARCHAR(50),
  tokens_in INTEGER,
  tokens_out INTEGER,
  cost_usd NUMERIC(10,4),     -- 0 für Subscription-Calls, > 0 nur für claude-api
  duration_ms INTEGER,
  success BOOLEAN
);

Subscription-Throttling:

• Codex: max 100 Calls / 3h-Fenster (Puffer vor Quota), 429-Erkennung → 30-Min-Cool-Down
• Kimi: max 200 Calls / Stunde
• Bei Throttle-Trigger: nicht-kritische Tasks in /wartet-auf-mensch/, kritische Pfade laufen weiter

Claude-API-Hard-Cap:

• $20 / Monat, $5 / Woche
• Pro Call ein claude_call_justification in der DB
• Bei Erreichen 80 %: Telegram-Alert, jeder weitere Call braucht Telegram-Approve
• Bei 100 %: alle Claude-Calls für Rest des Monats blockiert

Wochen-Telegram-Bericht montags: Codex-Quota-Auslastung, Kimi-Quota-Auslastung, Claude-API-Cost-Stand.

7.4 Quota-Eskalation und Fallback

Workflow ruft Cloud-LLM auf → wählt nach Tabelle 7.2 (Codex oder Kimi)
 → 429 / Quota erschöpft
   → Versuch des jeweils anderen Subscription-Providers (Kimi ↔ Codex)
     → Beide erschöpft → Lokales 8B (Qualitätsabschlag akzeptiert)
       → Auch das nicht ausreichend (Long-Form, > 2000 Token Output) → 14B-Batch in Nachtfenster
         → Wirklich kritisch jetzt? → Telegram-Alert "Soll Claude-API genutzt werden? (Y/N)"
           → Bei Y: Claude-Call mit Justification-Eintrag
           → Bei N: Auftrag in /wartet-auf-mensch/

Bei strukturellen Cloud-Ausfällen (Codex + Kimi beide down): n8n-Workflow emergency-throttle pausiert nicht-kritische Cron-Jobs (Newsletter-Drafts, Lead-Recherche), behält nur kritische Pfade (Email-Auto-Reply via Q+A-Wiki ohne LLM, Schlafstudie ohne LLM, Uptime-Monitoring).

---

8. Migrations-Strategie aus aktuellem Stack

8.1 Was aus dem alten /docker/* überlebt

8.2 Was migriert wird

8.3 Was wegkommt

• OpenClaw + alle 8 Personas-Configs — gestrichen
• media_server.py (Host-Service auf Port 8766) — gestrichen, Funktionalität in n8n + dedizierte Container
• Lenny-Telegram-v3 Workflow + 54 Tool-Webhooks — wird neu auf dem n8n als gereinigte Workflow-Sammlung gebaut, NICHT 1:1 portiert
• N8N-Tabellen n8n_session, n8n_task_queue, n8n_agent_state, n8n_mentions_processed — nicht mehr nötig, Postgres + pgvector ersetzt das
• Schablonen-Wiki Self-Optimization — wird nicht weiterverfolgt, einfache Markdown-Editierung reicht
• learning-capture + learning-inject Crons — durch Q+A-Wiki ersetzt

8.4 Migrations-Reihenfolge

Phase 0 (laufend): GoDaddy → Hostinger Site-Migration auf Subdomains
Phase 1: Stack-Foundation (Postgres+pgvector, TEI, Outline-or-MD, Uptime-Kuma)
Phase 2: Email-Workflow MVP (mit Q+A-Wiki, ohne Mailcow noch)
Phase 3: Mail-Strategie-Entscheidung + Versand-Setup (Mailcow oder Brevo-Relay)
Phase 4: Newsletter-Workflow + Brand-Wiki-Templates
Phase 5: Plugin v2 Entwicklung (eigener Sprint, 4–8 Wochen)
Phase 6: Lead-Recherche-Pipeline
Phase 7: Member-App MVP (WP+WooCommerce-Subscriptions zuerst)
Phase 8: GFKB-Integration (mit AVV)
Phase 9: HF-Content-Pipeline (Compliance-geprüft)
Phase 10: Skalierung + Hardware-Upgrade

---

9. Phasen-Roadmap — Foundation-Pflicht + Pattern-Bibliothek

Wichtig: Nur Phase 0 und Phase 1 sind aktive Bauprojekte mit Termin. Alle anderen Phasen (2–10) sind Patterns in einer Bibliothek. Sie werden aktiviert wenn Chapaty sagt "diesen Flow jetzt automatisieren" — nie davor (siehe Anker 4).

Phase 0 — Migrations-Abschluss (2026-04-27 bis ~05-15) [aktiv]

• ✅ Agent-System pausiert
• 🔄 5 WP + Perfex-Clone auf Staging-Subdomains
• ⏳ Sichtung durch Chapaty
• ⏳ DNS-Switches sequenziell
• ⏳ Mail-Migration (Brevo-Relay vorab oder mit DNS-Switch parallel)

Phase 1 — Stack-Foundation (3–5 Tage) [Pflicht, baldmöglichst]

Diese Phase ist Plumbing das jede künftige Automation brauchen wird. Wird einmalig gebaut, danach läuft sie still im Hintergrund.

• Postgres-Container (postgres:16-alpine) auf ai-net
• pgvector-Extension installiert
• TEI-Container (text-embeddings-inference) für Embedding
• Uptime-Kuma + Telegram-Bot
• Auftrags-Inbox: Markdown-Verzeichnis unter /root/wiki/auftrage/ mit Git
• Brand-Wiki-Skelett unter /root/wiki/brands/ (leere Dateien je Marke, werden bei Bedarf gefüllt)
• Aufräumen: OpenClaw + media_server.py + alte n8n-Workflows entfernen
• llm_calls Tabelle für Quota/Cost-Tracking
• qa_entries Tabelle initial leer

Nach Phase 1 ist das System bereit für Patterns, aktiv ausgeführt wird aber noch nichts.

---

Pattern-Bibliothek (Phasen 2–10)

Die folgenden Phasen sind vorgedachte Patterns mit klarer Aktivierungs-Anleitung. Sie werden on-demand aufgerufen, einzeln, eng gescopt.

Pattern A — Q+A-Email-Auto-Reply (für eine spezifische Frage-Klasse)

Trigger: Chapaty bemerkt wiederkehrende Frage, hat sie 3+ mal manuell beantwortet.

• 1 qa_entries-Eintrag mit Brand+Trigger+Template
• 1 n8n-Workflow nur für diese Frage-Klasse (Embedding-Match auf Brand)
• Approval-Loop bis use_count = 5 stabil, dann Auto-Pfad
• Aufwand: ~2 Std pro Frage-Klasse

Pattern B — Newsletter-Drafting (für eine Marke)

Trigger: Chapaty will regelmäßig Newsletter für Marke X verschicken.

• Brand-Wiki ausarbeiten (voice.md, compliance-tabu.md, produkt-claims.md)
• n8n-Workflow newsletter-draft-{brand} mit qwen3:8b lokal
• Versand-Pfad-Wahl (Listmonk vs. SMTP-Loop) treffen
• Aufwand: ~1 Tag inkl. Brand-Wiki-Schreibe-Zeit

Pattern C — Lead-Recherche (für eine Zielgruppe)

Trigger: Chapaty hat eine Akquise-Welle vor sich (z. B. 30 Lehrstühle anschreiben).

• SearXNG-Query-Template für die Zielgruppe
• Browser-Use-Skript für Datenextraktion
• Anschreiben-Vorlage mit Brand-Voice
• Throttling-Limit pro Tag
• Aufwand: ~1 Tag pro Zielgruppe

Pattern D — Astro-Site mit Agent-Edits (für ein neues Projekt)

Trigger: Chapaty + Claude Code starten ein neues Projekt das eine Site braucht.

• Claude Code baut die Astro-Basis mit <ContentBlock>-Slots (siehe 4.6)
• n8n-Tool edit-content einrichten
• Brand-Tabu-Liste verankert
• Aufwand: variabel (Site-Komplexität), n8n-Anbindung danach 2 Std

Pattern E — WP-Wartung über Plugin v2 (eigenes Sub-Projekt)

Trigger: Chapaty empfindet WP-Pflege als Schmerz, will Wochenrhythmus automatisieren.

• Plugin-v2-Sprint (4–8 Wochen, eigenes Foundation-Dokument vorab)
• Operations-API + Tracking-Modul + Forms-Sync + WC-Hooks
• n8n-Cron für wöchentliche Wartung pro WP-Site
• Aufwand: hoch (deshalb eigenes Sub-Projekt, nicht spontan aktivierbar)

Pattern F — Member-App MVP (für eine Marke)

Trigger: Chapaty hat Conversion-Bedarf bei einer Marke und einen Member-Flow im Kopf.

• WP+WooCommerce-Subscriptions-Setup (kein SvelteKit am Anfang)
• Hörbuch-Streaming-Plugin oder Member-Bereich-Plugin
• Conversion-Tracking
• Validierungs-Phase 4 Wochen
• Aufwand: 2–4 Wochen pro Marke

Pattern G — GFKB-Workflow (Werkstattbuch + Lieferschein)

Trigger: Chapaty will eine GFKB-Operation vom Hostinger aus automatisieren.

• AVV vorab unterschrieben (Block-Kriterium)
• n8n-Workflow mit Doppel-Niederschlag (Perfex-Viaviva intern + Perfex-GFKB extern)
• Aufwand: ~3 Tage pro Workflow + AVV-Vorlauf

Pattern H — HF-Content-Pipeline (Compliance-Sonderfall)

Trigger: Chapaty will Sylke-Format-Videos automatisieren.

• Anwalts-Check vorab (Block-Kriterium)
• Voice-Recording-Setup
• Remotion-Komponenten-Library
• Pilot-Video manuell, dann inkrementelle Automation
• Aufwand: hoch, eigenes Sub-Projekt mit eigenem Foundation-Doc

Pattern I — Schlafstudie + andere strukturierte Studien

Trigger: Chapaty will eine konkrete Studie starten.

• DB-Schema für die Studie
• Telegram/WhatsApp-Bot-Workflow
• Aggregations-Cron mit Cloud-LLM für Quartalsbericht
• Aufwand: ~3 Tage pro Studie

---

Phase 10 — Skalierung + Hardware-Upgrade (Trigger-basiert)

Wird ausgelöst wenn Schwellen aus Teil 12 überschritten werden. Kein eigener Termin.

---

10. Operations & Bus-Factor

10.1 Monitoring-Stack

Uptime-Kuma beobachtet:

• Alle Container-Health-Endpoints
• HTTP-Endpoints aller produktiven WP-Sites + Perfex
• n8n-Workflow-Heartbeat (custom endpoint)
• Postgres + Ollama erreichbar
• Disk-Usage > 80 %, RAM > 90 %, Load-Avg > 6.0
• SSL-Zertifikate < 14 Tage

Alerts → Telegram-Bot, eskaliert auf SMS bei kritischen Alarmen (Postgres down, Disk > 95 %).

10.2 Backup-Disziplin (3-2-1)

Drei Kopien, zwei Medien, eine off-site:

1. Lokal Hostinger: stündlicher Postgres-Dump + täglicher tarball aller /docker/*/html, /docker/*/dbdata und Volumes — /backup/hourly/ (24h rollend), /backup/daily/ (7d)
2. Hostinger-Snapshot wöchentlich (manuell via Panel oder via Hostinger-API-Skript)
3. Off-Site verschlüsselt: wöchentlicher Restic-Snapshot zu B2/S3 (oder vergleichbar) — Retention 4 Wochen

Disaster-Recovery-Runbook: ein eigenes Foundation-Dokument mit 5 Szenarien (DB-Crash, Container-weg, Server-weg, Domain-Lock, Compliance-Take-Down). Jeder Szenario mit RTO/RPO-Zielen.

10.3 Notfall-Operator-Plan (Bus-Faktor)

Wenn Chapaty 1+ Wochen ausfällt:

• Ein vertrauter Operator (z. B. Familienmitglied oder Freund) hat Notfall-Zugang via Vaultwarden
• Notfall-Doku in Vaultwarden: Aufruf-Anleitung "wie schalte ich n8n aus", "wie pause ich alle Mails", "wie kontaktiere ich Kunden"
• Auto-Reply auf alle Inboxen: "Antwort verzögert, melden uns innerhalb 7 Tagen"
• Cron-System pausiert sich nach 3 Tagen ohne Heartbeat von Chapaty selbst (deadman-switch)

10.4 Dokumentations-Pflicht

• Jeder n8n-Workflow hat einen Markdown-Header in Outline/Wiki: Zweck, Trigger, Outputs, Failure-Modes
• Jede Phase produziert ein Lessons-Learned-Doc (am Ende des Auftragsdokuments)
• Halbjährlich: Architektur-Audit, ein Tag, prüft ob Doku noch zur Realität passt

---

11. Compliance-Anker (HF-spezifisch)

11.1 HWG / UWG (Heilmittelwerbegesetz, Wettbewerbsrecht)

Für alle Hochfrequenz-Inhalte (Hörbuch, Newsletter, Video, Member-App):

• Keine Heilversprechen ("heilt", "lindert", "verhindert" sind Tabuwörter)
• Keine pauschalen Wirkungs-Zusagen ohne Studien-Beleg
• Disclaimer im Footer: "Keine Heilkunde, kein Ersatz für medizinische Behandlung"
• Tabu-Wort-Liste in /wiki/brands/hochfrequenz/compliance-tabu.md, technisch in jedem LLM-Call mitgegeben

Anwalts-Check vor Produktion:

• Sylke-Format-Template (Phase 9)
• Member-App-Texte
• Newsletter-Beispiele

Empfohlener Anwalt: Fachanwalt für Medizinwerberecht — Recherche separat. Auftragspauschale ~€500–1500 für Format-Check ist eingeplant.

11.2 GDPR für Gesundheits-Daten

Art. 9 DSGVO bei Krankheits-Symptomen:

• Roh-Inhalte werden NICHT in Q+A-Wiki gespeichert (siehe 6.4)
• Studienteilnehmer brauchen explizite Art-9-Einwilligung
• Datenschutz-Folgeabschätzung (DSFA) vor Member-App-Launch

11.3 AVV mit GFKB

Vorlage bei Phase 8 vorbereiten. Inhalt:

• Welche Daten werden auf Hostinger verarbeitet
• Welche Speicherorte (Postgres, n8n-Logs, Mailcow-Inbox)
• Löschfristen
• Haftungsregelung
• Audit-Right für GFKB

Ohne unterzeichneten AVV: kein produktiver GFKB-Workflow.

---

12. Hardware-Upgrade-Trigger

12.1 Konkrete Schwellen

12.2 Upgrade-Pfad

Stufe 1 (CPU-Upgrade Hostinger): KVM10 oder KVM12 — mehr vCPU, mehr RAM. Wenig Wartungsaufwand, ~+€20–40/Monat. Empfohlener erster Schritt bei CPU-Limit.

Stufe 2 (Dedicated-Server bei Hetzner): EX-Reihe mit AMD Ryzen + optional GPU. Mehr Leistung pro €, mehr Eigenverwaltung. Empfohlen bei Video-Pipeline-Aktivität.

Stufe 3 (GPU-Cloud bei Bedarf): RunPod oder Lambda für Batch-Renders — pay-per-use. Empfohlen bei sporadischer Video-Last.

---

13. Risiken & Mitigationen

---

14. Offene Entscheidungen mit Empfehlung

E1. Auftrags-Inbox: Outline vs. Markdown-Verzeichnis

Empfehlung: Markdown-Verzeichnis in /root/wiki/auftrage/ unter Git-Versionierung. Reicht für 1-Person-Betrieb, kein zusätzlicher Container. Outline kann Phase 7+ kommen wenn Volumen es rechtfertigt.

E2. Mailserver: Mailcow vs. SMTP-Relay (Brevo o. ä.)

Empfehlung: Phase 3a Brevo SMTP-Relay für ausgehend (300/Tag kostenlos), eingehend bleibt All-Inkl, Phase 3b Mailcow wenn All-Inkl-Konten umgezogen werden müssen UND klares Mehrwert-Szenario besteht (Vollkontrolle + DSGVO + Reputation). Empfehlung: Mailcow nur wenn echte Notwendigkeit, sonst Brevo dauerhaft.

E3. Cloud-LLM-Primary: Subscription-First

Festlegung (2026-04-27 mit Chapaty): Codex (ChatGPT-Pro) und Kimi K2 (NIM) sind die primären Arbeiter — beide kostendeckend über Subscription/Credits. Aufgabenverteilung nach Tabelle in 7.2 (Codex für Code-/Struktur-Tasks, Kimi für Sprache-/Long-Form). Lokales 8B als Sekundär. Claude-API nur als Last-Resort mit $20/Monat-Hard-Cap und Pro-Call-Justification.

Begründung der Verschiebung gegenüber Erstentwurf: Claude-API generiert bei Standard-Workload schnell drei- bis vierstellige Monatskosten — nicht tragbar im Solo-Betrieb. Codex+Kimi liefern für 95 % der Tasks ausreichende Qualität, ohne Per-Token-Risiko.

E4. Member-App: WP+WooCommerce vs. SvelteKit-Native

Empfehlung: WP+WooCommerce-Subscriptions als MVP in Phase 7. SvelteKit-Native erst wenn 100+ aktive Member-Nutzer und konkrete Schmerzpunkte mit der WP-Variante.

E5. Frontend-Stack-Vereinheitlichung

Festlegung (2026-04-27 mit Chapaty): Bestehende WP-Sites bleiben WP. Neue Projekte werden in Astro gebaut mit dem Agent-Editier-Pattern (siehe 4.6) — Claude Code baut die Astro-Site, n8n exponiert editierbare Content-Blocks für lokales Modell. Reduziert WP-Wartungslast bei Neuaufbau, hält Bestand stabil.

WP bleibt für: GFKB-Sites, hochfrequenz.tech, viaviva.team, follow4.life, krisen-navigator.com, powersales.team (alles aus aktueller Migration). Astro für: alle künftigen neuen Marken, Projekt-Landingpages, Member-Bereiche wo statisches CMS reicht.

E6. Anwalt für HWG-Check

Empfehlung: vor Phase 9 starten, idealerweise ein Anwalt aus dem Bereich Medizin-/Heilpraktiker-Werberecht. Recherche durch Chapaty, Budget €500–1500.

E7. Hardware-Upgrade-Plan

Empfehlung: Hostinger KVM10 als nächster Schritt wenn Trigger erreicht. Dedicated-Server erst bei Video-Pipeline-Last.

E8. Off-Site-Backup-Provider

Empfehlung: Backblaze B2 mit Restic. Kostengünstig, S3-kompatibel, etabliert. Alternativ Hetzner Storage Box wenn Compliance-bedingt EU-Server gewünscht.

E9. Schlafstudien-Veröffentlichung

Empfehlung: aufschieben bis Phase 9+. Erst Daten sammeln, dann publizieren. Format: eigenes PDF-Whitepaper auf hochfrequenz.tech, später wissenschaftliche Veröffentlichung wenn Anwalt freigibt.

E10. Petition-Plattform

Empfehlung: OpenPetition.de integriert via Embed/Link. Eigenbau erst wenn echter Bedarf (Custom-Workflow).

---

15. Was wir KONKRET als nächstes tun

Sobald GoDaddy-Migration auf Subdomains abgeschlossen ist (Phase 0 läuft):

1. DNS-Switches sequenziell — eine Site nach der anderen, jeweils 24h Beobachtungs-Fenster. Reihenfolge:

• viaviva.team (kleinste Risiko)
• powersales.team
• follow4.life
• krisen-navigator.com
• hochfrequenz.tech (zuletzt, größtes Risiko)

2. Mail-Migration starten — Phase 3a (Brevo-Relay-Setup), All-Inkl-Konten als IMAP-Quelle behalten

3. Phase-1-Auftragsdokument schreiben — separates auftrag-002-stack-foundation.md mit den konkreten Schritten:

• Postgres+pgvector deployen
• TEI-Embedding-Container deployen
• Uptime-Kuma + Telegram-Bot
• Brand-Wiki-Skeleton
• OpenClaw + media_server.py + alte n8n-Workflows entfernen

Erst nach Phase 1 starten wir Phase 2 (Email-MVP).

---

Schluss-Bemerkungen

Diese Strategie macht drei wesentliche Verschiebungen gegenüber dem Konzept-Entwurf:

1. Stack reduziert von 17+ auf ~12 Komponenten. Chatwoot, Plausible, Astro-zusätzlich, Mailcow-als-Big-Bang gestrichen. Was raus ist, kann später bei Bedarf nachgezogen werden.
2. Hardware-Limits werden zur ersten Architektur-Regel. Ohne explizites Token-/Latenz-Budget pro Workflow gibt es keinen Workflow.
3. Compliance ist Gate, nicht Footnote. HWG-Check und AVV blockieren ihre jeweiligen Phasen.

Was bewusst hart gemacht wurde:

• 14B-LLM-Verbot in interaktiven Pfaden — kein Kompromiss
• Cloud-LLM-Hard-Cap mit Telegram-Alarm — Schutz gegen explosive Kosten
• AVV vor GFKB — kein produktiver Workflow ohne Vertrag
• Mailserver-Eigenbau erst bei nachgewiesenem Bedarf — Wartungs-Last vermeiden

Was bewusst pragmatisch bleibt:

• Member-App startet auf WP, nicht SvelteKit — Validierung vor Eigenbau
• Markdown-Verzeichnis statt Outline — weniger Komponenten
• Eine Cloud-LLM-Provider-Empfehlung mit Fallback-Routing — keine Provider-Multilateralität ohne Notwendigkeit

Dieses Papier wird die Grundlage. Auftragsdokumente referenzieren auf Abschnitte hier. Bei jeder größeren Entscheidung gilt: passt das zu einem der drei Anker (Hardware / Bus-Faktor / LLM-Veredelung)? Wenn nein → Rückfrage an Chapaty.

---

Status: Arbeitspapier finalisiert. Bereit zur Diskussion und Anpassung. Erst nach Chapaty-Approval wird daraus die zentrale Foundation.