Damit Betreiber im Postfach sofort erkennen, ob eine Meldung aus einem
Browser oder der Desktop-App kommt (und mit welchem Stand), beschreiben
Administrationshandbuch und Betriebshandbuch das neue Betreff-Kürzel und
die Zeile "Herkunft"; das Betriebshandbuch erklaert zusaetzlich den Fall
eines alten Desktop-Clients ohne Details.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016g2npLxzH5gZpg8s2S6vKh
Die Middleware liest jetzt zusaetzlich dv/dc/dos aus der Anfrage und legt
daraus das Cookie tessera_desktop_client an (bereinigt per Muster, nur
wenn alle drei Werte gueltig sind); desktop-client.ts liest es zurueck.
Der Fehler-melden-Dialog fuellt daraus vier neue Nutzlastfelder
(clientKind/clientOs/clientVersion/clientCommit), damit die API die
Herkunft der Meldung ausweisen kann. Ohne das zweite Cookie (alter
Client) bleibt es bei "Desktop-App (unbekannt)".
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016g2npLxzH5gZpg8s2S6vKh
with_desktop_marker haengte bisher nur desktop=1 an die erste Navigation;
der Fehler-melden-Knopf konnte deshalb Windows- und Linux-Client nicht
unterscheiden. with_client_marker ist die neue reine Kernfunktion (dv,
dc, dos zusaetzlich zu desktop=1), with_desktop_marker bleibt als Huelle
mit den echten env!-Werten die unveraenderte Aufrufstelle an allen drei
Navigationen.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016g2npLxzH5gZpg8s2S6vKh
WebView2 (Windows) sieht im User-Agent aus wie Edge, WebKitGTK (Linux) wie
Safari — im Postfach war eine Client-Meldung von einer Browser-Meldung
nicht zu unterscheiden. Neuer reiner Helfer origin.ts leitet aus vier
optionalen DTO-Feldern (Desktop-App) bzw. dem User-Agent (Browser) ein
Betreff-Kuerzel und eine Zeile "Herkunft: ..." ab; rein informativ,
laengenbegrenzt, nichts wird gespeichert (T-GZA-01). Browser-Pfad ist
damit Ende-zu-Ende fertig.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016g2npLxzH5gZpg8s2S6vKh
Quick 260917-kgc (Plan/Recherche/Bericht/Verifikation) und Schnellfix a6d1a64
in der Quick-Task-Tabelle; Nachweise in allen sechs Berichten nachgetragen
(Playwright lokal, CI-Laeufe 382-384, Windows-Test-VM: In-App-Update
7479cb4 -> a6d1a64). Ueberholte .continue-here-Dateien entfernt,
Desktop-Client-Todo geschlossen.
Dieser Push aendert nichts unter apps/desktop -- er ist zugleich der
Beweisfall 2 des CI-Desktop-Skips (Pakete aus dem Zwischenspeicher).
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016g2npLxzH5gZpg8s2S6vKh
Neues Command get_client_info liefert "Tessera-App X.Y.Z · Stand <sha7>"
(ohne Stempel nur die Version); die Setup-Seite blendet die Zeile beim
Erststart und unter "Server-Adresse ändern" dezent ein. So ist ohne
Adressleiste erkennbar, welcher Client-Stand läuft.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
- Anwenderhandbuch: Menüeintrag "Update installieren", Ablauf per Klick
unter Windows/Linux, Fehlerfall, https-Bedingung, einmaliger Wechsel für
Clients bis 1.2.0
- Betriebshandbuch Kap. 10: Signierschlüssel (Secrets, Ablage, Sicherung,
Verlust), Kontrollzeile /desktop/update, Manifest-Felder, zwei Fehlerbilder
- Entwicklungshandbuch: lokal `tauri build --no-sign`, Hinweise zu tauri dev
- ci-cd-setup.md: die zwei neuen Secrets, Bau-Schritte signieren,
Fehlerbild "no private key"
- CHANGELOG: eine Zeile unter Unveröffentlicht → Neu
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
- ci.yml: Secrets TAURI_SIGNING_PRIVATE_KEY/_PASSWORD als env nur an den
beiden tauri-build-Schritten des Jobs desktop (kein Job-env, kein
--no-sign); alles andere strukturgleich
- desktop-collect.sh: liest <bundle>.sig (genau eine Base64-Zeile) als
files.<p>.signature ins Manifest, schreibt updateVersion (X.Y.Z bzw.
X.Y.Z-beta.g<sha7>); fehlende .sig bricht auf main/Tag oder bei
gesetztem Schluessel ab, warnt sonst (dev, lokal --no-sign)
- desktop-stamp.sh check: kein Cache-Stand ohne updateVersion und
Signaturen beider Plattformen
- .gitignore: *.key
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
- Neuer oeffentlicher Endpunkt (vor download/:platform): base-Origin wird
per safeOrigin validiert (nur http/https, kein Pfad/Query/Fragment/
Userinfo, sonst 400) und nur zum Bau der absoluten Download-URL genutzt,
nie serverseitig abgerufen
- 204 ohne Body bei fremder Plattform/Architektur, fehlendem Manifest,
fehlender Signatur oder fehlendem/ungueltigem updateVersion; sonst
{ version, pub_date (nur RFC 3339), url, signature, notes }
- Manifest-Felder signature (je Plattform) und updateVersion optional in
@tessera/shared, Eintragspruefung akzeptiert nur String-Signaturen
- 10 neue Spec-Tests, Test 11 erweitert (23 gesamt); latest/download
unveraendert
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
- tauri-plugin-updater 2.11 + semver eingebunden; pubkey, installMode passive
und createUpdaterArtifacts in tauri.conf.json (kein endpoints, keine
dangerous*-Schalter)
- Versionspruefung laeuft ueber updater_builder().check() gegen
/api-proxy/desktop/update mit eigenem version_comparator (is_update_newer:
hoehere Basis oder anderer Beta-Stempel beta.g<sha7>; gleiche Basis Live
→ kein Update); 15 s Pruefung, 600 s Download-Timeout
- Tray-Eintrag "Update installieren" laedt mit Fortschritt im Menuetext,
prueft die minisign-Signatur, installiert (Windows NSIS passiv, Linux
AppImage an Ort und Stelle) und startet neu; Fehler → Benachrichtigung
und Rueckfall auf die Einstellungsseite im Browser
- http-Server im Release: Menuetext "Update nur über https möglich", gesperrt
- 15 neue Tests, 2 umgestellt (33 gesamt); gen/schemas vom Bau nachgezogen
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Vier Quick-Tasks mit Plan, Bericht und Verifikation; Browser-Nachweis der
Web-Teile lokal erbracht (Kacheln #284a7b bei #0057b8, Proxy-Symbol trotz
Zertifikatsfehler, Direktbild bei interner Adresse, Sortierung ueber Reload).
Offen: CI-Beweis des Desktop-Skips nach diesem Push, Windows-VM-Probe der
Client-Aenderungen mit dem CI-Paket.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
- Neuer Unterabschnitt „Server-Adresse ändern" vor „Automatischer Start": wo die Adresse steht (Hinweistext, Menüzeile, Einstellungen → Desktop-App) und wie sie geändert wird (Rechtsklick → „Server-Adresse ändern…" → Setup-Seite → „Verbinden"/„Abbrechen")
- Tray-Liste ergänzt um „Verbunden mit …" (erste Zeile) und „Server-Adresse ändern…"; Hinweis auf den Tooltip nach der Liste; Erststart-Absatz verlinkt den neuen Unterabschnitt
- CHANGELOG.md: zwei Desktop-App-Stichpunkte unter Unveröffentlicht / Neu angehängt, fremde Zeilen unverändert (per git diff gegengeprüft)
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
- DesktopAppSettings rendert im Desktop-Client (useIsDesktopClient) einen Block "Verbunden mit: {origin}" plus Hinweis auf "Server-Adresse ändern…" im Infobereich-Menü; im Browser bleibt der Block weg
- Neue i18n-Schlüssel settings.desktop.connectedTo/changeHint in de.json und en.json
- Test 4 (Cookie tessera_desktop=1) und Test 5 (ohne Cookie) ergänzt; RED zuerst (Test 4 schlug auf der Zielbehauptung fehl), dann GREEN
- Alle 431 Web-Tests und type-check grün
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
- Tray zeigt erste (gesperrte) Menüzeile "Verbunden mit {host}" und Tooltip "Tessera – {host}" (bzw. "nicht verbunden")
- Neuer Menüpunkt "Server-Adresse ändern…" navigiert zur gebündelten Setup-Seite (lokaler Ursprung, kein Capability-Eintrag nötig)
- setup.html erkennt per neuem Command get_server_url den Änderungsmodus (Feld vorbelegt, "Aktuell verbunden mit: …", Knopf "Abbrechen" → open_server)
- Nach save_server_url aktualisieren apply_server (Tooltip + Menüzeile) und spawn_version_check (aus setup herausgezogen, läuft neu gegen den neuen Server) ohne Neustart; Tray-Klick "update" liest die Adresse jetzt beim Klick aus dem Store
- Reine Helfer server_host, tray_labels, setup_page_url, parse_server_url mit 13 neuen Tests (RED zuerst: 13 Compile-Fehler auf die fehlenden Helfer, dann GREEN); 18 Rust-Tests gesamt, fmt/check/clippy sauber
- capabilities/default.json unverändert (T-JN2-01, kein remote-Block)
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
- CHANGELOG.md: je ein Stichpunkt unter Neu (Sortierpfeile) und Behoben
(Symbol trotz Zertifikatsfehler/interner Adresse)
- docs/anleitung-anwender.md: Tabellenzeile „Favoriten" nennt die Pfeile
und den Browser-Ersatzweg fuer das Symbol
- docs/mandantentrennung-zugriffsklassifikation.md: Nachtrag zu
favoriteLink — reorder() laeuft ueber withTenantTransaction() ohne
Benutzerdimension in der Sitzung, Stand bleibt gebunden
- prisma-tenant.extension.ts: Kopfkommentar-Nachtrag, favorites.service.ts
(reorder) ist der erste Nutzer-CRUD-Aufrufer von withTenantTransaction()
— nur Kommentartext, Funktionscode unveraendert (prisma-tenant.extension.spec.ts
und rls-access-inventory.spec.ts weiterhin gruen)
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
- icon-discovery.service.ts: undicis eigenes fetch mit Modul-Singleton
LENIENT_TLS_AGENT (Agent({ connect: { rejectUnauthorized: false } }))
als dispatcher in fetchWithRedirectGuard, der einzigen Ausgangsstelle
fuer HTML-Ermittlung und Icon-Byte-Holen; SSRF-Schutz unveraendert
- undici 7.28.0 (bereits im Lockfile aufgeloest) als direkte Abhaengigkeit
von @tessera/api via pnpm add --offline
- PUT /favorites/order (ReorderFavoritesDto) vor den :id-Routen;
FavoritesService.reorder() setzt position=index fuer die Favoriten
eines Widgets in EINER withTenantTransaction, userId+widgetId in jeder
Bedingung (zweites Netz), eine BadRequestException fuer alle
Abweichungen (T-JDD-06)
- getIcon: X-Content-Type-Options nosniff + restriktive CSP (T-JDD-02)
- 10 neue Tests (3 Dispatcher, 7 reorder); volle API-Suite 68 Dateien/
1101 Tests und type-check gruen
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
- anleitung-betrieb.md Kap. 10: neuer Unterabschnitt "Wann gebaut wird und
wann Pakete uebernommen werden", Job-Dauer-Satz und Fehlerbilder-Tabelle
ergaenzt
- ci-cd-setup.md Abschnitt 4: Absatz zum Ueberspringen bei unveraendertem
Desktop; Abschnitt 6: neuer Fehlerbehebungs-Eintrag
- anleitung-entwicklung.md: Absatz zum CI-Ueberspringen bei "Desktop-App
lokal bauen"
- CHANGELOG.md: ein Stichpunkt unter Unveroeffentlicht/Geaendert
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
- Neues Skript .gitea/scripts/desktop-stamp.sh (Unterbefehle stamp/check):
Stempel aus Version + letztem Commit an den Desktop-Pfaden, Pruefung eines
restaurierten desktop-dist/ gegen Manifest, Kanal, Groesse und sha256
- ci.yml Job desktop: stamp -> actions/cache/restore (Stempel-Schluessel,
nur main) -> check -> 13 Bau-Schritte mit if: steps.reuse.outputs.reuse,
Stempel-Save vor unveraenderter Uebergabe an publish; quality/test/publish
und on: unveraendert (js-yaml-Tiefenvergleich gegen 38c1400)
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
- BRAND_OLIVE_MIX (54 %, #363636) und BRAND_OLIVE_FILL in brand.ts, Kalibrierung kommentiert
- vier achsenparallele Kacheln in tessera-logo.tsx: Inline-Style BRAND_OLIVE_FILL, festes Oliv-Attribut als Rückfall
- brand.test.ts (neu): rechnet Kalibrierung, Neutralität und Grenzfälle aus denselben Konstanten nach
- tessera-logo.test.tsx: Kacheltest auf Token-Fuellung (1x) und abgeleitete Fuellung (4x) umgestellt
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
publish-release.sh ignoriert GITHUB_API_URL/GITHUB_SERVER_URL (git.vicolab.de
hinter dem Proxy bricht grosse Uploads ab -- Release 1.2.0 blieb dadurch
zunaechst ohne Anhaenge). Im CI wird das Host-Gateway des Job-Containers aus
/proc/net/route ermittelt und Gitea direkt auf Port 3002 angesprochen, lokal
localhost:3002; GITEA_API bleibt als Override. Gateway-Weg aus Job-Netz
gegen die Gitea-API verifiziert; Anhaenge fuer v1.2.0 vom Host nachgetragen.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
- bundle.windows.nsis in tauri.conf.json: Deutsch ohne Sprachauswahl,
Tessera-Icon, Kopf-/Seitenbild, currentUser (kein Admin noetig)
- icons/nsis-header.bmp (150x57), icons/nsis-sidebar.bmp (164x314) ergaenzt
- CHANGELOG: vier neue Desktop-App-Stichpunkte (Beta-Hinweis, Installer,
Download-Links, Kontextmenue)
- anleitung-anwender.md: Installationsassistent-Satz, Tray-Eintrag erklaert
- anleitung-entwicklung.md: Ort der nsis-Konfiguration, Pruefweg per CI
- Schema-Pruefung (node) und cargo check gruen
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
- withDesktopCookie in middleware.ts setzt tessera_desktop=1 auf JEDER
Antwort (Fruehausstieg, Redirects, next()), wenn ?desktop=1 anliegt
- desktop-client.ts: isDesktopClient() liest das Cookie, useIsDesktopClient()
kapselt es hydration-sicher per useEffect
- DesktopDownloadLinks fragt /desktop/latest im Desktop-Client gar nicht
erst an und rendert nichts
- DesktopContextMenuGuard unterdrueckt das WebView2-Kontextmenue ausserhalb
von Eingabefeldern/contenteditable, in layout.tsx eingebunden
- middleware.test.ts (neu), desktop-client.test.ts (neu),
desktop-context-menu-guard.test.tsx (neu), Test 4 in
desktop-download-links.test.tsx — alle 417 Web-Tests und type-check gruen
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
- with_desktop_marker haengt desktop=1 an beide Navigationen (save_server_url,
Startnavigation im setup); der Store-Wert server_url bleibt ohne Parameter
- update_labels liefert Menue-/Benachrichtigungstext: bei Versionswechsel wie
bisher, bei gleicher Version (Beta-Kanal) nennt der Text den Commit-Stempel
- mod tests deckt beide Helfer ab (fmt/check/clippy/test --lib gruen)
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
- auth-actions.ts: fetchSessionState() unterscheidet tote Sitzung (401/403/leere 200-Antwort, Cookie wird geloescht) von API-Ausfall (5xx/Netzwerkfehler/Nicht-JSON, unavailable ohne Redirect); fetchCurrentUser bleibt unveraendert
- header.tsx: Waechter im useEffect leitet bei toter Sitzung per Vollnavigation auf /login?next=… um, bleibt bei API-Ausfall still
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
- safe-next.ts: buildNextParam()/sanitizeNextPath() als reine, getestete Funktionen (Open-Redirect-Schutz)
- middleware.ts: haengt next-Parameter an beide Login-Umleitungen (fehlendes Cookie, ungueltige Signatur)
- login/page.tsx: springt nach erfolgreicher Anmeldung auf den bereinigten next-Wert
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
- LogoMark: gedrehte Signalkachel per Inline-Style fill: var(--primary, BRAND_YELLOW) statt festem fill-Attribut
- folgt damit der persoenlichen Akzentfarbe (applyAccentColor in auth-store.ts) in Kopfzeile, Seitenleiste und leerem Dashboard; ohne Nutzer (Anmeldeseite) gilt der CSS-Standard Markengelb
- brand.ts: Kommentar zu BRAND_YELLOW als Rueckfallwert ergaenzt
- tessera-logo.test.tsx: Kacheltest auf Inline-Style-Fuellung umgeschrieben (jsdom haelt var() in style.fill)
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
schalli