Kansho/docs/architecture/technical/frontend_pwa_shell.md

87 lines
4.4 KiB
Markdown
Raw Normal View History

---
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 |
## 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`