docs: close reflection continuation concept blocks

Co-authored-by: Cursor <cursoragent@cursor.com>

.cursor/rules/kansho-documentation.mdc

@@ -0,0 +1,23 @@
+---
+description: Fachdokumentation nicht verdichten, Context Bundles nutzen
+globs: docs/**/*.md
+alwaysApply: false
+---
+
+# Kanshō – Dokumentation
+
+`fachliche_zielarchitektur.md` ist das führende Referenzdokument. Jedes Thema hat ein kanonisches Home; nicht duplizieren, sondern verlinken.
+
+## Änderungen
+
+- Keine stillschweigende Kürzung oder Löschung.
+- Ergänzen, explizit ersetzen, als überholt kennzeichnen oder Decision Record.
+- Dateinamen bleiben stabil, ohne Versionsnummern im Namen.
+- Frontmatter mindestens: Titel, Version/Status, Datum, document_role.
+- Status klar halten: Entschieden / Bevorzugte Richtung / Hypothese / Offen / Verworfen.
+
+## Kontext laden
+
+Nicht alle Kapitel gleichzeitig. Bundles stehen in `documentation_index.md`.
+
+Querschnittsinvarianten nicht abschwächen: Context Fidelity, Resurfacing/Saturation, Point-in-Time Self, Privacy Gateway.

.cursor/rules/kansho-privacy-guardrails.mdc

@@ -0,0 +1,26 @@
+---
+description: Privacy Gateway – Identität lokal, kein direkter AI-Egress
+alwaysApply: true
+---
+
+# Kanshō – Privacy Guardrails
+
+Invariante: Identität bleibt lokal. Externe Intelligenz erhält nur den notwendigen, minimierten, soweit sinnvoll pseudonymisierten Kontext.
+
+## Verbindlich
+
+- Persönlicher Kontext nie direkt an OpenRouter, Provider oder Tools senden.
+- Alle persönlichen AI-Aufrufe über eine lokale Privacy-Gateway-/Egress-Schicht.
+- Identity Mapping, Klarnamen, Secrets und vollständige Primärquellen bleiben in der Local Trusted Zone.
+- Für persönliche Kontexte: Zero Data Retention, kein Provider-Training, kein Prompt-Logging.
+- Fail Closed: kein stillschweigender Fallback auf unsichere Provider.
+- LLM-Egress und Tool-/Web-Egress sind getrennte Policies.
+- Antworten lokal validieren und erst dann demaskieren.
+
+## Datenklassen
+
+- A Local Only: Mapping, Secrets, vollständige Identität
+- B Pseudonymized AI Context: Normalfall für Dialoge
+- C Low-Identity: generische, nicht-personalisierte Inhalte
+
+Platzhalter wie `[[SELF]]` oder `[[PERSON:PARTNER]]` statt sprechender Aliase. Quelle: `docs/architecture/functional/guardrails.md`

.cursor/rules/kansho-product-identity.mdc

@@ -0,0 +1,26 @@
+---
+description: Kanshō-Produktidentität, Prinzipien und Nicht-Ziele
+alwaysApply: true
+---
+
+# Kanshō – Produktidentität
+
+Kanshō ist ein langfristiger persönlicher Reflexionsbegleiter (Personal Reflection Companion) in der Jinkendo-Familie. Kern: Wahrnehmen → Reflektieren → Verstehen → Einordnen.
+
+Nicht bauen oder vorschlagen als: Tagebuch-App mit KI, Meditations-App, Mood Tracker, generischer Chatbot, Aufgabenmanager, Fitness-Tracker oder automatischer psychologischer Diagnostiker.
+
+## Prinzipien
+
+- Dialog vor Formular; Kontext vor generischer Frage.
+- Hypothese statt künstlicher Gewissheit; Mensch entscheidet über Identität.
+- Reflection before Action; Action Candidates gehen an Kairo, nicht in Kanshō-To-dos.
+- Einfache UX, intern differenzierte Modelle. Keine Vereinfachung nur weil Implementierung leichter wird.
+- Primäre Startlogik: Kontinuität des Dialogs, kein Funktions-Dashboard.
+
+## Technik (entschieden, Stack offen)
+
+PWA, Mobile First, responsive Desktop, Offline und Transkription sind Anforderungen. UI-Framework, Datenbank und KI-Runtime nicht stillschweigend festlegen.
+
+## Quelle
+
+Details: `docs/architecture/functional/produktvision_und_produktidentitaet.md`

.gitignore

