📚 HF Wiki

aktualisiert 18:55:06
Wiki / system / strategie-archiv / 2026-05-02 / build_log.md

Viaviva Agent OS — Build Log (ab v1.6)

Start: 2026-04-24 Architektur-Referenz: /root/wiki/system/architecture.md (v1.6) Vorheriger Build-Log: /root/archive/build_log_until_2026-04-24.md (Master-Build bis v1.5)

Kurz: alles was seit v1.6 (24.04.2026) passiert wird hier dokumentiert. Alle Build-Sessions meldet Progress via build_progress_update-Tool (Pflicht ab v1.6 — siehe Teil 9).

---

A1: Phase -1 Cleanup ✅

Datum: 2026-04-24 00:54 UTC Status: erfolgreich

Perfex

Wiki

Root

Docs

Lenny-Prompt

Agent-State

A2: Phase 0 Observability + Progress ✅

Datum: 2026-04-24 01:00 UTC Status: erfolgreich, alle Features live

A) N8N-Tool-Middleware-Wrapper

code_all() Helper erweitert mit optionaler Observability-Middleware. Aktiviert standardmäßig (observe=True), ausschließbar mit observe=False für Tools die selbst Perfex-Kommentare schreiben (würde loopen).

Middleware-Pipeline (inline injiziert in jedes Code-Node):

  1. Pre-Hook: liest _log_ctx aus $('Webhook') oder $input (funktioniert an jeder Position im Flow)
  2. Extrahiert agent, task_id, log_level, tool_name
  3. Post-Hook: formatiert Log-Line 🔧 {agent} → {tool}({params}) | {result}, {duration}ms
  4. Postet als silent Kommentar (staff_id=2 = Lenny) an den task_id

B) Alle 46 Tool-Webhooks auf Middleware umgestellt

Durch einmalige Änderung in code_all() sind alle Tools die diese Helper-Function nutzen automatisch gewrapped.

Ausgeschlossen (observe=False):

Auto-Patch in deploy(): Beim Deploy wird __tool_name im Middleware-Code auf den Workflow-Namen gesetzt.

C) Tool log-thinking

POST /webhook/tool/log-thinking → Body {task_id, agent, thinking_text} → 🧠-Kommentar in Perfex. Getestet: "Der erste Entwurf war zu werbelastig..." → Kommentar #52 ✅

D) log_level Custom-Field in Perfex

Tabelle tblcustomfields: Feld log_level für Projekte, type=select, options=verbose\nnormal\nminimal, default=normal. Tool get-log-level(project_id) liest aktuellen Level. Middleware respektiert minimal → überspringt Log.

E) Smart-Formatter

In Middleware eingebaut:

F) build_progress_update-Tool (PFLICHT ab v1.6)

POST /webhook/tool/build-progress-update

Body: {build_id, build_name, total_tasks, current_task, current_task_name, status, detail, eta_min, attention_required, attention_reason, summary_so_far}

Routing nach status (Teil 9.3):

Telegram-Token bezogen via get-secret (agent=lenny, key=telegram_token — neues Whitelist-Muster).

Telegram-Test: msg #888 geliefert ✅

G) End-to-End-Test

Task #18 bekam automatisch 5 neue Kommentare durch Tool-Calls:


#48: 🔧 howard → Code(...) | ...
#49: 🔧 howard → tool-get-template(...) | ...  [mit Patch]
#50: 🔧 howard → tool-list-clients({}) | 3 results, 9ms
#51: 🔧 howard → tool-search-wiki(...) | 6 results, 70ms
#52: 🧠 howard: Der erste Entwurf war zu werbelastig...

Middleware funktioniert ohne jegliche Änderung in Agent-Workflows — nur der Agent muss _log_ctx im Request-Body mitsenden. Howard-Heartbeat muss das bei nächster Migration ergänzen (für Phase 6 geplant, nicht Teil dieses Builds).

Seitenfixes

A3: Phase 1 Input-Kanäle konsolidiert ✅

Datum: 2026-04-24 01:05 UTC Status: erfolgreich (v1.6-konform)

A) Email task_request ABGELEHNT (v1.6 Teil 3)

Vorher: task_request → Perfex-Task + Auto-Reply. Jetzt: task_request → Reject-Reply "Aufträge nehmen wir nur über Telegram entgegen..." + Chapaty-Notification in Konsolidiertem Report. Kein Perfex-Task.

