Lars/Kansho
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
081a47c68c
Kansho/docs/architecture/functional/handover.md

53 KiB
Raw Blame History

title status date product_family document_role source_of_truth repository_root_current canonical_docs_path
Kanshō – Handover für neue Konzept-Session Aktiver Übergabestand 2026-08-19 Jinkendo Session Handover / Bootstrap / Current Working State Kanonische Markdown-Dateien im eingebundenen Kanshō-Git-Repository unter docs/architecture/functional/ C:\dev\Kansho 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.

Default-Quellbewahrung und wachsende Textmengen

Status: fachliche Baseline entschieden; konkrete Organisationslogik offen

  • Bewusst in Kanshō eingebrachte Texte und der inhaltliche Dialogverlauf werden intern standardmäßig unmittelbar als zeitgebundene Originalquelle beziehungsweise verlässliche Originalrepräsentation bewahrt.
  • Originalquellen werden nicht wegen Alter, Umfang, geringer aktueller Relevanz oder vorhandener Summaries automatisch gelöscht oder überschrieben.
  • Eine Löschung erfolgt nur auf konkrete Nutzeraufforderung beziehungsweise durch eine dafür berechtigte administrative Handlung.
  • Quellbewahrung bedeutet nicht, dass jeder Text als sichtbarer Eintrag, eigener Thread, Reflection Space, aktives Memory oder mindnet-Knoten behandelt wird.
  • Sichtbarkeit, aktive Relevanz, Modellkontext, abgeleitete Memories und Integrationspersistenz bleiben selektiv. Re-Grounding und Wiederfinden müssen dennoch bis zur Quelle reichen können.

Die langfristige Organisation sehr großer Textmengen ist ein echter, bisher nicht ausreichend ausgearbeiteter Memory-/Datenarchitekturpunkt. Konsolidierung, Retrieval, Speicherstufen, Versionierung und Löschkaskaden sind später zu klären, ohne die Default-Quellbewahrung in eine automatische Löschlogik umzudeuten. Das kanonische Home ist memory_and_context.md.

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

Dieser Interviewblock ist vorläufig ausreichend geklärt. Die folgende Baseline bleibt für spätere Journaling-, Memory-, Integrations- und UX-Kapitel verbindlich.

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.

Die Nutzungssituation 3. Spontaner Gedanke / Moment ist vorläufig ausreichend geklärt.

Zusätzlich zur bereits dokumentierten reibungsarmen Erfassung ist entschieden:

  • Jeder bewusst übermittelte spontane Gedanke wird intern standardmäßig unmittelbar als zeitgebundene Originalquelle beziehungsweise verlässliche Originalrepräsentation bewahrt.
  • Die spätere Einordnung, Verknüpfung, Verdichtung oder Förderung zu einem sichtbaren beziehungsweise langfristigen Objekt ist davon getrennt.
  • Eine Löschung erfolgt nur auf konkrete Nutzeraufforderung beziehungsweise durch eine dafür berechtigte administrative Handlung.
  • Das noch offene Problem sehr großer Textmengen wird querschnittlich in memory_and_context.md und nicht künstlich innerhalb dieser Nutzungssituation ausgearbeitet.

Die Nutzungssituation 4. Früheren Faden fortsetzen ist nach einem gezielten Dokumentationsaudit ebenfalls vorläufig ausreichend geklärt.

Die vorhandenen kanonischen Kapitel legen gemeinsam bereits fest:

  • Contextual Continuation ist der bevorzugte Default; freie Fortsetzung und explizite Navigation bleiben möglich.
  • Kanshō rekonstruiert den relevanten früheren Denkstand aus Thread Memory, offenen Fragen, Zwischenständen, aktuellem quellengebundenem Space-Zustand und bei Bedarf Ursprungsquellen. Der Nutzer soll Wesentliches nicht wiederholen müssen.
  • Die sichtbare Orientierung bleibt kompakt und bedarfsbezogen. Bei eindeutiger direkter Fortsetzung reagiert Kanshō auf den neuen Impuls, ohne einen langen oder formalen Summary-Block vorzuschalten.
  • Vollständige Historie und Nutzer-Provenance bleiben zugänglich.
  • Bei Drift-Risiko, Widerspruch, Unsicherheit oder Nutzerwunsch gilt Re-Grounding aus den Ursprungsquellen.
  • Automatisches Resurfacing setzt aktuelle Relevanz voraus; die explizite Nutzerabsicht hat Vorrang.

Die zuvor als offen markierte Frage nach dem genauen sichtbaren Umfang der Rekonstruktion war damit keine neue fachliche Grundsatzentscheidung, sondern eine spätere UX-Ausprägung. Sie wird nicht erneut interviewt.

Die Konzeptarbeit soll jetzt fortsetzen bei:

Nutzungssituation 5 – Tiefe Reflexion / biografische Frage

Vor einer neuen Fachfrage wird auch für diesen Block zunächst gezielt geprüft, welche Entscheidungen bereits in dialogue_model.md, reflection_intelligence.md, self_model_and_lived_experience.md und den Guardrails enthalten sind. Erst danach wird der nächste tatsächlich offene, praxisrelevante Entscheidungspunkt bestimmt.

