Lars/Kansho
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
main
Kansho/docs/architecture/technical/frontend_pwa_shell.md
Lars e42f751fdc MVP 1.0
2026-08-29 20:28:59 +02:00

7.8 KiB
Raw Permalink Blame History

title version status date product_family document_role parent_document
Kanshō – Frontend-PWA-Shell und Navigation 0.1 Arbeitsstand 2026-08-19 Jinkendo Technical Chapter / PWA Shell / Navigation / Responsive technische_zielarchitektur.md

Kanshō – Frontend-PWA-Shell und Navigation

Kanonisches Home für PWA-Hülle, Breakpoint und Navigationsmechanik. Die Mitai-Shell wird weitgehend übernommen. Welche Kanshō-Orte später in dieser Shell stehen, folgt dem dann aktuellen Fachstand – der heutige Dialog-/Entry-Stand ist nicht final und wird hier nicht als technische Startroute eingefroren.

Mitai-Referenz: NAVIGATION_IA_DESIGN_PRINCIPLES.md, frontend/src/config/appNav.js, frontend/src/app.css, Shells unter frontend/src/layouts/.

1. Was die Shell übernimmt

  1. Progressive Web App, installierbar, Service Worker über Vite PWA-Plugin.
  2. Mobile First, vollwertiges Desktop-Layout.
  3. Ein Breakpoint: 1024px (Mitai). Darunter Bottom-Nav, darüber Desktop-Sidebar.
  4. Safe Area / Content-Padding für iOS-Homescreen.
  5. Eine Navigations-SSoT analog appNav.js (Reihenfolge, Labels, Icons, Admin-Sichtbarkeit).
  6. Bereichs-Shells, wenn ein Top-Level-Bereich eigene Sub-Navigation braucht.
  7. Getrennte Admin-Realm mit RequireAdmin.

Die Shell übernimmt die Mitai-Mechanik. Mitai-Labels (Übersicht, Erfassen, Verlauf, Ziele, Analyse) sind Domänenplatzhalter. Sie dürfen in einer ersten Rahmen-Kopie stehen, werden aber nicht mit Mitai-Fachseiten gefüllt. Die spätere Kanshō-IA ersetzt oder benennt sie, sobald das Fachkonzept dafür reif ist.

2. Fachliche Startlogik – nicht technisch einfrieren

Der aktuelle Fachstand bevorzugt Contextual Continuation statt eines Funktions-Dashboards (dialogue_model.md, produktvision_und_produktidentitaet.md). Das ist Arbeitsstand, kein finaler UX-Schnitt.

Technische Folge für den Rahmen:

  • Mitai-Home (/) und Nav-Mechanik dürfen zunächst wie in Mitai existieren (leere oder minimale Platzhalter).
  • Es wird keine verbindliche Kanshō-Startroute und keine endgültige Nav-Item-Liste in v0.1 festgeschrieben.
  • Interne Fachobjekte (Threads, Spaces, Hypothesen) werden nicht als Nutzer-Verwaltungsnav vorgebaut, nur weil der heutige Fachtext sie nennt.

3. Responsive Muster

Viewport Muster Status
< 1024px Bottom-Nav, volle Breite, Einhand-Nähe der Primäraktion entschieden als Rahmen
≥ 1024px Sidebar + Inhaltsfläche; Desktop darf Mehrspalten später nutzen entschieden als Rahmen
Lange Dialoge scrollbarer Verlauf, Eingabe unten; Desktop darf Kontextspalte später ergänzen bevorzugte Richtung

Kein zweites paralleles Layout-System. Zusätzliche Breakpoints nur mit dokumentiertem Grund.

4. PWA

  • vite-plugin-pwa wie Mitai.
  • Manifest, Icons und Offline-Cache gehören zur Shell.
  • Welche Daten offline schreibbar sind, steht in memory_storage_and_offline.md und ist in der Ausprägung offen.
  • Die Shell muss offline zumindest die installierte UI laden können (App Shell Cache). Fachliche Dialog-Offline-Fähigkeit ist davon getrennt.

5. Komponentenrahmen

Übernehmen als Muster, nicht als Domäne:

  • AuthContext
  • Layout-Shells
  • Avatar, einfache Markdown-Darstellung wo nötig
  • keine Mitai-Widgets, Charts oder Capture-Hubs als Kern

Business-Logik bleibt im Backend (backend_and_api.md).

6. Entscheidungsstand

Thema Stand Status
PWA + Vite PWA Plugin ja entschieden
Breakpoint 1024px Bottom-Nav / Sidebar entschieden
Nav-SSoT + Shells + Admin-Realm Mitai-Mechanik entschieden
Mitai-Nav-Labels als Platzhalter zulässig im Rahmen bevorzugte Richtung
Kanshō-Startroute / endgültige IA folgt späterem Fachstand offen
Desktop-Mehrspalten späterer Fach-/UX-Stand offen

6.1 Implementierungsstand (MVP-Journal-Routen)

