Dateien nach "docs/architecture/functional" hochladen

docs/architecture/functional/memory_and_context.md

@@ -0,0 +1,140 @@
+---
+    title: "Kanshō – Memory und Context"
+    status: "Arbeitsstand"
+    date: "2026-08-18"
+    product_family: "Jinkendo"
+    document_role: "Fachkapitel / Memory Architecture / Context"
+    parent_document: "fachliche_zielarchitektur.md"
+    ---
+
+    # Kanshō – Memory und Context
+
+Dieses Dokument ist das kanonische Home für Working Context, Thread Memory, Episodic Memory, Knowledge-Graph-Bezug und die Rolle von mindnet im kurzfristigen Dialog.
+
+<!-- Migriert aus `produktvision_und_produktidentitaet.md`: Abschnitt 10 Gedächtnismodell – Einleitung. Inhalt fachlich unverkuerzt; nur Heading-Level fuer die neue Dateistruktur angepasst. -->
+
+## 10. Gedächtnismodell
+
+Ein zentrales Ergebnis der bisherigen Konzeption ist die Erkenntnis, dass ein einziges LLM-Kontextfenster nicht ausreicht.
+
+Kanshō benötigt mehrere Gedächtnisebenen.
+
+<!-- Migriert aus `produktvision_und_produktidentitaet.md`: Abschnitt 10.1 Working Context. Inhalt fachlich unverkuerzt; nur Heading-Level fuer die neue Dateistruktur angepasst. -->
+
+### 10.1 Working Context
+
+Enthält beispielsweise:
+
+- aktuelle Nachrichten,
+- aktuelle Frage,
+- unmittelbar vorausgehende Aussagen,
+- temporäre Gesprächsinformationen.
+
+Lebensdauer:
+
+- Minuten bis Stunden,
+- primär für den aktuellen Dialog.
+
+---
+
+<!-- Migriert aus `produktvision_und_produktidentitaet.md`: Abschnitt 10.2 Thread Memory. Inhalt fachlich unverkuerzt; nur Heading-Level fuer die neue Dateistruktur angepasst. -->
+
+### 10.2 Thread Memory
+
+Enthält:
+
+- Zusammenfassungen einzelner Dialogfäden,
+- offene Fragen,
+- Zwischenstände,
+- noch nicht abgeschlossene Reflexionen,
+- relevante Aussagen aus früheren Sitzungen.
+
+Lebensdauer:
+
+- Tage,
+- Wochen,
+- Monate,
+- ggf. länger.
+
+---
+
+<!-- Migriert aus `produktvision_und_produktidentitaet.md`: Abschnitt 10.3 Episodic Memory. Inhalt fachlich unverkuerzt; nur Heading-Level fuer die neue Dateistruktur angepasst. -->
+
+### 10.3 Episodic Memory
+
+Enthält bedeutsame Ereignisse oder Erfahrungen wie:
+
+- Urlaubserlebnisse,
+- Konflikte,
+- Entscheidungen,
+- besondere Erfahrungen,
+- persönliche Wendepunkte,
+- wichtige Erkenntnisse.
+
+Diese Informationen sind langfristig relevant und sollen in geeigneter Form in Obsidian beziehungsweise mindnet überführt werden.
+
+---
+
+<!-- Migriert aus `produktvision_und_produktidentitaet.md`: Abschnitt 10.6 Knowledge Graph / mindnet. Inhalt fachlich unverkuerzt; nur Heading-Level fuer die neue Dateistruktur angepasst. -->
+
+### 10.6 Knowledge Graph / mindnet
+
+mindnet übernimmt die langfristige Vernetzung von Informationen.
+
+Dazu gehören:
+
+- Erfahrungen,
+- Erkenntnisse,
+- Beziehungen,
+- Referenzen,
+- Werte,
+- Entscheidungen,
+- wiederkehrende Themen,
+- offene Zusammenhänge.
+
+Kanshō soll dieses Wissen gezielt abrufen und neue Erkenntnisse wieder zurückführen.
+
+---
+
+<!-- Migriert aus `produktvision_und_produktidentitaet.md`: Abschnitt 11 Rolle von mindnet im kurzfristigen Dialog. Inhalt fachlich unverkuerzt; nur Heading-Level fuer die neue Dateistruktur angepasst. -->
+
+## 11. Rolle von mindnet im kurzfristigen Dialog
+
+Noch nicht abschließend entschieden ist, ob mindnet als kurzfristiger Dialogspeicher geeignet ist.
+
+Der derzeitige konzeptionelle Stand lautet:
+
+**mindnet sollte wahrscheinlich nicht der primäre Working-Memory-Speicher laufender Gespräche sein.**
+
+Gründe dafür sind insbesondere die unterschiedlichen Anforderungen:
+
+Ein Dialogspeicher benötigt unter anderem:
+
+- exakte Reihenfolge,
+- hohe Änderungsfrequenz,
+- Thread-Zustände,
+- lokale/offline Synchronisation,
+- schnelle Wiederaufnahme,
+- Branching,
+- Editierbarkeit,
+- Zustandsmanagement.
+
+mindnet ist dagegen besonders geeignet für:
+
+- langfristiges Wissen,
+- semantische Retrieval-Prozesse,
+- Beziehungen,
+- Episoden,
+- Erkenntnisse,
+- autobiografischen Kontext.
+
+Die derzeit bevorzugte Verantwortungsverteilung lautet deshalb:
+
+> **Kanshō besitzt den Dialog.**  
+> **mindnet besitzt das langfristige Gedächtnis.**  
+> **Obsidian bildet das menschenlesbare autobiografische Archiv.**
+
+Diese Entscheidung ist noch technisch zu validieren.
+
+---
+

