Dateien nach "docs/architecture/functional" hochladen

docs/architecture/functional/context_fidelity_and_regrounding.md

@@ -0,0 +1,228 @@
+---
+    title: "Kanshō – Context Fidelity und Re-Grounding"
+    status: "Arbeitsstand"
+    date: "2026-08-18"
+    product_family: "Jinkendo"
+    document_role: "Querschnittliches Fachkapitel / Context Fidelity / Re-Grounding"
+    parent_document: "fachliche_zielarchitektur.md"
+    ---
+
+    # Kanshō – Context Fidelity und Re-Grounding
+
+Dieses Dokument ist das kanonische Home für Context Drift, Quellenbindung, Fidelity und Re-Grounding.
+
+<!-- Migriert aus `fachliche_zielarchitektur.md`: ehemaliger Abschnitt 2.9 Context Fidelity und Re-Grounding. Inhalt fachlich unverkuerzt; nur Heading-Level fuer die neue Dateistruktur angepasst. -->
+
+### 2.9 Context Fidelity und Re-Grounding
+
+
+#### Root-Cause-Herleitung
+
+Die Anforderung an Context Fidelity und Re-Grounding entsteht nicht aus dem Wunsch nach zusätzlicher technischer Komplexität, sondern aus einer strukturellen Eigenschaft langfristiger KI-gestützter Dialogsysteme.
+
+##### Root Cause
+
+Kanshō soll Reflexionen, Dialoge, Threads und persönliche Entwicklung über Monate und Jahre hinweg fortführen können.
+
+Dafür kann nicht bei jeder Interaktion der vollständige historische Originalkontext in das aktive Kontextfenster geladen werden. Langfristige Inhalte müssen daher selektiert, zusammengefasst, verdichtet oder in abgeleitete Memory- beziehungsweise Zustandsstrukturen überführt werden.
+
+Jede Verdichtung ist jedoch zwangsläufig selektiv. Sie kann:
+
+- Details weglassen,
+- Gewichtungen verändern,
+- Mehrdeutigkeiten reduzieren,
+- zeitliche Zusammenhänge vereinfachen,
+- Interpretationen stärker wirken lassen als die ursprünglichen Aussagen,
+- frühere Hypothesen ungewollt stabilisieren.
+
+Problematisch wird dies insbesondere dann, wenn spätere Verdichtungen nicht mehr auf Originalquellen, sondern auf bereits verdichteten Zuständen aufbauen.
+
+Es entsteht dann potenziell eine Kette wie:
+
+`Originaldialog → Summary → Thread Memory → Reflection-Space-State → aktualisierte Zusammenfassung → neue Interpretation`
+
+Mit jeder weiteren Stufe kann sich der verwendete Kontext schrittweise vom ursprünglichen Bedeutungsgehalt entfernen.
+
+##### Risiko
+
+Ohne Gegenmechanismus besteht langfristig das Risiko, dass Kanshō nicht mehr primär auf die tatsächlichen Erlebnisse, Aussagen und dokumentierten Erfahrungen des Nutzers reagiert, sondern zunehmend auf seine eigenen früheren Verdichtungen und Interpretationen davon.
+
+Dies kann insbesondere zu folgenden Problemen führen:
+
+- Verlust relevanter Nuancen,
+- Verstärkung früherer Fehlinterpretationen,
+- Umdeutung von Hypothesen zu scheinbaren Tatsachen,
+- falsche Musterbildung,
+- unzutreffende Verknüpfungen zwischen Lebensbereichen,
+- fehlerhafte Fortschreibung des Self Models,
+- verzerrte Einordnung persönlicher Werte oder Entwicklungen,
+- scheinbar konsistente, aber biografisch falsche Langzeitnarrative.
+
+Besonders kritisch ist dieses Risiko bei Aussagen mit hoher persönlicher Bedeutung, etwa zu:
+
+- Werten,
+- Leitbild,
+- Selbstbild,
+- biografischen Wendepunkten,
+- langfristigen Mustern,
+- tiefen persönlichen Konflikten,
+- Vergangenheitsbewältigung.
+
+##### Fachliche Konsequenz
+
+Provenance allein reicht nicht aus.
+
+Es genügt nicht, nur zu wissen, **woher** eine verdichtete Aussage ursprünglich stammt. Kanshō muss zusätzlich beurteilen können, **wann die aktuell verwendete Verdichtung nicht mehr ausreichend zuverlässig ist und der Ursprungskontext erneut nachvollzogen werden sollte**.
+
+Der langfristige Kontext darf daher nicht unbegrenzt rekursiv aus bereits abgeleiteten Zuständen fortgeschrieben werden.
+
+##### Abgeleitete Anforderung
+
+Kanshō benötigt einen fachlichen Mechanismus zur Bewertung der Kontexttreue beziehungsweise des Drift-Risikos.
+
+Dieser Mechanismus muss bei Bedarf ein **Re-Grounding** auslösen können.
+
+Re-Grounding bedeutet:
+
+- relevante Ursprungsquellen erneut abrufen,
+- den aktuell verwendeten verdichteten Kontext dagegen prüfen,
+- Abweichungen, Widersprüche und Bedeutungsverschiebungen erkennen,
+- den aktuellen Zustand gegebenenfalls neu ableiten,
+- frühere Zustände und Änderungen nachvollziehbar erhalten.
+
+Der Vorgang muss sowohl:
+
+- automatisch beziehungsweise systemseitig,
+- als auch ausdrücklich durch den Nutzer
+
+ausgelöst werden können.
+
+Die konkrete technische Realisierung – beispielsweise als numerischer Drift Index, mehrdimensionale Fidelity-Metrik oder zustandsbasierte Bewertung – wird erst in der technischen Architektur festgelegt.
+
+Die fachliche Anforderung an Re-Grounding gilt unabhängig von dieser späteren technischen Ausgestaltung.
+
+Verdichtete Zustände, Thread Memories und Reflection-Space-Sichten dürfen nicht unbegrenzt rekursiv aufeinander aufbauen, ohne den ursprünglichen Kontext erneut zu prüfen.
+
+Die fachliche Zielarchitektur fordert deshalb einen **Context-Fidelity-/Drift-Mechanismus**.
+
+Dieser soll beantworten:
+
+> Wie sicher kann Kanshō sein, dass der aktuell verwendete verdichtete Kontext noch ausreichend treu zu den zugrunde liegenden Quellen ist?
+
+Bei ausreichendem Drift-Risiko wird ein **Re-Grounding** ausgelöst.
+
+Re-Grounding bedeutet:
+
+- relevante Ursprungsquellen erneut abrufen,
+- bisherigen verdichteten Kontext gegen diese Quellen prüfen,
+- Widersprüche und Veränderungen erkennen,
+- den aktuellen Zustand gegebenenfalls neu ableiten,
+- Provenance und Änderungshistorie erhalten.
+
+Der Mechanismus muss sowohl:
+
+- automatisch beziehungsweise systemseitig ausgelöst werden können,
+- als auch ausdrücklich durch den Nutzer anforderbar sein.
+
+Die konkrete technische Berechnung eines Index, Scores oder Zustandsmodells wird bewusst noch nicht festgelegt.
+
+Für Entwicklung und Test soll die Admin-/Developer View später mindestens sichtbar machen können:
+
+- letzten vollständigen Re-Grounding-Zeitpunkt,
+- relevante Drift-/Fidelity-Indikatoren,
+- verwendete Quellschichten,
+- Gründe für ausgelöstes Re-Grounding,
+- Unterschiede zwischen vorherigem und neu abgeleitetem Kontext.
+
+<!-- Migriert aus `produktvision_und_produktidentitaet.md`: ehemaliger Abschnitt 8.8 Context Drift und Re-Grounding. Inhalt fachlich unverkuerzt; nur Heading-Level fuer die neue Dateistruktur angepasst. -->
+
+### 8.8 Context Drift und Re-Grounding
+
+
+#### Warum diese Funktion notwendig ist
+
+Diese Anforderung entsteht aus der langfristigen Arbeitsweise von Kanshō:
+
+Langfristige Dialoge und Erinnerungen müssen im Laufe der Zeit verdichtet werden. Werden spätere Verdichtungen wiederum auf bereits verdichteten Zuständen aufgebaut, können sich Informationsverlust, Fehlinterpretationen und Bedeutungsverschiebungen schrittweise verstärken.
+
+Das zentrale Risiko besteht darin, dass Kanshō langfristig zunehmend auf seine eigene frühere Interpretation der Biografie reagiert und nicht mehr ausreichend auf die ursprünglichen Aussagen, Erlebnisse und Quellen des Nutzers.
+
+Daraus folgt die fachliche Notwendigkeit eines Re-Grounding-Mechanismus.
+
+Die vollständige Herleitung **Root Cause → Risiko → fachliche Konsequenz → abgeleitete Anforderung** ist in `fachliche_zielarchitektur.md` im Kapitel **Context Fidelity und Re-Grounding** dokumentiert.
+
+Die verdichtete aktuelle Sicht eines Reflection Space dient dazu, langfristige Dialoge handhabbar zu machen. Diese Verdichtung darf jedoch nicht dazu führen, dass Kanshō über längere Zeit nur noch auf früheren Zusammenfassungen, abgeleiteten Erinnerungen oder bereits interpretierten Zuständen aufbaut.
+
+Daher benötigt Kanshō fachlich einen Mechanismus zur Bewertung, **wie weit der aktuell verwendete Kontext noch zuverlässig auf den ursprünglichen Quellen basiert**.
+
+Arbeitstitel:
+
+- **Context Drift Index**
+- alternativ: **Re-Grounding Need**
+- alternativ: **Context Fidelity State**
+
+Die endgültige Bezeichnung ist offen.
+
+#### Zweck
+
+Der Mechanismus soll Kanshō veranlassen, bei zunehmender Unsicherheit oder möglicher semantischer Drift den tatsächlichen historischen Kontext erneut nachzuvollziehen.
+
+Dazu kann die KI – abhängig von Situation und Relevanz – erneut auf zugrunde liegende Quellen zurückgreifen, beispielsweise:
+
+- Originaldialoge,
+- frühere Tagebucheinträge,
+- Episoden und Memories,
+- Obsidian-Quellen,
+- mindnet-Knoten und deren Provenance,
+- bestätigte Self-Model-Aussagen,
+- frühere Hypothesen und deren Entwicklungsverlauf.
+
+#### Fachliche Trigger für Re-Grounding
+
+Ein erneutes Nachvollziehen des Ursprungskontexts soll insbesondere in Betracht gezogen werden, wenn:
+
+- ein Kontext über viele Verdichtungs- oder Aktualisierungsschritte fortgeschrieben wurde,
+- der letzte vollständige Quellenabgleich lange zurückliegt,
+- neue Informationen bisherigen Aussagen widersprechen,
+- mehrere Threads oder Reflection Spaces miteinander verschmelzen,
+- eine Aussage hohe persönliche Bedeutung besitzt,
+- das Self Model oder grundlegende Werte betroffen sind,
+- die KI selbst geringe Sicherheit bezüglich des Zusammenhangs erkennt,
+- Herkunft oder Provenance einer relevanten Aussage nicht ausreichend klar ist,
+- der Nutzer eine Einordnung korrigiert,
+- der Nutzer ausdrücklich verlangt, den ursprünglichen Kontext erneut nachzuvollziehen.
+
+#### Nutzerinitiierte Re-Grounding-Funktion
+
+Der Nutzer soll Kanshō jederzeit sinngemäß anweisen können:
+
+> „Prüfe noch einmal den ursprünglichen Kontext.“
+
+oder:
+
+> „Geh dafür noch einmal auf die ursprünglichen Reflexionen zurück.“
+
+Kanshō soll dann nicht lediglich die bestehende Zusammenfassung erneut interpretieren, sondern – soweit verfügbar – auf die zugrunde liegenden Quellen zurückgreifen.
+
+#### Verhältnis zur Nutzer-Transparenz
+
+Diese Re-Grounding-Funktion ist von der zuvor beschriebenen Aufklappbarkeit zu unterscheiden.
+
+- **Aufklappen / Provenance View:** Der Nutzer möchte sehen, worauf eine Aussage basiert.
+- **Re-Grounding:** Kanshō selbst rekonstruiert den relevanten Kontext erneut aus den Ursprungsquellen und prüft seine bisherige Verdichtung beziehungsweise Interpretation.
+
+Beide Funktionen greifen auf ähnliche Provenance-Strukturen zurück, dienen aber unterschiedlichen Zwecken.
+
+#### Kein blindes Überschreiben
+
+Ein erneuter Quellenabgleich soll frühere Zustände nicht spurlos überschreiben.
+
+Wenn sich die bisherige Einordnung ändert, sollte nachvollziehbar bleiben:
+
+- was zuvor angenommen wurde,
+- welche neuen beziehungsweise erneut geprüften Quellen berücksichtigt wurden,
+- warum sich die Einordnung verändert hat,
+- welcher aktuelle Stand daraus entstanden ist.
+
+Die konkrete Berechnung eines Drift- oder Fidelity-Werts wird erst in der technischen Architektur spezifiziert.
+