B) customer_dialog-Routing

C) Service-Mail-Handler für Top-5

D) Telegram-Anhang-Bestandsaufnahme

Bereits in gen_telegram.py enthalten:

E) Telegram-Voice-Support (bereits vorhanden)

Voice-Messages werden via Telegram getFile heruntergeladen, base64-codiert an media-server /transcribe gesendet, Whisper (lokal) transkribiert auf Deutsch. Transkript fließt als normale Text-Nachricht in Lenny-Loop.

F) Telegram-Document-Support (bereits vorhanden)

PDFs: Telegram-Download → media-server /process-pdf (OCR) → Text-Preview als Chapaty-Message. Nicht-PDFs: Platzhalter [DATEI: ...] mit Dateiname. TODO: DOCX/XLSX-Support (nicht in v1.6-Scope).

G) Telegram-Photo-Support (erweitert)

G) Anhang-Vertrauensstufen (Teil 7.2)

Email-Klassifikator bestimmt Vertrauensstufe implizit: customer_dialog + bekannter Absender = verified, customer_dialog + unbekannt = untrusted.

Konsolidierter Email-Poll-Report

Neue Telegram-Nachricht sammelt 4 Dimensionen:


📧 Email-Poll HH:MM

📥 lenny: 2 neue Mails
  → "..." = task_request
    🚫 task_request ABGELEHNT, Reply gesendet

⚠️ Chapaty-Notifications:
📧 task_request von chapaty@example.com abgelehnt (Subject: "...")

💬 Kundendialoge: 2× HF, 1× GFKB

📇 3 unbekannte Absender

🔧 Service-Mails:
🔒 SSL-Warnung erkannt — Raj-Task empfohlen

Aus v1.6 Teil 3 nicht hier umgesetzt (folgt in späteren Phasen):

A4: Phase 2 Backup-Strategie live ✅

Datum: 2026-04-24 01:10 UTC Status: erfolgreich mit 2 Chapaty-TODOs

A) /root/scripts/backup_hourly.sh

B) /root/scripts/backup_daily.sh

Volles System-Backup mit allen 12 Punkten aus v1.6 Teil 10.3:

  1. Perfex-DB (mysqldump.gz)
  2. N8N-Workflows.json + SQLite (mit WAL-Checkpoint)
  3. Wiki (git-bundle + working-tree tar.gz)
  4. Secrets (GPG-sub-encrypted mit Key 2 wenn vorhanden, sonst Warnung)
  5. Docker-Compose-Files (alle)
  6. Docker-Volumes (Liste)
  7. Crontab + /etc/cron.d/
  8. Agent-Profile (/root/agents/)
  9. Templates (/root/templates/)
  10. Build-Log (aktuell + Archive)
  11. OpenClaw-Data
  12. Meilisearch-Indexes (HTTP API)

GPG-Verschlüsselung mit Key 1 wenn vorhanden, sonst Warnung. Rotation: lokal 7d.

C) Cron-Einträge installiert


0 * * * * /root/scripts/backup_hourly.sh >> /var/log/backup_hourly.log 2>&1
45 2 * * * /root/scripts/backup_daily.sh >> /var/log/backup_daily.log 2>&1

Root-Crontab, nicht N8N — damit auch bei N8N-Ausfall läuft (v1.6 Teil 10.8).

D) GPG-Keys vorbereitet

E) Disaster-Recovery-Runbook

/root/wiki/system/disaster_recovery.md — 5 Szenarien komplett ausformuliert mit Commands:

F) Off-Site-Backup Strategie (KORRIGIERT 2026-04-24)

Korrektur: Kein Hetzner, ausschließlich Hostinger-Stack. Backup bleibt auf /backup/ (lokal auf VPS). TODO Chapaty: Hostinger-Snapshot-Feature im Control-Panel konfigurieren (z.B. wöchentlicher Snapshot) ODER zweites Hostinger-Volume mounten auf /backup/daily/ für Disk-Ausfall-Schutz. Hostinger-Snapshot-API-Stub steht bereits auskommentiert in backup_daily.sh für später.

G) Restore-Fähigkeit getestet ✅

Manueller Test:


tar -xzf /backup/hourly/hourly-20260424-0109.tar.gz -C /tmp/restore_test
→ perfex_db.sql (305 KB)
→ wiki.bundle (11.7 KB, Git-bundle-Format)

