- Mode-Badge über dem Textfeld zeigt aktiven Agent-Modus (Handlanger/Experten/Auto) mit Verarbeitungsphase
- Plan-Erkennung: erkennt strukturierte Pläne in Claude-Antworten (Mermaid, Sektionen, Schrittlisten)
- Automatisches Senden erkannter Pläne ans Präsentationsfenster als Slides
- PWA Docker Build Pipeline hinzugefügt
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Problem: Beim Nix-Wrapper lag nur das Binary unter ~/.local/share/claude-desktop/bin,
aber claude-bridge.js + node_modules waren nirgends deployt → "Bridge nicht gefunden"
beim ersten Chat-Versuch.
Loesung:
- claude.rs: Bridge-Such-Pfad um bin/../scripts erweitert (exe_dir.parent / scripts).
- update.rs: UpdateManifest + UpdateStatus um bundle_filename/bundle_sha256 erweitert.
Neues Tauri-Command apply_bundle_update: laedt tar.gz, pruefte SHA256, entpackt
nach ~/.local/share/claude-desktop, ruft npm ci --omit=dev auf. Im AppImage-Modus
no-op (Bundle ist im AppImage enthalten).
- lib.rs: apply_bundle_update registriert.
- CI: packt scripts/claude-bridge.js + package.json + package-lock.json als
claude-desktop-bundle_VERSION.tar.gz und laedt neben Binary in die Package Registry.
update.json v3 enthaelt bundle_filename + bundle_sha256.
- install.sh: Erst-Installer laedt das Bundle, verifiziert SHA, entpackt, fuehrt
npm ci --omit=dev aus. Holt nodejs bei Bedarf ueber nix-build (analog zu jq).
- UpdateDialog.svelte: ruft im Nix-Modus apply_bundle_update vor apply_update auf,
damit nach dem Neustart Scripts + node_modules aktuell sind.
- nix/default.nix: nodejs_22 + tar + gzip im Wrapper-PATH, damit die App aus dem
Binary heraus npm ci aufrufen kann.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Mein Custom-AppRun ueberschrieb das gesamte linuxdeploy-Setup. Resultat:
WebKitNetworkProcess wurde nicht gefunden weil WEBKIT_EXEC_PATH und das
korrekte LD_LIBRARY_PATH/Symlinks fehlten.
Fix: NixOS-Detection + WEBKIT-Defaults VOR den Original-Hook setzen, dann
linuxdeploy-Hook + AppRun.wrapped wie im Original aufrufen.
Forgejo Package Registry weist PUT auf existierenden Pfad mit 409 ab.
Bisher wurde nur 'latest/' geloescht, nicht aber 'VERSION/'. Beim
zweiten Build mit gleicher Version (0.1.0) crashte der Upload daher.
Zwei kombinierte Patches:
1. main.rs: WEBKIT_DISABLE_DMABUF_RENDERER + WEBKIT_DISABLE_COMPOSITING_MODE
als defensive Defaults wenn nicht vom User gesetzt. Behebt typische
WebKit2GTK-Renderer-Crashes auf modernen Wayland-Setups.
2. Workflow: nach 'tauri build' wird der AppRun gepatched.
- Detect NixOS via /run/opengl-driver/lib -> Host-Mesa via LD_LIBRARY_PATH
- WebKit-Workarounds als ENV-Defaults (override moeglich)
- Standard linuxdeploy-Pfade (PATH, XDG_DATA_DIRS etc.)
- Re-bundle mit appimagetool
Resultat: AppImage laeuft out-of-the-box auf Debian/Ubuntu/Fedora/NixOS,
ohne dass der User ENV-Vars setzen muss.
Tauri produziert "Claude Desktop_0.1.0_amd64.AppImage" mit Leerzeichen.
curl encoded URLs nicht automatisch -> malformed HTTP-Request, Step crash
in 150ms beim PUT.
Fix:
- AppImage vor Upload zu "Claude-Desktop_..." umbenennen (tr ' ' '-')
- set -e + curl --fail -sS damit echte HTTP-Fehler den Step killen
- BASE-URL als Variable, weniger Wiederholung
- runs-on: docker -> appimage (16-Forgejo-Runner-AppImage)
- APPIMAGE_EXTRACT_AND_RUN aus Workflow raus (jetzt im Runner-ENV)
- Erster echter Test des dedizierten AppImage-Runners
Der 17-Forgejo-Runner (docker:host-Label) hat Rust 1.87, Node 22,
GTK, WebKit, AppIndicator, patchelf usw. bereits aus dem
docker.forgejo-runner-Image vorinstalliert. Der bisherige
container:-Block mit rust:1.83-bookworm + apt-get install hat
wegen DNS/Netzwerk in der DinD-Umgebung versagt.
Loesung: container: komplett entfernen, Job laeuft direkt im
Runner. Spart den Pull, spart die apt-Installationen und umgeht
das DNS-Problem.
- Triggert bei [appimage] im Commit oder Release-Tag (v*)
- Baut mit Tauri-Container + Node 22 + Rust stable
- Lädt AppImage als Artifact hoch
- Bei Tag: Erstellt automatisch Release mit AppImage
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