docs/architecture/functional/migration_mapping.md

@@ -0,0 +1,75 @@
+---
+    title: "Kanshō – Migrationsmapping und Drift-Audit"
+    status: "Arbeitsstand"
+    date: "2026-08-18"
+    product_family: "Jinkendo"
+    document_role: "Migration Map / Documentation Integrity Audit"
+    parent_document: "fachliche_zielarchitektur.md"
+    ---
+
+    # Kanshō – Migrationsmapping und Drift-Audit
+
+## 1. Zweck
+
+Dieses Dokument protokolliert die verlustfreie Aufteilung des Dokumentationsstands vom 18.08.2026. Die vier Ausgangsdateien wurden vor jeder Transformation unverändert unter `checkpoint_originals/` gesichert.
+
+## 2. Checkpoint-Integrität
+
+| Datei | Bytes | SHA-256 |
+|---|---:|---|
+| `fachliche_zielarchitektur.md` | 51488 | `711317032724e46ac545d213b6e246f962662a547731ec7949dc61d146d59fb6` |
+| `produktvision_und_produktidentitaet.md` | 63647 | `f46358a730ac46eb817cb61a3afa7d0dfb83f4cfffd04484332939826300d216` |
+| `usage_situations.md` | 24883 | `92007021fdd6feccdf2db3bf534f2c3909f971d2a6036e43d03cc2ac90154d34` |
+| `guardrails.md` | 22198 | `8f4732f0ab309c551740c0135ca9cc92a8032323e5becf81adb1845d8e292dde` |
+
+## 3. Fachliches Mapping
+
+| Alter Abschnitt | Kanonisches Home nach Migration | Behandlung |
+|---|---|---|
+| fachliche_zielarchitektur.md §1, §2.1–2.8.1, §2.10 | `fachliche_zielarchitektur.md` | unverkuerzt beibehalten |
+| fachliche_zielarchitektur.md §2.9 | `context_fidelity_and_regrounding.md` | vollständig migriert |
+| fachliche_zielarchitektur.md §2.11 | `resurfacing_and_saturation.md` | vollständig migriert |
+| fachliche_zielarchitektur.md §2.12 | `self_model_and_lived_experience.md` | vollständig migriert |
+| fachliche_zielarchitektur.md §2.13 | `guardrails.md` | vollständig migriert |
+| fachliche_zielarchitektur.md §3 alte Repository-Struktur | `migration_mapping.md + neue §3 in fachliche_zielarchitektur.md` | explizit durch neue kanonische Struktur ersetzt; Original im Checkpoint |
+| fachliche_zielarchitektur.md §4–9 | `interview_plan.md` | vollständig migriert |
+| produktvision_und_produktidentitaet.md §1, §3–5, §18–19, §21–25 | `produktvision_und_produktidentitaet.md` | unverkuerzt beibehalten |
+| produktvision_und_produktidentitaet.md §2 | `integrations.md` | vollständig migriert |
+| produktvision_und_produktidentitaet.md §6, §8 Intro/8.1–8.3/8.5, §9 | `dialogue_model.md` | vollständig migriert |
+| produktvision_und_produktidentitaet.md §7, §8.4/8.6/8.7 | `reflection_spaces.md` | vollständig migriert |
+| produktvision_und_produktidentitaet.md §8.8 | `context_fidelity_and_regrounding.md` | vollständig migriert |
+| produktvision_und_produktidentitaet.md §8.9 | `usage_situations.md` | vollständig migriert |
+| produktvision_und_produktidentitaet.md §10 Intro/10.1–10.3/10.6, §11 | `memory_and_context.md` | vollständig migriert |
+| produktvision_und_produktidentitaet.md §10.4, §14, §17.1 Lived Experience | `self_model_and_lived_experience.md` | vollständig migriert |
+| produktvision_und_produktidentitaet.md §10.5, §15–16 | `writing_profile_and_journaling.md` | vollständig migriert |
+| produktvision_und_produktidentitaet.md §12–13 | `reflection_intelligence.md` | vollständig migriert |
+| produktvision_und_produktidentitaet.md §17 Journal/Memory/Knowledge/Action | `reflection_outputs.md` | vollständig migriert |
+| produktvision_und_produktidentitaet.md Guardrails-Zusammenfassung | `guardrails.md` | vollständig migriert |
+| produktvision_und_produktidentitaet.md §20 | `integrations.md` | vollständig migriert |
+| usage_situations.md §1–7 ohne §7.2 sowie §8 | `usage_situations.md` | beibehalten |
+| usage_situations.md §7.2 | `resurfacing_and_saturation.md` | vollständig migriert; Querverweis verbleibt |
+| guardrails.md §1–23 | `guardrails.md` | unverändert beibehalten |
+
+## 4. Migrationsregeln
+
+- Fachtexte wurden in die neuen Fachdateien **inhaltlich unverkuerzt** übernommen.
+- Bei migrierten Textblöcken wurden nur Markdown-Heading-Level angepasst, damit die Ursprungspassagen unter dem neuen Dokumenttitel sauber eingebettet sind.
+- Neue Einleitungen und Querverweise sind als neue Navigationsschicht hinzugekommen und ersetzen keine fachlichen Ursprungsaussagen.
+- Die vorherige Repository-Struktur wurde als einzige bewusst veraltete Struktur nicht als aktive Struktur fortgeführt; sie bleibt vollständig im unveränderten Checkpoint erhalten.
+- Root-Dokumente wurden erst nach Zuordnung aller fachlich relevanten Bereiche neu aufgebaut.
+- Der Interviewstatus wurde nach der Migration explizit auf den aktuellen Gesprächsstand „Tagesreflexion – Abschluss und Outputs“ aktualisiert; der vorherige Status bleibt im unveränderten Checkpoint erhalten.
+
+## 5. Drift-Audit nach Aufteilung
+
+- [x] Alle vier Ausgangsdateien unverändert gesichert.
+- [x] Produktvision: alle bisherigen Top-Level-Themen einem kanonischen Home zugeordnet.
+- [x] Zielarchitektur: Detailinvarianten in Fachkapitel migriert; Governance beibehalten.
+- [x] Usage Situations: Resurfacing/Saturation ausgelagert, Nutzungsspezifik beibehalten.
+- [x] Guardrails: vollständig beibehalten und um die bisherigen Root-Verweise ergänzt.
+- [x] Root Causes zu Re-Grounding, Lived Experience und Privacy bleiben erhalten.
+- [x] Statuslogik entschieden / bevorzugte Richtung / offen bleibt in den migrierten Ursprungspassagen erhalten.
+- [x] Keine fachliche Passage wurde wegen der Aufteilung absichtlich zusammengefasst oder entfernt.
+
+## 6. Künftige Regel
+
+Bei jeder fachlichen Änderung wird nur das kanonische Home geändert. Root-Dokumente erhalten nur dann eine Ergänzung, wenn eine neue produktweite Invariante, ein Scope-Wechsel oder eine Änderung der Dokumentationsarchitektur entsteht.

