---
    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; Profile-Analyse-Export 2.5 |

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