docs: clarify reflection closure and continuity model

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,6 +193,7 @@ Die ausführlichen Herleitungen der querschnittlichen Fachinvarianten werden nic
 
 - **Context Fidelity / Re-Grounding:** `context_fidelity_and_regrounding.md`
 - **Thread Resurfacing / Reflection Saturation:** `resurfacing_and_saturation.md`
+- **Session Lifecycle ≠ Thread Lifecycle:** `reflection_outputs.md` und `resurfacing_and_saturation.md`
 - **Point-in-Time Self / Lived Experience:** `self_model_and_lived_experience.md`
 - **Privacy Gateway / External-AI-Guardrails:** `guardrails.md`
 
@@ -241,6 +242,7 @@ Dieser Checkpoint dokumentiert den Abgleich mit dem bis zu diesem Zeitpunkt vorl
 Die fachliche Dokumentation ist nach Themen aufgeteilt. Ein Thema soll möglichst genau ein kanonisches fachliches Home besitzen.
 
 ```text
+handover.md
 fachliche_zielarchitektur.md
 produktvision_und_produktidentitaet.md
 documentation_index.md

docs/architecture/functional/interview_plan.md

@@ -869,6 +869,8 @@ Die unmittelbar nächste Sequenz sollte lauten:
 
 Diese Reihenfolge verhindert, dass technische Entscheidungen zu früh getroffen werden, bevor klar ist, welches Verhalten das Produkt tatsächlich benötigt.
 
+Parallel existiert seit 2026-08-19 eine **vorläufige technische Rahmenarchitektur** unter `docs/architecture/technical/` (Produktrahmen analog Mitai). Sie ersetzt Phasen F–G und I nicht. **Privacy Gateway und Guardrails** sind fachlich bereits Invariante (`guardrails.md`) und technisch bindend; Phase H vertieft Encryption, Löschen, Transparenz und Safety, ohne diese Invariante zu öffnen.
+
 ---
 
 ## 6. Interviewmethode
@@ -948,7 +950,7 @@ Technische Kapitel erhalten zusätzlich:
 | Reflection Spaces | fachliche Baseline vorläufig ausreichend geklärt; spätere Konkretisierung aus Dialog-, UX- und Memory-Kapiteln vorgesehen |
 | Nutzungssituationen | Typologie mit elf Situationen als vorläufig vollständige Baseline festgelegt |
 | Erleben festhalten | vorläufig ausreichend geklärt |
-| Tagesreflexion | in Bearbeitung; Einstieg, Priorisierung, Fokuswahl, adaptive Tiefe, Wiedervorlage und Resurfacing weitgehend geklärt |
+| Tagesreflexion | in Bearbeitung; Einstieg, Priorisierung, Fokuswahl, adaptive Tiefe, Wiedervorlage, Resurfacing und Trennung von Session-/Thread-Lebenszyklus geklärt |
 | Dialogmodell | wesentliche Baseline vorhanden; weitere Nutzungssituationen noch auszuarbeiten |
 | Threads | Grundmodell vorhanden; technisches State Model bewusst offen |
 | Thread Resurfacing | querschnittliches Fachkonzept entschieden |
@@ -992,16 +994,28 @@ Bereits geklärt sind insbesondere:
 - Thread Resurfacing als querschnittliches Konzept,
 - Reflection Saturation als Erkennung von möglicher Abschlussreife,
 - der Nutzer behält das letzte Wort über Weiterführen, Vertiefung, Wiedervorlage und Abschluss.
+- `Session Lifecycle ≠ Thread Lifecycle` als verbindliche Architekturregel; ein Session-Ende löst offene Threads nicht automatisch auf.
+- die bisher benannten Thread-Zustände sind eine nicht abschließende fachliche Baseline; weitere Zustände und Metainformationen bleiben im späteren Thread-/Datenmodell zu prüfen.
 
 ### Als Nächstes: Abschluss und Outputs der Tagesreflexion
 
+Im aktuellen Block wurde entschieden:
+
+- Die Session und ihre Threads besitzen getrennte Lebenszyklen.
+- Eine Session darf explizit durch den Nutzer, nach einer angenommenen Abschlussanregung bei Reflection Saturation oder durch natürlichen Gesprächsauslauf enden.
+- Das Session-Ende bedeutet nicht automatisch `Resolved` für beteiligte Threads.
+- Der sichtbare Abschluss ist adaptiv und möglichst leicht: kurzer persönlicher Abschlussgedanke bei substanziellen Reflexionen, schlichte Bestätigung bei kurzen oder natürlich ausgelaufenen Dialogen.
+- Offene Punkte, Wiedervorlagen und wenige Anschlussmöglichkeiten erscheinen nur kontextuell; es gibt keinen obligatorischen Ergebnisbildschirm und keine Abschluss-Checkliste.
+- Eine Tagesreflexion muss kein Ergebnisartefakt erzeugen. Der primäre Wert kann im Reflexions- beziehungsweise Achtsamkeitserleben selbst liegen.
+- Davon getrennt bleibt interne Kontinuitätsarbeit notwendig: Originalquelle, quellengebundene Summaries beziehungsweise Thread Memories, relevante Erkenntnisse, offene Fragen, mögliche Nebenfäden und tatsächliche Thread-Änderungen werden angemessen erhalten.
+- Interne Verdichtungen ersetzen die Originalquelle nicht. Bei Drift, Abweichung, möglicher Fehlinterpretation oder Nutzeranforderung gilt automatisches beziehungsweise nutzerinitiiertes Re-Grounding gemäß `context_fidelity_and_regrounding.md`.
+- Kontinuitätsarbeit ist eine laufende Systemverantwortung und nicht an das Session-Ende gebunden. Das Session-Ende dient als zusätzlicher Prüfpunkt; nur tatsächliche Änderungen werden fortgeschrieben, ohne Erkenntnisse, Nebenfäden oder sichtbare Outputs zu erzwingen.
+
 Noch fachlich zu entscheiden beziehungsweise zu bestätigen sind insbesondere:
 
-1. Welche sichtbaren Ergebnisse entstehen standardmäßig am Ende einer Tagesreflexion?
+1. Welche Inhalte verbleiben als quellengebundene Kontinuitätsstruktur und wann werden daraus Reflection Memory, Knowledge Delta oder andere langfristige Ableitungen?
-2. Welche internen Outputs entstehen immer, welche nur bei Relevanz?
+2. Nach welchen Kriterien entstehen Reflection Memory, Knowledge Delta und Action Candidate tatsächlich?
-3. Wie verhalten sich Session Output, Journal Entry, Reflection Memory, Knowledge Delta und Action Candidate zueinander?
+3. Wann wird ein Journal Entry automatisch vorbereitet, wann nur angeboten und wann bewusst nicht erzeugt?
-4. Soll die Trennung **`Session Lifecycle ≠ Thread Lifecycle`** als verbindliche Architekturregel übernommen werden?
-5. Wann wird ein Journal Entry automatisch vorbereitet, wann nur angeboten und wann bewusst nicht erzeugt?
 
 Nach vorläufigem Abschluss der Tagesreflexion folgt:
 

docs/architecture/functional/memory_and_context.md

@@ -138,3 +138,38 @@ Diese Entscheidung ist noch technisch zu validieren.
 
 ---
 
+## Kontinuitätsarbeit ohne zwingendes Output-Artefakt
+
+**Status: entschieden**
+
+Der Erfolg einer Reflexion hängt nicht davon ab, dass daraus zwingend ein Journal Entry, eine neue Erkenntnis, ein Knowledge Delta oder eine Handlungsabsicht entsteht.
+
+Davon unabhängig benötigt Kanshō interne Kontinuitätsarbeit, damit lange Dialoge, mehrere Threads und spätere Wiederaufnahmen ohne vermeidbaren Bedeutungsverlust möglich bleiben. Dazu können insbesondere gehören:
+
+- Erhalt des Originaldialogs beziehungsweise einer verlässlichen Originalrepräsentation,
+- Working-Context- und Thread-Memory-Summaries,
+- offene Fragen und Zwischenstände,
+- fachlich relevante Erkenntnisse,
+- vorläufig erkannte Nebenfäden oder Thread-Kandidaten,
+- Zeitbezug, Provenance, Confidence beziehungsweise Unsicherheit.
+
+Nicht jeder erkannte Nebenfaden muss zu einem sichtbaren oder dauerhaft eigenständigen Thread werden. Nicht jede Summary ist eine bestätigte Erkenntnis, und nicht jede Kontinuitätsstruktur ist ein sichtbarer Output.
+
+Da Summaries und weitere Verdichtungen selektiv sind, gelten für ihre langfristige Nutzung verbindlich die Regeln aus `context_fidelity_and_regrounding.md`: Die Originalquelle bleibt maßgeblich; bei ausreichendem Drift-Risiko, Abweichungen, Widersprüchen oder möglicher Fehlinterpretation muss Kanshō ein Re-Grounding aus den relevanten Ursprungsquellen auslösen können. Dies kann automatisch beziehungsweise systemseitig oder ausdrücklich durch den Nutzer angestoßen werden.
+
+Kontinuitätsarbeit ist nicht an das Ende einer Session gebunden. Sie darf und muss bei fachlichem Bedarf bereits während eines langen Dialogs erfolgen, insbesondere wenn der aktive Kontext sonst relevante Aussagen, Nebenfäden oder Zwischenstände verlieren würde.
+
+Das Session-Ende ist ein zusätzlicher fachlicher Kontinuitäts-Checkpoint. Dabei wird geprüft:
+
+- Ist die Originalquelle verlässlich erhalten?
+- Müssen Working Context, Summary oder Thread Memory aktualisiert werden?
+- Sind tatsächlich relevante Erkenntnisse, offene Fragen oder mögliche Nebenfäden entstanden?
+- Haben sich Thread-Zustand, Wiedervorlage oder andere Kontinuitätsinformationen tatsächlich verändert?
+- Besteht ein Drift- beziehungsweise Re-Grounding-Bedarf?
+
+Nur tatsächlich notwendige beziehungsweise entstandene Änderungen werden fortgeschrieben. Der Checkpoint erzeugt weder künstlich eine Erkenntnis noch einen Nebenfaden und verlangt kein sichtbares Output-Artefakt.
+
+Die konkrete technische Granularität, Speicherform und Aktualisierungslogik dieser Strukturen bleibt später auszuarbeiten.
+
+---
+

docs/architecture/functional/reflection_outputs.md

@@ -93,7 +93,90 @@ Kanshō selbst wird dadurch nicht zum Aufgaben- oder Projektmanager.
 
 ---
 
+## Session Lifecycle und Thread Lifecycle
+
+**Status: entschieden**
+
+### Root Cause
+
+Eine zeitlich begrenzte Nutzungssitzung und ein persönlicher Denk- oder Reflexionsfaden besitzen unterschiedliche natürliche Lebensdauern. Ein Gespräch kann für den aktuellen Moment ausreichend sein, obwohl sein Thema fachlich offen, bewusst wiedervorgelegt oder vorläufig nicht relevant bleibt.
+
+### Risiko
+
+Eine Kopplung beider Lebenszyklen würde entweder offene Themen beim Sitzungsende künstlich als gelöst behandeln oder Sitzungen unnötig offenhalten, solange noch ein weiterführbarer Thread existiert. Dadurch gingen natürliche Gesprächsabschlüsse, verlässliche Wiedervorlagen oder der tatsächliche Erkenntnisstand eines Threads verloren.
+
+### Fachliche Konsequenz und Architekturregel
+
+> **Session Lifecycle ≠ Thread Lifecycle**
+
+Das Ende einer Session bezeichnet das Ende der aktuellen Interaktion und der dazugehörigen Output-Verarbeitung. Es bedeutet nicht automatisch, dass alle in der Session berührten Threads abgeschlossen sind.
+
+Eine Session kann insbesondere enden durch:
+
+- einen expliziten Abschluss durch den Nutzer,
+- eine von Kanshō angebotene und vom Nutzer angenommene Abschlussmöglichkeit bei erkannter Reflection Saturation,
+- einen natürlichen Gesprächsauslauf, bei dem Kanshō einen kurzen oder für den Moment ausreichenden Intent nicht durch künstliche Folgefragen verlängert.
+
+Nach dem Session-Ende können betroffene Threads beispielsweise `Open`, `Anchored / Resurface`, `Dormant` oder `Resolved` sein. `Resolved` darf nur den für den derzeitigen Erkenntnisstand ausreichend bearbeiteten Thread bezeichnen; es folgt nicht allein aus dem Ende der Session.
+
+Die bisher benannten Thread-Zustände bilden ausdrücklich **keine abschließende Zustandsmenge und kein technisches State Model**. Ob weitere fachliche Zustände oder zusätzliche Metainformationen benötigt werden, wird in der späteren Ausarbeitung des Thread- und Datenmodells geprüft.
+
+---
+
+## Sichtbarer Abschluss einer Tagesreflexion
+
+**Status: entschieden**
+
+### Root Cause
+
+Der Abschluss soll dem Nutzer Orientierung und einen stimmigen Übergang aus der Reflexion geben. Gleichzeitig ist die Tagesreflexion ein natürlicher Dialog und kein formaler Workflow mit stets gleicher Ergebnisliste.
+
+### Risiko
+
+Ein obligatorischer Ergebnisbildschirm oder eine feste Abschluss-Checkliste würde auch kurze beziehungsweise natürlich auslaufende Gespräche künstlich verlängern und interne Modellkomplexität an die Oberfläche tragen. Ein vollständig unsichtbarer Abschluss könnte dagegen relevante offene Punkte, Wiedervorlagen oder sinnvolle Anschlussmöglichkeiten verlieren.
+
+### Fachliche Konsequenz und Entscheidung
+
+Der sichtbare Abschluss ist **adaptiv und möglichst leicht**. Der Standard bezeichnet ein Abschlussverhalten, nicht ein in jeder Session identisches Artefakt.
+
+Für eine substanzielle Tagesreflexion gilt grundsätzlich:
+
+- Kanshō gibt einen kurzen persönlichen Abschlussgedanken oder eine knappe Spiegelung statt einer vollständigen Gesprächszusammenfassung.
+- Offene Punkte und gesetzte Wiedervorlagen werden nur sichtbar gemacht, wenn sie tatsächlich bestehen und für den Abschluss relevant sind.
+- Es werden höchstens wenige kontextuelle Anschlussmöglichkeiten angeboten, beispielsweise „Tagebucheintrag ansehen“, „morgen weiter“ oder „noch vertiefen“.
+- Interne Outputs werden nicht allein aufgrund ihrer Existenz als technische Objekte präsentiert.
+
+Ein kurzer oder natürlich ausgelaufener Dialog darf mit einer schlichten Bestätigung enden. Kanshō erzeugt dann weder künstlich eine Zusammenfassung noch erzwingt es einen separaten Ergebnisbildschirm.
+
+Die hier vermiedene künstliche Zusammenfassung bezeichnet den **sichtbaren Abschluss**. Sie schließt interne, quellengebundene Summaries für Working Context, Thread Memory oder die langfristige Dialogkontinuität ausdrücklich nicht aus.
+
+Damit bleibt der Abschluss im Gespräch verankert. Eine spätere UX-Ausarbeitung darf seine Darstellung konkretisieren, aber daraus keinen verpflichtenden mehrstufigen Workflow machen.
+
+---
+
+## Reflexionserleben, Kontinuitätsarbeit und Output-Artefakte
+
+**Status: entschieden**
+
+Eine Tagesreflexion muss kein eigenständiges Ergebnisartefakt erzeugen, um fachlich sinnvoll oder erfolgreich zu sein. Ihr primärer Wert kann bereits im Wahrnehmen, Aussprechen, Reflektieren, vorläufigen Einordnen oder bewussten Offenlassen liegen.
+
+Davon zu unterscheiden ist die interne Kontinuitätsarbeit. Auch wenn kein Journal Entry, keine Reflection Memory, kein Knowledge Delta und kein Action Candidate entsteht, kann Kanshō insbesondere:
+
+- die verlässliche Originalrepräsentation des Dialogs als Primärquelle erhalten,
+- für lange Dialoge und spätere Wiederaufnahme quellengebundene Summaries beziehungsweise Thread Memories fortschreiben,
+- tatsächlich relevante Erkenntnisse, offene Fragen und mögliche Nebenfäden mit ihrem vorläufigen Status erhalten,
+- betroffene Thread-Zustände und Wiedervorlageanker aktualisieren,
+- zeitlichen Kontext, Provenance und Unsicherheit der abgeleiteten Strukturen bewahren.
+
+Diese Kontinuitätsstrukturen sind nicht automatisch sichtbare Session-Ergebnisse und nicht mit bestätigtem langfristigem Wissen gleichzusetzen. Ein möglicher Nebenfaden, eine Hypothese oder eine verdichtete Summary bleibt als vorläufige beziehungsweise abgeleitete Struktur gekennzeichnet.
+
+Summaries und andere Verdichtungen dürfen zur handhabbaren Fortsetzung über lange Dialoge hinweg verwendet werden. Sie ersetzen jedoch nicht die Originalquelle. Bei erkanntem Drift-Risiko, Widerspruch, möglicher Fehlinterpretation oder ausdrücklichem Nutzerwunsch wird der relevante Gesprächsverlauf gemäß `context_fidelity_and_regrounding.md` erneut aus den Ursprungsquellen analysiert und der verwendete Kontext gegebenenfalls neu abgeleitet.
+
+Kontinuitätsarbeit ist eine **laufende Systemverantwortung** und nicht ausschließlich ein Verarbeitungsschritt am Session-Ende. Summaries, Working Context oder Thread Memory dürfen bereits während eines langen Dialogs fortgeschrieben oder bei Bedarf neu aufgebaut werden. Das Session-Ende bildet lediglich einen zusätzlichen fachlichen Prüfpunkt, an dem notwendige Sicherungen, tatsächliche Änderungen und möglicher Re-Grounding-Bedarf bewertet werden. Es erzwingt weder eine neue Verdichtung noch ein Ergebnisartefakt.
+
+---
+
 
 ## Noch auszuarbeiten
 
-Beim Abschluss der laufenden Ausarbeitung der Nutzungssituation Tagesreflexion werden hier Session Output, Narrative Output, Long-Term Output sowie die Trennung `Session Lifecycle ≠ Thread Lifecycle` ergänzt.
+Beim Abschluss der laufenden Ausarbeitung der Nutzungssituation Tagesreflexion werden hier noch Session Output, Narrative Output und Long-Term Output sowie ihre konkreten Erzeugungs- und Persistenzregeln ergänzt. Die sichtbare Abschluss-Baseline ist entschieden; die genaue spätere UX-Darstellung bleibt konkretisierbar.

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/usage_situations.md

@@ -595,13 +595,20 @@ Bereits entschieden:
 - Flache, generische oder wiederkehrende Fragen sollen aktiv vermieden werden.
 - Kanshō soll sich an den individuellen Denk- und Antwortstil des Nutzers anpassen.
 - Nach dem ersten Impuls folgt kein starrer Fragenbaum; Kanshō reagiert adaptiv auf die tatsächliche Antwort.
+- Eine Tagesreflexions-Session darf enden, obwohl darin berührte Threads offen, wiedervorgelegt oder aktuell nicht relevant bleiben. Verbindlich gilt `Session Lifecycle ≠ Thread Lifecycle`.
+- Ein Session-Ende kann durch den expliziten Nutzerwunsch, durch eine angenommene Abschlussmöglichkeit bei Reflection Saturation oder durch einen natürlichen Gesprächsauslauf entstehen. Es darf keinen Thread allein dadurch als `Resolved` behandeln.
+- Der sichtbare Abschluss ist adaptiv und möglichst leicht: substanzielle Reflexionen erhalten grundsätzlich einen kurzen persönlichen Abschlussgedanken; kurze oder natürlich ausgelaufene Dialoge dürfen mit einer schlichten Bestätigung enden.
+- Offene Punkte, Wiedervorlagen und wenige Anschlussmöglichkeiten werden nur kontextuell gezeigt. Ein obligatorischer Ergebnisbildschirm oder eine Abschluss-Checkliste ist nicht vorgesehen.
+- Eine Tagesreflexion benötigt kein zwingendes Ergebnisartefakt. Unabhängig davon darf und muss Kanshō die für Kontinuität relevanten Originalquellen, Summaries, Erkenntnisse, offenen Fragen, Thread-Änderungen und möglichen Nebenfäden angemessen erhalten.
+- Interne Summaries sind abgeleitete, quellengebundene Kontinuitätsstrukturen und keine automatisch bestätigten Erkenntnisse. Bei Drift, Abweichung, möglicher Fehlinterpretation oder auf Nutzerwunsch gilt das Re-Grounding aus `context_fidelity_and_regrounding.md`.
+- Kontinuitätsarbeit kann bereits während einer langen Tagesreflexion erfolgen. Das Session-Ende ist ein zusätzlicher Prüfpunkt, aber weder der einzige Auslöser für Memory-/Summary-Pflege noch ein Zwang zur Erzeugung neuer Inhalte.
 
-Noch zu klären:
+Frühere offene Punkte und aktualisierter Stand:
 
-- Wie erkennt Kanshō, dass heute eher keine tiefe Reflexion sinnvoll oder erwünscht ist?
+- 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. Noch offen sind die konkreten Erzeugungs- und Persistenzregeln der einzelnen Artefakte.
 
 ## 7.2 Querverweis: Thread Resurfacing und Reflection Saturation