139 lines
6.5 KiB
Markdown
139 lines
6.5 KiB
Markdown
---
|
||
title: "Kanshō – Technischer Dokumentationsindex und Context Bundles"
|
||
version: "0.1"
|
||
status: "Arbeitsstand"
|
||
date: "2026-08-19"
|
||
product_family: "Jinkendo"
|
||
document_role: "Documentation Index / Technical Context Loading Guide"
|
||
parent_document: "technische_zielarchitektur.md"
|
||
---
|
||
# Kanshō – Technischer Dokumentationsindex
|
||
|
||
Für technische Arbeit nur die benötigten Dateien laden. Fachliche Homes nicht durch technische Kurzfassungen ersetzen. Dialog-/MVP-Stand nicht als final behandeln. **Datenschutz und Guardrails** (`../functional/guardrails.md`) sind verbindliche Invariante. Mitai-Produktrahmen weitgehend übernehmen, Gateway nicht umgehen.
|
||
|
||
**Technische Umsetzung (kanonisches Home):** `mvp_implementation.md`. **Fit-Gap-Analyse (fachlich):** `../functional/mvp_stand_und_abgleich.md` (2026-08-25). Technische Kapitel enthalten lokale Implementierungsstände; sie ersetzen weder die Umsetzungsbeschreibung noch die Fit-Gap-Analyse.
|
||
|
||
## 1. Root-Dokumente
|
||
|
||
Technisch:
|
||
|
||
- `technische_zielarchitektur.md` – Governance, Stack, Kapitelkarte, Entscheidungsstand.
|
||
- `documentation_index.md` – dieser Index.
|
||
|
||
Fachlich zusätzlich immer bei Querschnittsentscheidungen:
|
||
|
||
- `../functional/fachliche_zielarchitektur.md`
|
||
- `../functional/produktvision_und_produktidentitaet.md`
|
||
|
||
## 2. Technische Kapitel
|
||
|
||
| Datei | Kanonisches Thema |
|
||
|---|---|
|
||
| `product_frame_and_stack.md` | 3-Tier, Stack, Mitai-Übernahme |
|
||
| `auth_identity_and_roles.md` | Sessions, Rollen, Admin-Gate |
|
||
| `frontend_pwa_shell.md` | PWA, Responsive Shell, Navigation |
|
||
| `backend_and_api.md` | Router, API-First |
|
||
| `runtime_and_deploy.md` | Migrationen, Compose, Gitea |
|
||
| `platform_extensibility.md` | Registry, Prompt-Engine, Konfiguration |
|
||
| `data_architecture.md` | Persistenzgrenzen, Entitäten |
|
||
| `memory_storage_and_offline.md` | Dialogspeicher, Sync, Offline |
|
||
| `privacy_gateway.md` | Trust Zones, Egress, Demasking |
|
||
| `provenance_verification.md` | Intent-neutrale Provenienz- und Verifikationsschicht, `VerifiedArtifact` |
|
||
| `ai_architecture.md` | Inferenzpfad, Agenten |
|
||
| `integrations_technical.md` | Technische Handoffs |
|
||
| `admin_diagnostics.md` | Diagnoseansicht |
|
||
| `voice_and_media.md` | Sprache und Transkription |
|
||
| `security.md` | Security-Baseline |
|
||
| `mvp_implementation.md` | **Kanonisches Home der technischen MVP-Umsetzung** (Laufzeit, Module, Daten, API, Pfade; Profile-Analyse Export/Import §15). Fit-Gap bleibt fachlich. Freeze Candidate: `../functional/mvp_freeze_candidate.md`. |
|
||
|
||
## 3. Empfohlene Context Bundles
|
||
|
||
### Produktrahmen / erste Shell
|
||
|
||
1. `technische_zielarchitektur.md`
|
||
2. `product_frame_and_stack.md`
|
||
3. `auth_identity_and_roles.md`
|
||
4. `frontend_pwa_shell.md`
|
||
5. `backend_and_api.md`
|
||
6. `runtime_and_deploy.md`
|
||
7. `platform_extensibility.md`
|
||
8. fachlich: `../functional/produktvision_und_produktidentitaet.md` §19 und §21
|
||
|
||
### Produktrahmen / Erweiterung
|
||
|
||
1. `technische_zielarchitektur.md`
|
||
2. `platform_extensibility.md`
|
||
3. `privacy_gateway.md`
|
||
4. `ai_architecture.md`
|
||
5. `backend_and_api.md`
|
||
6. `admin_diagnostics.md`
|
||
|
||
### Privacy / externe KI
|
||
|
||
1. `technische_zielarchitektur.md`
|
||
2. `privacy_gateway.md`
|
||
3. `platform_extensibility.md`
|
||
4. `ai_architecture.md`
|
||
5. `provenance_verification.md`
|
||
6. `security.md`
|
||
7. fachlich: `../functional/guardrails.md`
|
||
8. bei Bedarf: `../functional/self_model_and_lived_experience.md`, `../functional/memory_and_context.md`
|
||
|
||
### Dialogspeicher / Memory / Offline
|
||
|
||
1. `data_architecture.md`
|
||
2. `memory_storage_and_offline.md`
|
||
3. fachlich: `../functional/memory_and_context.md`
|
||
4. `../functional/context_fidelity_and_regrounding.md`
|
||
5. `../functional/reflection_outputs.md`
|
||
6. `../functional/resurfacing_and_saturation.md`
|
||
|
||
### Integrationen
|
||
|
||
1. `integrations_technical.md`
|
||
2. fachlich: `../functional/integrations.md`
|
||
3. `../functional/reflection_outputs.md`
|
||
4. das betroffene Fachkapitel (Kairo, mindnet, Mitai, Shinkan)
|
||
|
||
### Admin / Diagnose
|
||
|
||
1. `admin_diagnostics.md`
|
||
2. `auth_identity_and_roles.md`
|
||
3. fachlich: `../functional/fachliche_zielarchitektur.md` §2.7
|
||
4. `../functional/reflection_spaces.md` (Admin-/Developer View)
|
||
|
||
### MVP-Journal-Slice / technische Umsetzung
|
||
|
||
Kanonisches Home **wie** der Slice gebaut ist: `mvp_implementation.md`. Fachliches Fit-Gap-Home bleibt `../functional/mvp_stand_und_abgleich.md`.
|
||
|
||
1. `mvp_implementation.md`
|
||
2. `provenance_verification.md`
|
||
3. `memory_storage_and_offline.md` §6.2
|
||
4. `backend_and_api.md` §5.1
|
||
5. `privacy_gateway.md` §9.1–9.2
|
||
6. `frontend_pwa_shell.md` §6.1
|
||
7. fachlich: `../functional/mvp.md`
|
||
8. `../functional/implementation_foundation.md`
|
||
9. `../functional/mvp_stand_und_abgleich.md`
|
||
10. bei Gegenlesung gegen das Gesamtziel: `../functional/produktvision_und_produktidentitaet.md`
|
||
11. bei Bedarf: `../functional/writing_profile_and_journaling.md`, `../functional/guardrails.md`
|
||
|
||
### Voice / PWA-Offline
|
||
|
||
1. `frontend_pwa_shell.md`
|
||
2. `voice_and_media.md`
|
||
3. `memory_storage_and_offline.md`
|
||
4. `privacy_gateway.md` (eigener Egress-Typ)
|
||
5. fachlich: `../functional/produktvision_und_produktidentitaet.md` §19.4–19.5
|
||
|
||
## 4. Ladeprinzip
|
||
|
||
> Root-Dokumente plus 2–4 betroffene Kapitel. Nicht den ganzen technischen und fachlichen Ordner gleichzeitig laden.
|
||
|
||
Vor Vereinfachungen die Invariantenliste in `technische_zielarchitektur.md` §3.6 prüfen.
|
||
|
||
## 5. Code-Gerüst
|
||
|
||
Lokaler Produktrahmen in `frontend/` und `backend/`. Zusammenhängende technische Umsetzung: `mvp_implementation.md`. Auth, Nutzerverwaltung, Prompt-DB, Platzhalter, Feature-Check, Privacy Gateway. **Dialog-Layer 0:** Conversations/Messages/`usage_sessions`, Thread-/Space-Identität, Derived-Hülle mit Provenance. **MVP-Journal-Slice:** nutzersichtbare Spaces, Journal Days, Dialogzug (ein Call), explizite Draft-Generierung, versionierte Entries (Übernehmen = neue Version, Dirty-Schutz im Editor), Inline-Medien, lokale Stichpunkte ohne Egress, Writing Profile (Hülle mit dynamischen Traits, Initial Profile Build). Fit-Gap: `../functional/mvp_stand_und_abgleich.md` (2026-08-25). Konfigurierbare Prompts `mvp.dialogue_turn`, `mvp.journal_reconstruct`, `mvp.journal_generate`, `mvp.entity_detect`, `mvp.profile_review`. Persönliche Folgestufen konsumieren ein lokal erzeugtes `VerifiedArtifact` (`provenance_verification.md`); der Journal-Adapter setzt die Policy. Provider-URL/Modell/Policy unter Admin → Schnittstellen; Keys nur in `backend/.env`. Schichten: Maskierung, Dialogzug, Journalentwurf, explizite Profile-Review. Admin-Testspur am Dialogzug (Egress, Antwort, Operation). Privacy-Pfad durchgängig, Security Layer nicht vollständig (`privacy_gateway.md` §9.2). Kein Stripe, keine Threads-UI, kein semantisches Retrieval. SQLite nur lokal.
|
||
|