docs/architecture/functional/produktvision_und_produktidentitaet.md

@@ -0,0 +1,514 @@
+---
+title: "Kanshō – Produktvision, Produktidentität und konzeptionelle Leitplanken"
+version: "0.1"
+status: "Arbeitsstand"
+date: "2026-08-18"
+product_family: "Jinkendo"
+document_role: "Product Vision / Product Identity / Scope Baseline"
+---
+# Kanshō – Produktvision, Produktidentität und konzeptionelle Leitplanken
+
+## 1. Zweck dieses Dokuments
+
+Dieses Dokument hält den aktuellen Stand der Produktvision für die neue Achtsamkeits- und Reflexionsanwendung innerhalb der Jinkendo-Produktfamilie fest.
+
+Es ist fachlich der in `fachliche_zielarchitektur.md` definierten Zielstruktur untergeordnet und bildet dort den Bereich Produktvision / Produktidentität aus.
+
+Es ist bewusst **keine Kurzfassung** und kein verdichtetes Management-Summary. Ziel ist, die bisher formulierten Gedanken, getroffenen Entscheidungen, Abgrenzungen und offenen Punkte möglichst vollständig und nachvollziehbar zu dokumentieren.
+
+Das Dokument dient als stabile Baseline für die weitere Konzeption. Spätere Änderungen sollen nicht dadurch erfolgen, dass bestehende Inhalte stillschweigend gekürzt oder entfernt werden, sondern durch:
+
+- Ergänzung neuer Erkenntnisse,
+- explizite Änderung bestehender Entscheidungen,
+- Kennzeichnung überholter Annahmen,
+- Versionierung in Gitea,
+- bei grundlegenden Richtungswechseln durch einen nachvollziehbaren Decision Record.
+
+---
+# 2. Ausgangslage und Produktfamilie
+
+Die vollständige Beschreibung der bestehenden Jinkendo-Komponenten, ihrer Rollen und der Integrationsgrenzen wird ab jetzt kanonisch in `integrations.md` gepflegt. Kanshō entsteht weiterhin als Bestandteil dieses Ökosystems und nicht als isoliertes Einzelprodukt.
+
+# 3. Arbeitstitel und Produktname
+
+Als derzeitiger Arbeitsname wurde vorgeschlagen:
+
+# **Kanshō**
+
+Der Name soll zunächst als Arbeitstitel verwendet werden.
+
+Eine endgültige Entscheidung über Produktname, Schreibweise, Markenfähigkeit, Domain, App-Store-Verfügbarkeit und mögliche Überschneidungen mit bestehenden Angeboten ist noch offen.
+
+---
+# 4. Produktvision
+
+Kanshō soll ein **persönlicher KI-gestützter Reflexionsbegleiter** innerhalb der Jinkendo-Produktfamilie werden.
+
+Im Vergleich zu den bereits bestehenden Jinkendo-Anwendungen soll Kanshō bewusst **stärker KI-kollaborativ** arbeiten. Die KI ist hier nicht nur unterstützende Funktion, sondern ein zentraler Dialog- und Reflexionspartner, der Kontext aufnimmt, frühere Denkwege kennt, Fragen entwickelt, Zusammenhänge vorsichtig anbietet und den Nutzer über längere Zeit begleitet.
+
+Die App soll Menschen nicht primär dabei unterstützen, Aufgaben zu planen, Daten zu tracken oder Inhalte nur abzulegen.
+
+Ihr Schwerpunkt liegt auf:
+
+> **Wahrnehmen → Reflektieren → Verstehen → Einordnen**
+
+Die App soll einen kontinuierlichen, vertrauenswürdigen Dialog über Erlebnisse, Gedanken, Gefühle, Entscheidungen, Entwicklungen und Lebensfragen ermöglichen.
+
+Dabei soll die KI nicht nur auf einzelne Eingaben reagieren, sondern:
+
+- den jeweiligen Lebenskontext verstehen,
+- den bisherigen Dialog kennen,
+- relevante frühere Erfahrungen berücksichtigen,
+- das persönliche Wertemodell und Leitbild einbeziehen,
+- offene Themen und frühere Reflexionsfäden wiedererkennen,
+- Zusammenhänge vorsichtig sichtbar machen,
+- passende Fragen stellen,
+- langfristige Entwicklung unterstützen.
+
+Kanshō soll damit deutlich mehr sein als:
+
+- ein digitales Tagebuch,
+- ein Chatbot,
+- eine Meditations-App,
+- ein Mood Tracker,
+- ein persönlicher Assistent.
+
+Der zentrale Produktgedanke ist:
+
+> **Kanshō ist der dialogische Reflexionsraum der Jinkendo-Familie.**
+
+---
+# 5. Produktidentität
+
+## 5.1 Gewählte Grundausrichtung
+
+Von drei möglichen Grundidentitäten wurde folgende Ausrichtung bevorzugt:
+
+### Personal Reflection Companion
+
+Kanshō wird primär als **langfristiger persönlicher Reflexionsbegleiter** verstanden.
+
+Tagebuch, Meditation und Achtsamkeit sind wichtige Funktionen, aber nicht die eigentliche Produktidentität.
+
+Damit gilt:
+
+**Nicht:** Tagebuch mit KI-Funktion.
+
+**Nicht:** Meditations-App mit Journaling.
+
+**Nicht:** Chatbot mit persönlichem Gedächtnis.
+
+**Sondern:** Ein langfristiger, dialogischer Reflexionsbegleiter, der Journaling, Achtsamkeit und Meditation als Werkzeuge verwendet.
+
+---
+
+## 5.2 Rolle innerhalb der Produktfamilie
+
+Die vereinfachte Verantwortungsverteilung lautet:
+
+- **Mitai:** Was passiert körperlich?
+- **Shinkan:** Was wird trainiert und entwickelt?
+- **Kairo:** Was soll geschehen und wie wird es operationalisiert?
+- **mindnet:** Was weiß und erinnert das persönliche Wissensnetz?
+- **Kanshō:** Was bedeutet das Erlebte für die Person?
+
+Diese Zuordnung ist eine zentrale Produktgrenze.
+
+---
+# 6–17. Fachliche Vertiefungen
+
+Die bisher in diesem Dokument enthaltenen Detailkonzepte wurden verlustfrei in kanonische Fachkapitel ausgelagert:
+
+- Kerninteraktion, Entry-Modell, Reflection Intent und Dialogfäden → `dialogue_model.md`
+- Reflexionskontexte und Reflection Spaces → `reflection_spaces.md`
+- Nutzungstypologie → `usage_situations.md`
+- Working/Thread/Episodic Memory und Context-Nutzung → `memory_and_context.md`
+- Thread Resurfacing und Reflection Saturation → `resurfacing_and_saturation.md`
+- Context Drift und Re-Grounding → `context_fidelity_and_regrounding.md`
+- Self Model, Wesenskern, Point-in-Time Self und Lived Experience → `self_model_and_lived_experience.md`
+- Writing Profile und Tagebuchgenerierung → `writing_profile_and_journaling.md`
+- Reflection Frontiers, Hypothesen und Kausalitätsvorsicht → `reflection_intelligence.md`
+- Ergebnisse eines Reflexionsdialogs → `reflection_outputs.md`
+- Jinkendo-Integrationen → `integrations.md`
+- Privacy Gateway und externe KI → `guardrails.md`
+
+Die unveränderte frühere Fassung bleibt unter `checkpoint_originals/produktvision_und_produktidentitaet.md` erhalten.
+
+# 18. Geplanter Funktionsumfang
+
+Der bisher genannte Funktionsumfang umfasst mindestens folgende Bereiche.
+
+## 18.1 Tägliche Reflexion
+
+- geführter Tagesrückblick,
+- kontextbezogene Einstiegsfrage,
+- Dialog statt starrem Formular,
+- Erkennen offener Themen,
+- **Generierung eines Tagebucheintrags aus der täglichen Reflexion als vorgesehene Kernfunktion**,
+- Überführung relevanter Erkenntnisse in mindnet.
+
+Noch offen ist, ob der Tagebucheintrag standardmäßig automatisch erzeugt, aktiv angefordert oder vor der Ablage ausdrücklich bestätigt werden soll. Diese offene Ausprägungsfrage ändert nichts an der ursprünglichen Anforderung, dass aus der täglichen Reflexion ein persönlicher Tagebucheintrag generiert werden können muss.
+
+---
+
+## 18.2 Tagebuch
+
+Als expliziter Referenzrahmen wurde vom Nutzer **Day One im „Gold“-Abo** genannt. Kanshō soll die für den Anwendungsfall relevanten hochwertigen Tagebuchfunktionen auf vergleichbarem Niveau abdecken, ohne dadurch zu einem reinen Day-One-Klon zu werden.
+
+Welche konkreten Funktionen des genannten Referenzprodukts übernommen, anders gelöst oder bewusst nicht benötigt werden, wird in einem eigenen Benchmark- und Journaling-Kapitel geprüft. Die aktuelle Produktbezeichnung und der konkrete Leistungsumfang des Referenzangebots sind dabei zum Zeitpunkt des Benchmarks nochmals zu verifizieren.
+
+Der genaue Funktionsumfang wird später spezifiziert.
+
+Erwartbare Bereiche sind unter anderem:
+
+- Tagebucheinträge,
+- Text,
+- Spracheingabe,
+- Medien,
+- Zeitbezug,
+- Suche,
+- Rückblick,
+- Kontext,
+- Verknüpfungen,
+- langfristige Historie.
+
+Wichtig:
+
+Das Tagebuch bleibt Teil der Reflexionsarchitektur und wird nicht zur alleinigen Produktidentität.
+
+---
+
+## 18.3 Geführte Meditation
+
+Kanshō soll geführte Meditation unterstützen.
+
+Noch offen ist, welche Formen darunter fallen:
+
+- klassische vorgefertigte Meditation,
+- KI-generierte Meditation,
+- personalisierte Meditation aus aktuellem Kontext,
+- Follow-up-Reflexion nach Meditation,
+- Atem- und Achtsamkeitsübungen,
+- kurze situative Interventionen.
+
+Dieser Funktionsbereich wird separat konzipiert.
+
+---
+
+## 18.4 Achtsamkeit
+
+Achtsamkeit soll nicht nur als Entspannungsfunktion verstanden werden.
+
+Mögliche Ausprägungen:
+
+- bewusste Wahrnehmung,
+- kurze Check-ins,
+- emotionale und körperliche Selbstwahrnehmung,
+- situative Reflexion,
+- nicht wertendes Beobachten,
+- Unterbrechung automatischer Reaktionsmuster.
+
+Eine genaue Definition des Achtsamkeitsverständnisses von Kanshō steht noch aus.
+
+---
+
+## 18.5 Langfristiger Reflexionsdialog
+
+Kanshō soll Reflexionen über längere Zeiträume fortsetzen können.
+
+Dazu gehören:
+
+- Wiederaufnahme alter Fäden,
+- Erkennen wiederkehrender Themen,
+- zeitliche Entwicklung,
+- Vergleich früherer und heutiger Perspektiven,
+- Reflexion über Monate und Jahre.
+
+---
+# 19. Technische Grundanforderungen
+
+Bereits festgehalten wurden folgende technische Anforderungen.
+
+## 19.1 PWA
+
+Kanshō wird als Progressive Web App umgesetzt.
+
+---
+
+## 19.2 Mobile First
+
+Die primäre Nutzung wird auf dem Smartphone erwartet.
+
+Daraus folgt:
+
+- mobile-first UX,
+- schnelle Öffnung,
+- geringe Einstiegshürde,
+- gute Spracheingabe,
+- kurze situative Interaktionen,
+- gleichzeitig Unterstützung längerer Reflexionsgespräche.
+
+---
+
+## 19.3 Responsive Desktop-Nutzung
+
+Trotz Mobile-First-Ansatz muss eine vollwertige Desktop-Nutzung möglich sein.
+
+Desktop kann insbesondere für folgende Situationen wichtig werden:
+
+- längere Texte,
+- Rückblicke,
+- tiefe Reflexionen,
+- Suche,
+- Lesen älterer Einträge,
+- strukturierte Auswertung.
+
+---
+
+## 19.4 Offline-Fähigkeit
+
+Die App soll offline nutzbar sein.
+
+Noch zu entscheiden ist:
+
+- welche Funktionen vollständig offline laufen,
+- welche KI-Funktionen online benötigen,
+- wie Dialoge lokal zwischengespeichert werden,
+- wie Synchronisation und Konflikte behandelt werden,
+- ob lokale Modelle für ausgewählte Funktionen genutzt werden.
+
+---
+
+## 19.5 Transkription
+
+Spracheingabe und Transkription sind zentrale technische Funktionen.
+
+Insbesondere auf dem Smartphone soll Reflexion nicht zwingend Tippen erfordern.
+
+Noch offen:
+
+- Live-Transkription oder nachträgliche Transkription,
+- lokal oder serverseitig,
+- Bearbeitung vor Speicherung,
+- Sprecher-/Pausenlogik,
+- Umgang mit langen Audioaufnahmen.
+
+---
+
+## 19.6 Integration in die Jinkendo-Familie
+
+Kanshō soll mit den bestehenden Anwendungen verbunden werden.
+
+Mindestens relevant sind:
+
+- Kairo,
+- mindnet,
+- Obsidian,
+- Shinkan,
+- Mitai.
+
+Die Integrationen sollen nicht nur technische Datenverbindungen sein, sondern der jeweiligen Produktverantwortung folgen.
+
+---
+# 21. Produktprinzipien
+
+Aus dem bisherigen Dialog lassen sich folgende Leitprinzipien ableiten.
+
+## 21.1 Dialog vor Formular
+
+Reflexion soll als Gespräch stattfinden und nicht primär als Checkliste.
+
+## 21.2 Kontext vor generischer Frage
+
+Fragen entstehen aus dem persönlichen und situativen Kontext.
+
+## 21.3 Erinnerung mit Herkunft
+
+Langfristige Aussagen müssen nachvollziehbar sein.
+
+## 21.4 Hypothese statt künstlicher Gewissheit
+
+Die KI darf Zusammenhänge anbieten, aber nicht erfinden.
+
+## 21.5 Mensch entscheidet über Identität
+
+Grundlegende Aussagen über Werte, Persönlichkeit und Wesenskern werden nicht stillschweigend festgeschrieben.
+
+## 21.6 Persönliche Sprache statt KI-Stil
+
+Generierte Texte sollen die Ausdrucksweise der Person erhalten.
+
+## 21.7 Reflection before Action
+
+Erst verstehen, dann gegebenenfalls handeln.
+
+## 21.8 Keine Funktionsduplikation
+
+Andere Jinkendo-Produkte behalten ihre jeweiligen Verantwortlichkeiten.
+
+## 21.9 Menschenlesbares Langzeitarchiv
+
+Wichtige Inhalte sollen nicht ausschließlich in proprietären internen Datenstrukturen existieren.
+
+## 21.10 Langfristige Kontinuität
+
+Das System soll über Monate und Jahre eine nachvollziehbare persönliche Entwicklung unterstützen.
+
+## 21.11 Einfachheit an der Oberfläche, Intelligenz im Kern
+
+Ein zentrales Architektur- und Produktprinzip lautet:
+
+> **Kanshō soll für den Nutzer einfach wirken, ohne deshalb intern einfach sein zu müssen.**
+
+Die fachliche und technische Modellierung darf nicht allein mit dem Ziel reduziert werden, möglichst wenige interne Objekte, Zustände oder Beziehungen zu besitzen.
+
+Vereinfachung ist nur dann sinnvoll, wenn dadurch keine wesentlichen Fähigkeiten verloren gehen.
+
+Insbesondere muss die interne Architektur ausreichend differenziert bleiben, um langfristig folgende Anforderungen erfüllen zu können:
+
+- mehrere parallele und sich entwickelnde Dialogfäden,
+- langfristige Erinnerung über Monate und Jahre,
+- kontextabhängige Wiederaufnahme früherer Themen,
+- Reflection Spaces mit überlappenden Lebensbereichen und Rollen,
+- dynamische Bildung und Konsolidierung von Strukturen,
+- zeitliche Entwicklung von Erkenntnissen und Selbstbeschreibungen,
+- Unterscheidung zwischen Beobachtung, Interpretation, Hypothese und bestätigter Erkenntnis,
+- nachvollziehbare Provenance und Confidence,
+- ein versionierbares Self Model,
+- ein langfristig lernendes Writing Profile,
+- Reflection Frontiers und noch ungeklärte Zusammenhänge,
+- Integration von mindnet, Obsidian, Kairo, Mitai und Shinkan,
+- kontextabhängige Auswahl relevanter Informationen,
+- rollenbasierte Diagnose- und Transparenzansichten,
+- spätere Erweiterbarkeit ohne grundlegenden Umbau des Kernmodells.
+
+Die normale Benutzeroberfläche soll diese interne Differenzierung weitgehend abstrahieren.
+
+Damit gilt:
+
+**Komplexität darf unter der Motorhaube existieren, wenn sie fachlich notwendig ist.  
+Komplexität soll aber nicht ungefiltert an den Nutzer weitergereicht werden.**
+
+Eine interne Vereinfachung darf daher niemals ausschließlich mit dem Argument erfolgen, dass das zugrunde liegende Modell dadurch leichter implementierbar wird.
+
+Vor jeder wesentlichen Modellvereinfachung soll geprüft werden:
+
+1. Welche heutigen Fähigkeiten hängen von der betreffenden Struktur ab?
+2. Welche bereits vorgesehenen späteren Fähigkeiten würden dadurch erschwert oder unmöglich?
+3. Kann dieselbe Nutzervereinfachung auch durch UX, Automatisierung oder KI-gestützte Strukturierung erreicht werden?
+4. Ist die Entscheidung später ohne grundlegende Migration oder Redesign reversibel?
+
+---
+# 22. Bewusste Nicht-Ziele
+
+Kanshō soll derzeit ausdrücklich nicht zu folgenden Produkten werden:
+
+- Projektmanagementsystem,
+- Aufgabenmanager,
+- Gesundheits- oder Fitness-Tracker,
+- Trainingsplanungsanwendung,
+- reines digitales Tagebuch,
+- ausschließlich Meditations-App,
+- generischer KI-Chat,
+- automatischer psychologischer Diagnostiker,
+- System, das ungesicherte Persönlichkeitsprofile erzeugt.
+
+---
+# 23. Noch offene Kernfragen
+
+Die folgenden Punkte sind bewusst noch nicht entschieden.
+
+1. Fachliche Struktur und Lebenszyklus der Reflection Spaces.
+2. Verhältnis von stabilen Lebenskontexten, dynamischen Reflexionsräumen und aktuellen Intents.
+3. Regeln für Entstehung, Sichtbarkeit, Konsolidierung und Wiederaufnahme von Dialogfäden.
+4. Konkrete Stufen, Regeln und Nutzerkontrollen des bereits beschlossenen konfigurierbaren Autonomiegrads der KI bei Strukturierung und Konsolidierung.
+5. Technisches Working-Memory-Modell.
+6. Datenbank für laufende Dialoge.
+7. Synchronisation und Offline-Architektur.
+8. Umfang und Rolle lokaler KI.
+9. genaue Integration mit Obsidian.
+10. Schema für Reflection Memories.
+11. Schema für Knowledge Deltas.
+12. Versionierung des Self Models.
+13. Mechanismus zur Nutzerbestätigung persönlicher Hypothesen.
+14. Aufbau und Training des Writing Profiles.
+15. Umgang mit widersprüchlichen Erinnerungen.
+16. zeitliche Gewichtung alter Informationen.
+17. Vergessen, Löschen und Datenschutz.
+18. genaue Journaling-Funktionen.
+19. Meditationskonzept.
+20. Achtsamkeitskonzept.
+21. Mobile UX.
+22. Spracheingabe und Transkription.
+23. Rolle anderer Jinkendo-Anwendungen im Context Builder.
+24. Agenten- und Prompt-Architektur.
+25. technische API- und Event-Integration.
+26. Sicherheits- und Krisengrenzen.
+27. Produktname und Branding.
+28. Ausprägung der Admin-/Developer-Diagnoseansicht und konkretes Rollen-/Berechtigungsmodell.
+---
+# 24. Aktueller Entscheidungsstand
+
+| Thema | Entscheidung / Arbeitsstand | Status |
+|---|---|---|
+| Produktidentität | Personal Reflection Companion | entschieden |
+| Kerninteraktion | geführter KI-Reflexionsdialog | entschieden |
+| Tagebuch | wichtiges Werkzeug, aber nicht Produktkern | entschieden |
+| Meditation | wichtiger Funktionsbereich | grundsätzlich vorgesehen |
+| Achtsamkeit | wichtiger Funktionsbereich | grundsätzlich vorgesehen |
+| Mobile | Mobile First | entschieden |
+| Desktop | responsive PWA | entschieden |
+| Offline | erforderlich | entschieden, Ausprägung offen |
+| Transkription | erforderlich | entschieden, Ausprägung offen |
+| mindnet | langfristiges Gedächtnis / Retrieval | bevorzugte Richtung |
+| Obsidian | menschenlesbares Langzeitarchiv | bevorzugte Richtung |
+| kurzfristiger Dialogspeicher | wahrscheinlich nicht mindnet | Hypothese / zu validieren |
+| Dialogfäden | mehrere Threads innerhalb eines Gesprächs möglich | entschieden |
+| Thread-Trennung | KI darf Trennung vorschlagen | entschieden |
+| Self Model | versioniert und bestätigungsorientiert | entschieden |
+| Kausalität | Beobachtung, Hypothese und bestätigte Erkenntnis trennen | entschieden |
+| Writing Profile | eigener langfristiger Bestandteil | entschieden |
+| Tagebuchgenerierung | Inhalt/Bedeutung und Stil getrennt erzeugen | bevorzugte Richtung |
+| Action Candidates | Übergabe an Kairo | entschieden |
+| Adaptiver Einstieg | Contextual Continuation als Default, freie Reflexion und Navigation jederzeit möglich | entschieden |
+| Hauptvorschlag | ein priorisierter Vorschlag plus wenige diskrete Alternativen | entschieden |
+| Reflection Intent | eigene Dimension neben Reflection Space | entschieden |
+| Primäre Startlogik | Kontinuität des Dialogs statt Funktions-Dashboard | entschieden |
+| Strukturierungsautonomie | KI erkennt, schlägt vor und kann abhängig von Konfiguration selbständig strukturieren/konsolidieren | entschieden |
+| Strukturpflege | Nutzer soll nicht zum Verwalter von Threads/Spaces werden | entschieden |
+| Fachlich vs. technisch | grundsätzlich getrennte Konzeptstränge; technische Vorentscheidungen nur bei wesentlichen Architekturzwängen | entschieden |
+| Sichtbarkeit interner Struktur | normale Nutzer sehen nur relevante, kuratierte Strukturen | entschieden |
+| Admin-/Developer View | interne KI-Strukturen müssen für Test, Entwicklung und Administration inspizierbar sein | entschieden |
+| Zugriff Diagnoseansicht | nur für berechtigte Rollen, z. B. Hauptadmin / Entwickler | entschieden, Rollenmodell später zu spezifizieren |
+| Architekturprinzip | einfache UX bei maximal sinnvoller interner Intelligenz und Differenzierung | entschieden |
+| Vereinfachung | interne Modelle dürfen nicht so weit reduziert werden, dass bestehende oder geplante Kernfähigkeiten verloren gehen | entschieden |
+| Reflection Space | kein Ablageort, sondern lebendiger Denk- und Erfahrungsraum | entschieden |
+| Reflection-Space-Zustand | laufend aktualisierte, quellengebundene Sicht auf den aktuellen Stand | entschieden |
+| Kernnutzen eines Space | Orientierung, Fortsetzung, offene Fragen, Historie und Entwicklung | entschieden |
+| Context Drift | Kanshō muss mögliche Drift verdichteter Langzeitkontexte erkennen können | entschieden |
+| Re-Grounding | bei Bedarf Rekonstruktion aus Ursprungsquellen statt erneuter Interpretation bestehender Summaries | entschieden |
+| Nutzer-Trigger | Nutzer kann erneuten Quellenabgleich ausdrücklich anfordern | entschieden |
+| Drift-Metrik | fachlich erforderlich, konkrete Berechnung und Bezeichnung später technisch zu spezifizieren | bevorzugte Richtung |
+| KI-Kollaboration | Kanshō ist bewusst stärker KI-kollaborativ als die bisherigen Jinkendo-Komponenten | entschieden |
+| Tägliche Reflexion | Generierung eines persönlichen Tagebucheintrags muss möglich sein; konkrete Automatik/Bestätigung noch offen | entschieden |
+| Journaling-Referenz | Day One im vom Nutzer genannten „Gold“-Abo dient als expliziter Benchmark-Rahmen; konkrete Funktionen später zu verifizieren | entschieden als Referenz |
+| Space-Dauer | Reflection Spaces können kurz-/mittelfristig oder langfristig relevant sein; Bedeutung statt Dauer ist ausschlaggebend | entschieden |
+| Space-Standardansicht | Aktueller Stand, offene Punkte, Weiterdenken und bisheriger Weg als vorläufige sichtbare Baseline | bevorzugte Richtung / später konkretisierbar |
+| Nutzer-Provenance | verdichtete Aussagen sollen für den Nutzer auf zugrunde liegende Inhalte aufklappbar sein | entschieden |
+| Nutzungstypologie | elf grundlegende Nutzungssituationen als vorläufig vollständige fachliche Baseline | entschieden / später erweiterbar |
+| Rückblicksdifferenzierung | Nachschlagen, Revue passieren und Entwicklungsrückblick sind fachlich unterschiedliche Intents | entschieden |
+| Externe Reflexionstrigger | andere Jinkendo-Komponenten dürfen Reflexionsanlässe anbieten; Kairo plant, Kanshō reflektiert | entschieden |
+| Lived Experience Layer | persistente Dialoge bilden zeitgebundene geäußerte Gedanken, Gefühle, Zweifel und Denkwege als ergänzende Ebene des digitalen Zwillings ab | entschieden |
+| Primärquelle | Originaldialog / verlässliche Originalrepräsentation bleibt erhalten; Summaries und Modelle sind abgeleitete Schichten | entschieden |
+| Point-in-Time Self | frühere innere Perspektiven bleiben zeitgebunden rekonstruierbar und werden nicht durch heutige Sichtweisen überschrieben | entschieden |
+| Innerer Zustand | Kanshō speichert geäußerte Innenperspektive, nicht behauptete objektive psychologische Wahrheit | entschieden |
+| Produktname Kanshō | Arbeitstitel | offen |
+
+---
+# 25. Arbeitsdefinition
+
+Die derzeitige Arbeitsdefinition lautet:
+
+> **Kanshō ist der persönliche KI-Reflexionsbegleiter innerhalb der Jinkendo-Plattform. Er hilft einem Menschen, Erlebnisse, Gedanken, Gefühle und Wahrnehmungen bewusst zu erfassen, in einem kontinuierlichen und kontextbezogenen Dialog zu reflektieren, mit seinem langfristigen persönlichen Wissens- und Wertemodell zu verbinden und daraus nachvollziehbare Erkenntnisse über sich und seine Entwicklung entstehen zu lassen.**
+
+Diese Definition ist eine Baseline für die weitere Produktkonzeption und darf später geändert werden, sollte aber nicht ohne dokumentierte Entscheidung stillschweigend verkürzt oder ersetzt werden.