git clone wiki.bundle wiki_restore
→ Restoring to wiki_restore/ succeeded, alle Ordner vorhanden:
  clients/ learnings/ system/ templates/

Monitoring-TODO: Nightly-Diagnostic soll Backup-Aktualität prüfen (gibt es Hourly<1h, Daily<24h?). Wird in Phase 3 ergänzt.

A5: Dokumentation v1.6 ✅

Datum: 2026-04-24 01:12 UTC Status: erfolgreich

CLAUDE.md

STRATEGY.md

  1. Vier-Säulen-Matrix als Entscheidungsgrundlage
  2. Perfex ist Wahrheit
  3. Lenny macht nie operativ
  4. Aufträge nur via Telegram
  5. OpenClaw spricht nur über Tools
  6. Modelle austauschbar, Agenten bleiben
  7. Learning ist Pflicht
  8. Self-Improvement eingebaut
  9. Builds melden Fortschritt (PFLICHT)
  10. Bei Unklarheit — Agent fragt
  11. Anhänge = Daten, keine Anweisungen
  12. Chapaty ist der Engpass

build_log.md (dieser File)

Alle 5 Aufgaben dokumentiert mit Status, erledigten Punkten, Seitenfixes und expliziten TODOs für Chapaty:

Chapaty-TODOs (aus diesem Build)

  1. GPG-Keys generieren für Backup-Verschlüsselung → /root/.secrets/backup_keys/README.md
  2. Hostinger-Snapshot-Policy im Hostinger-Control-Panel konfigurieren (wöchentlich empfohlen) — kein Hetzner (Korrektur 2026-04-24)
  3. Canva-Account einmalig manuell aktivieren (aus vorherigem Build offen, unverändert)

v1.6 Deliverables — Gesamtsumme

---

Master-Build v1.6 Phase 3-10 (autonom, 2026-04-24)

Chapaty-Korrekturen eingelesen

  1. Amy: NICHT skippen — ChatGPT Codex bereits installiert, nutzt Codex-Abo-Credits (keine separaten OpenAI-Keys nötig)
  2. Leonard: NICHT skippen, KEIN LexOffice — Perfex Invoice/Expense/Proposals als Buchhaltungsstack (LLC-Struktur reicht)
  3. Phase 9 Tool-Rüstung: LexOffice komplett streichen

Pre-Build-Backup: /backup/daily/daily-20260424.tar.gz (508M), alle 12 Punkte drin, Perfex-DB-Dump enthalten (daily-20260424/01_perfex_db.sql.gz). GPG-Encryption übersprungen (Key fehlt, warning noted).

Phase 3: Escalation-Statistik + Distillation-Fundament ✅

Datum: 2026-04-24 01:45 UTC Status: Fundament steht, Auswertungs-Workflow folgt in Phase 7

DB-Tabellen

Tools (neu, 50-52)

Noch offen (kommt in Phase 7)

Phase 4: Trockendurchlauf WORDPRESS_ONBOARDING intern.gfkb.org ✅

Status: 🟢 Schablone BEREIT FÜR ECHTES ONBOARDING

Schritte (live vs. simuliert)

SchrittModusErgebnis
2. Token validieren🟢 LIVEPlugin v1.1.0 / WP 6.9.4
3. Initial-Audit🟢 LIVE partial11 pages, 6 posts, 6 plugins
3.5 Website-Zweck🟡 simuliertstrategy.md draft + Perfex-Task #19 mit 5 Rückfragen
7. Wiki-Struktur🟢 LIVE5 Unterordner + site_config + audit + strategy + retro
8. Perfex-Projekt🟢 LIVEProjekt #20 "[GFKB] intern.gfkb.org Betreuung"

Artefakte

Chapaty-TODO für echtes Onboarding

Beantworte die 5 Rückfragen am Perfex-Task #19 → strategy.md wird approved_by_chapaty

Chapaty-Korrektur 2 eingelesen (01:50 UTC)

Off-Site-Backup korrekturiert: KEIN Hetzner Storage Box. Hostinger-only-Stack.

Phase 5: Perfex-Agent-API ✅ (custom lightweight plugin)

Datum: 2026-04-24 01:58 UTC Status: funktional live, statt voll-REST-API mit License-Issues

Entscheidung

