diff --git a/docs/architecture/functional/dialogue_model.md b/docs/architecture/functional/dialogue_model.md index 73a6c65..30fc65c 100644 --- a/docs/architecture/functional/dialogue_model.md +++ b/docs/architecture/functional/dialogue_model.md @@ -43,6 +43,8 @@ Für den laufenden Dialog gilt als fachliche Anforderung: - 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. +Diese Kontinuitätsarbeit erfolgt bei Bedarf bereits während eines langen Dialogs und nicht erst an dessen sichtbarem Ende. Summaries beziehungsweise Working- und Thread-Memory-Strukturen dürfen laufend fortgeschrieben werden, müssen aber quellengebunden bleiben und unterliegen den Re-Grounding-Regeln aus `context_fidelity_and_regrounding.md`. + --- diff --git a/docs/architecture/functional/documentation_index.md b/docs/architecture/functional/documentation_index.md index 613d8b6..efb56cf 100644 --- a/docs/architecture/functional/documentation_index.md +++ b/docs/architecture/functional/documentation_index.md @@ -13,6 +13,7 @@ Dieses Dokument dient dazu, für weitere Konzeptarbeit nur die tatsächlich ben ## 1. Root-Dokumente +- `handover.md` – Session-Bootstrap und aktueller Arbeitsstand; verweist für Details auf die kanonischen Fachkapitel und ersetzt sie nicht. - `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. diff --git a/docs/architecture/functional/fachliche_zielarchitektur.md b/docs/architecture/functional/fachliche_zielarchitektur.md index ec503e7..65b013d 100644 --- a/docs/architecture/functional/fachliche_zielarchitektur.md +++ b/docs/architecture/functional/fachliche_zielarchitektur.md @@ -193,6 +193,7 @@ Die ausführlichen Herleitungen der querschnittlichen Fachinvarianten werden nic - **Context Fidelity / Re-Grounding:** `context_fidelity_and_regrounding.md` - **Thread Resurfacing / Reflection Saturation:** `resurfacing_and_saturation.md` +- **Session Lifecycle ≠ Thread Lifecycle:** `reflection_outputs.md` und `resurfacing_and_saturation.md` - **Point-in-Time Self / Lived Experience:** `self_model_and_lived_experience.md` - **Privacy Gateway / External-AI-Guardrails:** `guardrails.md` @@ -241,6 +242,7 @@ Dieser Checkpoint dokumentiert den Abgleich mit dem bis zu diesem Zeitpunkt vorl Die fachliche Dokumentation ist nach Themen aufgeteilt. Ein Thema soll möglichst genau ein kanonisches fachliches Home besitzen. ```text +handover.md fachliche_zielarchitektur.md produktvision_und_produktidentitaet.md documentation_index.md diff --git a/docs/architecture/functional/handover.md b/docs/architecture/functional/handover.md new file mode 100644 index 0000000..4928979 --- /dev/null +++ b/docs/architecture/functional/handover.md @@ -0,0 +1,1532 @@ +--- +title: "Kanshō – Handover für neue Konzept-Session" +status: "Aktiver Übergabestand" +date: "2026-08-19" +product_family: "Jinkendo" +document_role: "Session Handover / Bootstrap / Current Working State" +source_of_truth: "Kanonische Markdown-Dateien im eingebundenen Kanshō-Git-Repository unter docs/architecture/functional/" +repository_root_current: "C:\\dev\\Kansho" +canonical_docs_path: "docs/architecture/functional/" +--- + +# Kanshō – Handover für neue Konzept-Session + +## 1. Zweck dieses Handovers + +Dieses Dokument ist der **vollständige fachliche Aufsatzpunkt für eine neue Kanshō-Konzept-Session**. + +Es soll ermöglichen, die Arbeit ohne Rückgriff auf den langen bisherigen Chat fortzusetzen und dabei insbesondere verhindern, dass: + +- bereits getroffene Entscheidungen erneut diskutiert werden, +- wichtige Root Causes oder Architekturgründe verloren gehen, +- offene Punkte versehentlich als entschieden behandelt werden, +- ältere, inzwischen archivierte Dokumentstände wieder zur aktiven Grundlage werden, +- Inhalte bei späteren Änderungen stillschweigend verdichtet oder entfernt werden. + +Das Handover ersetzt **nicht** die kanonischen Fachdateien. Es beschreibt ihren Zusammenhang, die wichtigsten bereits bindenden Entscheidungen, den aktuellen Interviewstand und den exakten nächsten Arbeitsschritt. + +Für Detailarbeit gilt immer: + +> **Handover zum Einstieg lesen → anschließend nur die für das aktuelle Thema benötigten kanonischen Fachdateien laden.** + +--- + +# 2. Repository, kanonischer Pfad und Source of Truth + +Der Nutzer hat den neu aufgeteilten Kanshō-Dokumentationsstand vollständig nach Gitea übernommen und die früheren großen Dokumente in ein Archiv verschoben. + +Das aktive Kanshō-Git-Repository ist der ChatGPT-Projektumgebung als **Read/Write-Quelle** eingebunden. + +## 2.1 Aktueller lokaler Repository Root + +In der derzeitigen Entwicklungsumgebung lautet der physische Pfad: + +`C:\dev\Kansho` + +Dieser absolute Windows-Pfad ist eine **Umgebungsinformation**, keine fachliche Identität des Repositorys. Er kann sich später ändern. + +## 2.2 Kanonischer fachlicher Dokumentationspfad + +Relativ zum Repository Root liegen die aktiven fachlichen Architektur- und Konzeptdateien unter: + +`docs/architecture/functional/` + +Beispiele: + +- `docs/architecture/functional/handover.md` +- `docs/architecture/functional/fachliche_zielarchitektur.md` +- `docs/architecture/functional/produktvision_und_produktidentitaet.md` +- `docs/architecture/functional/usage_situations.md` +- `docs/architecture/functional/reflection_outputs.md` + +Für Dokumentation, Querverweise und Arbeitsanweisungen sollen grundsätzlich **repository-relative Pfade** verwendet werden. + +Der absolute Pfad `C:\dev\Kansho\...` soll nur verwendet werden, wenn eine konkrete lokale Dateioperation dies technisch benötigt. + +## 2.3 Verbindliche Source-of-Truth-Regel + +Ab jetzt gilt: + +> **Ausschließlich die kanonischen Dateien unter `docs/architecture/functional/` im eingebundenen Kanshō-Repository sind die aktive fachliche Source of Truth.** + +Insbesondere gilt: + +- Eine im Chat erzeugte oder hochgeladene Kopie einer gleichnamigen Datei ist **nicht** automatisch kanonisch. +- Temporäre Download-Artefakte sind keine Source of Truth. +- Frühere große Dokumente im Archiv sind keine aktive Arbeitsgrundlage. +- Ältere Chat-Inhalte dürfen aktuelle kanonische Repository-Dateien nicht überschreiben. +- Wenn Chat-Kontext und Repository-Datei voneinander abweichen, hat die aktuelle kanonische Repository-Datei Vorrang, sofern nicht ausdrücklich ein Audit historischer Stände durchgeführt wird. + +Die archivierten früheren Dateien sind: + +- historische Referenz, +- Audit-/Recovery-Material, +- keine aktive Arbeitsgrundlage. + +Sie dürfen nur dann wieder herangezogen werden, wenn der Nutzer dies ausdrücklich für einen historischen Vergleich, Audit oder Recovery verlangt. + +## 2.4 Read/Write-Arbeitsweise + +Wenn die Projektumgebung Schreibzugriff auf das eingebundene Repository besitzt, sollen fachliche Änderungen **direkt in der jeweils kanonischen Datei unter `docs/architecture/functional/`** vorgenommen werden. + +Bevorzugter Ablauf: + +1. relevante kanonische Datei lesen, +2. bestehenden Kontext und Entscheidungsstatus prüfen, +3. Änderung fachlich mit dem Nutzer klären, +4. Änderung additiv und konsistent direkt in der Repository-Datei einarbeiten, +5. betroffene Querverweise beziehungsweise Entscheidungsstände prüfen, +6. nach der Änderung die betroffenen Passagen erneut lesen beziehungsweise den Diff inhaltlich kontrollieren, +7. dem Nutzer die geänderten Repository-Dateien und den fachlichen Änderungsumfang nennen. + +Es sollen **keine parallelen Ersatzkopien** außerhalb des Repositorys erzeugt werden, außer der Nutzer verlangt ausdrücklich ein Export-/Download-Artefakt. + +Git-Commit und Push erfolgen nur, wenn der Nutzer dies ausdrücklich verlangt und die konkrete Arbeitsumgebung diese Aktionen unterstützt. + + +--- + +# 3. Integrität der Dokumentenaufteilung + +Vor diesem Handover wurde die Aufteilung technisch gegen die vollständigen Ausgangsdokumente geprüft. + +Ergebnis: + +- `produktvision_und_produktidentitaet.md`: fachliche Inhalte vollständig in der neuen Struktur erhalten. +- `usage_situations.md`: fachliche Inhalte vollständig erhalten. +- `guardrails.md`: fachliche Inhalte vollständig erhalten. +- `fachliche_zielarchitektur.md`: alle weiterhin fachlich gültigen Inhalte vollständig erhalten. + +Bewusst **nicht als aktiver Inhalt** übernommen wurden nur: + +1. eine überholte frühere Repository-/Ordnerstruktur, +2. ein überholter früherer Interview-/Fortschrittsstand. + +Diese historischen Zustände bleiben im Archiv/Checkpoint erhalten. + +Der technische Blockvergleich ergab für die weiterhin gültigen Inhalte: + +> **298 von 298 relevanten Inhaltsblöcken vorhanden; 0 fachliche Blöcke fehlend.** + +Die neue Dokumentstruktur kann deshalb ohne Rückgriff auf die archivierten Ausgangsdokumente als vollständige fachliche Arbeitsbasis verwendet werden. + +--- + +# 4. Arbeits- und Dokumentationsregeln für jede folgende Session + +Diese Regeln sind verbindlich. + +## 4.1 Keine stillschweigende Verdichtung + +Bestehende fachliche Inhalte dürfen nicht dadurch „verbessert“ werden, dass frühere Details, Beispiele, Begründungen oder Einschränkungen unbemerkt verschwinden. + +Änderungen erfolgen durch: + +- Ergänzung, +- explizite Präzisierung, +- bewusst dokumentierte Ersetzung, +- Kennzeichnung als überholt, +- Gitea-Versionierung. + +## 4.2 Entscheidungsstatus erhalten + +Unterscheide konsequent: + +- **Entschieden** +- **Bevorzugte Richtung** +- **Hypothese** +- **Offen** +- **Verworfen** +- **Später prüfen** + +Keine offene Frage darf nur aufgrund einer plausiblen Architekturidee stillschweigend als Entscheidung behandelt werden. + +## 4.3 Ein kanonisches Home pro Thema + +Detailentscheidungen werden im fachlich zuständigen Dokument gepflegt. + +Andere Dokumente enthalten höchstens: + +- kurze Querverweise, +- querschnittliche Invarianten, +- Statusreferenzen. + +Root-Dokumente dürfen nicht wieder zu großen Sammeldokumenten anwachsen. + +## 4.4 Fachlich vor technisch + +Zuerst klären: + +- gewünschtes Nutzererlebnis, +- fachliche Verantwortung, +- benötigte Konzepte, +- Nutzerkontrolle, +- Produktgrenzen. + +Technische Entscheidungen werden nachgelagert, außer sie beeinflussen unmittelbar: + +- Datenschutz, +- Offline-Fähigkeit, +- Sicherheit, +- schwer reversible Produktgrenzen, +- zentrale Integrationen. + +## 4.5 Root Cause erhalten + +Bei architekturrelevanten Entscheidungen gilt: + +1. Root Cause +2. Risiko +3. fachliche Konsequenz +4. abgeleitete Anforderung / Entscheidung + +Ein späterer Architekturmechanismus darf nicht von seiner ursprünglichen Begründung getrennt werden. + +## 4.6 Keine Übervereinfachung + +Zentrales Prinzip: + +> **Einfache UX, maximale sinnvolle Intelligenz und Differenzierung im Kern.** + +Interne Modelle dürfen komplex sein, wenn diese Komplexität benötigt wird für: + +- Langzeitgedächtnis, +- Threading, +- Reflection Spaces, +- Provenance, +- Self Model, +- zeitliche Entwicklung, +- Re-Grounding, +- Resurfacing, +- Privacy, +- Integrationen. + +Vor struktureller Vereinfachung muss ein Capability Check erfolgen. + +## 4.7 Drift-Audit + +Vor: + +- Wechsel in einen größeren neuen Themenblock, +- struktureller Dokumentänderung, +- Handover, +- wesentlicher Architekturvereinfachung + +prüfen: + +1. Sind alle expliziten Anforderungen dokumentiert? +2. Sind Entscheidungen vollständig erhalten? +3. Wurde etwas ungewollt verallgemeinert? +4. Stimmen offen/entschieden noch? +5. Sind Root Causes erhalten? +6. Widersprechen sich Fachdateien? +7. Ist der Interviewstatus aktuell? +8. Wurde etwas stillschweigend gelöscht oder verdichtet? +9. Ist die kanonische Dateistruktur eingehalten? + +--- + +# 5. Produktidentität und Vision + +Arbeitsname: + +> **Kanshō** + +Der Name ist weiterhin ein Arbeitstitel. + +Gewählte Produktidentität: + +> **Personal Reflection Companion** + +Kanshō ist **nicht** primär: + +- Tagebuch, +- Meditations-App, +- Mood Tracker, +- Aufgabenmanager, +- generischer Chatbot. + +Kanshō ist der: + +> **dialogische Reflexionsraum der Jinkendo-Familie.** + +Kernkette: + +> **Wahrnehmen → Reflektieren → Verstehen → Einordnen** + +Kanshō soll bewusst stärker KI-kollaborativ arbeiten als andere Jinkendo-Komponenten. Die KI ist zentraler Dialog- und Reflexionspartner und soll über längere Zeit: + +- Kontext verstehen, +- frühere Denkwege kennen, +- relevante frühere Erfahrungen berücksichtigen, +- Werte und Leitbild einbeziehen, +- offene Themen wiedererkennen, +- vorsichtig Zusammenhänge anbieten, +- passende Fragen entwickeln, +- Entwicklung über Monate und Jahre begleiten. + +--- + +# 6. Produktgrenzen innerhalb von Jinkendo + +Die vereinfachte Verantwortungsverteilung ist verbindlich: + +- **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? + +Wichtige Übergaben: + +## Kairo + +Kanshō darf: + +- Ziele/Entwicklungskontexte lesen, +- Handlungsabsichten erkennen, +- Action Candidates erzeugen, +- Übergabe an Kairo anbieten. + +Kanshō übernimmt **keine** dauerhafte Aufgaben-, Projekt- oder Zielverwaltung. + +Leitregel: + +> **Kairo plant den Anlass beziehungsweise die Handlung. Kanshō führt die Reflexion.** + +## mindnet + +mindnet ist langfristiges persönliches Wissensnetz und Retrieval-Schicht. + +Kanshō darf: + +- relevantes Wissen abrufen, +- Werte/Leitbild einbeziehen, +- Erfahrungen finden, +- Zusammenhänge nutzen, +- Reflection Memories zurückführen, +- Knowledge Deltas vorschlagen. + +## Obsidian + +Obsidian bleibt bevorzugt das: + +> **menschenlesbare autobiografische Langzeitarchiv.** + +Kanshō soll unter anderem Tagebucheinträge und strukturierte Reflexionen dort ablegen können. + +## Shinkan und Mitai + +Sie können kontextbezogene Informationen liefern, aber Kanshō dupliziert weder: + +- Trainingsplanung, +- Fitness-/Gesundheitstracking, +- Ernährungs- oder Vitaldatentracking. + +--- + +# 7. Zentrale Produktprinzipien + +Bereits entschieden: + +1. **Dialog vor Formular** +2. **Kontext vor generischer Frage** +3. **Erinnerung mit Herkunft / Provenance** +4. **Hypothese statt künstlicher Gewissheit** +5. **Mensch entscheidet über Identitätsaussagen** +6. **Persönliche Sprache statt generischem KI-Stil** +7. **Reflection before Action** +8. **Keine Funktionsduplikation innerhalb Jinkendo** +9. **Menschenlesbares Langzeitarchiv** +10. **Langfristige Kontinuität** +11. **Einfache Oberfläche, intelligenter und differenzierter Kern** + +Bewusste Nicht-Ziele: + +- Projektmanagementsystem, +- Aufgabenmanager, +- Gesundheits-/Fitness-Tracker, +- Trainingsplaner, +- reines Tagebuch, +- reine Meditations-App, +- generischer KI-Chat, +- psychologischer Diagnostiker, +- System, das ungesicherte Persönlichkeitsprofile als Tatsachen festschreibt. + +--- + +# 8. Technische Grundanforderungen, die fachlich bereits gesetzt sind + +Bereits vorgesehen: + +- **PWA** +- **Mobile First** +- responsive vollwertige Desktop-Nutzung +- **Offline-Fähigkeit** +- **Spracheingabe / Transkription** +- Integration in Jinkendo +- leistungsfähige externe KI darf verwendet werden + +Noch offen sind die jeweiligen technischen Ausprägungen. + +--- + +# 9. Reflection Spaces + +Ein Reflection Space ist **kein Ordner und kein Chat-Archiv**. + +Arbeitsdefinition: + +> Ein Reflection Space ist eine lebendige, laufend aktualisierte Sicht auf einen zusammenhängenden persönlichen Denk- und Erfahrungsraum. + +Er kann verbinden: + +- Dialoge, +- Threads, +- Tagebucheinträge, +- offene Fragen, +- Erkenntnisse, +- zeitliche Entwicklung, +- andere Spaces, +- mindnet-Kontext, +- bei Bedarf weitere Jinkendo-Kontexte. + +Kernnutzen: + +1. Orientierung +2. Fortsetzung +3. offene Fragen +4. Historie +5. Entwicklung + +Vorläufige sichtbare Standardansicht: + +1. **Aktueller Stand** +2. **Was ist noch offen?** +3. **Weiterdenken** +4. **Bisheriger Weg** + +Weitere Regeln: + +- Spaces können Tage/Wochen, Monate oder Jahre relevant sein. +- Bedeutung/Relevanz entscheidet, nicht eine feste Dauer. +- aktuell irrelevante Spaces dürfen aus der normalen Oberfläche zurücktreten. +- sie bleiben auffindbar und können bei erneuter Relevanz wieder auftauchen. +- nicht jeder Nebenfaden wird automatisch ein sichtbarer Space. +- die KI soll Struktur weitgehend im Hintergrund erkennen, vorschlagen, bilden und konsolidieren. +- der Autonomiegrad soll konfigurierbar sein. +- der Nutzer soll **nicht zum Administrator seiner Threads/Spaces werden**. +- falsche Zuordnung, Trennung oder Zusammenführung muss korrigierbar bleiben. +- verdichtete Space-Aussagen müssen für den Nutzer auf Quellen aufklappbar sein. + +Zusätzlich ist eine **Admin-/Developer View** vorgesehen, die interne Struktur, Provenance, Confidence, Context-Builder-Auswahl, Hypothesen und Konsolidierungsentscheidungen sichtbar machen kann. + +--- + +# 10. Dialogmodell + +Wesentliche Baseline: + +## Adaptive Entry Model + +Bevorzugte Hierarchie: + +1. **Contextual Continuation** – Default +2. **Free Reflection** +3. **Explicit Navigation** + +Das ist keine starre Navigation. Der Nutzer kann jederzeit frei beginnen oder gezielt einen früheren Kontext öffnen. + +Die Startoberfläche soll daher **kein Feature-Dashboard** sein. + +Bevorzugt: + +- ein intelligent priorisierter Hauptimpuls, +- wenige diskrete Alternativen, +- Möglichkeit zur freien Reflexion, +- Zugriff auf offene Themen/Spaces/Journal bei Bedarf. + +## Reflection Intent und Dialogführung sind getrennt + +Reflection Intent beantwortet: + +> Was möchte der Nutzer mit dieser Interaktion erreichen? + +Dialogführung beantwortet: + +> Wie soll Kanshō ihn dabei begleiten? + +Mögliche Dialogführungsformen: + +- frei erzählen / erfassen, +- adaptiver Dialog, +- geführtes Interview, +- Leitfragen/Ritualstruktur. + +Die Dialogführung darf: + +- explizit gewählt, +- zusätzlich adaptiv erkannt, +- pro Intent/Kontext gelernt + +werden. + +Explizite Nutzersteuerung hat Vorrang. + +## Dialogfäden + +Mehrere Threads können innerhalb eines Gesprächs entstehen. + +Nicht jedes Seitenthema erzeugt einen sichtbaren Thread. + +Kanshō darf: + +- Fäden intern markieren, +- sie parken, +- später wiederaufnehmen, +- Trennung vorschlagen, +- vorhandenen Kontext verknüpfen. + +Die Dialogstruktur soll unterstützen, aber den Gesprächsfluss nicht unnötig fragmentieren. + +--- + +# 11. Memory- und Context-Modell + +Ein einzelnes LLM-Kontextfenster reicht fachlich nicht aus. + +Bisheriges Schichtenmodell: + +## Working Context + +- aktuelle Nachrichten, +- aktuelle Frage, +- unmittelbare Gesprächsumgebung, +- Minuten/Stunden. + +## Thread Memory + +- Thread-Zusammenfassungen, +- offene Fragen, +- Zwischenstände, +- nicht abgeschlossene Reflexionen, +- Tage bis Monate oder länger. + +## Episodic Memory + +- bedeutsame Erfahrungen, +- Konflikte, +- Urlaubserlebnisse, +- Entscheidungen, +- Wendepunkte, +- wichtige Erkenntnisse. + +Langfristig in geeigneter Form Richtung Obsidian/mindnet. + +## Knowledge Graph / mindnet + +Langfristige Vernetzung von: + +- Erfahrungen, +- Erkenntnissen, +- Beziehungen, +- Referenzen, +- Werten, +- Entscheidungen, +- wiederkehrenden Themen, +- offenen Zusammenhängen. + +Bevorzugte Verantwortungsverteilung: + +> **Kanshō besitzt den Dialog.**
+> **mindnet besitzt das langfristige Gedächtnis.**
+> **Obsidian bildet das menschenlesbare autobiografische Archiv.** + +Technisch ist noch zu validieren, welcher Speicher Working-/Dialog-Memory übernimmt. + +--- + +# 12. Self Model, Lived Experience und digitaler Zwilling + +## Self Model + +Das Self Model kann enthalten: + +- Werte, +- Leitbild, +- Prinzipien, +- Rollen, +- langfristige Ziele, +- bestätigte Muster, +- Selbstbeschreibungen, +- wiederkehrende Spannungsfelder. + +Es muss: + +- versioniert sein, +- Herkunft kennen, +- Zeitbezug kennen, +- Beobachtung und Interpretation unterscheiden, +- nicht stillschweigend durch die KI verändert werden. + +Zentrale Grenze: + +> **Die KI darf keinen Wesenskern erfinden.** + +Neue grundlegende Muster beginnen als Hypothese und werden erst nach bewusster Bestätigung zu stabilen Self-Model-Aussagen. + +## Lived Experience / Inner-State Layer + +Die Persistenz vollständiger Kanshō-Unterhaltungen erzeugt eine zusätzliche Ebene des digitalen Zwillings. + +Nicht nur „was geschah“ oder „was wurde entschieden“ wird erhalten, sondern: + +- wie die Person zu diesem Zeitpunkt dachte, +- welche Gefühle sie beschrieb, +- Zweifel, +- Ambivalenzen, +- Alternativen, +- Denkwege, +- offene Fragen, +- damalige Sprache und Argumentation. + +Wichtige Präzisierung: + +> Kanshō speichert die **geäußerte, zeitgebundene Innenperspektive**, nicht einen behaupteten objektiven inneren Zustand. + +## Point-in-Time Self + +Zielperspektive: + +> Wie habe ich zu einem bestimmten Zeitpunkt gedacht, gefühlt, bewertet und argumentiert? + +Spätere Sichtweisen überschreiben frühere nicht. + +Widerspruch und Veränderung sind selbst wertvolle Informationen. + +## Originalquelle vor Interpretation + +Verbindliche Invariante: + +> **Rohdialog / verlässliche Originalrepräsentation = Primärquelle.**
+> Summaries, Memories, Emotionseinordnungen, Patterns und Self-Model-Aussagen = abgeleitete Schichten. + +Abgeleitete Schichten dürfen die Originalquelle nicht ersetzen. + +--- + +# 13. Context Fidelity und Re-Grounding + +Diese Invariante ist aus einem grundlegenden Langzeitrisiko entstanden. + +## Root Cause + +Langfristige Dialoge können nicht vollständig in jedem LLM-Kontext geladen werden. + +Daher entstehen Verdichtungen: + +`Originaldialog → Summary → Thread Memory → Space State → neue Zusammenfassung → weitere Interpretation` + +## Risiko + +Mehrstufige Verdichtung kann über Monate/Jahre: + +- Nuancen verlieren, +- frühere Fehlinterpretationen verstärken, +- Hypothesen zu scheinbaren Tatsachen machen, +- falsche Muster erzeugen, +- Self Model verzerren, +- biografisch falsche, aber scheinbar kohärente Narrative erzeugen. + +## Konsequenz + +Provenance allein reicht nicht. + +Kanshō muss erkennen können, wann verdichteter Kontext nicht mehr zuverlässig genug ist. + +## Re-Grounding + +Dann muss Kanshō: + +- Ursprungsquellen erneut laden, +- aktuelle Verdichtung dagegen prüfen, +- Widersprüche/Bedeutungsverschiebungen erkennen, +- Zustand ggf. neu ableiten, +- frühere Zustände und Änderungen erhalten. + +Trigger können sein: + +- viele Verdichtungsschritte, +- lange Zeit seit Quellenabgleich, +- Widerspruch, +- Space-/Thread-Merge, +- hohe persönliche Bedeutung, +- Werte/Self Model betroffen, +- geringe Confidence, +- unklare Provenance, +- Nutzerkorrektur, +- ausdrücklicher Nutzerwunsch. + +Nutzer soll ausdrücklich sagen können: + +> „Prüfe noch einmal den ursprünglichen Kontext.“ + +Die konkrete technische Fidelity-/Drift-Metrik ist bewusst noch offen. + +--- + +# 14. Thread Resurfacing und Reflection Saturation + +Diese beiden Konzepte sind querschnittliche Invarianten. + +## Thread Resurfacing + +Frage: + +> **Wann soll ein früheres oder offenes Thema wieder aktiv relevant werden?** + +Trigger: + +1. explizite Nutzeranfrage – z. B. „Was ist noch offen?“ +2. zeitlicher/örtlicher Kontext +3. neues Erlebnis im gleichen Kontext +4. explizit gesetzter Wiedervorlageanker +5. semantische Reaktivierung +6. aktueller Bezug zu einem Reflection Space + +Beispiel: + +Ein Urlaubsthema kann während des Urlaubs aktiv relevant sein und noch eine begrenzte Rückschauphase danach besitzen, ohne danach „vergessen“ zu werden. + +Verbindliche Trennung: + +> **Memory ≠ Current Relevance** + +Langfristig gespeichert bedeutet nicht, dass ein Thema im Alltag ständig wieder angeboten werden soll. + +## Reflection Saturation + +Frage: + +> **Ist für die aktuelle Sitzung wahrscheinlich ausreichend gesagt beziehungsweise verstanden worden?** + +Mögliche Signale: + +- Reflection Intent, +- expliziter Nutzerwunsch, +- individuelle typische Dialogtiefe, +- Umfang/Tiefe vergleichbarer Reflexionen, +- Abdeckung aktiver Themen, +- offene Randthemen, +- sinkender zusätzlicher Erkenntnisgewinn, +- Gesprächssignale. + +Verbindliche Regel: + +> **Kanshō darf Abschlussreife erkennen und anbieten, aber der Nutzer entscheidet über Weiterführen, Vertiefung, Wiedervorlage oder Abschluss.** + +Fachliche Thread-Zustände als Baseline, noch kein technisches State Model: + +- Active +- Open +- Anchored / Resurface +- Dormant +- Resolved + +--- + +# 15. Writing Profile und Journalgenerierung + +Ziel: + +> Von Kanshō erzeugte Texte sollen auch nach Jahren vertraut wirken und sich wie eigene Texte lesen. + +Writing Profile kann unter anderem lernen: + +- Satzlängen und Rhythmus, +- Wortwahl, +- typische Formulierungen, +- Detailgrad, +- Erzählstruktur, +- Verhältnis Erleben/Reflexion, +- emotionale Direktheit, +- Übergänge, +- Humor, +- Perspektive, +- zeitliche Erzählweise. + +Eigene frühere Texte sollen als Stilreferenzen dienen. + +Das Writing Profile muss zeitlich/versioniert gedacht werden, weil sich persönlicher Stil entwickeln kann. + +## Zweistufige Journalgenerierung + +Bevorzugtes Modell: + +### Stufe 1 – Inhalt/Bedeutung rekonstruieren + +Klären: + +- Was ist tatsächlich passiert? +- Was wurde ausdrücklich gesagt? +- Was wurde empfunden? +- Welche Erkenntnisse entstanden? +- Was ist Interpretation/Hypothese? +- Was gehört in den Eintrag? + +### Stufe 2 – persönliche Narration + +Erst danach wird aus bestätigtem Inhalt ein Text erzeugt unter Nutzung von: + +- Writing Profile, +- passenden eigenen Texten, +- Kontext, +- gewünschtem Detailgrad, +- zeitlicher Perspektive. + +Dadurch werden **Inhaltstreue und Stil getrennt**. + +Day One im vom Nutzer genannten „Gold“-Abo ist expliziter Benchmark-Rahmen für spätere Journaling-Funktionsanalyse. Produktbezeichnung und aktuelle Features sind beim Benchmark erneut zu verifizieren. + +--- + +# 16. Reflection Intelligence + +## Reflection Frontiers + +mindnet kann offene, noch nicht verstandene Beziehungsketten enthalten. + +Beispiele: + +- Ereignis + Reaktion, Ursache/Bedeutung offen, +- Wert steht in Spannung zu Entscheidung, +- wiederkehrende ähnliche Erlebnisse ohne bestätigtes Muster, +- unvollständige frühere Reflexion. + +Kanshō darf solche **Reflection Frontiers** bei passender Relevanz wieder aufnehmen. + +Dabei: + +- keine zwanghafte Wiederholung, +- keine erfundene Kausalität, +- keine Hypothese als Fakt. + +## Beobachtung / Interpretation / Hypothese + +Kanshō muss fachlich unterscheiden zwischen: + +- Fakten/Quellen, +- expliziten Nutzeraussagen, +- bestätigten Erkenntnissen, +- Interpretation, +- Hypothese, +- vermuteter Beziehung, +- offener Frage. + +Kausalität darf nicht leichtfertig behauptet werden. + +--- + +# 17. Privacy / External AI Guardrails + +Die lokale Infrastruktur reicht derzeit nicht als alleinige Basis für leistungsfähige große KI-Modelle. + +Externe Inferenz, insbesondere über Dienste wie OpenRouter, ist deshalb grundsätzlich vorgesehen. + +Gleichzeitig verarbeitet Kanshō hochsensible autobiografische und dialogische Daten. + +Zentrale Architektur-Invariante: + +> **Identität bleibt lokal. Externe Intelligenz erhält nur den notwendigen, minimierten und soweit sinnvoll pseudonymisierten Kontext.** + +## Privacy Gateway + +Persönliche externe AI-Aufrufe dürfen nicht direkt aus Kanshō-Komponenten zum Provider gehen. + +Dazwischen liegt fachlich eine lokale Privacy-/Egress-Schicht mit: + +- Context Minimization, +- Entity Detection, +- Pseudonymisierung, +- Policy Check, +- Provider-/Endpoint-Eligibility, +- Egress Validation, +- Response Validation, +- lokaler Rehydration/Demasking, +- Audit-Metadaten, +- Fail-Closed-Handling. + +## Datenklassen + +Baseline: + +- **A – Local Only** +- **B – Pseudonymized AI Context** +- **C – Low-Identity / Non-identifying Context** + +## Pseudonyme + +Beispiele: + +- `[[SELF]]` +- `[[PERSON:PARTNER]]` +- `[[PERSON:CHILD_01]]` +- `[[ORG:EMPLOYER]]` +- `[[PLACE:HOME_CITY]]` + +Regeln: + +- Mapping bleibt ausschließlich lokal. +- keine unnötig sprechenden Aliase. +- relevante Pseudonyme sollen ausreichend stabil sein. +- Demasking findet ausschließlich lokal statt. + +## Re-Identifikation + +Nur Namen zu entfernen reicht nicht. + +Auch Quasi-Identifikatoren müssen berücksichtigt werden: + +- seltene berufliche Rolle, +- konkreter Ort, +- Alter, +- Familienstruktur, +- seltene Ereignisse, +- Kombination mehrerer Merkmale. + +Das Ziel ist **Pseudonymisierung + Datenminimierung**, nicht die falsche Behauptung vollständiger Anonymität. + +## Provider Policy + +Für persönliche Kontexte gilt als Baseline: + +- Zero Data Retention / funktional gleichwertige Policy grundsätzlich erforderlich, +- kein freiwilliges Prompt-/Response-Logging, +- keine Freigabe für Training/Produktverbesserung, +- EU-/Region-Routing bevorzugt beziehungsweise später policyabhängig erzwingbar, +- kein stiller Fallback auf weniger geschützte Provider, +- Tool-/Web-Egress benötigt eigene Policy, +- Response wird vor Demasking lokal geprüft. + +Guardrails haben Vorrang vor: + +- Modellqualität, +- Kosten, +- Latenz, +- Komfort. + +--- + +# 18. Typische Nutzungssituationen + +Die Typologie gilt als **vorläufig vollständig, aber erweiterbar**: + +1. **Erleben festhalten** +2. **Tagesreflexion** +3. **Spontaner Gedanke / Moment** +4. **Früheren Faden fortsetzen** +5. **Tiefe Reflexion / biografische Frage** +6. **Entscheidung / Orientierung** +7. **Inspiration / Vision / Kreativität** +8. **Achtsamkeit / Meditation / Check-in** +9. **Rückblick und persönliche Entwicklung** +10. **Geplante Reflexionszeit / Ritual** +11. **Wiederfinden und Revue passieren** + +Wichtige Unterscheidung: + +- **Nachschlagen:** „Was war damals?“ – hohe Quellenorientierung, geringe Interpretation. +- **Revue passieren:** „Wie war diese Zeit für mich?“ – kuratierter Erlebnisrückblick. +- **Entwicklungsrückblick:** „Was hat sich seit damals verändert?“ – zeitliche persönliche Entwicklung. + +Intent-Wechsel innerhalb eines Dialogs sind erlaubt und vorgesehen. + +--- + +# 19. Nutzungssituation „Erleben festhalten“ + +Status: + +> **vorläufig ausreichend geklärt** + +Wesentliche Baseline: + +- authentisches Erleben festhalten, +- darf frei, fragmentarisch und nicht chronologisch erfolgen, +- Text oder Sprache, +- kann als adaptiver Dialog oder Interview unterstützt werden, +- Kanshō ist Dialogpartner, nicht nur Editor eines fertigen Textes, +- tiefe Reflexion darf angeboten werden, aber nicht erzwungen werden, +- „nur festhalten“ muss möglich sein, +- Journal Entry ist ein Ergebnis des Prozesses, nicht zwingend die Eingabeform, +- Kanshō darf intern Personen, Ereignisse, Reihenfolge, Stimmungen und Threads erkennen, +- es darf keine Chronologie erfinden, wenn sie nicht zuverlässig rekonstruierbar ist, +- Dialogpräferenzen sollen pro Intent/Kontext lernbar sein und durch explizite Nutzersteuerung überstimmt werden können. + +Spätere Konkretisierung erfolgt in Journaling-, Dialog- und UX-Kapiteln. + +--- + +# 20. Nutzungssituation „Tagesreflexion“ – aktueller Stand + +Dies ist der **aktive Interviewblock**. + +Bereits entschieden beziehungsweise als fachliche Baseline akzeptiert: + +## Dynamik statt Fragebogen + +Die Tagesreflexion basiert nicht auf einem festen Standard-Fragenkatalog. + +Prinzip: + +> **Tiefe vor Vollständigkeit. Relevanz vor Routine.** + +Typischerweise soll **ein guter persönlich relevanter Impuls** genügen, um die Reflexion zu öffnen. + +Kanshō soll vermeiden: + +- generische Journaling-Fragen ohne Kontext, +- mechanische Frageketten, +- häufige Wiederholungen, +- Fragen, deren Antwort bereits bekannt ist, +- künstlich „tiefe“ Fragen ohne echten Bezug. + +## Anpassung an Denk- und Antwortstil + +Kanshō soll nicht nur den Schreibstil lernen, sondern auch die Art, wie der Nutzer reflektiert. + +Relevant sind beispielsweise: + +- Direktheit, +- Tiefe, +- analytisch vs. offen, +- Fragenlänge, +- Umgang mit Ambivalenz, +- Geschwindigkeit Beschreibung → Interpretation, +- Rhythmus Frage / Spiegelung / Raum. + +## Priorisierung + +Grundsatz: + +> **Der aktuelle Tag beziehungsweise das aktuelle Erleben hat Vorrang.** + +Reihenfolge: + +1. explizite aktuelle Nutzerintention +2. aktueller Tages-/Erlebniskontext +3. frühere Themen mit erkennbarem aktuellem Bezug +4. sonstige offene historische Threads nur bei passendem Anlass oder expliziter Anfrage + +Ein Thema wird **nicht** nur deshalb hervorgeholt, weil es noch offen ist. + +## Hauptimpuls + Fokuswahl + +Default: + +- ein intelligent priorisierter Hauptimpuls, +- wenige diskrete Alternativen. + +Zusätzlich kann der Nutzer einen erweiterten **Katalog aktuell relevanter Reflexionsgegenstände** öffnen und den Fokus aktiv verschieben. + +Dieser Katalog ist **kein Fragenkatalog**. + +Mögliche Kandidaten: + +- heutige Erlebnisse, +- auffällige Momente, +- offene Gedanken, +- relevante frühere Threads, +- markierte Themen, +- aktuelle Reflection Spaces, +- geplante Reflexionsgegenstände. + +Explizite Nutzerwahl hat Vorrang. + +## Wiedervorlage + +Der Nutzer kann sagen: + +- „Morgen weiter.“ +- „Später nochmal.“ +- „Beim nächsten Tagesrückblick darauf zurückkommen.“ +- „Nächste Woche wieder aufnehmen.“ + +Das erzeugt fachlich eine **Wiedervorlage des bestehenden Threads**, nicht automatisch einen Kairo-Task oder neuen Space. + +Explizite Wiedervorlage hat höhere Priorität als rein algorithmisch offene Threads, aber die jeweils aktuelle Nutzerintention bleibt höher. + +## Resurfacing + +Wiederauftauchen eines Themas kann ausgelöst werden durch: + +- explizites Nachfragen, +- Zeit/Ort, +- nächstes Erlebnis im gleichen Kontext, +- gesetzten Anker, +- semantische Reaktivierung. + +Beispiel des Nutzers: + +Ein Urlaubsthema ist während des Urlaubs aktiv relevant und kann noch eine begrenzte Rückschauphase danach besitzen. Danach bleibt es gespeichert, soll aber nicht ungefragt ständig auftauchen. + +## Tiefe und Abschlussreife + +Akzeptiertes fachliches Modell: + +- die Tiefe ist Intent-abhängig, +- Kanshō darf aus dem persönlichen Muster vergleichbarer Reflexionen lernen, +- Umfang allein ist kein Completion-Kriterium, +- offene Haupt- und Randthemen können intern mitgeführt werden, +- sinkender Erkenntnisgewinn kann ein Saturation-Signal sein, +- der Nutzer darf das Gespräch jederzeit selbst beenden, +- Kanshō darf bei erkennbarer Saturation einen Abschluss anbieten, +- es soll die Sitzung nicht eigenmächtig als psychologisch „abgeschlossen“ erklären. + +### Dokumentationshinweis + +`usage_situations.md` enthält noch zwei ältere offene Bulletpoints zur Erkennung geringer Tiefe und zu unscharfen Wiedervorlagen. Der aktuellere fachliche Stand ist in `resurfacing_and_saturation.md` und im aktuellen `interview_plan.md` abgebildet. + +Bei der nächsten Änderung von `usage_situations.md` diese Statusdifferenz **additiv bereinigen**, ohne den früheren Kontext zu verlieren. + +--- + +# 21. Aktueller Output-Stand + +`reflection_outputs.md` kennt bisher vier Output-Arten: + +## Journal Entry + +Menschenlesbarer autobiografischer Text. + +Ziel: + +- primär Obsidian, +- damit indirekt mindnet. + +## Reflection Memory + +Verdichtete, nachvollziehbare Erkenntnis. + +Ziel: + +- mindnet. + +## Knowledge Delta + +Neue oder geänderte Beziehung im persönlichen Wissensnetz, beispielsweise: + +- neue Verbindung, +- korrigierte frühere Annahme, +- neue Hypothese. + +Ziel: + +- mindnet. + +## Action Candidate + +Aus Reflexion entstandene Handlungsabsicht. + +Ziel: + +- Kairo. + +Kanshō bietet die Übernahme an, wird aber nicht zum Aufgabenmanager. + +--- + +# 22. Tagesreflexion: bestätigter Stand zu Abschluss und Kontinuität + +Der Abschluss- und Kontinuitätsblock wurde in der aktuellen Session weitergeführt. Die folgenden Punkte sind **entschieden** und bilden den aktuellen Aufsatzpunkt. + +## Abschluss einer Sitzung + +Drei Wege: + +### A. Expliziter Abschluss durch Nutzer + +Höchste Priorität. + +Beispiele: + +- „Das reicht für heute.“ +- „Ich bin fertig.“ +- „Lass uns morgen weitermachen.“ + +Wichtig: + +Eine Session kann enden, obwohl ein Thread offen bleibt. + +### B. Reflection Saturation + +Kanshō erkennt: + +- Hauptthemen ausreichend bearbeitet, +- offene Nebenpunkte geklärt oder geankert, +- wenig zusätzlicher Erkenntnisgewinn, +- Antworten beginnen sich zu wiederholen. + +Dann soll es einen Abschluss **anbieten**, nicht erzwingen. + +### C. Natürlicher Gesprächsauslauf + +Kanshō darf einen kurzen Intent auch kurz bleiben lassen und soll keine künstlichen Folgefragen erzeugen. + +## Sichtbarer Abschluss + +Normalerweise möglichst wenig UI-Komplexität. + +Beispiel: + +- kurzer Abschlussgedanke / Spiegelung, +- ggf. offener Punkt, +- ggf. gesetzte Wiedervorlage, +- wenige Aktionen wie: + - Tagebucheintrag ansehen/erstellen, + - morgen weiter, + - noch vertiefen. + +Der sichtbare Abschluss ist adaptiv und möglichst leicht. Eine substanzielle Tagesreflexion erhält grundsätzlich einen kurzen persönlichen Abschlussgedanken oder eine knappe Spiegelung. Ein kurzer oder natürlich ausgelaufener Dialog darf mit einer schlichten Bestätigung enden. Es gibt keinen obligatorischen Ergebnisbildschirm und keine Abschluss-Checkliste. + +## Verbindliche Architekturregel + +> **Session Lifecycle ≠ Thread Lifecycle** + +Eine Sitzung kann enden, während ein Thread: + +- Open, +- Anchored, +- Dormant + +bleibt. + +Diese Trennung ist ausdrücklich entschieden. Das Session-Ende setzt einen beteiligten Thread nicht automatisch auf `Resolved`. Die bisher benannten Thread-Zustände sind eine nicht abschließende fachliche Baseline; weitere Zustände und Metainformationen bleiben später zu prüfen. + +## Kein zwingendes Ergebnisartefakt + +Eine Tagesreflexion muss kein Journal, keine Erkenntnis, kein Knowledge Delta und keine Handlungsabsicht erzeugen, um fachlich sinnvoll zu sein. Der primäre Wert kann im Wahrnehmen, Aussprechen, Reflektieren, vorläufigen Einordnen oder bewussten Offenlassen liegen. + +Davon getrennt bleibt interne Kontinuitätsarbeit notwendig: + +- Originaldialog beziehungsweise verlässliche Originalrepräsentation als Primärquelle, +- quellengebundene Summaries sowie Working Context und Thread Memory, +- relevante Erkenntnisse, offene Fragen und mögliche Nebenfäden mit vorläufigem Status, +- tatsächliche Thread-Änderungen und Wiedervorlageanker, +- Zeitbezug, Provenance und Unsicherheit. + +Kontinuitätsarbeit ist eine laufende Systemverantwortung und nicht an das Session-Ende gebunden. Das Session-Ende ist lediglich ein zusätzlicher Prüfpunkt. Es erzwingt weder eine neue Verdichtung noch ein sichtbares oder internes Ergebnisartefakt. + +Summaries und andere Verdichtungen ersetzen nicht die Originalquelle. Bei Drift, Abweichung, Widerspruch, möglicher Fehlinterpretation oder ausdrücklichem Nutzerwunsch gilt automatisches beziehungsweise nutzerinitiiertes Re-Grounding gemäß `context_fidelity_and_regrounding.md`. + +## Nicht übernommene frühere Output-Hypothese + +Die frühere Dreiteilung `Session Output / Narrative Output / Long-Term Output` ist **nicht als abschließendes Output-Modell entschieden**. Sie darf insbesondere nicht dazu führen, dass jede Reflexion ein Ergebnis produzieren muss oder Kanshō primär als Wissens- und Artefaktsystem verstanden wird. + +--- + +# 23. Exakter nächster Interviewschritt + +Die neue Session soll **nicht** mit einer allgemeinen Projektfrage beginnen. + +Sie soll direkt fortsetzen bei: + +> **Tagesreflexion – Abschluss und Outputs** + +Zu entscheiden beziehungsweise zu bestätigen sind: + +1. Welche Inhalte verbleiben als quellengebundene Kontinuitätsstruktur und wann werden daraus Reflection Memory, Knowledge Delta oder andere langfristige Ableitungen? +2. Nach welchen Kriterien entstehen Reflection Memory, Knowledge Delta und Action Candidate tatsächlich? +3. Wann wird ein Journal Entry: + - automatisch vorbereitet, + - angeboten, + - bewusst nicht erzeugt? + +Erst **nach** vorläufigem Abschluss dieser Punkte wird die Tagesreflexion fachlich geschlossen. + +Danach folgt: + +> **Nutzungssituation 3 – Spontaner Gedanke / Moment** + +--- + +# 24. Aktueller Interviewfortschritt + +| Themenbereich | Status | +|---|---| +| Produktvision | weitgehend geklärt; später präzisierbar | +| Produktidentität | weitgehend entschieden | +| Produktgrenzen | weitgehend entschieden | +| Reflection Spaces | Baseline vorläufig ausreichend geklärt | +| Nutzungstypologie | 11 Situationen als vorläufig vollständige Baseline | +| Erleben festhalten | vorläufig ausreichend geklärt | +| Tagesreflexion | in Bearbeitung; Session-/Thread-Trennung, natürlicher sichtbarer Abschluss, kein zwingendes Ergebnisartefakt und laufende Kontinuitätsarbeit entschieden | +| Dialogmodell | wesentliche Baseline vorhanden | +| Threads | Grundmodell vorhanden; technisches State Model offen | +| Thread Resurfacing | entschieden | +| Reflection Saturation | entschieden; technische Berechnung offen | +| Memory Architecture | erstes Schichtenmodell vorhanden | +| Context Fidelity / Re-Grounding | Root Cause + Invariante entschieden | +| Self Model | erste verbindliche Prinzipien | +| Lived Experience / Point-in-Time Self | entschieden | +| Writing Profile | erste Prinzipien | +| Reflection Frontiers | Konzept vorhanden | +| Journaling | Kernanforderungen + zweistufige Generierung | +| Meditation | grob | +| Achtsamkeit | grob | +| UX | Leitplanken, Details offen | +| Voice/Transkription | Anforderung vorhanden | +| Offline | Anforderung vorhanden | +| Integrationen | Produktgrenzen vorhanden; technische Contracts offen | +| Guardrails / Privacy Gateway | fachliche Baseline entschieden | +| AI Architecture | offen | +| Data Architecture | offen | +| Security/Privacy Detailarchitektur | offen | +| MVP | offen | + +--- + +# 25. Kanonische aktive Dateien + +Alle folgenden Pfade sind relativ zum Repository Root `C:\dev\Kansho`. + +| Datei | Kanonisches Thema | +|---|---| +| `docs/architecture/functional/handover.md` | Session-Bootstrap / aktueller Arbeitsstand | +| `docs/architecture/functional/fachliche_zielarchitektur.md` | Governance, Dokumentationsprinzipien, Querschnittsinvarianten | +| `docs/architecture/functional/produktvision_und_produktidentitaet.md` | Vision, Identität, Scope, Produktprinzipien | +| `docs/architecture/functional/documentation_index.md` | Context Bundles / Ladeplan | +| `docs/architecture/functional/interview_plan.md` | Interviewmethode, Fortschritt, Next Step | +| `docs/architecture/functional/usage_situations.md` | Nutzungssituationen / Tagesreflexion | +| `docs/architecture/functional/reflection_spaces.md` | Reflection Contexts / Spaces | +| `docs/architecture/functional/dialogue_model.md` | Entry / Intent / Dialogführung / Threads | +| `docs/architecture/functional/memory_and_context.md` | Working, Thread, Episodic Memory / mindnet | +| `docs/architecture/functional/resurfacing_and_saturation.md` | Wiedervorlage / Relevanz / Saturation | +| `docs/architecture/functional/context_fidelity_and_regrounding.md` | Drift / Provenance / Re-Grounding | +| `docs/architecture/functional/self_model_and_lived_experience.md` | Self Model / Point-in-Time Self / Digital Twin | +| `docs/architecture/functional/writing_profile_and_journaling.md` | Writing Profile / Journalgenerierung | +| `docs/architecture/functional/reflection_intelligence.md` | Reflection Frontiers / Hypothesen / Kausalität | +| `docs/architecture/functional/reflection_outputs.md` | Journal / Memory / Knowledge / Action Outputs | +| `docs/architecture/functional/integrations.md` | Jinkendo-Grenzen / Übergaben | +| `docs/architecture/functional/guardrails.md` | Privacy Gateway / Pseudonymisierung / External AI | +| `docs/architecture/functional/migration_mapping.md` | Mapping und Integritätsaudit | + +Archivierte Dokumente außerhalb dieses aktiven Satzes gehören **nicht** zum normalen Arbeitskontext. + + +--- + +# 26. Empfohlenes Context Bundle für die neue Session + +Die neue Session soll zunächst **direkt aus dem eingebundenen Repository** lesen. + +Zuerst vollständig laden: + +1. `docs/architecture/functional/handover.md` + +Für den aktuellen Interviewblock anschließend laden: + +2. `docs/architecture/functional/fachliche_zielarchitektur.md` +3. `docs/architecture/functional/produktvision_und_produktidentitaet.md` +4. `docs/architecture/functional/interview_plan.md` +5. `docs/architecture/functional/usage_situations.md` +6. `docs/architecture/functional/reflection_outputs.md` +7. `docs/architecture/functional/resurfacing_and_saturation.md` + +Nur wenn eine konkrete Entscheidung es benötigt zusätzlich: + +- `docs/architecture/functional/dialogue_model.md` +- `docs/architecture/functional/writing_profile_and_journaling.md` +- `docs/architecture/functional/memory_and_context.md` + +Nicht vorsorglich alle Kanshō-Dateien laden. + +Ziel der Aufteilung ist ausdrücklich, den aktiven Kontext klein genug zu halten, ohne fachliche Informationen zu verlieren. + + +--- + +# 27. Context Bundles für spätere Themen + +## Memory / digitaler Zwilling + +- Root-Dokumente +- `docs/architecture/functional/memory_and_context.md` +- `docs/architecture/functional/self_model_and_lived_experience.md` +- `docs/architecture/functional/context_fidelity_and_regrounding.md` +- `docs/architecture/functional/guardrails.md` + +## Dialogarchitektur + +- Root-Dokumente +- `docs/architecture/functional/dialogue_model.md` +- `docs/architecture/functional/usage_situations.md` +- `docs/architecture/functional/reflection_spaces.md` +- `docs/architecture/functional/resurfacing_and_saturation.md` + +## Integrationen + +- Root-Dokumente +- `docs/architecture/functional/integrations.md` +- `docs/architecture/functional/reflection_outputs.md` +- betroffenes Fachkapitel + +## Privacy / externe KI + +- `docs/architecture/functional/fachliche_zielarchitektur.md` +- `docs/architecture/functional/guardrails.md` +- `docs/architecture/functional/self_model_and_lived_experience.md` +- `docs/architecture/functional/memory_and_context.md` +- betroffenes Technik-/Integrationskapitel + +--- + +# 28. Vorgehen bei Dokumentänderungen in der neuen Session + +Wenn eine Entscheidung getroffen wird: + +1. Bestimme das **kanonische Home** unter `docs/architecture/functional/`. +2. Lies das relevante bestehende Kapitel ausreichend vollständig. +3. Prüfe vorhandene Root Causes, Beispiele, Status und Querverweise. +4. Ergänze die Entscheidung **additiv**. +5. Entferne ältere Inhalte nicht stillschweigend. +6. Aktualisiere Entscheidungsstatus. +7. Aktualisiere `docs/architecture/functional/interview_plan.md`, wenn sich der Fortschritt ändert. +8. Aktualisiere Root-Dokumente nur bei echter querschnittlicher Invariante. +9. Prüfe betroffene andere Fachkapitel auf Widerspruch. +10. Bei Themenwechsel Drift-Audit durchführen. +11. Wenn Read/Write-Zugriff besteht, bearbeite die **kanonische Repository-Datei direkt** statt eine neue Chat-Kopie zu erzeugen. +12. Lies die geänderten Passagen nach der Bearbeitung nochmals und prüfe, ob frühere Informationen erhalten geblieben sind. +13. Nenne dem Nutzer anschließend: + - welche Repository-Dateien geändert wurden, + - welche fachlichen Entscheidungen ergänzt wurden, + - ob Querschnittsdokumente angepasst wurden, + - welche offenen Punkte verbleiben. + +Keine parallele Datei außerhalb des Repositorys soll zur neuen Source of Truth werden. + + +--- + +# 29. Verhalten im Konzeptdialog + +Die neue Session soll: + +- auf Deutsch arbeiten, +- präzise und kritisch sein, +- keine bereits beantworteten Fragen wiederholen, +- bei offenen Punkten einen konkreten Vorschlag machen, +- Entscheidungen gemeinsam mit dem Nutzer schrittweise festziehen, +- technische Details nicht zu früh festlegen, +- langfristige Konsequenzen trotzdem früh sichtbar machen, +- wichtige Root Causes dokumentieren, +- nicht versuchen, die interne Architektur aus Implementierungsbequemlichkeit klein zu halten. + +Wenn ein Nutzerbeitrag bereits eine klare Entscheidung enthält, diese nicht unnötig erneut bestätigen lassen, sondern dokumentieren und zum nächsten echten offenen Punkt wechseln. + +--- + +# 30. Bootstrap-Anweisung für eine neue Chat-Session + +Wenn dieses Dokument in einer neuen Session geladen wird, soll die Session sinngemäß so weiterarbeiten: + +> Wir setzen die fachliche Konzeption von Kanshō fort. +> +> Das aktive Kanshō-Git-Repository ist als Read/Write-Quelle eingebunden. +> +> Aktueller lokaler Repository Root: +> +> `C:\dev\Kansho` +> +> Die **aktive und alleinige fachliche Source of Truth** liegt repository-relativ unter: +> +> `docs/architecture/functional/` +> +> Verwende für fachliche Verweise grundsätzlich repository-relative Pfade. Der absolute Windows-Pfad ist nur die aktuelle lokale Einbindung. +> +> Lies zuerst vollständig: +> +> `docs/architecture/functional/handover.md` +> +> und anschließend die dort für den aktuellen Arbeitsschritt angegebenen kanonischen Dateien. +> +> Verwende keine älteren archivierten Dokumente, Chat-Artefakte oder früher erzeugten Download-Kopien als aktive Grundlage. +> +> Wenn wir im Konzeptdialog Entscheidungen treffen und Schreibzugriff besteht, aktualisiere ausschließlich die jeweils zuständige kanonische Datei unter `docs/architecture/functional/`. Erzeuge keine parallele Ersatzkopie als neue Source of Truth. +> +> Erhalte Entscheidungen, Root Causes, Beispiele, Einschränkungen und offene Punkte vollständig; keine stillschweigende Verdichtung. +> +> Der aktive Interviewblock ist **Tagesreflexion – Abschluss und Outputs**. +> +> Beginne nicht mit einer allgemeinen Projektzusammenfassung oder einer bereits beantworteten Frage. Setze direkt bei der noch offenen Abgrenzung zwischen quellengebundener Kontinuitätsstruktur und optionalen langfristigen Ableitungen an. +> +> Vor der ersten fachlichen Frage bestätige kurz: +> 1. welche kanonischen Repository-Dateien für diesen Schritt gelesen wurden, +> 2. was bereits entschieden ist, +> 3. welcher konkrete Punkt noch offen ist. +> +> Danach unmittelbar im Konzeptdialog fortfahren. + + +--- + +# 31. Integritätsreferenz des aktiven Split-Standes + +Die beim Split erzeugte `manifest.json` enthält Dateigrößen und SHA-256-Werte der aktiven Dateien sowie die Prüfsummen der vollständigen Ausgangs-Checkpoints. + +Diese Referenz dient nur der technischen Verifikation und nicht als fachlicher Inhalt. + +Wichtig: + +> Wenn später ein Dokument in Gitea bewusst geändert wird, ändert sich natürlich seine Prüfsumme. Das ist normal. Die Manifest-Werte kennzeichnen den initialen verlustfrei migrierten Split-Stand. + +--- + +# 32. Kurzform des aktuellen Arbeitsauftrags + +**Repository:** `C:\dev\Kansho`
+**Kanonische Fachdateien:** `docs/architecture/functional/`
+**Arbeitsmodus:** kanonische Dateien direkt lesen/schreiben; keine parallelen Chat-Kopien als Source of Truth
+**Aktives Thema:** Tagesreflexion
+**Status:** fast fachlich abgeschlossen
+**Nächste Entscheidung:** Kontinuitätsstrukturen vs. optionale langfristige Ableitungen
+**Danach:** Spontaner Gedanke / Moment
+**Entschiedene Architekturregel:** `Session Lifecycle ≠ Thread Lifecycle`
+**Entschieden:** kein zwingendes Ergebnisartefakt; laufende, quellengebundene Kontinuitätsarbeit mit Re-Grounding
+**Output-Frage:** Kriterien für Reflection Memory, Knowledge Delta und Action Candidate
+**Journal-Frage:** automatisch vorbereiten vs. anbieten vs. nicht erzeugen
+**Dokumente primär zu ändern:** `usage_situations.md`, `reflection_outputs.md`, `memory_and_context.md`, `interview_plan.md`. + +--- + +# 33. Abschluss + +Dieses Handover markiert den bewussten Wechsel aus der langen bisherigen Konzept-Session in eine neue Arbeits-Session. + +Der fachliche Stand ist nicht „neu zu rekonstruieren“. + +Er ist bereits dokumentiert. + +Die nächste Session soll daher: + +> **kanonische Repository-Dateien lesen → an der markierten offenen Stelle fortsetzen → entscheiden → direkt im kanonischen Repository dokumentieren → geänderten Inhalt prüfen → Drift prüfen.** diff --git a/docs/architecture/functional/interview_plan.md b/docs/architecture/functional/interview_plan.md index f023acc..e949294 100644 --- a/docs/architecture/functional/interview_plan.md +++ b/docs/architecture/functional/interview_plan.md @@ -869,6 +869,8 @@ Die unmittelbar nächste Sequenz sollte lauten: Diese Reihenfolge verhindert, dass technische Entscheidungen zu früh getroffen werden, bevor klar ist, welches Verhalten das Produkt tatsächlich benötigt. +Parallel existiert seit 2026-08-19 eine **vorläufige technische Rahmenarchitektur** unter `docs/architecture/technical/` (Produktrahmen analog Mitai). Sie ersetzt Phasen F–G und I nicht. **Privacy Gateway und Guardrails** sind fachlich bereits Invariante (`guardrails.md`) und technisch bindend; Phase H vertieft Encryption, Löschen, Transparenz und Safety, ohne diese Invariante zu öffnen. + --- ## 6. Interviewmethode @@ -948,7 +950,7 @@ Technische Kapitel erhalten zusätzlich: | Reflection Spaces | fachliche Baseline vorläufig ausreichend geklärt; spätere Konkretisierung aus Dialog-, UX- und Memory-Kapiteln vorgesehen | | Nutzungssituationen | Typologie mit elf Situationen als vorläufig vollständige Baseline festgelegt | | Erleben festhalten | vorläufig ausreichend geklärt | -| Tagesreflexion | in Bearbeitung; Einstieg, Priorisierung, Fokuswahl, adaptive Tiefe, Wiedervorlage und Resurfacing weitgehend geklärt | +| Tagesreflexion | in Bearbeitung; Einstieg, Priorisierung, Fokuswahl, adaptive Tiefe, Wiedervorlage, Resurfacing und Trennung von Session-/Thread-Lebenszyklus geklärt | | Dialogmodell | wesentliche Baseline vorhanden; weitere Nutzungssituationen noch auszuarbeiten | | Threads | Grundmodell vorhanden; technisches State Model bewusst offen | | Thread Resurfacing | querschnittliches Fachkonzept entschieden | @@ -992,16 +994,28 @@ Bereits geklärt sind insbesondere: - Thread Resurfacing als querschnittliches Konzept, - Reflection Saturation als Erkennung von möglicher Abschlussreife, - der Nutzer behält das letzte Wort über Weiterführen, Vertiefung, Wiedervorlage und Abschluss. +- `Session Lifecycle ≠ Thread Lifecycle` als verbindliche Architekturregel; ein Session-Ende löst offene Threads nicht automatisch auf. +- die bisher benannten Thread-Zustände sind eine nicht abschließende fachliche Baseline; weitere Zustände und Metainformationen bleiben im späteren Thread-/Datenmodell zu prüfen. ### Als Nächstes: Abschluss und Outputs der Tagesreflexion +Im aktuellen Block wurde entschieden: + +- Die Session und ihre Threads besitzen getrennte Lebenszyklen. +- Eine Session darf explizit durch den Nutzer, nach einer angenommenen Abschlussanregung bei Reflection Saturation oder durch natürlichen Gesprächsauslauf enden. +- Das Session-Ende bedeutet nicht automatisch `Resolved` für beteiligte Threads. +- Der sichtbare Abschluss ist adaptiv und möglichst leicht: kurzer persönlicher Abschlussgedanke bei substanziellen Reflexionen, schlichte Bestätigung bei kurzen oder natürlich ausgelaufenen Dialogen. +- Offene Punkte, Wiedervorlagen und wenige Anschlussmöglichkeiten erscheinen nur kontextuell; es gibt keinen obligatorischen Ergebnisbildschirm und keine Abschluss-Checkliste. +- Eine Tagesreflexion muss kein Ergebnisartefakt erzeugen. Der primäre Wert kann im Reflexions- beziehungsweise Achtsamkeitserleben selbst liegen. +- Davon getrennt bleibt interne Kontinuitätsarbeit notwendig: Originalquelle, quellengebundene Summaries beziehungsweise Thread Memories, relevante Erkenntnisse, offene Fragen, mögliche Nebenfäden und tatsächliche Thread-Änderungen werden angemessen erhalten. +- Interne Verdichtungen ersetzen die Originalquelle nicht. Bei Drift, Abweichung, möglicher Fehlinterpretation oder Nutzeranforderung gilt automatisches beziehungsweise nutzerinitiiertes Re-Grounding gemäß `context_fidelity_and_regrounding.md`. +- Kontinuitätsarbeit ist eine laufende Systemverantwortung und nicht an das Session-Ende gebunden. Das Session-Ende dient als zusätzlicher Prüfpunkt; nur tatsächliche Änderungen werden fortgeschrieben, ohne Erkenntnisse, Nebenfäden oder sichtbare Outputs zu erzwingen. + Noch fachlich zu entscheiden beziehungsweise zu bestätigen sind insbesondere: -1. Welche sichtbaren Ergebnisse entstehen standardmäßig am Ende einer Tagesreflexion? -2. Welche internen Outputs entstehen immer, welche nur bei Relevanz? -3. Wie verhalten sich Session Output, Journal Entry, Reflection Memory, Knowledge Delta und Action Candidate zueinander? -4. Soll die Trennung **`Session Lifecycle ≠ Thread Lifecycle`** als verbindliche Architekturregel übernommen werden? -5. Wann wird ein Journal Entry automatisch vorbereitet, wann nur angeboten und wann bewusst nicht erzeugt? +1. Welche Inhalte verbleiben als quellengebundene Kontinuitätsstruktur und wann werden daraus Reflection Memory, Knowledge Delta oder andere langfristige Ableitungen? +2. Nach welchen Kriterien entstehen Reflection Memory, Knowledge Delta und Action Candidate tatsächlich? +3. Wann wird ein Journal Entry automatisch vorbereitet, wann nur angeboten und wann bewusst nicht erzeugt? Nach vorläufigem Abschluss der Tagesreflexion folgt: diff --git a/docs/architecture/functional/memory_and_context.md b/docs/architecture/functional/memory_and_context.md index f8b05ea..f3287de 100644 --- a/docs/architecture/functional/memory_and_context.md +++ b/docs/architecture/functional/memory_and_context.md @@ -138,3 +138,38 @@ Diese Entscheidung ist noch technisch zu validieren. --- +## Kontinuitätsarbeit ohne zwingendes Output-Artefakt + +**Status: entschieden** + +Der Erfolg einer Reflexion hängt nicht davon ab, dass daraus zwingend ein Journal Entry, eine neue Erkenntnis, ein Knowledge Delta oder eine Handlungsabsicht entsteht. + +Davon unabhängig benötigt Kanshō interne Kontinuitätsarbeit, damit lange Dialoge, mehrere Threads und spätere Wiederaufnahmen ohne vermeidbaren Bedeutungsverlust möglich bleiben. Dazu können insbesondere gehören: + +- Erhalt des Originaldialogs beziehungsweise einer verlässlichen Originalrepräsentation, +- Working-Context- und Thread-Memory-Summaries, +- offene Fragen und Zwischenstände, +- fachlich relevante Erkenntnisse, +- vorläufig erkannte Nebenfäden oder Thread-Kandidaten, +- Zeitbezug, Provenance, Confidence beziehungsweise Unsicherheit. + +Nicht jeder erkannte Nebenfaden muss zu einem sichtbaren oder dauerhaft eigenständigen Thread werden. Nicht jede Summary ist eine bestätigte Erkenntnis, und nicht jede Kontinuitätsstruktur ist ein sichtbarer Output. + +Da Summaries und weitere Verdichtungen selektiv sind, gelten für ihre langfristige Nutzung verbindlich die Regeln aus `context_fidelity_and_regrounding.md`: Die Originalquelle bleibt maßgeblich; bei ausreichendem Drift-Risiko, Abweichungen, Widersprüchen oder möglicher Fehlinterpretation muss Kanshō ein Re-Grounding aus den relevanten Ursprungsquellen auslösen können. Dies kann automatisch beziehungsweise systemseitig oder ausdrücklich durch den Nutzer angestoßen werden. + +Kontinuitätsarbeit ist nicht an das Ende einer Session gebunden. Sie darf und muss bei fachlichem Bedarf bereits während eines langen Dialogs erfolgen, insbesondere wenn der aktive Kontext sonst relevante Aussagen, Nebenfäden oder Zwischenstände verlieren würde. + +Das Session-Ende ist ein zusätzlicher fachlicher Kontinuitäts-Checkpoint. Dabei wird geprüft: + +- Ist die Originalquelle verlässlich erhalten? +- Müssen Working Context, Summary oder Thread Memory aktualisiert werden? +- Sind tatsächlich relevante Erkenntnisse, offene Fragen oder mögliche Nebenfäden entstanden? +- Haben sich Thread-Zustand, Wiedervorlage oder andere Kontinuitätsinformationen tatsächlich verändert? +- Besteht ein Drift- beziehungsweise Re-Grounding-Bedarf? + +Nur tatsächlich notwendige beziehungsweise entstandene Änderungen werden fortgeschrieben. Der Checkpoint erzeugt weder künstlich eine Erkenntnis noch einen Nebenfaden und verlangt kein sichtbares Output-Artefakt. + +Die konkrete technische Granularität, Speicherform und Aktualisierungslogik dieser Strukturen bleibt später auszuarbeiten. + +--- + diff --git a/docs/architecture/functional/reflection_outputs.md b/docs/architecture/functional/reflection_outputs.md index a89028a..7dae30f 100644 --- a/docs/architecture/functional/reflection_outputs.md +++ b/docs/architecture/functional/reflection_outputs.md @@ -93,7 +93,90 @@ Kanshō selbst wird dadurch nicht zum Aufgaben- oder Projektmanager. --- +## Session Lifecycle und Thread Lifecycle + +**Status: entschieden** + +### Root Cause + +Eine zeitlich begrenzte Nutzungssitzung und ein persönlicher Denk- oder Reflexionsfaden besitzen unterschiedliche natürliche Lebensdauern. Ein Gespräch kann für den aktuellen Moment ausreichend sein, obwohl sein Thema fachlich offen, bewusst wiedervorgelegt oder vorläufig nicht relevant bleibt. + +### Risiko + +Eine Kopplung beider Lebenszyklen würde entweder offene Themen beim Sitzungsende künstlich als gelöst behandeln oder Sitzungen unnötig offenhalten, solange noch ein weiterführbarer Thread existiert. Dadurch gingen natürliche Gesprächsabschlüsse, verlässliche Wiedervorlagen oder der tatsächliche Erkenntnisstand eines Threads verloren. + +### Fachliche Konsequenz und Architekturregel + +> **Session Lifecycle ≠ Thread Lifecycle** + +Das Ende einer Session bezeichnet das Ende der aktuellen Interaktion und der dazugehörigen Output-Verarbeitung. Es bedeutet nicht automatisch, dass alle in der Session berührten Threads abgeschlossen sind. + +Eine Session kann insbesondere enden durch: + +- einen expliziten Abschluss durch den Nutzer, +- eine von Kanshō angebotene und vom Nutzer angenommene Abschlussmöglichkeit bei erkannter Reflection Saturation, +- einen natürlichen Gesprächsauslauf, bei dem Kanshō einen kurzen oder für den Moment ausreichenden Intent nicht durch künstliche Folgefragen verlängert. + +Nach dem Session-Ende können betroffene Threads beispielsweise `Open`, `Anchored / Resurface`, `Dormant` oder `Resolved` sein. `Resolved` darf nur den für den derzeitigen Erkenntnisstand ausreichend bearbeiteten Thread bezeichnen; es folgt nicht allein aus dem Ende der Session. + +Die bisher benannten Thread-Zustände bilden ausdrücklich **keine abschließende Zustandsmenge und kein technisches State Model**. Ob weitere fachliche Zustände oder zusätzliche Metainformationen benötigt werden, wird in der späteren Ausarbeitung des Thread- und Datenmodells geprüft. + +--- + +## Sichtbarer Abschluss einer Tagesreflexion + +**Status: entschieden** + +### Root Cause + +Der Abschluss soll dem Nutzer Orientierung und einen stimmigen Übergang aus der Reflexion geben. Gleichzeitig ist die Tagesreflexion ein natürlicher Dialog und kein formaler Workflow mit stets gleicher Ergebnisliste. + +### Risiko + +Ein obligatorischer Ergebnisbildschirm oder eine feste Abschluss-Checkliste würde auch kurze beziehungsweise natürlich auslaufende Gespräche künstlich verlängern und interne Modellkomplexität an die Oberfläche tragen. Ein vollständig unsichtbarer Abschluss könnte dagegen relevante offene Punkte, Wiedervorlagen oder sinnvolle Anschlussmöglichkeiten verlieren. + +### Fachliche Konsequenz und Entscheidung + +Der sichtbare Abschluss ist **adaptiv und möglichst leicht**. Der Standard bezeichnet ein Abschlussverhalten, nicht ein in jeder Session identisches Artefakt. + +Für eine substanzielle Tagesreflexion gilt grundsätzlich: + +- Kanshō gibt einen kurzen persönlichen Abschlussgedanken oder eine knappe Spiegelung statt einer vollständigen Gesprächszusammenfassung. +- Offene Punkte und gesetzte Wiedervorlagen werden nur sichtbar gemacht, wenn sie tatsächlich bestehen und für den Abschluss relevant sind. +- Es werden höchstens wenige kontextuelle Anschlussmöglichkeiten angeboten, beispielsweise „Tagebucheintrag ansehen“, „morgen weiter“ oder „noch vertiefen“. +- Interne Outputs werden nicht allein aufgrund ihrer Existenz als technische Objekte präsentiert. + +Ein kurzer oder natürlich ausgelaufener Dialog darf mit einer schlichten Bestätigung enden. Kanshō erzeugt dann weder künstlich eine Zusammenfassung noch erzwingt es einen separaten Ergebnisbildschirm. + +Die hier vermiedene künstliche Zusammenfassung bezeichnet den **sichtbaren Abschluss**. Sie schließt interne, quellengebundene Summaries für Working Context, Thread Memory oder die langfristige Dialogkontinuität ausdrücklich nicht aus. + +Damit bleibt der Abschluss im Gespräch verankert. Eine spätere UX-Ausarbeitung darf seine Darstellung konkretisieren, aber daraus keinen verpflichtenden mehrstufigen Workflow machen. + +--- + +## Reflexionserleben, Kontinuitätsarbeit und Output-Artefakte + +**Status: entschieden** + +Eine Tagesreflexion muss kein eigenständiges Ergebnisartefakt erzeugen, um fachlich sinnvoll oder erfolgreich zu sein. Ihr primärer Wert kann bereits im Wahrnehmen, Aussprechen, Reflektieren, vorläufigen Einordnen oder bewussten Offenlassen liegen. + +Davon zu unterscheiden ist die interne Kontinuitätsarbeit. Auch wenn kein Journal Entry, keine Reflection Memory, kein Knowledge Delta und kein Action Candidate entsteht, kann Kanshō insbesondere: + +- die verlässliche Originalrepräsentation des Dialogs als Primärquelle erhalten, +- für lange Dialoge und spätere Wiederaufnahme quellengebundene Summaries beziehungsweise Thread Memories fortschreiben, +- tatsächlich relevante Erkenntnisse, offene Fragen und mögliche Nebenfäden mit ihrem vorläufigen Status erhalten, +- betroffene Thread-Zustände und Wiedervorlageanker aktualisieren, +- zeitlichen Kontext, Provenance und Unsicherheit der abgeleiteten Strukturen bewahren. + +Diese Kontinuitätsstrukturen sind nicht automatisch sichtbare Session-Ergebnisse und nicht mit bestätigtem langfristigem Wissen gleichzusetzen. Ein möglicher Nebenfaden, eine Hypothese oder eine verdichtete Summary bleibt als vorläufige beziehungsweise abgeleitete Struktur gekennzeichnet. + +Summaries und andere Verdichtungen dürfen zur handhabbaren Fortsetzung über lange Dialoge hinweg verwendet werden. Sie ersetzen jedoch nicht die Originalquelle. Bei erkanntem Drift-Risiko, Widerspruch, möglicher Fehlinterpretation oder ausdrücklichem Nutzerwunsch wird der relevante Gesprächsverlauf gemäß `context_fidelity_and_regrounding.md` erneut aus den Ursprungsquellen analysiert und der verwendete Kontext gegebenenfalls neu abgeleitet. + +Kontinuitätsarbeit ist eine **laufende Systemverantwortung** und nicht ausschließlich ein Verarbeitungsschritt am Session-Ende. Summaries, Working Context oder Thread Memory dürfen bereits während eines langen Dialogs fortgeschrieben oder bei Bedarf neu aufgebaut werden. Das Session-Ende bildet lediglich einen zusätzlichen fachlichen Prüfpunkt, an dem notwendige Sicherungen, tatsächliche Änderungen und möglicher Re-Grounding-Bedarf bewertet werden. Es erzwingt weder eine neue Verdichtung noch ein Ergebnisartefakt. + +--- + ## Noch auszuarbeiten -Beim Abschluss der laufenden Ausarbeitung der Nutzungssituation Tagesreflexion werden hier Session Output, Narrative Output, Long-Term Output sowie die Trennung `Session Lifecycle ≠ Thread Lifecycle` ergänzt. +Beim Abschluss der laufenden Ausarbeitung der Nutzungssituation Tagesreflexion werden hier noch Session Output, Narrative Output und Long-Term Output sowie ihre konkreten Erzeugungs- und Persistenzregeln ergänzt. Die sichtbare Abschluss-Baseline ist entschieden; die genaue spätere UX-Darstellung bleibt konkretisierbar. diff --git a/docs/architecture/functional/resurfacing_and_saturation.md b/docs/architecture/functional/resurfacing_and_saturation.md index e600670..2f93b58 100644 --- a/docs/architecture/functional/resurfacing_and_saturation.md +++ b/docs/architecture/functional/resurfacing_and_saturation.md @@ -159,6 +159,18 @@ Für die weitere Architektur sind mindestens folgende fachlichen Zustände bezie Diese Begriffe sind noch **kein festes technisches State Model**. Sie dienen zunächst dazu, spätere Architekturentscheidungen konsistent auszurichten. +Die Aufzählung ist ausdrücklich **nicht abschließend**. In der späteren Ausarbeitung des Thread- und Datenmodells ist zu prüfen, ob weitere fachliche Zustände oder zusätzliche Metainformationen benötigt werden. Aus der heutigen Baseline darf keine vorzeitige technische Vollständigkeit abgeleitet werden. + +#### Session Lifecycle und Thread Lifecycle + +Als verbindliche querschnittliche Architekturregel gilt: + +> **Session Lifecycle ≠ Thread Lifecycle** + +Eine aktuelle Reflexionssitzung kann enden, während ein darin bearbeiteter Thread `Open`, `Anchored / Resurface` oder `Dormant` bleibt. Das Session-Ende bezeichnet nur das Ende der aktuellen Interaktion und ihrer Output-Verarbeitung. Es setzt einen Thread nicht automatisch auf `Resolved`. + +Umgekehrt richtet sich der weitere Lebenszyklus des Threads nach seinem fachlichen Erkenntnisstand, seiner aktuellen Relevanz und einer möglichen Wiedervorlage. Die ausführliche Herleitung und die Output-Folgen werden kanonisch in `reflection_outputs.md` geführt. + #### Architekturweite Gültigkeit Thread Resurfacing und Reflection Saturation sind querschnittliche Konzepte. diff --git a/docs/architecture/functional/usage_situations.md b/docs/architecture/functional/usage_situations.md index 0b37e80..dac2f8a 100644 --- a/docs/architecture/functional/usage_situations.md +++ b/docs/architecture/functional/usage_situations.md @@ -595,13 +595,20 @@ Bereits entschieden: - Flache, generische oder wiederkehrende Fragen sollen aktiv vermieden werden. - Kanshō soll sich an den individuellen Denk- und Antwortstil des Nutzers anpassen. - Nach dem ersten Impuls folgt kein starrer Fragenbaum; Kanshō reagiert adaptiv auf die tatsächliche Antwort. +- Eine Tagesreflexions-Session darf enden, obwohl darin berührte Threads offen, wiedervorgelegt oder aktuell nicht relevant bleiben. Verbindlich gilt `Session Lifecycle ≠ Thread Lifecycle`. +- Ein Session-Ende kann durch den expliziten Nutzerwunsch, durch eine angenommene Abschlussmöglichkeit bei Reflection Saturation oder durch einen natürlichen Gesprächsauslauf entstehen. Es darf keinen Thread allein dadurch als `Resolved` behandeln. +- Der sichtbare Abschluss ist adaptiv und möglichst leicht: substanzielle Reflexionen erhalten grundsätzlich einen kurzen persönlichen Abschlussgedanken; kurze oder natürlich ausgelaufene Dialoge dürfen mit einer schlichten Bestätigung enden. +- Offene Punkte, Wiedervorlagen und wenige Anschlussmöglichkeiten werden nur kontextuell gezeigt. Ein obligatorischer Ergebnisbildschirm oder eine Abschluss-Checkliste ist nicht vorgesehen. +- Eine Tagesreflexion benötigt kein zwingendes Ergebnisartefakt. Unabhängig davon darf und muss Kanshō die für Kontinuität relevanten Originalquellen, Summaries, Erkenntnisse, offenen Fragen, Thread-Änderungen und möglichen Nebenfäden angemessen erhalten. +- Interne Summaries sind abgeleitete, quellengebundene Kontinuitätsstrukturen und keine automatisch bestätigten Erkenntnisse. Bei Drift, Abweichung, möglicher Fehlinterpretation oder auf Nutzerwunsch gilt das Re-Grounding aus `context_fidelity_and_regrounding.md`. +- Kontinuitätsarbeit kann bereits während einer langen Tagesreflexion erfolgen. Das Session-Ende ist ein zusätzlicher Prüfpunkt, aber weder der einzige Auslöser für Memory-/Summary-Pflege noch ein Zwang zur Erzeugung neuer Inhalte. -Noch zu klären: +Frühere offene Punkte und aktualisierter Stand: -- Wie erkennt Kanshō, dass heute eher keine tiefe Reflexion sinnvoll oder erwünscht ist? -- Wie soll Kanshō mit unscharfen Wiedervorlagen wie „später“ umgehen, ohne unnötig nachzufragen? -- Wann ist eine Tagesreflexion fachlich abgeschlossen? -- Welche Outputs entstehen standardmäßig am Ende? +- Die frühere Frage „Wie erkennt Kanshō, dass heute eher keine tiefe Reflexion sinnvoll oder erwünscht ist?“ ist fachlich durch Intent-Abhängigkeit, persönliche Dialogtiefe, Gesprächssignale und Nutzerhoheit eingegrenzt. Die konkrete Erkennungslogik bleibt später technisch auszuarbeiten. +- Die frühere Frage „Wie soll Kanshō mit unscharfen Wiedervorlagen wie ‚später‘ umgehen, ohne unnötig nachzufragen?“ ist durch kontextbezogene Ableitung und gezieltes Nachfragen nur bei notwendiger Verlässlichkeit eingegrenzt. Die konkrete Ausprägung bleibt später in Dialog- und UX-Konzeption zu prüfen. +- Der Lebenszyklus der aktuellen Sitzung ist vom Lebenszyklus ihrer Threads getrennt. Die natürliche sichtbare Abschluss-Baseline ist entschieden; ihre genaue spätere UX-Darstellung bleibt konkretisierbar. +- Die Trennung zwischen optionalen Ergebnisartefakten und notwendiger interner Kontinuitätsarbeit ist entschieden. Noch offen sind die konkreten Erzeugungs- und Persistenzregeln der einzelnen Artefakte. ## 7.2 Querverweis: Thread Resurfacing und Reflection Saturation