112 lines
7.1 KiB
Markdown
112 lines
7.1 KiB
Markdown
---
|
||
title: "Kanshō – Frontend-PWA-Shell und Navigation"
|
||
version: "0.1"
|
||
status: "Arbeitsstand"
|
||
date: "2026-08-19"
|
||
product_family: "Jinkendo"
|
||
document_role: "Technical Chapter / PWA Shell / Navigation / Responsive"
|
||
parent_document: "technische_zielarchitektur.md"
|
||
---
|
||
# Kanshō – Frontend-PWA-Shell und Navigation
|
||
|
||
Kanonisches Home für PWA-Hülle, Breakpoint und Navigations**mechanik**. 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.
|
||
|
||
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`
|