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:
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,
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.
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.**
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ō 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.**<br>
> **mindnet besitzt das langfristige Gedächtnis.**<br>
> **Obsidian bildet das menschenlesbare autobiografische Archiv.**
Technisch ist noch zu validieren, welcher Speicher Working-/Dialog-Memory übernimmt.
- 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`.
> 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,
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.
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.
- 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.
> 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.
> 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.
**Nächster Schritt:** zuerst gezielter Audit der bereits dokumentierten Entscheidungen; danach nur den nächsten tatsächlich offenen praxisrelevanten Punkt fragen<br>
**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<br>
**Offen:** skalierbare Organisation sehr großer Textmengen, Retrieval, Speicherstufen und Löschkaskaden<br>
**Output-Abgrenzung:** für die Tagesreflexion ausreichend geklärt; Detailheuristiken später in den zuständigen Fachkapiteln<br>
**Journal-Default:** bei substanzieller Tagesreflexion automatisch vorbereiten und dezent anbieten; Ausnahmen für kurze, rein achtsame, nicht erzählbare oder ausdrücklich journalfreie Dialoge<br>
**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`.
