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