111 lines
5.0 KiB
Markdown
111 lines
5.0 KiB
Markdown
---
|
||
title: "Kanshō – Dokumentationsindex und Context Bundles"
|
||
status: "Arbeitsstand"
|
||
date: "2026-08-18"
|
||
product_family: "Jinkendo"
|
||
document_role: "Documentation Index / Context Loading Guide"
|
||
parent_document: "fachliche_zielarchitektur.md"
|
||
---
|
||
|
||
# Kanshō – Dokumentationsindex und Context Bundles
|
||
|
||
Dieses Dokument dient dazu, für weitere Konzeptarbeit nur die tatsächlich benötigten Dateien in den aktiven Kontext zu laden.
|
||
|
||
## 1. Root-Dokumente
|
||
|
||
- `handover.md` – Session-Bootstrap für die **Konzept-/Interviewarbeit**; nicht der Code-Stand. Implementierungsstand und Fit-Gap: `mvp_stand_und_abgleich.md`.
|
||
- `fachliche_zielarchitektur.md` – Governance, Dokumentationsprinzipien, Querschnittsinvarianten, Dateistruktur.
|
||
- `produktvision_und_produktidentitaet.md` – Vision, Identität, Scope, Produktprinzipien und Nicht-Ziele.
|
||
- `interview_plan.md` – Kapitelplan, Interviewmethode, Fortschritt und nächster Interviewblock.
|
||
|
||
## 2. Fachkapitel
|
||
|
||
| Datei | Kanonisches Thema |
|
||
|---|---|
|
||
| `usage_situations.md` | Nutzungssituationen und aktuell ausgearbeitete Tagesreflexion |
|
||
| `reflection_spaces.md` | Reflection Contexts und Spaces |
|
||
| `dialogue_model.md` | Entry, Intent, Gesprächsführung, Dialogfäden |
|
||
| `memory_and_context.md` | Working/Thread/Episodic Memory, Context, mindnet im Dialog |
|
||
| `resurfacing_and_saturation.md` | Wiedervorlage, Relevanz, Saturation |
|
||
| `context_fidelity_and_regrounding.md` | Drift, Provenance, Re-Grounding |
|
||
| `self_model_and_lived_experience.md` | Self Model, Point-in-Time Self, digitaler Zwilling |
|
||
| `writing_profile_and_journaling.md` | persönlicher Schreibstil und Journalgenerierung |
|
||
| `reflection_intelligence.md` | Reflection Frontiers, Hypothesen, Kausalitätsvorsicht |
|
||
| `reflection_outputs.md` | Journal/Memory/Knowledge/Action Outputs |
|
||
| `integrations.md` | Jinkendo-Produktgrenzen und Integrationen |
|
||
| `guardrails.md` | Privacy Gateway, Pseudonymisierung, externe KI |
|
||
| `mvp.md` | Erster vertikaler Slice (dialoggeführtes Journal) |
|
||
| `implementation_foundation.md` | Verbindliche Leitplanke zwischen Zielmodell und Slice |
|
||
| `mvp_stand_und_abgleich.md` | **Kanonische Fit-Gap-Analyse** (2026-08-25): Code gegen Foundation, MVP-Slice und Gesamtziel; Gaps, Ungenauigkeiten, Prüfbrief für Gegenlesung |
|
||
|
||
## 3. Empfohlene Context Bundles
|
||
|
||
### Laufendes Interview zu Nutzungssituationen
|
||
|
||
1. `fachliche_zielarchitektur.md`
|
||
2. `produktvision_und_produktidentitaet.md`
|
||
3. `interview_plan.md`
|
||
4. `usage_situations.md`
|
||
5. bei Bedarf `dialogue_model.md` und `resurfacing_and_saturation.md`
|
||
|
||
### Memory / digitaler Zwilling
|
||
|
||
1. Root-Dokumente
|
||
2. `memory_and_context.md`
|
||
3. `self_model_and_lived_experience.md`
|
||
4. `context_fidelity_and_regrounding.md`
|
||
5. `guardrails.md`
|
||
|
||
### Dialogarchitektur
|
||
|
||
1. Root-Dokumente
|
||
2. `dialogue_model.md`
|
||
3. `usage_situations.md`
|
||
4. `reflection_spaces.md`
|
||
5. `resurfacing_and_saturation.md`
|
||
|
||
### Integrationen
|
||
|
||
1. Root-Dokumente
|
||
2. `integrations.md`
|
||
3. `reflection_outputs.md`
|
||
4. das jeweils betroffene Fachkapitel
|
||
|
||
### MVP-Journal-Slice / Fit-Gap
|
||
|
||
Kanonisches Home der Fit-Gap-Analyse ist `mvp_stand_und_abgleich.md`. Es ersetzt weder `mvp.md` noch die Foundation noch die Produktvision.
|
||
|
||
**Technische Umsetzung** (wie der Slice gebaut ist, nicht der fachliche Abgleich): `../technical/mvp_implementation.md`.
|
||
|
||
1. `mvp.md`
|
||
2. `implementation_foundation.md`
|
||
3. `mvp_stand_und_abgleich.md`
|
||
4. `writing_profile_and_journaling.md`
|
||
5. `guardrails.md`
|
||
6. bei Gegenlesung gegen das Gesamtziel zusätzlich `produktvision_und_produktidentitaet.md`
|
||
7. technisch: `../technical/mvp_implementation.md` und `../technical/documentation_index.md` Bundle „MVP-Journal-Slice / technische Umsetzung“
|
||
|
||
### Datenschutz / externe KI
|
||
|
||
1. `fachliche_zielarchitektur.md`
|
||
2. `guardrails.md`
|
||
3. `self_model_and_lived_experience.md`
|
||
4. `memory_and_context.md`
|
||
5. das konkret betroffene Technik- oder Integrationskapitel
|
||
|
||
## 4. Technische Architektur
|
||
|
||
Seit 2026-08-19 existiert eine vorläufige technische Rahmenarchitektur unter `../technical/`. Einstieg: `../technical/technische_zielarchitektur.md` und `../technical/documentation_index.md`.
|
||
|
||
Sie übernimmt den Produktrahmen **weitgehend von Mitai**. Datenschutz, Privacy Gateway und Guardrails sind fachlich bereits Invariante und technisch bindend. Dialog-, Memory- und MVP-Schnitte bleiben Arbeitsstand; Phasen F–I führen sie weiter. Encryption, Löschen und DSFA (Phase H1) sind Ausprägung, nicht Ersatz der Invariante.
|
||
|
||
Technische Umsetzung des gebauten Journal-Slices: `../technical/mvp_implementation.md`. Fit-Gap bleibt fachlich: `mvp_stand_und_abgleich.md`.
|
||
|
||
## 5. Ladeprinzip
|
||
|
||
> **Nicht alle Kanshō-Dokumente gleichzeitig laden.** Root-Dokumente plus die 2–4 fachlich betroffenen Dateien bilden den Standardkontext.
|
||
|
||
Code-Stand, Slice-Gaps und Abstand zum Gesamtziel nicht aus einzelnen technischen „Implementierungsstand“-Abschnitten rekonstruieren. Dafür `mvp_stand_und_abgleich.md` laden.
|
||
|
||
Vor größeren Querschnittsentscheidungen wird zusätzlich über `migration_mapping.md` und die relevanten Invarianten geprüft, ob andere Kapitel betroffen sind.
|