docs/architecture/functional/dialogue_model.md

@@ -0,0 +1,230 @@
+---
+    title: "Kanshō – Dialogmodell und Gesprächsführung"
+    status: "Arbeitsstand"
+    date: "2026-08-18"
+    product_family: "Jinkendo"
+    document_role: "Fachkapitel / Dialogue Model"
+    parent_document: "fachliche_zielarchitektur.md"
+    ---
+
+    # Kanshō – Dialogmodell und Gesprächsführung
+
+Dieses Dokument ist das kanonische Home für Kerninteraktion, Gesprächseinstieg, Reflection Intent, Dialogführung und Dialogfäden.
+
+<!-- Migriert aus `produktvision_und_produktidentitaet.md`: Abschnitt 6 Kerninteraktion. Inhalt fachlich unverkuerzt; nur Heading-Level fuer die neue Dateistruktur angepasst. -->
+
+## 6. Kerninteraktion
+
+Die wichtigste Funktion von Kanshō ist nicht das Speichern eines Tagebucheintrags, sondern ein **geführter Reflexionsdialog**.
+
+Die App soll deshalb dialogzentriert gedacht werden.
+
+Ein Dialog kann beispielsweise ausgelöst werden durch:
+
+- ein aktuelles Erlebnis,
+- einen Tagesrückblick,
+- eine emotionale Reaktion,
+- eine offene persönliche Frage,
+- eine Erinnerung,
+- ein wiederkehrendes Muster,
+- einen beruflichen Konflikt,
+- eine Idee,
+- eine Zukunftsvision,
+- eine bewusste Achtsamkeitsphase,
+- eine Meditation,
+- eine frühere offene Reflexion.
+
+Die KI soll nicht nur generische Fragen stellen, sondern den bestehenden Kontext nutzen.
+
+Für den laufenden Dialog gilt als fachliche Anforderung:
+
+- Der Gesprächsfluss soll sich auch über längere Reflexionen hinweg natürlich und zusammenhängend anfühlen.
+- Wichtige Informationen aus dem aktuellen Gespräch dürfen nicht allein deshalb verloren gehen, weil sich mehrere Themen oder Threads entwickeln.
+- Der Nutzer soll relevante Informationen nicht regelmäßig wiederholen müssen.
+- Aktiver Reflection Intent, aktuelle Threads und wesentliche Aussagen müssen im Arbeitskontext erhalten beziehungsweise bei Bedarf gezielt wiederhergestellt werden.
+
+---
+
+<!-- Migriert aus `produktvision_und_produktidentitaet.md`: Abschnitt 8 Einleitung Kontextbezogener Gesprächseinstieg. Inhalt fachlich unverkuerzt; nur Heading-Level fuer die neue Dateistruktur angepasst. -->
+
+## 8. Kontextbezogener Gesprächseinstieg
+
+Ein neuer Dialog soll nicht mit einer beliebigen oder immer gleichen Standardfrage beginnen.
+
+Die Eingangsfrage soll sich aus dem vorhandenen Kontext ergeben.
+
+Dazu kann Kanshō beispielsweise berücksichtigen:
+
+- aktuellen Reflexionsraum,
+- letzten Dialog in diesem Kontext,
+- offene Dialogfäden,
+- kürzlich gespeicherte Erlebnisse,
+- relevante Einträge aus mindnet,
+- Werte und Leitbild,
+- zeitliche Zusammenhänge,
+- ggf. Informationen anderer Jinkendo-Anwendungen.
+
+Ziel ist ein Einstieg, der sich wie die Fortsetzung eines bestehenden persönlichen Denkprozesses anfühlt.
+
+<!-- Migriert aus `produktvision_und_produktidentitaet.md`: Abschnitt 8.1 Adaptives Entry-Modell. Inhalt fachlich unverkuerzt; nur Heading-Level fuer die neue Dateistruktur angepasst. -->
+
+### 8.1 Adaptives Entry-Modell
+
+Für den Einstieg in Kanshō wurde ein abgestuftes Modell festgelegt.
+
+#### Stufe 1 – Contextual Continuation (Default)
+
+Kanshō eröffnet die Nutzung primär mit einem intelligent priorisierten Vorschlag, der an den bisherigen persönlichen Kontext anknüpft.
+
+Mögliche Ausgangspunkte sind beispielsweise:
+
+- der letzte Dialog,
+- ein noch offener Dialogfaden,
+- eine unbeantwortete Frage,
+- ein aktueller Reflection Space,
+- ein naheliegender Tagesrückblick,
+- ein länger offenes, aktuell relevantes Thema.
+
+Der Vorschlag ist immer als Einladung formuliert und nicht als Vorgabe.
+
+Kanshō priorisiert grundsätzlich **einen Hauptvorschlag**. Daneben können wenige diskrete Alternativen angeboten werden.
+
+#### Stufe 2 – Free Reflection
+
+Der Nutzer kann jederzeit ohne vorherige Auswahl frei sprechen oder schreiben.
+
+Kanshō versucht dann aus dem Gespräch heraus:
+
+- den passenden Kontext,
+- einen vorhandenen Reflection Space,
+- mögliche Threads,
+- die aktuelle Nutzungsabsicht
+
+zu erkennen.
+
+#### Stufe 3 – Explicit Navigation
+
+Wenn der Nutzer gezielt an etwas anknüpfen möchte, kann er bewusst navigieren, beispielsweise zu:
+
+- einem früheren Dialog,
+- einer offenen Frage,
+- einem offenen Thread,
+- einem Reflection Space,
+- einem bestimmten Tagebucheintrag,
+- einem konkreten Urlaubstag.
+
+Die Reihenfolge C → B/A ist keine starre Prozesslogik, sondern die bevorzugte Interaktionshierarchie. Der Nutzer kann jederzeit direkt in Stufe 2 oder 3 wechseln.
+
+<!-- Migriert aus `produktvision_und_produktidentitaet.md`: Abschnitt 8.2 Reflection Intent. Inhalt fachlich unverkuerzt; nur Heading-Level fuer die neue Dateistruktur angepasst. -->
+
+### 8.2 Reflection Intent
+
+Neben dem Kontext wird eine zweite Dimension benötigt: die **aktuelle Absicht der Reflexion**.
+
+Ein Reflection Space beschreibt, **worüber beziehungsweise in welchem Lebenszusammenhang** reflektiert wird.
+
+Der Reflection Intent beschreibt, **was der Nutzer in diesem Moment mit der Interaktion erreichen möchte**.
+
+Beispiele:
+
+- `Space: Urlaub / Lošinj 2026` + `Intent: Tageserlebnisse festhalten`
+- `Space: Urlaub / Lošinj 2026` + `Intent: tiefer reflektieren`
+- `Space: Persönliche Entwicklung / Gestaltungsdrang` + `Intent: offenen Thread fortsetzen`
+- `Space: Beruf / aktuelle Rolle` + `Intent: Entscheidung einordnen`
+
+Der Intent kann:
+
+- explizit gewählt werden,
+- aus dem Einstieg erkannt werden,
+- sich im Verlauf des Gesprächs verändern.
+
+Kanshō soll sein Dialogverhalten am Intent ausrichten.
+
+Beispielsweise:
+
+- beim autobiografischen Festhalten stärker zuhören und strukturieren,
+- bei tiefer Reflexion gezielter nachfragen,
+- beim Fortsetzen eines Threads den bisherigen Denkstand rekonstruieren,
+- bei einer offenen Frage vorhandene Perspektiven und frühere Erkenntnisse einbeziehen.
+
+<!-- Migriert aus `produktvision_und_produktidentitaet.md`: Abschnitt 8.3 Konsequenz für die Startoberfläche. Inhalt fachlich unverkuerzt; nur Heading-Level fuer die neue Dateistruktur angepasst. -->
+
+### 8.3 Konsequenz für die Startoberfläche
+
+Die Startoberfläche soll nicht primär als klassische Funktionsnavigation mit gleichwertigen Modulen wie „Tagebuch“, „Meditation“, „Reflexion“ und „Achtsamkeit“ aufgebaut werden.
+
+Primär soll sie die **Kontinuität des persönlichen Dialogs** sichtbar machen.
+
+Ein mögliches Muster ist:
+
+- ein intelligent priorisierter Hauptvorschlag,
+- wenige Alternativen wie freie Reflexion, Tagebuch, offene Threads oder Reflection Spaces,
+- jederzeitiger Wechsel in gezielte Navigation.
+
+Damit wird Kanshō als langfristiger Begleiter erlebt und nicht als Sammlung einzelner Tools.
+
+---
+
+<!-- Migriert aus `produktvision_und_produktidentitaet.md`: Abschnitt 8.5 Fachliche Ebene versus technische Umsetzung. Inhalt fachlich unverkuerzt; nur Heading-Level fuer die neue Dateistruktur angepasst. -->
+
+### 8.5 Fachliche Ebene versus technische Umsetzung
+
+Für die weitere Konzeption wird grundsätzlich zwischen zwei Ebenen getrennt:
+
+#### Fachliche Zielarchitektur
+
+Sie beschreibt:
+
+- welches Verhalten Kanshō aus Sicht des Nutzers zeigen soll,
+- welche fachlichen Objekte und Verantwortlichkeiten benötigt werden,
+- welche Entscheidungen der Nutzer treffen können muss,
+- welche Informationen und Beziehungen grundsätzlich relevant sind.
+
+#### Technische Architektur
+
+Sie beschreibt später:
+
+- wie diese Anforderungen implementiert werden,
+- welche Datenmodelle und Speicher verwendet werden,
+- wie Agenten, Modelle, Retrieval und Synchronisation funktionieren,
+- welche Heuristiken oder Algorithmen eingesetzt werden.
+
+Technische Architekturentscheidungen werden im fachlichen Konzept nur dann vorgezogen, wenn sie eine wesentliche Produktgrenze oder eine später kaum reversible Grundentscheidung darstellen.
+
+Die fachliche Konzeption soll bewusst vermeiden, aus jeder Produktidee frühzeitig ein komplexes technisches Subsystem abzuleiten.
+
+<!-- Migriert aus `produktvision_und_produktidentitaet.md`: Abschnitt 9 Dialogfäden. Inhalt fachlich unverkuerzt; nur Heading-Level fuer die neue Dateistruktur angepasst. -->
+
+## 9. Dialogfäden
+
+Ein Gespräch kann mehrere Themen oder Reflexionsfäden enthalten.
+
+Beispiel:
+
+Ein Dialog beginnt im Kontext `Urlaub → Lošinj 2026`.
+
+Während des Gesprächs entstehen möglicherweise mehrere Fäden:
+
+- körperliches Befinden,
+- Erholung,
+- Familie,
+- Arbeiten während des Urlaubs,
+- persönlicher Gestaltungsdrang,
+- Zukunftsfragen.
+
+Diese Themen sollen nicht zwangsläufig in getrennten Chats gestartet werden.
+
+Kanshō soll im Dialog erkennen können, wenn sich ein eigener Reflexionsfaden entwickelt.
+
+Mögliche Verhaltensweisen:
+
+- Faden zunächst nur intern markieren,
+- später wieder aufnehmen,
+- bei deutlicher thematischer Abzweigung eine Trennung vorschlagen,
+- Faden bewusst parken,
+- Faden mit vorhandenem mindnet-Kontext verbinden.
+
+Die KI darf die Dialogstruktur unterstützen, soll den Gesprächsfluss aber nicht unnötig fragmentieren.
+
+---
+