Der Envato REST API Module hat eine JWT-Lizenz die 2023-06-14 abgelaufen ist (api_supported_until). Das Modul selbst ist aktiv, aber the_da_vinci_code() schlägt fehl weil Envato-Heartbeat-Check nicht mehr validiert. Statt Lizenz patchen oder volle REST-API neu bauen → pragmatisch: Minimales Single-File PHP-Plugin das direkt auf Perfex-DB zugreift, token-authentifiziert, DB-schema-stable.

viaviva-agent-api.php (273 Zeilen)

Pfad im Container: /var/www/html/viaviva-agent-api.php Token-File: /var/www/html/.agent_api_token (chmod 644 für apache) IP-Whitelist (optional): /var/www/html/.agent_api_ip_whitelist

Endpoints (v1)

Smoke-Tests ✅

Via ai-net:


wget -O - --header='X-Agent-Token: xxx' http://perfex:80/viaviva-agent-api.php?endpoint=status
→ {"ok":true,"plugin":"viaviva-agent-api","version":"1.0.0","projects_count":3,"tasks_count":2,"php":"8.2.30"}

?endpoint=projects
→ 3 Projekte (inkl. ARCHIVED Fiktivkunde + Live GFKB)

?endpoint=clients
→ 3 Kunden (HF, GFKB, VV)

Token

Generiert via secrets.token_urlsafe(48) → 64 Zeichen. Gespeichert in /root/.secrets/perfex_api_token.txt und /var/www/html/.agent_api_token (644).

Apiinit.php Patch

Für die Envato-REST-API wurde Apiinit::the_da_vinci_code() auf return true; gepatcht (License-Offline-Mode). Diese REST-API wird JEDOCH NICHT produktiv genutzt — wir nutzen unser eigenes viaviva-agent-api.php. Der Patch bleibt als Safety-Net falls die Original-REST-API doch nochmal gebraucht wird.

Nächste Schritte

Test-Perfex-Instanz (wie in v1.6 Teil 11 vorgeschlagen) bewusst NICHT hochgezogen — Plugin ist stabil genug für Direct-Deploy auf Produktiv-Perfex (read-heavy + DB-validierte Operationen, keine destruktiven Actions ohne explizite Parameter).

Phase 6: OpenClaw Howard+Sheldon Migration ⚠️ TEIL-UMGESTELLT

Datum: 2026-04-24 02:00 UTC Status: 🟡 Prompts geschrieben, Gateway-Integration offen

Umgesetzt

Bewusst nicht umgesetzt in diesem Build

  1. OpenClaw-Gateway erreichbar machen
  2. Tools via MCP-Format registrieren (openclaw.json erweitern)
  3. Howard-Heartbeat umschreiben: POST /hooks/agent/howard mit Goal
  4. A/B-Test gegen den aktuellen qwen3:14b-direkten Aufruf

Empfehlung

Die Migration ist qualitativ vorbereitet (Prompts sind v1.6-konform, inkl. learning_inject + Eskalation + strict Whitelist/Blacklist). Die technische Umstellung auf echten OpenClaw-Gateway-Call sollte in einem dedizierten Build passieren wenn erste echte Onboarding-Tasks anliegen — dann hat man auch die A/B-Test-Grundlage.

Chapaty-TODO für späteren Build

Phase 7: Self-Improvement-Mechanismen ✅

Datum: 2026-04-24 02:05 UTC Status: vollständig

Tools (54 gesamt, +2)

Crons (11 gesamt, +3)

DB-Tabellen (2 neu)

Verbleibende Self-Improvement-Mechanismen aus Teil 6

Monatlicher distillation-review läuft bereits (bewertet + cleant die Solutions-Tabelle).

Phase 8: Agenten-Aktivierung ✅ (Prompts für alle 6)

Datum: 2026-04-24 02:10 UTC Status: OpenClaw-Prompts für 6 Agents live, Trigger in späteren Builds

6 neue OpenClaw-Prompts (/docker/openclaw-sh3f/data/.openclaw/agents/{x}/agent/prompt.md)