docs/architecture/functional/reflection_intelligence.md

@@ -0,0 +1,72 @@
+---
+    title: "Kanshō – Reflection Intelligence"
+    status: "Arbeitsstand"
+    date: "2026-08-18"
+    product_family: "Jinkendo"
+    document_role: "Fachkapitel / Reflection Frontiers / Hypothesen / Kausalität"
+    parent_document: "fachliche_zielarchitektur.md"
+    ---
+
+    # Kanshō – Reflection Intelligence
+
+Dieses Dokument ist das kanonische Home für offene Bedeutungs- und Zusammenhangsketten, Reflection Frontiers sowie die Trennung von Beobachtung, Interpretation, Hypothese und Kausalitätsbehauptung.
+
+<!-- Migriert aus `produktvision_und_produktidentitaet.md`: Abschnitt 12 Offene Enden und unvollständige Zusammenhänge in mindnet. Inhalt fachlich unverkuerzt; nur Heading-Level fuer die neue Dateistruktur angepasst. -->
+
+## 12. Offene Enden und unvollständige Zusammenhänge in mindnet
+
+In mindnet existieren bereits offene Enden, für die noch keine erschöpfende Kausal- oder Bedeutungskette aufgebaut wurde.
+
+Diese Eigenschaft kann für Kanshō besonders wertvoll sein.
+
+Arbeitstitel für solche offenen Stellen:
+
+### Reflection Frontiers
+
+Reflection Frontiers sind Themen, Beziehungen oder Erfahrungen, die noch nicht vollständig verstanden oder eingeordnet sind.
+
+Beispiele:
+
+- Ein Ereignis und eine Reaktion stehen nebeneinander, aber die Bedeutung ist unklar.
+- Ein Wert scheint mit einer späteren Entscheidung in Spannung zu stehen.
+- Mehrere Erlebnisse ähneln sich, ohne dass ein belastbares Muster bestätigt ist.
+- Eine frühere Reflexion wurde nicht abgeschlossen.
+- Eine Annahme über sich selbst ist noch nicht geprüft.
+
+Kanshō kann solche Stellen bei passendem Kontext erneut anbieten.
+
+---
+
+<!-- Migriert aus `produktvision_und_produktidentitaet.md`: Abschnitt 13 Vorsicht bei Kausalität und psychologischer Interpretation. Inhalt fachlich unverkuerzt; nur Heading-Level fuer die neue Dateistruktur angepasst. -->
+
+## 13. Vorsicht bei Kausalität und psychologischer Interpretation
+
+Kanshō darf keine ungesicherten Kausalzusammenhänge als Tatsachen darstellen.
+
+Zu unterscheiden sind mindestens:
+
+- beobachtete Tatsache,
+- eigene Aussage des Nutzers,
+- bestätigte Erkenntnis,
+- Interpretation,
+- Hypothese,
+- vermuteter Zusammenhang,
+- offene Frage.
+
+Beispielsweise sollte die App nicht vorschnell speichern:
+
+`A verursacht B`
+
+sondern gegebenenfalls:
+
+- `A trat gemeinsam mit B auf`
+- `A könnte mit B zusammenhängen`
+- `B erinnert an A`
+- `A steht möglicherweise in Spannung zu B`
+- `Hypothese: A beeinflusst B`
+- `Zusammenhang ungeklärt`
+
+Dies ist eine zentrale Qualitäts- und Vertrauensanforderung.
+
+---
+