docs/architecture/functional/documentation_index.md

@@ -0,0 +1,82 @@
+---
+    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
+
+- `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 |
+
+## 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
+
+### 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. Ladeprinzip
+
+> **Nicht alle Kanshō-Dokumente gleichzeitig laden.** Root-Dokumente plus die 2–4 fachlich betroffenen Dateien bilden den Standardkontext.
+
+Vor größeren Querschnittsentscheidungen wird zusätzlich über `migration_mapping.md` und die relevanten Invarianten geprüft, ob andere Kapitel betroffen sind.

docs/architecture/functional/fachliche_zielarchitektur.md

@@ -0,0 +1,268 @@
+---
+title: "Kanshō – Fachliche Zielarchitektur und Interviewplan"
+version: "0.1"
+status: "Arbeitsstand"
+date: "2026-08-18"
+product_family: "Jinkendo"
+document_role: "Fachliche Zielarchitektur / Master Structure / Interview Plan"
+---
+# Kanshō – Fachliche Zielarchitektur
+
+## 1. Zweck dieses Dokuments
+
+Dieses Dokument definiert die fachliche Zielarchitektur der Kanshō-Produktdokumentation.
+
+Jedes fachlich relevante Kapitel soll später als **eigenständige Markdown-Datei** in Gitea geführt werden.
+
+Damit werden drei Ziele verfolgt:
+
+1. Die Dokumentation bleibt modular und versionierbar.
+2. Einzelne Themen können weiterentwickelt werden, ohne andere Inhalte unbeabsichtigt zu verdichten oder zu überschreiben.
+3. Die Kapitelstruktur bildet gleichzeitig den Fahrplan für den weiteren Konzeptdialog beziehungsweise das Interview.
+
+Dieses Dokument ist somit:
+
+- das **erste und führende Referenzdokument** der fachlichen Konzeption,
+- Inhaltsverzeichnis,
+- Dokumentationsarchitektur,
+- Interviewplan,
+- Fortschrittsübersicht.
+
+Die übrigen fachlichen Dokumente werden aus dieser Zielarchitektur abgeleitet und fachlich hier eingeordnet.
+
+---
+# 2. Dokumentationsprinzipien
+
+## 2.1 Keine stillschweigende Verdichtung
+
+Ein bestehendes Kapitel wird nicht dadurch „verbessert“, dass ältere Inhalte ohne Kennzeichnung verschwinden.
+
+Änderungen erfolgen durch:
+
+- Ergänzung,
+- explizite Ersetzung,
+- Kennzeichnung als überholt,
+- Decision Record,
+- Gitea-Versionierung.
+
+---
+
+## 2.2 Entscheidungen und Ideen trennen
+
+Jedes Kapitel soll klar unterscheiden zwischen:
+
+- **Entschieden**
+- **Bevorzugte Richtung**
+- **Hypothese**
+- **Offen**
+- **Verworfen**
+- **Später prüfen**
+
+---
+
+## 2.3 Herkunft von Aussagen erhalten
+
+Wo sinnvoll soll kenntlich bleiben, ob ein Punkt stammt aus:
+
+- expliziter Nutzeranforderung,
+- gemeinsam getroffener Entscheidung,
+- Architekturvorschlag,
+- technischem Zwang,
+- späterer Validierung,
+- externem Research.
+
+---
+
+## 2.4 Keine unnötige Duplizierung
+
+Ein Thema hat möglichst ein fachliches „Home“.
+
+Andere Kapitel verlinken darauf, statt denselben Inhalt mehrfach vollständig zu kopieren.
+
+---
+
+## 2.5 Kapitel sind unabhängig versionierbar
+
+Jede Datei erhält mindestens:
+
+- Titel,
+- Version,
+- Status,
+- Datum,
+- Rolle des Dokuments.
+
+Die **Dateinamen selbst bleiben stabil und enthalten keine Versionsnummern oder laufenden Nummerierungspräfixe**. Versionierung erfolgt über Gitea beziehungsweise die Dokumentmetadaten, nicht durch Umbenennen der Datei.
+
+---
+
+
+## 2.6 Trennung von fachlicher und technischer Konzeption
+
+Die fachliche Zielarchitektur ist führend.
+
+Im Interview wird zunächst beschrieben:
+
+- welches Nutzererlebnis gewünscht ist,
+- welche fachlichen Verantwortlichkeiten bestehen,
+- welche Objekte oder Beziehungen für das Produktverständnis notwendig sind,
+- welche Entscheidungen oder Kontrollen beim Nutzer liegen.
+
+Die technische Umsetzung wird bewusst nachgelagert.
+
+Ausnahmen sind nur dann sinnvoll, wenn eine technische Grundentscheidung:
+
+- die fachliche Produktgrenze unmittelbar beeinflusst,
+- später nur mit sehr hohem Aufwand revidierbar wäre,
+- oder zwingende Auswirkungen auf Datenschutz, Offline-Fähigkeit, Sicherheit oder Integrationen hat.
+
+Ziel ist, eine fachlich klare, aber handhabbare Architektur zu entwickeln und unnötige Frühkomplexität zu vermeiden.
+
+
+## 2.7 Transparenz- und Diagnoseprinzip
+
+Die normale Nutzeroberfläche soll interne KI-Strukturen bewusst abstrahieren.
+
+Für Entwicklung, Test und Administration wird jedoch eine gesonderte **Admin-/Developer View** vorgesehen.
+
+Diese dient insbesondere dazu, fachliche und später technische Entscheidungen nachvollziehen zu können, ohne die reguläre Nutzung mit interner Komplexität zu belasten.
+
+Die Diagnoseansicht soll perspektivisch unter anderem Einblick geben in:
+
+- Threads und Thread-Kandidaten,
+- Reflection-Space-Zuordnungen,
+- Konsolidierungsentscheidungen,
+- Memory-Provenance,
+- Confidence und Unsicherheit,
+- Hypothesen,
+- Context-Builder-Ergebnisse,
+- verwendete Wissensquellen,
+- Strukturänderungen.
+
+Der Zugriff ist rollenbasiert und nicht für reguläre Nutzer vorgesehen.
+
+Dieses Prinzip ist fachlich bereits entschieden; genaue UI, Berechtigungen und technische Implementierung werden später spezifiziert.
+
+
+## 2.8 Schutz vor Übervereinfachung
+
+Die Zielarchitektur folgt ausdrücklich **nicht** dem Prinzip, den internen Kern möglichst klein oder einfach zu halten.
+
+Ziel ist vielmehr:
+
+> **maximale Nutzereinfachheit bei ausreichender interner Intelligenz und Differenzierung.**
+
+Daraus folgt für den Konzeptdialog:
+
+- Fachliche Komplexität wird nicht allein deshalb entfernt, weil sie technisch unbequem ist.
+- Interne Modelle dürfen komplex sein, wenn sie zur langfristigen Produktfähigkeit erforderlich sind.
+- Die Benutzeroberfläche abstrahiert interne Komplexität.
+- Automatisierung und KI-gestützte Strukturierung sollen Verwaltungsaufwand vom Nutzer fernhalten.
+- Vor jeder größeren Vereinfachung ist ein Capability-Check durchzuführen.
+
+### Capability-Check vor Modellvereinfachungen
+
+Vor einer strukturellen Vereinfachung wird geprüft:
+
+1. Welche bereits beschlossenen Anforderungen benötigen die Struktur?
+2. Welche später vorgesehenen Fähigkeiten könnten betroffen sein?
+3. Welche Integrationen hängen davon ab?
+4. Welche Langzeitfunktionen wie Memory, Self Model, Threading, Provenance oder Konsolidierung würden eingeschränkt?
+5. Ist die Vereinfachung reversibel?
+6. Kann die wahrgenommene Komplexität stattdessen auf UX-Ebene reduziert werden?
+
+Erst wenn diese Prüfung keine relevanten Funktionsverluste zeigt, soll eine interne Vereinfachung vorgenommen werden.
+
+
+
+## 2.8.1 Herleitung architekturrelevanter Entscheidungen
+
+Architekturrelevante Entscheidungen mit langfristiger Tragweite oder späterem Vereinfachungsrisiko sollen nicht nur als Lösung dokumentiert werden.
+
+Wo die Begründung für die spätere Nachvollziehbarkeit wesentlich ist, wird zusätzlich folgende Struktur festgehalten:
+
+1. **Root Cause** – welches zugrunde liegende Problem oder welche Systembedingung erzeugt den Bedarf?
+2. **Risiko** – welche fachlichen oder qualitativen Folgen entstehen ohne Gegenmaßnahme?
+3. **Fachliche Konsequenz** – welche Eigenschaft muss das Produkt deshalb besitzen?
+4. **Abgeleitete Anforderung / Entscheidung** – welcher Mechanismus oder welche Architekturleitplanke folgt daraus?
+
+Dieses Prinzip soll verhindern, dass später nur noch ein Architekturmechanismus sichtbar ist, während sein ursprünglicher Zweck verloren geht und die Entscheidung deshalb fälschlich als entbehrliche Komplexität behandelt wird.
+
+## 2.9 Querschnittliche Fachinvarianten
+
+Die ausführlichen Herleitungen der querschnittlichen Fachinvarianten werden nicht mehr in diesem Root-Dokument gepflegt. Sie besitzen jeweils ein kanonisches Fachkapitel und müssen bei späteren Architekturentscheidungen explizit konsistenzgeprüft werden.
+
+- **Context Fidelity / Re-Grounding:** `context_fidelity_and_regrounding.md`
+- **Thread Resurfacing / Reflection Saturation:** `resurfacing_and_saturation.md`
+- **Point-in-Time Self / Lived Experience:** `self_model_and_lived_experience.md`
+- **Privacy Gateway / External-AI-Guardrails:** `guardrails.md`
+
+> **Keine dieser Invarianten darf durch spätere technische Vereinfachungen stillschweigend abgeschwächt werden.**
+
+## 2.10 Dokumentationsintegrität und Drift-Audit
+
+Da die Produktkonzeption über einen langen Dialog hinweg entsteht, wird nicht nur der spätere Anwendungskontext, sondern auch die **Konzeptdokumentation selbst** gegen Drift geschützt.
+
+Vor dem Wechsel in einen neuen größeren Themenblock oder vor einem Handover soll geprüft werden:
+
+1. Sind alle expliziten Nutzeranforderungen seit dem letzten Audit dokumentiert?
+2. Sind gemeinsam getroffene Entscheidungen vollständig erhalten?
+3. Wurden ursprünglich konkrete Anforderungen ungewollt verallgemeinert oder abgeschwächt?
+4. Wurden offene Punkte versehentlich als entschieden dargestellt oder umgekehrt?
+5. Sind Root Causes und Begründungen architekturrelevanter Entscheidungen erhalten?
+6. Widersprechen sich Zielarchitektur und Fach-/Produktdokumente?
+7. Ist der Interviewstatus aktuell?
+8. Wurden Inhalte stillschweigend gelöscht oder durch eine kürzere Formulierung ersetzt?
+9. Sind Dateinamen und Repository-Struktur weiterhin mit den vereinbarten Gitea-Prinzipien konsistent?
+
+Korrekturen aus einem Audit sollen additiv erfolgen. Inhaltliche Löschungen oder Verdichtungen dürfen nur vorgenommen werden, wenn sie als bewusste Änderung nachvollziehbar sind.
+
+
+### Audit-Checkpoint 2026-08-18
+
+Vor dem Wechsel vom Reflection-Space-Block zu den typischen Nutzungssituationen wurde die bestehende Dokumentation gegen den bisherigen Konzeptdialog geprüft.
+
+Dabei wurden keine bewussten fachlichen Entscheidungen verworfen. Es wurden jedoch mehrere Stellen identifiziert, an denen frühere konkrete Aussagen zu allgemein geworden oder der Dokumentstatus veraltet war. Additiv beziehungsweise strukturell korrigiert wurden insbesondere:
+
+- explizite Verankerung von Kanshō als bewusst stärker KI-kollaborative Jinkendo-Komponente,
+- Wiederherstellung des konkret genannten Referenzrahmens „Day One im Gold-Abo“ für die spätere Journaling-Analyse,
+- explizite Sicherung des generierten Tagebucheintrags als vorgesehene Kernfunktion der täglichen Reflexion,
+- Dokumentation der vorläufigen sichtbaren Reflection-Space-Baseline,
+- explizite Nutzer-Provenance beziehungsweise Aufklappbarkeit verdichteter Aussagen,
+- Dokumentation, dass Reflection Spaces sowohl kurz-/mittelfristig als auch langfristig relevant sein können,
+- Aktualisierung des Interviewstatus: Reflection Spaces vorläufig ausreichend geklärt; typische Nutzungssituationen als nächster Block,
+- Entfernung numerischer Präfixe aus den vorgeschlagenen Gitea-Datei- und Ordnernamen,
+- Korrektur inkonsistenter Kapitel- und Listenummerierungen,
+- strukturelle Verschiebung des Prinzips „Einfachheit an der Oberfläche, Intelligenz im Kern“ aus den Integrationsprinzipien in die Produktprinzipien, ohne inhaltliche Kürzung.
+
+Dieser Checkpoint dokumentiert den Abgleich mit dem bis zu diesem Zeitpunkt vorliegenden Konzeptdialog. Spätere Erkenntnisse können bestehende Punkte konkretisieren oder bewusst ändern, sollen diese Änderungen jedoch nachvollziehbar dokumentieren.
+
+# 3. Kanonische Dokumentstruktur
+
+Die fachliche Dokumentation ist nach Themen aufgeteilt. Ein Thema soll möglichst genau ein kanonisches fachliches Home besitzen.
+
+```text
+fachliche_zielarchitektur.md
+produktvision_und_produktidentitaet.md
+documentation_index.md
+interview_plan.md
+usage_situations.md
+reflection_spaces.md
+dialogue_model.md
+memory_and_context.md
+resurfacing_and_saturation.md
+context_fidelity_and_regrounding.md
+self_model_and_lived_experience.md
+writing_profile_and_journaling.md
+reflection_intelligence.md
+reflection_outputs.md
+integrations.md
+guardrails.md
+migration_mapping.md
+```
+
+Die unveränderten Quelldokumente vor der Aufteilung liegen im Verzeichnis `checkpoint_originals/`.
+
+# 4. Interviewsteuerung
+
+Der detaillierte Kapitelplan, die Interviewmethode, Definition of Done, Fortschrittsstatus und der nächste Interviewblock werden ab jetzt in `interview_plan.md` gepflegt.
+