Reihenfolge laut v1.6 Teil 14:

  1. stuart/agent/prompt.md — Lead Hunter: qwen3:8b + Crawl4AI/SearXNG, 3 Mails/Tag/Kanal hard limit, DSGVO-konform
  2. penny/agent/prompt.md — Marketing Strategist: Kimi K2 primär, Sheldon-Review pflicht, Budget-Gate für Claude bei >€1000-Kampagnen
  3. zackpixel/agent/prompt.md — Media Producer: qwen3:8b für Prompts + Media-APIs, Kosten-Preview vor jedem Call, Tages-Budget $5
  4. leonard/agent/prompt.md — Buchhalter (KEIN LexOffice): Perfex Invoice/Expense/Proposals, GPT-5 bei Komplex-Fällen, monatliche BWA
  5. amy/agent/prompt.md — QA + Codex (Codex-Abo vorhanden): primär ChatGPT Codex, Fallback Claude Sonnet. Hard $3/Tag.
  6. bernadette/agent/prompt.md — Security+Compliance: qwen3:14b, Claude mit Chapaty-Gate, Secret-Rotation 90-Tage, Learnings-Konflikt-Check wöchentlich

Profile-Updates (/root/agents/*.md)

Was NICHT in diesem Build

Chapaty-TODOs

  1. Codex-Installationspfad bestätigen (wo ist die Codex-Binary installiert? Amy muss wissen wie sie sie aufruft)
  2. Für Penny: erste Kampagnen-Briefing-Vorlage freigeben
  3. Für Zack: API-Keys für Gemini Imagen / Replicate / Pixverse (optional, pro API)
  4. Für Bernadette: Security-Scan-Scope (welche Sites sollen wöchentlich gescannt werden?)

Phase 9: Tool-Rüstung ✅ (Listmonk deployed, andere credentials-gated)

Datum: 2026-04-24 02:15 UTC

Credentials-Audit

ToolCredentialStatus
NVIDIA NIMnvidia_nim_key.txt✅ aktiv
OpenAIopenai_api_key.txt⚠️ PLACEHOLDER — Amy nutzt Codex-via-Abo (Korrektur)
Hunter.io—❌ fehlt (Stuart optional, nicht blockierend)
Replicate (Flux)—❌ fehlt
ElevenLabs—❌ fehlt
Segmind (Pixverse)—❌ fehlt
Google AI Studio (Imagen)—❌ fehlt
Mailgun—❌ fehlt
Shopify—❌ fehlt
Meta Graph—❌ fehlt
LinkedIn—❌ fehlt
DataForSEO—❌ fehlt
DeepL—❌ fehlt
LexOffice—❌ gestrichen (v1.6 Korrektur — Perfex-only für Leonard)

Listmonk deployed (Newsletter self-hosted)

Erstes Login: Admin-Setup über http://localhost:9001 (Chapaty muss initial Super-Admin-Passwort setzen).

Chapaty-TODOs: fehlende Credentials priorisiert

MUSS (Revenue-kritisch, sollte innerhalb 2 Wochen):

  1. Google AI Studio API-Key (Gemini Imagen, 500/Tag Free Tier) — Zack braucht das
  2. Replicate API-Key (Flux, $5/Monat ausreichend) — Zack Fallback-Bilder
  3. Hunter.io API-Key ($49/Monat) — Stuart für Email-Prospecting (optional aber nützlich)

SHOULD:

  1. ElevenLabs für TTS (Hörbuch-Produktion HF-Dartsch-Serie)
  2. Meta Graph API (Instagram + Facebook Posting) — Penny
  3. LinkedIn-Integration (OAuth-genehmigungspflichtig) — Penny B2B

COULD (später):

  1. Pixverse via Segmind — AI-Video
  2. DataForSEO — Keyword-Research
  3. Shopify-Admin-API für hochfrequenz.tech (OAuth)
  4. DeepL API — DE/EN/ES Mehrsprachigkeit
  5. Mailgun für produktive Email-Outbound (aktuell all-inkl via SMTP, funktional aber kein scaling)

WON'T/GESTRICHEN:

Was nicht in diesem Build gebaut

Listmonk-N8N-Tool-Webhooks (newsletter-create-campaign, newsletter-send, newsletter-stats) — wenn Penny erste Kampagne plant, dann als Teil der Kampagne-Implementation bauen (nicht auf Vorrat).

Phase 10: Echte Aufträge — Vorbereitung ✅

Datum: 2026-04-24 02:18 UTC Status: 4 Perfex-Projekte + Briefing-Queue-Dokument für Chapaty

Angelegte Perfex-Projekte (Platzhalter bis Chapaty-Briefing)

Projekt-IDNameStatus
#21[GFKB] intern.gfkb.org Shop-Aufbauwartet auf Briefing
#22[HF] HF Content-Serie Schlafstudiewartet auf Briefing
#23[VV] Shelter-SaaS Lead-Kampagnewartet auf Briefing
#24[VV] Viaviva.team öffentliche Websitewartet auf Briefing

Zentrales Briefing-Dokument

/root/wiki/system/briefing_queue_for_chapaty.md — pro Projekt:

Nicht angelegt (zu früh/komplex)

Kein Execute in diesem Build

Laut Chapaty-Vorgabe: nur vorbereiten, kein echter Durchlauf. Chapaty briefed pro Projekt → Lenny legt Tasks an → Agents arbeiten.

🏁 Build v1.6 Phase 3-10 ABGESCHLOSSEN (2026-04-24 02:20 UTC)

Übersicht

PhaseStatusKernergebnis
Phase 3 Escalation+Distillation✅2 DB-Tabellen + 3 Tools (log-escalation, get-best-escalation-for, record-distillation)
Phase 4 WP-Onboarding Dry-Run intern.gfkb.org✅Schablone 🟢 bereit, Task #19 offen für Chapaty
Phase 5 Perfex-Agent-API✅Custom 273-Zeilen Plugin live, alle CRUD-Endpoints
Phase 6 OpenClaw Howard+Sheldon⚠️ teilweisePrompts v1.6-konform, Gateway-Routing später
Phase 7 Self-Improvement✅Mech 1-4 live (+2 Tools, +3 Crons), 5+6 Fundament
Phase 8 Agenten-Prompts✅6 neue Prompts (Amy+Codex korrigiert, Leonard Perfex-only)
Phase 9 Tool-Rüstung✅ ListmonkNewsletter-Container live; 11 Tools TODO
Phase 10 Echte Aufträge vorbereitet✅4 Projekte (#21-24) + briefing_queue_for_chapaty.md

Pre-Build-Backup

/backup/daily/daily-20260424.tar.gz (508M) — alle 12 Punkte, Perfex-DB-Dump enthalten ✅

Korrekturen eingearbeitet

  1. Amy bleibt IN (Codex-via-Abo vorhanden)
  2. Leonard: KEIN LexOffice — Perfex Invoice/Expense/Proposals
  3. Off-Site-Backup: KEIN Hetzner — Hostinger-Panel-Snapshot

Chapaty-TODOs (priorisiert)

  1. Briefings für 4 Projekte (siehe /root/wiki/system/briefing_queue_for_chapaty.md)
  2. GPG-Keys für Backup (5 Min Arbeit, kritisch)
  3. Hostinger-Snapshot-Policy im Panel
  4. Codex-Pfad bestätigen (Amy)
  5. Google AI Studio API-Key (Zack für Bilder)
  6. Task #19 Rückfragen beantworten (GFKB strategy.md)

Empfehlung nächster Schritt

Projekt #22 HF Content-Serie Schlafstudie briefen — einfachster End-to-End-Test:

v1.6 OpenClaw-Leben-Erwecken Build (2026-04-24 02:30 UTC)

Status: 🟡 GELB — Infrastruktur gebaut, Runtime-Issues dokumentiert

Gebaut

  1. OpenClaw Bridge — media-server /openclaw-execute + N8N-Tool tool-openclaw-execute (Tool 55)
  2. Howard-Heartbeat umgestellt — OpenClaw primär, Ollama-Fallback bei Timeout
  3. Queue-Discipline — Pick-Query mit AND (SELECT COUNT(*) FROM n8n_task_queue WHERE status='active') < 2
  4. Prognose-Kalibrierung — tool-get-duration-estimate + tool-record-task-duration (Tools 56+57) + neue DB-Tabelle n8n_task_duration_stats
  5. Prompts v1.6-konform:

Tool-Summe: 57 (war 54 → +3)

Tests ausgeführt

Tests NICHT ausgeführt (Runtime-Blocker)

Empfehlung

Option A (Hybrid, pragmatisch): Projekt #22 HF Content-Serie Schlafstudie in Hybrid-Mode starten. System ist architektonisch v1.6. Option B (puristisch): 1-2 Tage OpenClaw-Fix-Build (Workspace-Slimming, Gateway-Binding, MCP-Tool-Registrierung).

Details in /root/wiki/system/validation/2026-04-24_openclaw.md + /root/wiki/system/validation/openclaw_ready.md

---

v1.6 OpenClaw Fix + Refactor Build (2026-04-24 04:20 UTC)

Pre-Build-Backup

/backup/hourly/hourly-20260424-0413.tar.gz (64K)

Block A: Workspace-Refactor — abgeschlossen

Jeder Agent bekommt die Research-konforme 6-File-Struktur (SOUL/AGENTS/USER/TOOLS/MEMORY/HEARTBEAT).

Token-Budgets pro Agent (Ziel ≤ 2000 Tokens):

Aufteilung laut Research-Spec:

Entfernte Dateien (archived in _archive_pre_v16_refactor/):

Archivierte Backups:

Block A fortsetzung (Bindings + Context-Window)

Bindings konfiguriert in openclaw.json:

Context-Window-Problem gelöst: Root Cause war, dass Ollama qwen3:8b default nur 16k ctx rapportiert. OpenClaw-warning-Threshold ist 32k. Fix: neue Modelfile-basierte Varianten erstellt:

Agent-Zuweisungen umgestellt auf -32k-Varianten:

Block B + C Zusammenfassung

Latenz-Problem: Howard antwortet, aber über Codex-Fallback (5 min). qwen3-32k-Versuch scheitert in OpenClaw-embedded-runner, obwohl direkt via curl funktionsfähig. Ursache vermutlich deep in Ollama-OpenAI-Bridge — out-of-scope für diesen Build.

agent.bindings-Schema: Vom Config-Validator abgelehnt. OpenClaw 2026.4.15 nutzt vermutlich anderes Location (channels.*.bindings oder ähnlich). In Research-Doc stand yaml-Format das anders positioniert werden muss. Nachgelagerter Fix.

Onboarding-Ready: 4 neue Tools (file-ops, vision-analyze, build-resource-snapshot, perfex-file-upload), DB-Tabelle n8n_resource_snapshots. System kann jetzt onboarding material.zip verarbeiten.

Raj-Problem behoben: corrections.md erweitert. Raj-Logic wird openclaw-sh3f-Stack nicht mehr mit docker rm+docker run behandeln.

🏁 Build v1.6 OpenClaw-Fix ABGESCHLOSSEN

Rating: 🟡 GELB

Nächster Schritt: Chapaty kann onboarding material.zip hochladen + Briefing-Prompt starten.

---

immovia.plus Cockpit Phase 1 (2026-04-30 17:25 UTC)

Pre-Build-Backup: /backup/manual/pre-immovia-cockpit-phase1-20260430-170800.tar.gz

Ausgangslage

Cockpit-Modul /var/www/html/modules/immovia_cockpit/ v0.1.0 war als reiner Read-Only-Lister installiert: 4 Tabellen-Views (Tipps, Objekte, Profile, Sessions), Detail nur für Tipps. Controller hatte Methoden object_new, object/$id, object_save, object_toggle_publish — die referenzierte View object_form.php fehlte. Daher kein Klick-Through auf Objekte, kein Anlegen, keine Bearbeitung. DB enthielt 1 Objekt (PY-1903 Stub).

Geliefert

  1. Astro→DB Importer /root/projects/immovia/scripts/import_astro_to_db.py — idempotenter Sync der src/content/objects/*.json Astro-Content-Dateien in tblimmovia_objects + tblimmovia_object_photos. PY-1903 (Altbau Asunción) komplett aufgefüllt, PY-26K-0001 (Traumhaus Caacupé) neu via Sequenz angelegt. Beide Objekte 6-sprachig mit voller Beschreibung, Eckdaten, Features, Tags, paper_status, Foto-Pfaden.
  2. Heute-Dashboard dashboard() + views/dashboard.php als neue Cockpit-Startseite (index→dashboard). 4 Quadranten + 6er KPI-Reihe: Was-muss-heute (Pending Changes, neue Tipps 24h, Eskalationen, Faktencheck-Blocks), Mateo-Live (5 letzte Sessions), Pipeline-Puls (Objekt-Status-Bar + Tipps + Profile), Quick-Actions.
  3. Objekt-Liste views/objects.php — Status-Counts oben, Pending-Changes-Badge, Foto-Count, „Neues Objekt"-Button, Bearbeiten-Link pro Zeile.
  4. Objekt-Detail/Form views/object_form.php (NEU, 280+ Zeilen) — Tab-Layout mit 9 Tabs: Stammdaten, Titel & Beschreibung (6 Sprachen), Lage (mit Sensible-Daten-Warnhinweis), Eckdaten, Features & Tags, Preis & Status (inkl. Verhandlungs-Min Staff-only), Papiere-Checkliste, Fotos-Galerie, Dokumente, Änderungs-Log, Aktivitäts-Timeline. Verwendet form_open() für CSRF-Auto-Inject (vorher 403 weil HTML-Form ohne Token).
  5. Aktivitäts-Timeline je Objekt — aggregiert object_changes, verlinkte Mateo-Sessions (über related_object_id), Tipps die zum Objekt führten, plus Object-Lifecycle (created/updated). Vertikale Timeline mit Icons.
  6. Sidebar-Menu ergänzt um „Heute" als position=1 (vor Tipps).

Tests

Bleibt offen für Phase 2

---

immovia.plus Cockpit Phase 2 — Kanban + Karte (2026-04-30 17:30 UTC)

Pre-Build-Backup: /backup/manual/pre-immovia-phase2-kanban-20260430-172341.tar.gz

Geliefert

  1. Kanban-Pipeline — kanban() Controller + views/kanban.php. 8 Status-Spalten (Eingang→Aufgegeben), farbcodiert. Karten mit Cover-Thumb, Public-ID, Titel, Ort+m², Preis (k-Notation), Live/Exklusiv-Badges, Foto-Count, Tage-in-Status. Drag-and-Drop via SortableJS (CDN, 1.15.2). Bei Drop: AJAX POST an object_set_status mit CSRF, Spalten-Counter wird live aktualisiert, Toast unten rechts ("Speichere … / ✓"). Bei Fehler: Karte snappt zurück.
  2. AJAX-Endpoint object_set_status — schreibt Status + updated_at, plus approved Audit-Eintrag in tblimmovia_object_changes (raw_message: "Status-Wechsel via Kanban", source_role=staff). Ergebnis erscheint automatisch in der Objekt-Timeline.
  3. Karte — map() Controller + views/map.php mit Leaflet 1.9.4 (CDN, OpenStreetMap-Tiles). Status-farbige Pins (DivIcon mit Initial-Buchstaben des object_type), Popup mit Cover-Thumb, Public-ID, Titel, Ort/m², Status-Badge, Details-Link. Auto-fitBounds bei mehreren Pins, Default-Center Asunción/Cordillera (-25.40, -57.30) wenn keine GPS-Daten. Side-Panel mit Liste „Ohne GPS" inkl. Direkt-Link zum Lage-Tab.
  4. Sidebar-Menu ergänzt: „Pipeline (Kanban)" position=11, „Karte" position=12.

Tests

Bleibt offen

---

immovia.plus Foto-Enhancement Pipeline (2026-04-30 17:40 UTC)

Pre-Build-Backup: /backup/manual/pre-immovia-phase2-kanban-20260430-172341.tar.gz

Komponenten

  1. media-server /process-image-enhance Endpoint (/root/media_server.py, ~150 LoC). ImageMagick-Pipeline mit allen Schritten einzeln deaktivierbar:
  1. Cockpit Foto-Upload im Object-Form Tab „Fotos":
  1. Foto-Management UI:
  1. media-server Erweiterungen:

Tests

Was kommt automatisch in die Pipeline (nicht abwählbar)

Bleibt offen für später

---

immovia.plus PAUSE — Phase 1+2 abgeschlossen (2026-04-30 17:46 UTC)

Resume-Dokument: /root/projects/immovia/RESUME.md — vollständiger Stand für jederzeitige Fortsetzung.

Backups:

Memory aktualisiert: /root/.claude/projects/-root/memory/project_immovia_cockpit.md zeigt auf RESUME.md.

Heißester Phase-3-Punkt: Astro-Auto-Deploy nach Foto-Upload (~1–2 h Aufwand, schließt den Loop „Cockpit-Edit → 60 s später live auf immovia.plus"). Backlog mit 6 priorisierten Punkten in RESUME.md.

Projekt-Wechsel: ab jetzt Fokus auf hochfrequenz.tech (Perfex-Projekt #22 HF Content-Serie Schlafstudie offen, sites/strategy unter /root/wiki/clients/HF/ und /root/projects/HF/).