Kansho/docs/architecture/technical/product_frame_and_stack.md

title	version	status	date	product_family	document_role	parent_document
Kanshō – Produktrahmen und Stack	0.1	Arbeitsstand	2026-08-19	Jinkendo	Technical Chapter / Product Frame / Stack	technische_zielarchitektur.md

Kanshō – Produktrahmen und Stack

Kanonisches Home für die übertragbare Laufzeit- und UI-Hülle. Fachliche Identität bleibt in ../functional/produktvision_und_produktidentitaet.md.

1. Herkunft

Explizite Nutzeranforderung: Der Produktrahmen (PWA, Responsive, Desktop/Mobile-Shell, Authentifizierung, Userrollen, Multiuser auf Instanz-Ebene, API- und Deploy-Muster) soll weitgehend von Mitai übernommen werden, nicht neu entwickelt werden.

Der aktuelle fachliche Konzeptionsstand zu Dialog, Memory und MVP ist nicht final. Datenschutz und Guardrails sind bindend. Mitai enthält kein Kanshō-Privacy-Gateway; dieser Pfad wird ergänzt, nicht von Mitai übernommen.

Referenz: Mitai Jinkendo, nicht Kairo und nicht Shinkan.

Mitai-Foundation beschreibt übertragbare Muster unabhängig von Körper-Tracking: C:\dev\mitai\.claude\docs\jinkendo-foundation/.

2. Systemüberblick

Kanshō folgt dem Mitai-3-Tier-Modell.

Nutzergerät (PWA)
    ↓ HTTPS
Frontend (React + Vite, Nginx in Prod)
    ↓ /api
Backend (FastAPI)
    ↓
PostgreSQL
    ↓ nur über Privacy Gateway
Externe KI / Tools

Alle persönlichen Daten und das Identity Mapping liegen in der Local Trusted Zone. Siehe privacy_gateway.md.

3. Stack

Schicht	Technologie	Status
UI	React 18 ohne TypeScript-Pflicht	entschieden
Build	Vite, vite-plugin-pwa	entschieden
Routing	React Router 6	entschieden
Icons	Lucide React	entschieden
API	FastAPI, Python 3.12	entschieden
DB	PostgreSQL 16	entschieden
Auth-Hash	bcrypt	entschieden
Container	Docker Compose	entschieden
Reverse Proxy	Nginx vor dem Frontend-Bundle (Prod-Muster Mitai)	bevorzugte Richtung
Hosting	selbst gehostet, Gitea-CI wie die Familie	entschieden

State Management: Context (Auth, Profil), kein Redux. Herkunft: Mitai-Frontend-Muster.

4. Was als Rahmen übernommen wird

Weitgehend das Mitai-Muster, inklusive konkreter Datei- und UX-Mechanik:

• PWA-Installierbarkeit, Vite PWA-Plugin, Manifest.
• Breakpoint 1024px, Bottom-Nav, Desktop-Sidebar, Safe Area.
• Nav-SSoT, Bereichs-Shells, RequireAdmin, Admin-Realm.
• AuthContext, Login/Register/Verify/Setup analog Mitai.
• Server-Sessions, Rollen user / admin, Rate Limits, bcrypt.
• Ein Modul = ein Backend-Router, API-First, Fehlerformat {detail}.
• Nummerierte SQL-Migrationen, Compose Dev/Prod, Gitea-Branches.
• Multiuser auf Instanz-Ebene, Isolation über Session-profile_id.
• Registry-Muster, Prompt-/Workflow-Engine, Data Layer, Feature-Check an der API: platform_extensibility.md.

Platzhalter-Seiten der Mitai-Nav dürfen als leere Shell-Routen mitwandern, bis der Fachstand Kanshō-Inhalte vorgibt. Sie werden nicht mit Tracking-Fachlogik gefüllt.

5. Was nicht übernommen wird

Nur Domäne, Mandantenmodell und bekannte Sicherheitslücken – nicht der Rahmen.

Nicht übernehmen	Begründung
Körper-Tracking, Messwerte, Capture-Fachlogik, CSV-Import, Membership als Kern	Mitai-Domäne
Shinkan: Verein → viele Nutzer	anderes Produktmodell
X-Profile-Id ohne Session-Bindung	IDOR; siehe auth_identity_and_roles.md
TypeScript-Pflicht, JWT/SSO als Ist	nicht Mitai-Rahmen
Direkter LLM-Provider-Call aus der Engine	Kanshō ergänzt Privacy Gateway (privacy_gateway.md)

Kanshō-spezifische Startlogik, Dialog-IA und Memory-Modelle kommen aus der späteren Fachkonzeption. Sie sind kein Grund, Login, Shell, Deploy oder Router anders zu bauen.

6. Multiuser ohne Mandanten

Status: entschieden

Kanshō ist nutzerbezogen. Ein Account entspricht einem Profil. Es gibt keine Vereine, Clubs oder Organisations-Workspaces.

Mehrere Nutzer auf einer Instanz sind zulässig (wie Mitai). Isolation erfolgt über profile_id der Session, nicht über eine Tenant-Tabelle.

Admin sieht Diagnose- und Verwaltungsfunktionen, nicht die private Reflexion anderer Nutzer als Alltagspfad. Details: admin_diagnostics.md.

7. KI im Rahmen

Externe Modelle sind für leistungsfähige Dialoge vorgesehen. Sie sind kein Teil des UI-Frameworks. Jeder persönliche Aufruf läuft über das Privacy Gateway. OpenRouter ist Kandidat, kein Zwang.

Mitai-Prompt-Engine-Muster (ein Executor, Registry, Admin-Konfiguration) wird übernommen; der LLM-Callback ist in Kanshō das Privacy Gateway, nicht Roh-OpenRouter. Siehe platform_extensibility.md.

8. Entscheidungsstand

Thema	Stand	Status
3-Tier PWA	React + FastAPI + PostgreSQL	entschieden
Referenz	Mitai-Rahmen weitgehend	entschieden
Fachliche IA / Startroute	nicht durch den Rahmen vorwegnehmen	offen (Fach-Arbeitsstand)
Mandantenmodell	keines	entschieden
Konkrete Ports/Domains	lokal 5188/8018; Server 3006/8005 und 3096/8096; kansho.jinkendo.de	entschieden 2026-09-07
Gemeinsame UI-Bibliothek der Familie	eigene Kopie des Musters, kein Shared-Package vorausgesetzt	bevorzugte Richtung

9. Offene Fragen

1. Soll der Rahmen später in ein gemeinsames Jinkendo-Paket extrahiert werden oder als kopiertes Muster in Kanshō leben?
2. Welche Domain und welche Host-Ports gelten für Dev/Prod? Entschieden 2026-09-07: kansho.jinkendo.de / dev.kansho.jinkendo.de, Ports 3006/8005 und 3096/8096. Prod-Frontend nicht 3005 (Bookstack).
3. Wird Nginx als eigener Container beibehalten oder das Vite-Preview nur für lokale Entwicklung genutzt? Entschieden: Frontend-Nginx im Compose-Container (Prod/Dev-Server); Vite nur lokal.

10. Querverweise

• Fachlich: ../functional/produktvision_und_produktidentitaet.md §19, §21.11
• Technisch: alle übrigen Kapitel dieses Ordners
• Mitai: .claude/docs/technical/ARCHITECTURE.md, FRONTEND.md, Foundation-Index