@@ -0,0 +1,38 @@
+# Dependencies
+node_modules/
+.pnp
+.pnp.js
+
+# Build / cache
+dist/
+build/
+.vite/
+.turbo/
+.cache/
+coverage/
+*.tsbuildinfo
+
+# Environment and secrets
+.env
+.env.*
+!.env.example
+*.pem
+*.key
+
+# Logs
+logs/
+*.log
+npm-debug.log*
+
+# OS / editor
+.DS_Store
+Thumbs.db
+*.swp
+.idea/
+.vscode/*
+!.vscode/extensions.json
+
+# Test / local data
+tmp/
+temp/
+data/local/

AGENTS.md

@@ -0,0 +1,30 @@
+# Kanshō – Agentenleitfaden
+
+Kanshō ist der dialogische Reflexionsraum der Jinkendo-Familie. Die fachliche Dokumentation in `docs/architecture/functional/` ist führend. Code folgt der Facharchitektur, nicht umgekehrt.
+
+## Vor jeder größeren Arbeit
+
+1. `documentation_index.md` lesen und nur das passende Context Bundle laden.
+2. Root-Dokumente plus 2–4 betroffene Fachkapitel, nicht den ganzen Ordner.
+3. Statuswörter ernst nehmen: Entschieden, Bevorzugte Richtung, Hypothese, Offen, Verworfen.
+
+## Produktgrenzen
+
+Kanshō beantwortet: **Was bedeutet das Erlebte für die Person?**
+
+Andere Produkte behalten ihre Verantwortung:
+
+- Mitai: körperliches Geschehen
+- Shinkan: Training und Entwicklung
+- Kairo: Planung und Operationalisierung
+- mindnet: persönliches Wissensnetz
+
+Keine Aufgabenverwaltung, kein Fitness-Tracker, keine psychologische Diagnose, kein stillschweigendes Persönlichkeitsprofil.
+
+## Dokumentieren
+
+Bestehende Kapitel nicht stillschweigend kürzen. Änderungen additiv, explizit oder als Decision Record. Dateinamen bleiben stabil.
+
+## Privacy
+
+Identität bleibt lokal. Persönlicher Kontext geht nie direkt an externe Modelle. Details: `guardrails.md`.

README.md

@@ -0,0 +1,59 @@
+# Kanshō
+
+Persönlicher KI-Reflexionsbegleiter innerhalb der Jinkendo-Produktfamilie.
+
+> Wahrnehmen → Reflektieren → Verstehen → Einordnen
+
+Kanshō ist **kein** Tagebuch mit KI, keine Meditations-App und kein generischer Chatbot. Die Produktidentität ist ein langfristiger, dialogischer Reflexionsbegleiter. Journaling, Achtsamkeit und Meditation sind Werkzeuge, nicht der Kern.
+
+## Aktueller Stand
+
+Dieses Repository enthält derzeit die **fachliche Konzeption**. Es gibt noch keine Anwendungs-Codebasis.
+
+| Bereich | Stand |
+|---|---|
+| Produktidentität | entschieden: Personal Reflection Companion |
+| Technische Form | entschieden: PWA, Mobile First, Offline, Transkription |
+| Fachliche Doku | Baseline in `docs/architecture/functional/` |
+| App / MVP | noch nicht begonnen |
+
+Remote: [gitea.stommer.de/Lars/Kansho](https://gitea.stommer.de/Lars/Kansho.git)
+
+## Dokumentation zuerst laden
+
+Nicht alle Kapitel gleichzeitig in den Kontext ziehen. Der Index beschreibt sinnvolle Bundles:
+
+- `docs/architecture/functional/documentation_index.md`
+
+Führende Root-Dokumente:
+
+1. `docs/architecture/functional/fachliche_zielarchitektur.md`
+2. `docs/architecture/functional/produktvision_und_produktidentitaet.md`
+3. `docs/architecture/functional/interview_plan.md`
+
+Nächster Konzeptblock: Abschluss und Outputs der **Tagesreflexion** (siehe Interviewplan).
+
+## Lokal weiterarbeiten
+
+```powershell
+git pull
+```
+
+Änderungen nach Gitea:
+
+```powershell
+git add .
+git commit -m "Kurze Begründung, warum die Änderung nötig ist"
+git push
+```
+
+## Cursor / Vibe Coding
+
+Projektregeln liegen in `.cursor/rules/` und in `AGENTS.md`. Sie halten Produktgrenzen, Dokumentationsprinzipien und Privacy-Guardrails im Agenten-Kontext.
+
+Noch **nicht** entschieden und deshalb nicht stillschweigend festlegen:
+
+- UI-Framework / konkreter PWA-Stack
+- Datenbank und Sync
+- genaue Offline-/KI-Ausprägung
+- MVP-Schnitt

docs/architecture/functional/dialogue_model.md

@@ -43,6 +43,8 @@ Für den laufenden Dialog gilt als fachliche Anforderung:
 - Der Nutzer soll relevante Informationen nicht regelmäßig wiederholen müssen.
 - Aktiver Reflection Intent, aktuelle Threads und wesentliche Aussagen müssen im Arbeitskontext erhalten beziehungsweise bei Bedarf gezielt wiederhergestellt werden.
 
+Diese Kontinuitätsarbeit erfolgt bei Bedarf bereits während eines langen Dialogs und nicht erst an dessen sichtbarem Ende. Summaries beziehungsweise Working- und Thread-Memory-Strukturen dürfen laufend fortgeschrieben werden, müssen aber quellengebunden bleiben und unterliegen den Re-Grounding-Regeln aus `context_fidelity_and_regrounding.md`.
+
 ---
 
 <!-- Migriert aus `produktvision_und_produktidentitaet.md`: Abschnitt 8 Einleitung Kontextbezogener Gesprächseinstieg. Inhalt fachlich unverkuerzt; nur Heading-Level fuer die neue Dateistruktur angepasst. -->

docs/architecture/functional/documentation_index.md

@@ -13,6 +13,7 @@ Dieses Dokument dient dazu, für weitere Konzeptarbeit nur die tatsächlich ben
 
 ## 1. Root-Dokumente
 
+- `handover.md` – Session-Bootstrap und aktueller Arbeitsstand; verweist für Details auf die kanonischen Fachkapitel und ersetzt sie nicht.
 - `fachliche_zielarchitektur.md` – Governance, Dokumentationsprinzipien, Querschnittsinvarianten, Dateistruktur.
 - `produktvision_und_produktidentitaet.md` – Vision, Identität, Scope, Produktprinzipien und Nicht-Ziele.
 - `interview_plan.md` – Kapitelplan, Interviewmethode, Fortschritt und nächster Interviewblock.

docs/architecture/functional/fachliche_zielarchitektur.md

@@ -193,7 +193,9 @@ Die ausführlichen Herleitungen der querschnittlichen Fachinvarianten werden nic
 
 - **Context Fidelity / Re-Grounding:** `context_fidelity_and_regrounding.md`
 - **Thread Resurfacing / Reflection Saturation:** `resurfacing_and_saturation.md`
+- **Session Lifecycle ≠ Thread Lifecycle:** `reflection_outputs.md` und `resurfacing_and_saturation.md`
 - **Point-in-Time Self / Lived Experience:** `self_model_and_lived_experience.md`
+- **Default-Quellbewahrung / skalierbare Informationsorganisation:** `memory_and_context.md`
 - **Privacy Gateway / External-AI-Guardrails:** `guardrails.md`
 
 > **Keine dieser Invarianten darf durch spätere technische Vereinfachungen stillschweigend abgeschwächt werden.**
@@ -241,6 +243,7 @@ Dieser Checkpoint dokumentiert den Abgleich mit dem bis zu diesem Zeitpunkt vorl
 Die fachliche Dokumentation ist nach Themen aufgeteilt. Ein Thema soll möglichst genau ein kanonisches fachliches Home besitzen.
 
 ```text
+handover.md
 fachliche_zielarchitektur.md
 produktvision_und_produktidentitaet.md
 documentation_index.md

docs/architecture/functional/guardrails.md

@@ -562,6 +562,19 @@ Nicht automatisch in Audit Logs gespeichert werden sollen:
 - echte Namen,
 - Identity Mapping.
 
+## 18.1 Interne Quellbewahrung und Löschhoheit
+
+**Status: fachliche Baseline entschieden; technische Umsetzung offen**
+
+Die für Kanshō entschiedene Default-Quellbewahrung findet innerhalb der vertrauenswürdigen internen Datenhaltung statt und ist von externer Provider-Retention zu unterscheiden.
+
+- Inhaltliche Originalquellen werden standardmäßig bewahrt und nicht allein wegen Alter, Menge, geringer aktueller Relevanz oder vorhandener Verdichtungen automatisch gelöscht.
+- Eine Löschung erfolgt nur auf konkrete Nutzeraufforderung beziehungsweise durch eine dafür berechtigte administrative Handlung.
+- Administrative Löschung ist keine automatische Speicherbereinigung und darf nicht mit dem Zurückstufen, Archivieren oder Ausblenden derzeit irrelevanter Inhalte verwechselt werden.
+- Die genaue Autorisierung, Nachvollziehbarkeit und Weitergabe einer Löschung an Ableitungen, Indizes, Backlinks und Integrationen bleibt auszuarbeiten.
+
+Die vollständige fachliche Abgrenzung zwischen Quellbewahrung, aktiver Relevanz und skalierbarer Informationsorganisation wird in `memory_and_context.md` geführt.
+
 ---
 
 # 19. Guardrail-Priorität
@@ -611,7 +624,7 @@ Die Konfiguration soll weitgehend als Policy hinterlegt sein.
 9. Welche lokale Fallback-Funktion wird benötigt?
 10. Wie wird Voice/Transcription in dieselbe Trust-Architektur integriert?
 11. Welche Policies gelten für Web Search und Plugins?
-12. Wie werden Retention und vollständiges Löschen umgesetzt?
+12. Wie werden die entschiedene Default-Quellbewahrung und ausdrückliche vollständige beziehungsweise selektive Löschungen technisch umgesetzt und auf Ableitungen, Indizes und Integrationen propagiert?
 13. Wie wird das Identity Mapping verschlüsselt und gesichert?
 14. Welche Funktionen benötigt die Admin-/Developer View?
 15. Welche Guardrails müssen deterministisch sein und welche dürfen KI-gestützt arbeiten?
@@ -643,6 +656,8 @@ Die Konfiguration soll weitgehend als Policy hinterlegt sein.
 | Response Validation | lokale Prüfung vor Demasking | entschieden |
 | Rehydration | ausschließlich lokal | entschieden |
 | Guardrails | providerunabhängig definieren | entschieden |
+| Interne Originalquellen | standardmäßig bewahren; keine automatische Löschung wegen Alter, Menge oder geringer Relevanz | entschieden |
+| Löschhoheit | konkrete Nutzeraufforderung oder berechtigte administrative Handlung; Ausprägung und Löschkaskade offen | fachliche Baseline entschieden |
 
 ---
 

docs/architecture/functional/integrations.md

@@ -145,6 +145,8 @@ Kanshō kann:
 - neue Reflection Memories erzeugen,
 - Knowledge Deltas vorschlagen.
 
+Nicht jede Reflexion muss eine neue mindnet-Persistierung erzeugen. Abhängig vom Inhalt können jedoch auch zusätzlich oder später langfristig relevante Ableitungen entstehen, beispielsweise aus Entscheidungen mit Tragweite, bedeutsamen Gedanken zu Ideen, relevanten Erkenntnissen oder veränderten Zusammenhängen. Diese Ableitungen müssen auf ihre Quellen zurückführbar bleiben und dürfen vorläufige Gedanken oder Hypothesen nicht als bestätigtes Wissen ausgeben.
+
 ---
 
 ### 20.3 Obsidian
@@ -155,9 +157,12 @@ Kanshō soll insbesondere:
 
 - Tagebucheinträge erzeugen,
 - strukturierte Reflexionen ablegen,
+- geeignete menschenlesbare Entscheidungs- und Gedankeninhalte bewahren,
 - bestehende Inhalte referenzieren,
 - kein proprietäres geschlossenes Archiv erzeugen.
 
+Welche Inhalte nach Obsidian gelangen, richtet sich nach ihrem autobiografischen beziehungsweise menschenlesbaren Langzeitnutzen. Eine schematische Ablage jedes internen Memory-, Thread- oder Knowledge-Objekts ist nicht vorgesehen.
+
 Der genaue Ablage- und Synchronisationsmechanismus ist noch zu bestimmen.
 
 ---

docs/architecture/functional/interview_plan.md

@@ -240,15 +240,24 @@ Festlegen, was am Ende einer Reflexion geschieht.
 
 Die Gedächtnisebenen endgültig definieren.
 
+**Bereits entschieden:**
+
+- Bewusst eingebrachte inhaltliche Texte und Dialogquellen werden intern standardmäßig unmittelbar bewahrt.
+- Alter, Menge, geringe aktuelle Relevanz oder vorhandene Verdichtungen lösen keine automatische Quellenlöschung aus.
+- Löschung erfolgt nur auf konkrete Nutzeraufforderung beziehungsweise durch eine dafür berechtigte administrative Handlung.
+- Quellbewahrung ist von sichtbaren Objekten, aktiven Memories, aktivem Modellkontext sowie Persistierung nach Obsidian oder mindnet zu unterscheiden.
+
 **Leitfragen:**
 
 - Was gehört in Working Context?
 - Was gehört in Thread Memory?
 - Was wird episodische Erinnerung?
 - Was wird dauerhaftes Wissen?
-- Was darf automatisch gespeichert werden?
+- Welche abgeleiteten Memory-Strukturen dürfen automatisch erzeugt oder aktualisiert werden?
 - Was benötigt Bestätigung?
-- Was darf später vergessen werden?
+- Welche Inhalte beziehungsweise Ableitungen dürfen aus aktiver Relevanz oder sichtbaren Sichten zurücktreten, ohne ihre Quellen zu löschen?
+- Wie werden sehr große Textmengen langfristig konsolidiert, indexiert, wiedergefunden und reaktiviert, ohne eine unüberschaubare Anzahl sichtbarer Einzelobjekte zu erzeugen?
+- Wie wirkt sich eine ausdrückliche Löschung auf Ableitungen, Indizes, Backlinks und Integrationen aus?
 
 **Zieldateien:**
 
@@ -869,6 +878,8 @@ Die unmittelbar nächste Sequenz sollte lauten:
 
 Diese Reihenfolge verhindert, dass technische Entscheidungen zu früh getroffen werden, bevor klar ist, welches Verhalten das Produkt tatsächlich benötigt.
 
+Parallel existiert seit 2026-08-19 eine **vorläufige technische Rahmenarchitektur** unter `docs/architecture/technical/` (Produktrahmen analog Mitai). Sie ersetzt Phasen F–G und I nicht. **Privacy Gateway und Guardrails** sind fachlich bereits Invariante (`guardrails.md`) und technisch bindend; Phase H vertieft Encryption, Löschen, Transparenz und Safety, ohne diese Invariante zu öffnen.
+
 ---
 
 ## 6. Interviewmethode
@@ -948,12 +959,14 @@ Technische Kapitel erhalten zusätzlich:
 | Reflection Spaces | fachliche Baseline vorläufig ausreichend geklärt; spätere Konkretisierung aus Dialog-, UX- und Memory-Kapiteln vorgesehen |
 | Nutzungssituationen | Typologie mit elf Situationen als vorläufig vollständige Baseline festgelegt |
 | Erleben festhalten | vorläufig ausreichend geklärt |
-| Tagesreflexion | in Bearbeitung; Einstieg, Priorisierung, Fokuswahl, adaptive Tiefe, Wiedervorlage und Resurfacing weitgehend geklärt |
+| Tagesreflexion | vorläufig ausreichend geklärt; Einstieg, adaptive Führung, 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 bedarfsbezogene Orientierung, Quellenzugang und Re-Grounding bereits querschnittlich entschieden |
 | Dialogmodell | wesentliche Baseline vorhanden; weitere Nutzungssituationen noch auszuarbeiten |
 | Threads | Grundmodell vorhanden; technisches State Model bewusst offen |
 | Thread Resurfacing | querschnittliches Fachkonzept entschieden |
 | Reflection Saturation | querschnittliches Fachkonzept entschieden; konkrete technische Berechnung später |
-| Memory Architecture | erstes Schichtenmodell vorhanden |
+| Memory Architecture | erstes Schichtenmodell und Default-Quellbewahrung entschieden; skalierbare Organisation sehr großer Textmengen offen |
 | Context Fidelity / Re-Grounding | Root Cause und fachliche Invariante entschieden |
 | mindnet-Rolle | Grundrichtung vorhanden |
 | Self Model | erste verbindliche Prinzipien vorhanden |
@@ -977,7 +990,7 @@ Technische Kapitel erhalten zusätzlich:
 
 ## 9. Nächster Interviewblock
 
-Aktiv ist weiterhin die Nutzungssituation **2. Tagesreflexion**.
+Die Nutzungssituation **2. Tagesreflexion** ist vorläufig ausreichend geklärt.
 
 Bereits geklärt sind insbesondere:
 
@@ -992,20 +1005,59 @@ Bereits geklärt sind insbesondere:
 - Thread Resurfacing als querschnittliches Konzept,
 - Reflection Saturation als Erkennung von möglicher Abschlussreife,
 - der Nutzer behält das letzte Wort über Weiterführen, Vertiefung, Wiedervorlage und Abschluss.
+- `Session Lifecycle ≠ Thread Lifecycle` als verbindliche Architekturregel; ein Session-Ende löst offene Threads nicht automatisch auf.
+- die bisher benannten Thread-Zustände sind eine nicht abschließende fachliche Baseline; weitere Zustände und Metainformationen bleiben im späteren Thread-/Datenmodell zu prüfen.
 
-### Als Nächstes: Abschluss und Outputs der Tagesreflexion
+### Tagesreflexion – vorläufig ausreichend geklärt
 
-Noch fachlich zu entscheiden beziehungsweise zu bestätigen sind insbesondere:
+Im aktuellen Block wurde entschieden:
 
-1. Welche sichtbaren Ergebnisse entstehen standardmäßig am Ende einer Tagesreflexion?
+- Die Session und ihre Threads besitzen getrennte Lebenszyklen.
-2. Welche internen Outputs entstehen immer, welche nur bei Relevanz?
+- Eine Session darf explizit durch den Nutzer, nach einer angenommenen Abschlussanregung bei Reflection Saturation oder durch natürlichen Gesprächsauslauf enden.
-3. Wie verhalten sich Session Output, Journal Entry, Reflection Memory, Knowledge Delta und Action Candidate zueinander?
+- Das Session-Ende bedeutet nicht automatisch `Resolved` für beteiligte Threads.
-4. Soll die Trennung **`Session Lifecycle ≠ Thread Lifecycle`** als verbindliche Architekturregel übernommen werden?
+- Der sichtbare Abschluss ist adaptiv und möglichst leicht: kurzer persönlicher Abschlussgedanke bei substanziellen Reflexionen, schlichte Bestätigung bei kurzen oder natürlich ausgelaufenen Dialogen.
-5. Wann wird ein Journal Entry automatisch vorbereitet, wann nur angeboten und wann bewusst nicht erzeugt?
+- Offene Punkte, Wiedervorlagen und wenige Anschlussmöglichkeiten erscheinen nur kontextuell; es gibt keinen obligatorischen Ergebnisbildschirm und keine Abschluss-Checkliste.
+- Eine Tagesreflexion muss kein Ergebnisartefakt erzeugen. Der primäre Wert kann im Reflexions- beziehungsweise Achtsamkeitserleben selbst liegen.
+- Davon getrennt bleibt interne Kontinuitätsarbeit notwendig: Originalquelle, quellengebundene Summaries beziehungsweise Thread Memories, relevante Erkenntnisse, offene Fragen, mögliche Nebenfäden und tatsächliche Thread-Änderungen werden angemessen erhalten.
+- Interne Verdichtungen ersetzen die Originalquelle nicht. Bei Drift, Abweichung, möglicher Fehlinterpretation oder Nutzeranforderung gilt automatisches beziehungsweise nutzerinitiiertes Re-Grounding gemäß `context_fidelity_and_regrounding.md`.
+- Kontinuitätsarbeit ist eine laufende Systemverantwortung und nicht an das Session-Ende gebunden. Das Session-Ende dient als zusätzlicher Prüfpunkt; nur tatsächliche Änderungen werden fortgeschrieben, ohne Erkenntnisse, Nebenfäden oder sichtbare Outputs zu erzwingen.
+- Die Rollen von Thread Memory, Reflection Frontier, Reflection Memory, Knowledge Delta und Action Candidate sind bereits ausreichend getrennt dokumentiert. Genauere Erkennungs-, Bestätigungs-, Promotion- und Persistenzheuristiken gehören in die späteren Memory-, Daten-, Integrations- und Reflection-Intelligence-Kapitel und werden nicht im Nutzungsszenario vorgezogen.
+- Bei einer substanziellen Tagesreflexion wird standardmäßig ein persönlicher Journal-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.
+- Abhängig vom Inhalt können zusätzlich oder später geeignete quellengebundene Persistierungen in Obsidian und mindnet entstehen, insbesondere 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 schrittweise Verwässerung oder Halluzination von Erkenntnissen.
 
-Nach vorläufigem Abschluss der Tagesreflexion folgt:
+Detailheuristiken und technische Ausprägungen werden später in ihren zuständigen Kapiteln behandelt. Sie sind keine Voraussetzung mehr für den Abschluss dieser Nutzungssituation.
 
-### Nutzungssituation 3 – Spontaner Gedanke / Moment
+### Nutzungssituation 3 – Spontaner Gedanke / Moment: vorläufig ausreichend geklärt
+
+Bereits entschieden:
+
+- Der spontane Gedanke, das Gefühl oder die Beobachtung wird zuerst zuverlässig und mit minimaler Reibung erfasst.
+- Kanshō bestätigt die Erfassung kurz und macht daraus nicht ungefragt ein Interview oder eine tiefe Reflexion.
+- Eine Vertiefung darf diskret angeboten werden, beginnt aber nur bei entsprechender Nutzerfortsetzung oder erkennbarem Mehrwert.
+- Kontextzuordnung, mögliche Verknüpfungen und Thread-Kandidaten können im Hintergrund erkannt werden, ohne den Erfassungsmoment zu verlangsamen.
+- Jeder bewusst übermittelte spontane Gedanke wird standardmäßig unmittelbar als zeitgebundene Originalquelle beziehungsweise verlässliche Originalrepräsentation bewahrt.
+- Quellbewahrung ist von späterer Einordnung, Verdichtung, sichtbarer Struktur sowie einer möglichen Persistierung nach Obsidian oder mindnet getrennt.
+- Eine Löschung erfolgt nur auf konkrete Nutzeraufforderung beziehungsweise durch eine dafür berechtigte administrative Handlung; Alter, Menge oder geringe aktuelle Relevanz bewirken keine automatische Quellenlöschung.
+
+Die dauerhafte Organisation sehr großer Textmengen ist als echter, bisher nicht ausreichend behandelter Querschnittspunkt für die spätere Memory-, Daten- und Integrationskonzeption aufgenommen. Sie wird nicht künstlich im Nutzungsszenario ausdetailliert.
+
+### Nutzungssituation 4 – Früheren Faden fortsetzen: vorläufig ausreichend geklärt
+
+Der Dokumentationsaudit hat ergeben, dass das Wiederaufnahmeverhalten bereits durch mehrere kanonische Entscheidungen hinreichend bestimmt ist:
+
+- `Contextual Continuation` ist der bevorzugte Default; freie Fortsetzung und explizite Navigation bleiben jederzeit möglich.
+- Kanshō rekonstruiert Thread Memory, offene Fragen, Zwischenstände und den aktuellen quellengebundenen Space-Zustand, sodass der Nutzer nicht wieder bei null beginnen oder Wesentliches wiederholen muss.
+- Die sichtbare Orientierung bleibt kompakt und bedarfsbezogen. Ein langer Summary-Block ist keine Voraussetzung für die Fortsetzung; bei eindeutigem Nutzerimpuls wird direkt natürlich weiterdialogisiert.
+- 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 Nutzerintention besitzt Vorrang.
+
+Die zuvor als offen formulierte Frage nach dem Umfang der sichtbaren Rekonstruktion war damit keine noch ungeklärte fachliche Grundsatzentscheidung, sondern eine spätere UX-Ausprägung. Sie wird im Nutzungssituationsinterview nicht erneut gestellt.
+
+### Aktiver Interviewblock: Nutzungssituation 5 – Tiefe Reflexion / biografische Frage
+
+Vor der ersten neuen Fachfrage wird auch für diesen Block ein gezielter Audit der bereits dokumentierten Entscheidungen durchgeführt. Erst danach wird der nächste tatsächlich offene, praxisrelevante Entscheidungspunkt bestimmt.
 
 Danach werden die verbleibenden Nutzungssituationen schrittweise nach derselben Interviewmethode ausgearbeitet.
 

docs/architecture/functional/memory_and_context.md

@@ -138,3 +138,87 @@ Diese Entscheidung ist noch technisch zu validieren.
 
 ---
 
+## Kontinuitätsarbeit ohne zwingendes Output-Artefakt
+
+**Status: entschieden**
+
+Der Erfolg einer Reflexion hängt nicht davon ab, dass daraus zwingend ein Journal Entry, eine neue Erkenntnis, ein Knowledge Delta oder eine Handlungsabsicht entsteht.
+
+Davon unabhängig benötigt Kanshō interne Kontinuitätsarbeit, damit lange Dialoge, mehrere Threads und spätere Wiederaufnahmen ohne vermeidbaren Bedeutungsverlust möglich bleiben. Dazu können insbesondere gehören:
+
+- Erhalt des Originaldialogs beziehungsweise einer verlässlichen Originalrepräsentation,
+- Working-Context- und Thread-Memory-Summaries,
+- offene Fragen und Zwischenstände,
+- fachlich relevante Erkenntnisse,
+- vorläufig erkannte Nebenfäden oder Thread-Kandidaten,
+- Zeitbezug, Provenance, Confidence beziehungsweise Unsicherheit.
+
+Nicht jeder erkannte Nebenfaden muss zu einem sichtbaren oder dauerhaft eigenständigen Thread werden. Nicht jede Summary ist eine bestätigte Erkenntnis, und nicht jede Kontinuitätsstruktur ist ein sichtbarer Output.
+
+Da Summaries und weitere Verdichtungen selektiv sind, gelten für ihre langfristige Nutzung verbindlich die Regeln aus `context_fidelity_and_regrounding.md`: Die Originalquelle bleibt maßgeblich; bei ausreichendem Drift-Risiko, Abweichungen, Widersprüchen oder möglicher Fehlinterpretation muss Kanshō ein Re-Grounding aus den relevanten Ursprungsquellen auslösen können. Dies kann automatisch beziehungsweise systemseitig oder ausdrücklich durch den Nutzer angestoßen werden.
+
+Kontinuitätsarbeit ist nicht an das Ende einer Session gebunden. Sie darf und muss bei fachlichem Bedarf bereits während eines langen Dialogs erfolgen, insbesondere wenn der aktive Kontext sonst relevante Aussagen, Nebenfäden oder Zwischenstände verlieren würde.
+
+Das Session-Ende ist ein zusätzlicher fachlicher Kontinuitäts-Checkpoint. Dabei wird geprüft:
+
+- Ist die Originalquelle verlässlich erhalten?
+- Müssen Working Context, Summary oder Thread Memory aktualisiert werden?
+- Sind tatsächlich relevante Erkenntnisse, offene Fragen oder mögliche Nebenfäden entstanden?
+- Haben sich Thread-Zustand, Wiedervorlage oder andere Kontinuitätsinformationen tatsächlich verändert?
+- Besteht ein Drift- beziehungsweise Re-Grounding-Bedarf?
+
+Nur tatsächlich notwendige beziehungsweise entstandene Änderungen werden fortgeschrieben. Der Checkpoint erzeugt weder künstlich eine Erkenntnis noch einen Nebenfaden und verlangt kein sichtbares Output-Artefakt.
+
+Für die Produktqualität besitzt die verlässliche Langzeitkommunikation höhere Priorität als die maximale Extraktion möglichst vieler Memories oder Wissenselemente. Verdichtungen sollen Kontinuität ermöglichen, dürfen Erkenntnisse aber nicht schrittweise verwässern, vorläufige Deutungen stabilisieren oder fehlende Zusammenhänge halluzinieren. Die verbindlichen Gegenmaßnahmen werden in `context_fidelity_and_regrounding.md` geführt.
+
+Die konkrete technische Granularität, Speicherform und Aktualisierungslogik dieser Strukturen bleibt später auszuarbeiten.
+
+---
+
+## Default-Quellbewahrung und skalierbare Informationsorganisation
+
+**Status: fachliche Baseline entschieden; konkrete Organisations- und Speicherlogik offen**
+
+### Root Cause
+
+Kanshō ist auf langfristige Kommunikation, spätere Rekonstruktion und Re-Grounding ausgelegt. Dafür müssen auch kurze, zunächst unscheinbare oder erst später bedeutsame Äußerungen als zeitgebundene Quellen verfügbar bleiben. Gleichzeitig kann über Jahre eine sehr große Menge an Dialog- und Textmaterial entstehen.
+
+### Risiko
+
+Eine relevance-, alters- oder mengengetriebene automatische Löschung könnte Quellen vernichten, deren Bedeutung erst später sichtbar wird, und Re-Grounding sowie Point-in-Time-Rekonstruktion beschädigen. Umgekehrt würde eine undifferenzierte Behandlung jedes Textes als sichtbares Objekt, aktives Memory oder eigener mindnet-Knoten das System fachlich und in der Nutzung zumüllen.
+
+### Fachliche Konsequenz
+
+Quellbewahrung und Informationsorganisation sind getrennte Verantwortungen:
+
+> **Alles als Quelle bewahren bedeutet nicht, alles sichtbar, aktiv oder semantisch gleichrangig zu halten.**
+
+### Abgeleitete Entscheidungen
+
+- Vom Nutzer bewusst in Kanshō eingebrachte Texte und der inhaltliche Dialogverlauf werden standardmäßig unmittelbar als zeitgebundene Originalquelle beziehungsweise verlässliche Originalrepräsentation in der internen vertrauenswürdigen Datenhaltung bewahrt.
+- Dies gilt auch für kurze spontane Gedanken. Ihre spätere Einordnung, Verknüpfung oder Verdichtung ist von der unmittelbaren Quellbewahrung getrennt.
+- Originalquellen werden nicht allein wegen Alter, Umfang, derzeit geringer Relevanz, Konsolidierung oder vorhandener Summaries automatisch gelöscht oder überschrieben.
+- Eine Löschung erfolgt nur auf konkrete Nutzeraufforderung beziehungsweise durch eine dafür berechtigte administrative Handlung. Administrative Löschung ist kein automatisches Mittel zur Relevanz- oder Mengenbereinigung.
+- Summaries, Thread Memories, Reflection Memories, Knowledge Deltas, Indizes und andere abgeleitete Strukturen dürfen selektiv erzeugt, aktualisiert, konsolidiert, zurückgestuft oder aus dem aktiven Kontext entfernt werden. Sie ersetzen und löschen dadurch nicht ihre Quellen.
+- Nicht jeder gespeicherte Text wird zu einem sichtbaren Eintrag, Thread, Reflection Space, Journal Entry, Reflection Memory oder mindnet-Knoten.
+- Nur der für die aktuelle Situation relevante Ausschnitt wird in den aktiven Modellkontext geladen. Langfristig gespeichert bedeutet weder dauerhaft aktiv noch dauerhaft sichtbar.
+- Wiederfinden und Re-Grounding müssen bei Bedarf bis auf die bewahrte Quellenebene reichen können.
+
+Diese Baseline bezieht sich auf die interne Kanshō-Quellhaltung. Sie erlaubt weder eine unminimierte Weitergabe an externe Modelle noch externe Provider-Speicherung; hierfür gelten weiterhin die Regeln aus `guardrails.md`.
+
+### Später auszuarbeitende Fragen
+
+Die dauerhafte Organisation sehr großer Textmengen wurde bisher noch nicht im erforderlichen Umfang konzipiert. Später zu klären sind insbesondere:
+
+- fachliche Lebenszyklen zwischen aktiv, ruhend, archiviert und bei Bedarf reaktiviert,
+- konsolidierte Sichten und Retrieval über viele Jahre, ohne eine unüberschaubare Zahl sichtbarer Einzelobjekte zu erzeugen,
+- Granularität, Versionierung, Indexierung und technische Speicherstufen der Quellen,
+- Umgang mit echten Duplikaten, Varianten und Korrekturen, ohne zeitliche Perspektiven oder Provenance zu verlieren,
+- Auswirkungen einer ausdrücklichen Löschung auf Ableitungen, Indizes, Backlinks, Exporte sowie bereits nach Obsidian oder mindnet überführte Inhalte,
+- Rollen, Berechtigungen, Nachvollziehbarkeit und technische Ausführung administrativer Löschungen,
+- Kapazitäts-, Kosten-, Offline- und Synchronisationsgrenzen über sehr lange Nutzungszeiträume.
+
+Diese offenen Punkte dürfen die entschiedene Default-Quellbewahrung nicht stillschweigend in eine automatische inhaltliche Lösch- oder Vergessenslogik umdeuten.
+
+---
+

docs/architecture/functional/reflection_outputs.md

@@ -25,6 +25,8 @@ Diese Ergebnisse müssen voneinander getrennt behandelt werden.
 
 Ein menschenlesbarer autobiografischer Text.
 
+Bei einer substanziellen Tagesreflexion wird standardmäßig ein persönlicher Entwurf im Hintergrund vorbereitet und am natürlichen Abschluss dezent zur Ansicht, Bearbeitung oder Übernahme angeboten. Kurze Check-ins, reine Achtsamkeitssequenzen, fehlender erzählerischer Gehalt oder ein ausdrücklicher Nutzerwunsch gegen einen Eintrag führen bewusst nicht zu einem erzwungenen Entwurf. Automatische Vorbereitung ist nicht mit ungeprüfter endgültiger Ablage gleichzusetzen.
+
 Zielsystem:
 
 - primär Obsidian,
@@ -93,7 +95,113 @@ Kanshō selbst wird dadurch nicht zum Aufgaben- oder Projektmanager.
 
 ---
 
+## Session Lifecycle und Thread Lifecycle
 
-## Noch auszuarbeiten
+**Status: entschieden**
 
-Beim Abschluss der laufenden Ausarbeitung der Nutzungssituation Tagesreflexion werden hier Session Output, Narrative Output, Long-Term Output sowie die Trennung `Session Lifecycle ≠ Thread Lifecycle` ergänzt.
+### Root Cause
+
+Eine zeitlich begrenzte Nutzungssitzung und ein persönlicher Denk- oder Reflexionsfaden besitzen unterschiedliche natürliche Lebensdauern. Ein Gespräch kann für den aktuellen Moment ausreichend sein, obwohl sein Thema fachlich offen, bewusst wiedervorgelegt oder vorläufig nicht relevant bleibt.
+
+### Risiko
+
+Eine Kopplung beider Lebenszyklen würde entweder offene Themen beim Sitzungsende künstlich als gelöst behandeln oder Sitzungen unnötig offenhalten, solange noch ein weiterführbarer Thread existiert. Dadurch gingen natürliche Gesprächsabschlüsse, verlässliche Wiedervorlagen oder der tatsächliche Erkenntnisstand eines Threads verloren.
+
+### Fachliche Konsequenz und Architekturregel
+
+> **Session Lifecycle ≠ Thread Lifecycle**
+
+Das Ende einer Session bezeichnet das Ende der aktuellen Interaktion und der dazugehörigen Output-Verarbeitung. Es bedeutet nicht automatisch, dass alle in der Session berührten Threads abgeschlossen sind.
+
+Eine Session kann insbesondere enden durch:
+
+- einen expliziten Abschluss durch den Nutzer,
+- eine von Kanshō angebotene und vom Nutzer angenommene Abschlussmöglichkeit bei erkannter Reflection Saturation,
+- einen natürlichen Gesprächsauslauf, bei dem Kanshō einen kurzen oder für den Moment ausreichenden Intent nicht durch künstliche Folgefragen verlängert.
+
+Nach dem Session-Ende können betroffene Threads beispielsweise `Open`, `Anchored / Resurface`, `Dormant` oder `Resolved` sein. `Resolved` darf nur den für den derzeitigen Erkenntnisstand ausreichend bearbeiteten Thread bezeichnen; es folgt nicht allein aus dem Ende der Session.
+
+Die bisher benannten Thread-Zustände bilden ausdrücklich **keine abschließende Zustandsmenge und kein technisches State Model**. Ob weitere fachliche Zustände oder zusätzliche Metainformationen benötigt werden, wird in der späteren Ausarbeitung des Thread- und Datenmodells geprüft.
+
+---
+
+## Sichtbarer Abschluss einer Tagesreflexion
+
+**Status: entschieden**
+
+### Root Cause
+
+Der Abschluss soll dem Nutzer Orientierung und einen stimmigen Übergang aus der Reflexion geben. Gleichzeitig ist die Tagesreflexion ein natürlicher Dialog und kein formaler Workflow mit stets gleicher Ergebnisliste.
+
+### Risiko
+
+Ein obligatorischer Ergebnisbildschirm oder eine feste Abschluss-Checkliste würde auch kurze beziehungsweise natürlich auslaufende Gespräche künstlich verlängern und interne Modellkomplexität an die Oberfläche tragen. Ein vollständig unsichtbarer Abschluss könnte dagegen relevante offene Punkte, Wiedervorlagen oder sinnvolle Anschlussmöglichkeiten verlieren.
+
+### Fachliche Konsequenz und Entscheidung
+
+Der sichtbare Abschluss ist **adaptiv und möglichst leicht**. Der Standard bezeichnet ein Abschlussverhalten, nicht ein in jeder Session identisches Artefakt.
+
+Für eine substanzielle Tagesreflexion gilt grundsätzlich:
+
+- Kanshō gibt einen kurzen persönlichen Abschlussgedanken oder eine knappe Spiegelung statt einer vollständigen Gesprächszusammenfassung.
+- Offene Punkte und gesetzte Wiedervorlagen werden nur sichtbar gemacht, wenn sie tatsächlich bestehen und für den Abschluss relevant sind.
+- Es werden höchstens wenige kontextuelle Anschlussmöglichkeiten angeboten, beispielsweise „Tagebucheintrag ansehen“, „morgen weiter“ oder „noch vertiefen“.
+- Interne Outputs werden nicht allein aufgrund ihrer Existenz als technische Objekte präsentiert.
+
+Ein kurzer oder natürlich ausgelaufener Dialog darf mit einer schlichten Bestätigung enden. Kanshō erzeugt dann weder künstlich eine Zusammenfassung noch erzwingt es einen separaten Ergebnisbildschirm.
+
+Die hier vermiedene künstliche Zusammenfassung bezeichnet den **sichtbaren Abschluss**. Sie schließt interne, quellengebundene Summaries für Working Context, Thread Memory oder die langfristige Dialogkontinuität ausdrücklich nicht aus.
+
+Damit bleibt der Abschluss im Gespräch verankert. Eine spätere UX-Ausarbeitung darf seine Darstellung konkretisieren, aber daraus keinen verpflichtenden mehrstufigen Workflow machen.
+
+---
+
+## Reflexionserleben, Kontinuitätsarbeit und Output-Artefakte
+
+**Status: entschieden**
+
+Eine Tagesreflexion muss kein eigenständiges Ergebnisartefakt erzeugen, um fachlich sinnvoll oder erfolgreich zu sein. Ihr primärer Wert kann bereits im Wahrnehmen, Aussprechen, Reflektieren, vorläufigen Einordnen oder bewussten Offenlassen liegen.
+
+Davon zu unterscheiden ist die interne Kontinuitätsarbeit. Auch wenn kein Journal Entry, keine Reflection Memory, kein Knowledge Delta und kein Action Candidate entsteht, kann Kanshō insbesondere:
+
+- die verlässliche Originalrepräsentation des Dialogs als Primärquelle erhalten,
+- für lange Dialoge und spätere Wiederaufnahme quellengebundene Summaries beziehungsweise Thread Memories fortschreiben,
+- tatsächlich relevante Erkenntnisse, offene Fragen und mögliche Nebenfäden mit ihrem vorläufigen Status erhalten,
+- betroffene Thread-Zustände und Wiedervorlageanker aktualisieren,
+- zeitlichen Kontext, Provenance und Unsicherheit der abgeleiteten Strukturen bewahren.
+
+Diese Kontinuitätsstrukturen sind nicht automatisch sichtbare Session-Ergebnisse und nicht mit bestätigtem langfristigem Wissen gleichzusetzen. Ein möglicher Nebenfaden, eine Hypothese oder eine verdichtete Summary bleibt als vorläufige beziehungsweise abgeleitete Struktur gekennzeichnet.
+
+Summaries und andere Verdichtungen dürfen zur handhabbaren Fortsetzung über lange Dialoge hinweg verwendet werden. Sie ersetzen jedoch nicht die Originalquelle. Bei erkanntem Drift-Risiko, Widerspruch, möglicher Fehlinterpretation oder ausdrücklichem Nutzerwunsch wird der relevante Gesprächsverlauf gemäß `context_fidelity_and_regrounding.md` erneut aus den Ursprungsquellen analysiert und der verwendete Kontext gegebenenfalls neu abgeleitet.
+
+Kontinuitätsarbeit ist eine **laufende Systemverantwortung** und nicht ausschließlich ein Verarbeitungsschritt am Session-Ende. Summaries, Working Context oder Thread Memory dürfen bereits während eines langen Dialogs fortgeschrieben oder bei Bedarf neu aufgebaut werden. Das Session-Ende bildet lediglich einen zusätzlichen fachlichen Prüfpunkt, an dem notwendige Sicherungen, tatsächliche Änderungen und möglicher Re-Grounding-Bedarf bewertet werden. Es erzwingt weder eine neue Verdichtung noch ein Ergebnisartefakt.
+
+---
+
+## Inhaltsabhängige langfristige Persistenz
+
+**Status: entschieden**
+
+Der Journal Entry ist ein häufiger, aber nicht der einzige mögliche persistierte Ausdruck eines Dialogs. Abhängig vom tatsächlichen Inhalt können zusätzlich oder zu einem späteren Zeitpunkt weitere quellengebundene Ableitungen entstehen, beispielsweise bei:
+
+- Entscheidungen mit persönlicher Tragweite,
+- bedeutsamen Gedanken zu Ideen oder Vorhaben,
+- relevanten Erkenntnissen oder Perspektivveränderungen,
+- neuen, korrigierten oder anders gewichteten Zusammenhängen.
+
+Die fachliche Ablage folgt der bestehenden Verantwortungsverteilung:
+
+- Kanshō bewahrt den Dialog und die zeitgebundene Innenperspektive als Primärquelle.
+- Obsidian dient für geeignete menschenlesbare Tagebuch-, Reflexions-, Entscheidungs- oder Gedankeninhalte.
+- mindnet übernimmt geeignete langfristige Vernetzung, Retrieval und strukturierte Ableitungen wie Reflection Memories oder Knowledge Deltas.
+
+Nicht jeder relevante Inhalt muss gleichzeitig in allen Systemen abgelegt werden. Maßgeblich sind fachlicher Nutzen, spätere Wiederauffindbarkeit und die jeweilige Systemverantwortung; eine rein schematische Vervielfältigung wird nicht verlangt.
+
+Alle abgeleiteten Persistierungen müssen auf den ursprünglichen Dialog beziehungsweise andere verlässliche Quellen zurückführbar bleiben und ihren epistemischen Status erhalten. Für die langfristige Qualität gilt `context_fidelity_and_regrounding.md`: Verlässliche Kommunikation über Monate und Jahre hat Vorrang vor maximaler Extraktion. Erkenntnisse dürfen durch wiederholte Verdichtung weder verwässert noch durch scheinbar plausible Halluzinationen ersetzt werden.
+
+---
+
+
+## Später auszuarbeiten
+
+Die fachlichen Rollen von Thread Memory, Reflection Frontier, Reflection Memory, Knowledge Delta und Action Candidate sind für diesen Nutzungsschritt ausreichend voneinander abgegrenzt. Genauere Erkennungs-, Bestätigungs-, Promotion- und Persistenzheuristiken werden erst in den jeweils zuständigen Memory-, Daten-, Integrations- und Reflection-Intelligence-Kapiteln ausgearbeitet. Sie werden nicht als Voraussetzung für den praktischen Abschluss der Nutzungssituation Tagesreflexion vorgezogen.

docs/architecture/functional/resurfacing_and_saturation.md

@@ -159,6 +159,18 @@ Für die weitere Architektur sind mindestens folgende fachlichen Zustände bezie
 
 Diese Begriffe sind noch **kein festes technisches State Model**. Sie dienen zunächst dazu, spätere Architekturentscheidungen konsistent auszurichten.
 
+Die Aufzählung ist ausdrücklich **nicht abschließend**. In der späteren Ausarbeitung des Thread- und Datenmodells ist zu prüfen, ob weitere fachliche Zustände oder zusätzliche Metainformationen benötigt werden. Aus der heutigen Baseline darf keine vorzeitige technische Vollständigkeit abgeleitet werden.
+
+#### Session Lifecycle und Thread Lifecycle
+
+Als verbindliche querschnittliche Architekturregel gilt:
+
+> **Session Lifecycle ≠ Thread Lifecycle**
+
+Eine aktuelle Reflexionssitzung kann enden, während ein darin bearbeiteter Thread `Open`, `Anchored / Resurface` oder `Dormant` bleibt. Das Session-Ende bezeichnet nur das Ende der aktuellen Interaktion und ihrer Output-Verarbeitung. Es setzt einen Thread nicht automatisch auf `Resolved`.
+
+Umgekehrt richtet sich der weitere Lebenszyklus des Threads nach seinem fachlichen Erkenntnisstand, seiner aktuellen Relevanz und einer möglichen Wiedervorlage. Die ausführliche Herleitung und die Output-Folgen werden kanonisch in `reflection_outputs.md` geführt.
+
 #### Architekturweite Gültigkeit
 
 Thread Resurfacing und Reflection Saturation sind querschnittliche Konzepte.

docs/architecture/functional/self_model_and_lived_experience.md

@@ -98,6 +98,8 @@ Dabei werden nicht nur Ergebnisse einer Reflexion gespeichert, sondern – sowei
 - welche Aussagen nur Hypothesen oder Momentaufnahmen waren,
 - welche Sprache und Denkstruktur zu diesem Zeitpunkt verwendet wurde.
 
+„Soweit vom Nutzer vorgesehen“ bedeutet dabei keine erneute Opt-in-Entscheidung für jeden Dialog. Die fachliche Baseline ist die unmittelbare Bewahrung der vollständigen inhaltlichen Dialogquelle beziehungsweise einer verlässlichen Originalrepräsentation. Davon kann der Nutzer ausdrücklich abweichen oder eine Löschung verlangen; eine dafür berechtigte administrative Löschung bleibt ebenfalls möglich. Alter, Datenmenge, geringe aktuelle Relevanz oder eine vorhandene Summary sind für sich allein kein Löschgrund. Die skalierbare Organisation der wachsenden Quellenmenge wird in `memory_and_context.md` geführt.
+
 Diese Ebene wird vorläufig als **Lived Experience / Inner-State Layer** bezeichnet.
 
 #### Keine Behauptung eines objektiven inneren Zustands

docs/architecture/functional/usage_situations.md

@@ -363,6 +363,29 @@ Kernanforderung:
 
 Eine spätere Vertiefung kann angeboten werden, muss aber nicht unmittelbar erfolgen.
 
+### Default-Verhalten beim spontanen Festhalten
+
+**Status: entschieden**
+
+Kanshō erfasst den Gedanken, das Gefühl oder die Beobachtung zuerst zuverlässig und mit minimaler Reibung. Es macht aus dem Einstieg nicht ungefragt ein Interview oder eine tiefe Reflexion.
+
+Nach der Erfassung gilt:
+
+- Kanshō bestätigt kurz und unaufdringlich, dass der Inhalt festgehalten wurde.
+- Eine Vertiefung darf diskret angeboten werden, beginnt aber nur bei einer entsprechenden Nutzerfortsetzung oder erkennbarem Mehrwert.
+- Interne Kontextzuordnung, mögliche Verknüpfungen und die Erkennung eines Thread-Kandidaten können im Hintergrund erfolgen.
+- Die interne Strukturierung darf den unmittelbaren Erfassungsmoment nicht verlangsamen oder den Nutzer zu Verwaltungsentscheidungen zwingen.
+
+### Unmittelbare Speicherung
+
+**Status: entschieden**
+
+Jeder bewusst übermittelte spontane Gedanke wird standardmäßig unmittelbar als zeitgebundene Originalquelle beziehungsweise verlässliche Originalrepräsentation bewahrt. Die spätere Einordnung, Verknüpfung, Verdichtung oder mögliche Förderung zu einem Thread, Journal Entry, Reflection Memory oder Knowledge Delta ist davon getrennt und erfolgt nur, soweit sie fachlich sinnvoll ist.
+
+Die Quellbewahrung erzeugt daher nicht automatisch ein weiteres sichtbares Objekt und nicht automatisch einen mindnet-Knoten. Eine Löschung erfolgt nur auf konkrete Nutzeraufforderung beziehungsweise durch eine dafür berechtigte administrative Handlung. Die querschnittliche Baseline und die noch offene Organisation großer Textmengen werden in `memory_and_context.md` geführt.
+
+Mit dieser Entscheidung ist die Nutzungssituation **Spontaner Gedanke / Moment** vorläufig ausreichend geklärt. Weitere Speicher-, Retrieval- und Integrationsdetails werden in ihren jeweiligen Fachkapiteln behandelt und nicht in diesem Nutzungsszenario vorgezogen.
+
 ---
 
 ## 3.4 Früheren Faden fortsetzen
@@ -377,6 +400,24 @@ Mögliche Einstiege:
 - „Ich habe noch einmal über unsere Diskussion nachgedacht.“
 - „Ich glaube, ich habe eine Antwort auf die offene Frage.“
 
+### Wiederaufnahme-Baseline
+
+**Status: entschieden; aus den bestehenden Dialog-, Space-, Memory-, Resurfacing- und Re-Grounding-Entscheidungen konsolidiert**
+
+Für diese Nutzungssituation gelten bereits folgende fachliche Entscheidungen:
+
+- `Contextual Continuation` ist der bevorzugte Default. Der Nutzer kann zugleich jederzeit frei fortsetzen oder gezielt zu einem früheren Dialog, Thread, Reflection Space, Tagebucheintrag oder anderen konkreten Kontext navigieren.
+- Kanshō rekonstruiert den relevanten bisherigen Denkstand aus Thread Memory, offenen Fragen, Zwischenständen, dem aktuellen quellengebundenen Space-Zustand und bei Bedarf den zugrunde liegenden Quellen. Der Nutzer soll wesentliche Informationen nicht regelmäßig wiederholen müssen.
+- Die sichtbare Orientierung bleibt kompakt und bedarfsbezogen. Maßgeblich sind der aktuelle Stand, derzeit relevante offene Punkte und ein sinnvoller Fortsetzungspunkt – nicht die ungefragte Wiedergabe der vollständigen Historie oder eines langen Summary-Blocks.
+- Bei einer eindeutigen direkten Fortsetzung reagiert Kanshō unmittelbar auf den neuen Nutzerimpuls und macht eine formale Zusammenfassung nicht zur Voraussetzung des Dialogs. Benötigter früherer Kontext wird natürlich in die Antwort integriert.
+- Die vollständige Historie bleibt zugänglich. Verdichtete Aussagen und sichtbare aktuelle Zustände müssen für den Nutzer auf ihre Quellen aufklappbar sein.
+- Bei Unsicherheit, Widerspruch, längeren Verdichtungsketten, möglicher Fehlinterpretation oder Nutzeranforderung muss Kanshō den relevanten Ursprungskontext re-grounden, statt eine frühere Summary lediglich erneut zu interpretieren.
+- Langfristig gespeicherte Threads werden nicht allein deshalb ungefragt hervorgeholt. Automatisches Resurfacing setzt aktuelle Relevanz voraus; die explizite Nutzerabsicht hat Vorrang.
+
+Damit ist die fachliche Kernfrage des Fortsetzens bereits beantwortet. Die genaue visuelle Darstellung, Textlänge und Interaktionsgestaltung bleiben spätere UX-Ausprägungen und werden nicht als neue fachliche Grundsatzentscheidung im Nutzungsszenario vorgezogen.
+
+Die Nutzungssituation **Früheren Faden fortsetzen** ist damit vorläufig ausreichend geklärt.
+
 ---
 
 ## 3.5 Tiefe Reflexion / biografische Frage
@@ -584,7 +625,7 @@ Zusätzlich werden je Situation geprüft:
 
 Für diese Nutzungssituation liegt eine fachliche Baseline vor. Spätere Konkretisierungen erfolgen in Journaling-, Dialog- und UX-Kapiteln.
 
-## 2. Tagesreflexion – in Bearbeitung
+## 2. Tagesreflexion – vorläufig ausreichend geklärt
 
 Bereits entschieden:
 
@@ -595,13 +636,24 @@ Bereits entschieden:
 - Flache, generische oder wiederkehrende Fragen sollen aktiv vermieden werden.
 - Kanshō soll sich an den individuellen Denk- und Antwortstil des Nutzers anpassen.
 - Nach dem ersten Impuls folgt kein starrer Fragenbaum; Kanshō reagiert adaptiv auf die tatsächliche Antwort.
+- Eine Tagesreflexions-Session darf enden, obwohl darin berührte Threads offen, wiedervorgelegt oder aktuell nicht relevant bleiben. Verbindlich gilt `Session Lifecycle ≠ Thread Lifecycle`.
+- Ein Session-Ende kann durch den expliziten Nutzerwunsch, durch eine angenommene Abschlussmöglichkeit bei Reflection Saturation oder durch einen natürlichen Gesprächsauslauf entstehen. Es darf keinen Thread allein dadurch als `Resolved` behandeln.
+- Der sichtbare Abschluss ist adaptiv und möglichst leicht: substanzielle Reflexionen erhalten grundsätzlich einen kurzen persönlichen Abschlussgedanken; kurze oder natürlich ausgelaufene Dialoge dürfen mit einer schlichten Bestätigung enden.
+- Offene Punkte, Wiedervorlagen und wenige Anschlussmöglichkeiten werden nur kontextuell gezeigt. Ein obligatorischer Ergebnisbildschirm oder eine Abschluss-Checkliste ist nicht vorgesehen.
+- Eine Tagesreflexion benötigt kein zwingendes Ergebnisartefakt. Unabhängig davon darf und muss Kanshō die für Kontinuität relevanten Originalquellen, Summaries, Erkenntnisse, offenen Fragen, Thread-Änderungen und möglichen Nebenfäden angemessen erhalten.
+- Interne Summaries sind abgeleitete, quellengebundene Kontinuitätsstrukturen und keine automatisch bestätigten Erkenntnisse. Bei Drift, Abweichung, möglicher Fehlinterpretation oder auf Nutzerwunsch gilt das Re-Grounding aus `context_fidelity_and_regrounding.md`.
+- Kontinuitätsarbeit kann bereits während einer langen Tagesreflexion erfolgen. Das Session-Ende ist ein zusätzlicher Prüfpunkt, aber weder der einzige Auslöser für Memory-/Summary-Pflege noch ein Zwang zur Erzeugung neuer Inhalte.
+- Bei einer substanziellen Tagesreflexion wird standardmäßig im Hintergrund ein persönlicher Journal-Entwurf vorbereitet und am natürlichen Abschluss dezent angeboten. Kurze Check-ins, reine Achtsamkeitssequenzen, fehlender erzählerischer Gehalt oder ein ausdrückliches „kein Tagebuch“ erzwingen keinen 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.
+- Die verlässliche Langzeitkommunikation und Rückführbarkeit auf den Dialog haben Vorrang vor maximaler Extraktion. Summaries und Ableitungen dürfen Erkenntnisse nicht verwässern oder durch Halluzinationen ersetzen.
 
-Noch zu klären:
+Frühere offene Punkte und aktualisierter Stand:
 
-- Wie erkennt Kanshō, dass heute eher keine tiefe Reflexion sinnvoll oder erwünscht ist?
+- Die frühere Frage „Wie erkennt Kanshō, dass heute eher keine tiefe Reflexion sinnvoll oder erwünscht ist?“ ist fachlich durch Intent-Abhängigkeit, persönliche Dialogtiefe, Gesprächssignale und Nutzerhoheit eingegrenzt. Die konkrete Erkennungslogik bleibt später technisch auszuarbeiten.
-- Wie soll Kanshō mit unscharfen Wiedervorlagen wie „später“ umgehen, ohne unnötig nachzufragen?
+- Die frühere Frage „Wie soll Kanshō mit unscharfen Wiedervorlagen wie ‚später‘ umgehen, ohne unnötig nachzufragen?“ ist durch kontextbezogene Ableitung und gezieltes Nachfragen nur bei notwendiger Verlässlichkeit eingegrenzt. Die konkrete Ausprägung bleibt später in Dialog- und UX-Konzeption zu prüfen.
-- Wann ist eine Tagesreflexion fachlich abgeschlossen?
+- Der Lebenszyklus der aktuellen Sitzung ist vom Lebenszyklus ihrer Threads getrennt. Die natürliche sichtbare Abschluss-Baseline ist entschieden; ihre genaue spätere UX-Darstellung bleibt konkretisierbar.
-- Welche Outputs entstehen standardmäßig am Ende?
+- Die Trennung zwischen optionalen Ergebnisartefakten und notwendiger interner Kontinuitätsarbeit ist entschieden. Die Rollen von Thread Memory, Reflection Frontier, Reflection Memory, Knowledge Delta und Action Candidate sind für die Tagesreflexion ausreichend geklärt; Detailheuristiken folgen später in ihren jeweiligen Fachkapiteln.
+- Das Default-Verhalten des Journal Entry und die Möglichkeit weiterer inhaltsabhängiger Persistierungen sind entschieden. Die Nutzungssituation ist damit vorläufig ausreichend geklärt; spätere Journaling-, Memory-, Integrations- und UX-Kapitel dürfen sie konkretisieren, aber nicht stillschweigend umdeuten.
 
 ## 7.2 Querverweis: Thread Resurfacing und Reflection Saturation
 
@@ -704,3 +756,6 @@ Ein umfassendes technisches Trigger-System wird daraus zu diesem Zeitpunkt noch
 | Dialogführung | explizit wählbar und zusätzlich durch Kanshō adaptiv erkennbar | bevorzugte Richtung |
 | Journal Entry | Ergebnis des Erfassungs-/Dialogprozesses, nicht zwingend direkte Eingabeform | bevorzugte Richtung |
 | Erleben festhalten – konkretes Dialogverhalten | differenziertes Arbeitsmodell vorhanden | in Bearbeitung |
+| Spontaner Gedanke – Erfassung | zuerst zuverlässig, reibungsarm und ohne ungefragtes Interview | entschieden |
+| Spontaner Gedanke – Quellbewahrung | unmittelbar und standardmäßig; spätere Einordnung davon getrennt | entschieden |
+| Früheren Faden fortsetzen | Contextual Continuation mit rekonstruiertem Denkstand; kompakte bedarfsbezogene Orientierung, Quellenzugang und Re-Grounding | entschieden |

docs/architecture/functional/writing_profile_and_journaling.md

@@ -97,6 +97,24 @@ Damit werden Inhaltstreue und sprachliche Gestaltung bewusst getrennt.
 
 ---
 
+## Journal Entry als häufiger, aber nicht zwingender Abschluss einer Tagesreflexion
+
+**Status: entschieden**
+
+Bei einer substanziellen Tagesreflexion wird standardmäßig im Hintergrund ein persönlicher Journal-Entwurf vorbereitet. Am natürlichen Abschluss wird dezent angeboten, ihn anzusehen, zu bearbeiten oder zu übernehmen.
+
+Dabei gilt:
+
+- Häufig wird aus einer Tagesreflexion ein Journal Entry entstehen.
+- Ein kurzer Check-in, eine reine Achtsamkeitssequenz oder ein Dialog ohne ausreichenden erzählerischen Inhalt erzwingt keinen Entwurf.
+- Wenn der Nutzer ausdrücklich nur reflektieren oder keinen Tagebucheintrag erzeugen möchte, entsteht keiner.
+- Automatische Vorbereitung bedeutet noch keine ungeprüfte endgültige Ablage.
+- Für den Entwurf gilt weiterhin die zweistufige Trennung zwischen inhaltlicher Rekonstruktion und persönlicher Narration.
+
+Der Journal Entry ist damit ein häufiger und hochwertiger Ausdruck der Tagesreflexion, aber weder ihr notwendiger Erfolgsnachweis noch ihr einzig möglicher persistierter Inhalt.
+
+---
+
 
 ## Querverweise