Status: Code vorhanden, keine finale Start-IA. Technische Umsetzung der Routen: mvp_implementation.md §6. Fit-Gap zu Produktstart und /dialog: ../functional/mvp_stand_und_abgleich.md.

Die Shell-Nav bleibt Start / Journal / Einstellungen. Der MVP-Slice füllt /journal:

  • /journal Space-Liste
  • /journal/:spaceId Entry-Chronologie und Tage
  • /journal/:spaceId/trash Papierkorb
  • /journal/:spaceId/:dayId Dialog, Generate, include_existing, lokale Tagesstichpunkte
  • /journal/:spaceId/:dayId/entry Fließtexteditor (Markdown, Inline-Bild/Video, Versionen, Dirty-Flag)
  • /journal/:spaceId/:dayId/source/:conversationId Quelldialog

/ ist Kontinuität: Fortsetzen des letzten aktiven Journal Day oder Space-Einstieg, kein Dashboard. /dialog bleibt Admin-Harness. Der Journal-Editor führt ein Dirty-Flag; In-App-Navigation mit ungespeicherten Änderungen wird bestätigt. Browser-Zurück bleibt über beforeunload bewusst dünn. Stichpunkte: Return erzeugt eine neue Zeile und fokussiert sie.

Admin sieht unter dem Gespräch keine Live-Testspur mehr.

Additiv 2026-08-28: /admin/debug schaltet eine lokale Persistenz ein und aus (Default aus) und zeigt den Verlauf als Space / Tag / Gespräch / Schritt. Ist Persistenz an, bietet der Dialog (Journal-Tag und Dev-Harness) den Download der Gesprächs-JSON. Der generierte Tagebucheintrag behält die Journal-Testspur (CallTrace) und den JSON-Download des Entwurfs.

Additiv 2026-08-29: Der Journal-Tag behält vier Gestaltungsauswahlen. „Persönliche Stimme“ bleibt eine Liste; optional zeigt sie knapp, welche Stilquellen die gewählte Ausprägung verwendet. Kein zusätzlicher Regler.

Additiv 2026-08-29: Die Liste enthält zusätzlich Legacy-Vergleichsausprägungen. Admin zeigt Vorgänger-ID und Revision.

Additiv 2026-08-29: API-Fehler (Profilanalyse, Journal, Dialog) zeigen Code, Providergrund und eine Kostennotiz (cost_report.note), nicht nur „Anfrage fehlgeschlagen“. /api wird im Service Worker als NetworkOnly geladen, damit lange Review-Läufe nicht an einem GET-Cache hängen. Der Dev-Proxy wartet bis zu zehn Minuten auf /api.

Die Dialogfläche bleibt in der Inhaltsäule der Shell. Lange Nachrichten umbrechen oder scrollen intern; sie dürfen die Seite nicht in der Breite aufweiten. Zeilenumbrüche und Leerzeilen in Nutzer- und Impulstexten bleiben in der Darstellung erhalten.

Mobile (unter 1024px): Bottom-Nav, Kopfzeile, volle Breite, Safe-Area, Gespräche als kompakte Umschalter oben, Verlauf scrollt, Eingabe darunter in Daumennähe, Stichpunkte unter dem Dialog. Desktop (ab 1024px): Sidebar, Lesespalte für Standardseiten, Dialogfläche voll in der Inhaltsäule, Stichpunkte rechts daneben. Kein weiterer Breakpoint. Der Journal-Tag zeigt den Dialog zuerst; Draft und Einträge nur als kurze Verweise. Mehrere Gespräche werden erst beim Erzeugen des Tagebuchs zur Wahl gestellt.

Mobile (unter 1024px): Bottom-Nav, Kopfzeile, volle Breite, Safe-Area, Gespräche als kompakte Umschalter oben, Verlauf scrollt, Eingabe darunter in Daumennähe, Stichpunkte unter dem Dialog. Desktop (ab 1024px): Sidebar, Lesespalte für Standardseiten, Dialogfläche voll in der Inhaltsäule, Stichpunkte rechts daneben. Kein weiterer Breakpoint. Der Journal-Tag zeigt den Dialog zuerst; Draft und Einträge nur als kurze Verweise. Mehrere Gespräche werden erst beim Erzeugen des Tagebuchs zur Wahl gestellt.

7. Offene Fragen

  1. Welche Platzhalter-Routen bleiben in der ersten Rahmen-Kopie sichtbar, welche werden ausgeblendet, bis Fachseiten existieren?
  2. Wo liegt Journal-Lesen relativ zum laufenden Dialog (eigene Route vs. Overlay)?
  3. Wie wird Spracheingabe in der mobilen Chrome platziert, ohne die Dialogfläche zu verdrängen? → voice_and_media.md

8. Querverweise

  • Fachlich (aktueller Arbeitsstand, nicht final): ../functional/dialogue_model.md, ../functional/produktvision_und_produktidentitaet.md §19
  • Technisch: product_frame_and_stack.md, auth_identity_and_roles.md, admin_diagnostics.md