Die Rollen von Thread Memory, Reflection Frontier, Reflection Memory, Knowledge Delta und Action Candidate sind für die Tagesreflexion ausreichend voneinander abgegrenzt. Detaillierte Heuristiken werden später in ihren jeweiligen Fachkapiteln ausgearbeitet und nicht als Voraussetzung für den Abschluss dieses Nutzungsszenarios vorgezogen.

Der Journal-Default ist entschieden: Bei einer substanziellen Tagesreflexion wird standardmäßig im Hintergrund ein persönlicher Entwurf vorbereitet und am natürlichen Abschluss dezent angeboten. Kurze Check-ins, reine Achtsamkeitssequenzen, fehlender erzählerischer Gehalt oder ein ausdrücklicher Gegenwunsch erzeugen keinen erzwungenen Entwurf. Vorbereitung bedeutet noch keine ungeprüfte endgültige Ablage.

Je nach Inhalt können zusätzlich oder später geeignete quellengebundene Persistierungen in Obsidian und mindnet entstehen, etwa bei Entscheidungen mit Tragweite, bedeutsamen Gedanken zu Ideen oder relevanten neuen Zusammenhängen. Verlässliche Langzeitkommunikation, Originalquellen und Re-Grounding haben Vorrang vor maximaler Extraktion und schützen gegen Verwässerung oder Halluzination von Erkenntnissen.

Die Tagesreflexion ist damit vorläufig ausreichend geklärt und wird nicht erneut geöffnet, sofern ein späteres Kapitel keinen echten Widerspruch oder Konkretisierungsbedarf erzeugt.

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 vorläufig ausreichend geklärt; Abschluss, Session-/Thread-Trennung, Kontinuität, Journal-Default und inhaltsabhängige Persistenz entschieden
Spontaner Gedanke / Moment vorläufig ausreichend geklärt; reibungsarme Erfassung und unmittelbare Default-Quellbewahrung entschieden
Früheren Faden fortsetzen vorläufig ausreichend geklärt; Contextual Continuation, kompakte Orientierung, Quellenzugang und Re-Grounding bereits 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 und Default-Quellbewahrung entschieden; Organisation sehr großer Textmengen offen
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:

  1. docs/architecture/functional/fachliche_zielarchitektur.md
  2. docs/architecture/functional/produktvision_und_produktidentitaet.md
  3. docs/architecture/functional/interview_plan.md
  4. docs/architecture/functional/usage_situations.md
  5. docs/architecture/functional/dialogue_model.md
  6. docs/architecture/functional/reflection_intelligence.md
  7. docs/architecture/functional/self_model_and_lived_experience.md

Nur wenn eine konkrete Entscheidung es benötigt zusätzlich:

  • docs/architecture/functional/context_fidelity_and_regrounding.md
  • docs/architecture/functional/guardrails.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 Nutzungssituation 5 – Tiefe Reflexion / biografische Frage.

Beginne nicht mit einer allgemeinen Projektzusammenfassung oder einer bereits beantworteten Frage. Prüfe vor der ersten neuen Frage gezielt die bereits dokumentierten Entscheidungen zu tiefer Reflexion, Hypothesen, Kausalitätsvorsicht, Self Model und Guardrails. Tagesreflexion, spontaner Gedanke und Fortsetzen eines früheren Fadens sind vorläufig ausreichend geklärt.

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: Tiefe Reflexion / biografische Frage
Status Tagesreflexion: vorläufig ausreichend geklärt
Status spontaner Gedanke: vorläufig ausreichend geklärt; unmittelbare Default-Quellbewahrung entschieden
Status früheren Faden fortsetzen: vorläufig ausreichend geklärt; Contextual Continuation, kompakte Orientierung, Quellenzugang und Re-Grounding entschieden
Nächster Interviewblock: Nutzungssituation 5 – Tiefe Reflexion / biografische Frage
Nächster Schritt: zuerst gezielter Audit der bereits dokumentierten Entscheidungen; danach nur den nächsten tatsächlich offenen praxisrelevanten Punkt fragen
Entschiedene Architekturregel: Session Lifecycle ≠ Thread Lifecycle
Entschieden: kein zwingendes Ergebnisartefakt; laufende, quellengebundene Kontinuitätsarbeit mit Re-Grounding
Entschieden: interne Originalquellen standardmäßig bewahren; keine automatische Löschung wegen Alter, Menge oder geringer Relevanz; Löschung nur auf Nutzeraufforderung oder berechtigte administrative Handlung
Offen: skalierbare Organisation sehr großer Textmengen, Retrieval, Speicherstufen und Löschkaskaden
Output-Abgrenzung: für die Tagesreflexion ausreichend geklärt; Detailheuristiken später in den zuständigen Fachkapiteln
Journal-Default: bei substanzieller Tagesreflexion automatisch vorbereiten und dezent anbieten; Ausnahmen für kurze, rein achtsame, nicht erzählbare oder ausdrücklich journalfreie Dialoge
Dokumente des nächsten Blocks: usage_situations.md, dialogue_model.md, reflection_intelligence.md und self_model_and_lived_experience.md; bei Bedarf context_fidelity_and_regrounding.md und guardrails.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.