Kansho/docs/architecture/technical/frontend_pwa_shell.md

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 / Dialog / Journal / Einstellungen. Der MVP-Slice füllt /journal:

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

/ bleibt dünn und verweist auf das Journal. /dialog ruft in der Testphase denselben Dialogzug auf wie der Journal Day (POST .../turn), bleibt aber ohne Space-Chronologie und ist nicht die zweite Produkt-IA. Home wird kein Dashboard. Der Journal-Editor führt ein Dirty-Flag; In-App-Navigation mit ungespeicherten Änderungen wird bestätigt. Stichpunkte: Return erzeugt eine neue Zeile und fokussiert sie.

Admin sieht unter dem Gespräch eine Testspur: intern gerenderter Prompt, maskierter Egress, Rohantwort, demaskierte Antwort, gewählte Dialogoperation. Keine Mapping-Tabelle. Nicht die produktive Nutzer-IA.

Die Dialogfläche bleibt in der Inhaltsäule der Shell. Lange Nachrichten und die Testspur umbrechen oder scrollen intern; sie dürfen die Seite nicht in der Breite aufweiten.

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