Kansho/docs/architecture/functional/interview_plan.md

title	status	date	product_family	document_role	parent_document
Kanshō – Interviewplan und Konzeptfortschritt	Arbeitsstand	2026-08-18	Jinkendo	Interview Plan / Progress / Definition of Done	fachliche_zielarchitektur.md

# Kanshō – Interviewplan und Konzeptfortschritt

4. Kapitelplan und Interviewreihenfolge

Die folgende Reihenfolge ist nicht identisch mit der späteren Ordnernummerierung. Sie ist danach geordnet, welche Entscheidungen aufeinander aufbauen.

---

Phase A – Identität und Lebenskontext

A1. Produktvision und Produktidentität

Status: weitgehend begonnen

Ziel des Interviews:

• die bewusst stärker KI-kollaborative Rolle von Kanshō innerhalb der Jinkendo-Familie erhalten und weiter schärfen,
• Produktkern endgültig schärfen,
• Nutzenversprechen definieren,
• Rolle innerhalb Jinkendo abgrenzen,
• Begriffe festlegen.

Leitfragen:

• Was soll Kanshō langfristig für einen Menschen sein?
• Welche Veränderung soll durch jahrelange Nutzung entstehen?
• Was soll die App ausdrücklich niemals werden?
• Woran erkennt man, dass eine Funktion „zu Kanshō gehört“?
• Was ist der Unterschied zwischen Reflexion, Coaching, Therapie, Journaling und Achtsamkeit innerhalb des Produkts?

Zieldateien:

• product_vision.md
• product_identity.md
• product_principles.md
• scope_and_non_goals.md
• jinkendo_product_boundaries.md

---

A2. Zielnutzer und Nutzung über Jahre

Ziel:

Nicht nur einzelne User Stories, sondern die langfristige Beziehung zwischen Mensch und Anwendung definieren.

Leitfragen:

• Ist Kanshō zunächst primär für den Ersteller selbst gedacht oder bereits als generisches Produkt?
• Welche Voraussetzungen muss ein Nutzer mitbringen?
• Wie verändert sich Kanshō nach einem Monat, einem Jahr und zehn Jahren?
• Welche Inhalte sind sehr privat?
• Welche Situationen führen spontan zur Nutzung?
• Welche Situationen führen zu geplanten Reflexionen?

Zieldateien:

• target_users.md
• usage_situations.md
• lifecycle_and_long_term_use.md

---

Phase B – Reflection Spaces und Dialog

B1. Reflection Contexts, Reflection Spaces und Reflection Intent

Ziel:

Das zentrale Kontextmodell definieren und klar zwischen dem thematischen Lebenskontext und der aktuellen Nutzungsabsicht unterscheiden.

Zusätzliche fachliche Leitplanken:

• Kanshō soll Strukturierungsarbeit weitgehend im Hintergrund übernehmen.
• Nicht jedes Seitenthema wird automatisch zu einem sichtbaren Thread oder Reflection Space.
• Die KI darf Zusammenhänge erkennen und Vorschläge zur Trennung oder Konsolidierung machen.
• Der Grad der KI-Autonomie bei Anlage und Konsolidierung soll konfigurierbar sein.
• Der Nutzer muss falsche Strukturierungen korrigieren können.
• Die konkrete technische Heuristik zur Bewertung von Relevanz, Wiederkehr, Tiefe oder Dauer wird in dieser Phase noch nicht festgelegt.
• Interne Struktur darf deutlich detaillierter sein als die sichtbare Nutzerstruktur.
• Für Entwicklung und Test muss diese interne Struktur in einer berechtigten Diagnoseansicht inspizierbar sein.

Vorläufige sichtbare Baseline eines geöffneten Reflection Space:

• Aktueller Stand
• Was ist noch offen?
• Weiterdenken
• Bisheriger Weg

Diese vier Elemente sind ein akzeptierter Ausgangspunkt und dürfen in späteren Dialog- und UX-Kapiteln konkretisiert werden.

Weitere bereits beschlossene Leitplanken:

• Reflection Spaces können sowohl über Tage/Wochen als auch langfristig über Monate oder Jahre relevant sein.
• Bedeutung und fortdauernde Relevanz sind wichtiger als eine feste Mindestdauer.
• aktuell nicht relevante Spaces dürfen in der normalen Oberfläche zurücktreten und später wieder hervorgeholt werden.
• verdichtete Aussagen müssen für den Nutzer auf ihre zugrunde liegenden Inhalte aufklappbar sein.
• diese Nutzer-Provenance ist von internem Re-Grounding der KI zu unterscheiden.

Leitfragen:

• Welche übergeordneten Lebensräume gibt es?
• Welche davon sind stabil?
• Welche entstehen dynamisch?
• Kann ein Erlebnis mehreren Räumen gleichzeitig angehören?
• Wie werden Räume erzeugt, zusammengeführt, beendet oder archiviert?
• Wie unterscheiden sich Kontext, Thema, Projekt, Rolle und Lebensbereich?
• Wie werden Kairo-Objekte und mindnet-Knoten verknüpft?
• Welche Reflection Intents gibt es?
• Welche Intents werden explizit gewählt und welche automatisch erkannt?
• Kann sich der Intent während eines Dialogs ändern?
• Wie beeinflusst der Intent das Verhalten der KI?

Zieldateien:

• reflection_contexts.md
• reflection_spaces.md
• reflection_space_model.md

---

B2. Gesprächseinstieg

Ziel:

Definieren, wie Kanshō einen Dialog beginnt.

Bereits entschieden:

• Default ist ein kontextbezogener Fortsetzungsvorschlag.
• Kanshō priorisiert einen Hauptvorschlag und zeigt nur wenige Alternativen.
• Der Nutzer kann jederzeit frei sprechen/schreiben oder gezielt navigieren.
• Der Einstieg folgt damit fachlich dem Muster Contextual Continuation → Free Reflection / Explicit Navigation.
• Die Startoberfläche soll Kontinuität des Dialogs zeigen und nicht primär ein Funktions-Dashboard sein.

Leitfragen:

• Öffnet der Nutzer die App ohne konkrete Absicht?
• Kann Kanshō einen Einstieg vorschlagen?
• Welche Informationen darf Kanshō für eine Einstiegsfrage verwenden?
• Wann ist eine frühere offene Frage wichtiger als das aktuelle Tagesgeschehen?
• Wie direkt oder zurückhaltend soll die KI sein?
• Darf Kanshō proaktiv schwierige Themen ansprechen?

Zieldateien:

• dialogue_entry.md
• home_and_entry_points.md

---

B3. Geführte Reflexion

Ziel:

Die eigentliche Gesprächsmethodik definieren.

Leitfragen:

• Welche Arten von Fragen stellt Kanshō?
• Wann spiegelt die KI?
• Wann fasst sie zusammen?
• Wann widerspricht sie?
• Wie tief darf sie nachfragen?
• Wie erkennt sie, dass ein Thema noch nicht ausreichend verstanden ist?
• Wie verhindert man mechanische Coaching-Fragen?

Zieldateien:

• dialogue_model.md
• guided_reflection.md
• reflection_model.md

---

B4. Dialogfäden und Branching

Ziel:

Mehrere parallele Denkfäden modellieren.

Leitfragen:

• Wann entsteht ein Thread?
• Muss der Nutzer ihn sehen?
• Wie erkennt die KI einen neuen Faden?
• Wann schlägt sie eine Trennung vor?
• Wie wird ein Faden geparkt?
• Wann wird ein alter Faden wieder angeboten?
• Wie werden Threads miteinander verbunden?

Zieldateien:

• threads_and_branching.md
• dialogue_data_model.md

---

B5. Abschluss eines Dialogs

Ziel:

Festlegen, was am Ende einer Reflexion geschieht.

Leitfragen:

• Muss jeder Dialog einen expliziten Abschluss haben?
• Welche Zusammenfassung sieht der Nutzer?
• Welche Erkenntnisse werden vorgeschlagen?
• Was wird gespeichert?
• Was wird verworfen?
• Was wird an andere Apps übergeben?
• Wann entsteht ein Tagebucheintrag?

Zieldateien:

• dialogue_closure.md
• reflection_outputs.md

---

Phase C – Gedächtnis, Identität und Langzeitbezug

C1. Memory Architecture

Ziel:

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?
• Welche abgeleiteten Memory-Strukturen dürfen automatisch erzeugt oder aktualisiert werden?
• Was benötigt Bestätigung?
• 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:

• memory_architecture.md
• working_context.md
• thread_memory.md
• episodic_memory.md

---

C2. Self Model

Ziel:

Definieren, wie Kanshō stabile persönliche Informationen repräsentiert.

Leitfragen:

• Was gehört zum Self Model?
• Was sind Werte?
• Was ist Leitbild?
• Was ist Rolle?
• Was ist Eigenschaft?
• Was ist nur momentane Selbstbeschreibung?
• Wie wird eine Hypothese bestätigt?
• Wie werden Widersprüche behandelt?
• Darf sich ein Wert verändern?

Zieldateien:

• self_model.md
• values_and_inner_alignment.md
• identity_and_profile_model.md

---

C3. Writing Profile

Ziel:

Eine persönliche Stimme über Jahre erhalten.

Leitfragen:

• Welche Texte gelten als authentische Stilreferenz?
• Wie stark soll Kanshō stilistisch imitieren?
• Was darf sprachlich geglättet werden?
• Wie viel Unperfektheit soll bewusst erhalten bleiben?
• Wie erkennt man Stiländerungen im Laufe des Lebens?
• Soll ein Tagebuchtext verschiedene historische Schreibstile respektieren?

Zieldateien:

• writing_profile.md
• personal_writing_style.md

---

C4. Zeit, Erinnerung und Widerspruch

Ziel:

Verhindern, dass das System vergangene und aktuelle Wahrheiten vermischt.

Leitfragen:

• Wie wird Zeit an Erinnerungen modelliert?
• Wie unterscheidet Kanshō „damals glaubte ich“ von „heute glaube ich“?
• Was passiert mit falschen Erinnerungen?
• Wie werden Korrekturen propagiert?
• Wie stark verlieren alte Informationen an Gewicht?
• Was bedeutet bewusstes Vergessen?

Zieldateien:

• temporal_memory.md
• conflicts_forgetting_and_correction.md
• versioning_and_provenance.md

---

C5. Context Builder

Ziel:

Definieren, welcher Kontext für eine konkrete LLM-Anfrage zusammengestellt wird.

Leitfragen:

• Welche Informationsquellen gibt es?
• Welche haben Priorität?
• Wie viel Working Context?
• Welche Erinnerungen?
• Welche Werte?
• Welche offenen Threads?
• Welche Informationen aus Mitai, Shinkan oder Kairo?
• Wie verhindert man Context Pollution?
• Wie wird Unsicherheit transportiert?

Zieldatei:

• context_builder.md

---

Phase D – Reflexionsintelligenz und Outputs

D1. Beobachtung, Interpretation und Hypothese

Ziel:

Ein erkenntnistheoretisch sauberes Modell schaffen.

Leitfragen:

• Wie unterscheiden wir Tatsache, Nutzerinterpretation und KI-Hypothese?
• Welche Confidence benötigen unterschiedliche Aussagen?
• Wer darf eine Hypothese bestätigen?
• Wie wird eine Hypothese später verworfen?
• Wie verhindert man scheinbare psychologische Gewissheit?

Zieldateien:

• observation_interpretation_hypothesis.md
• versioning_and_provenance.md

---

D2. Reflection Frontiers

Ziel:

Offene Bedeutungs- und Erkenntnisräume aus mindnet nutzbar machen.

Leitfragen:

• Was genau ist ein offenes Ende?
• Wie wird es erkannt?
• Wie wird Relevanz bewertet?
• Wann darf Kanshō es wieder aufgreifen?
• Wie verhindert man obsessives Wiederholen?
• Wann gilt eine Frontier als geschlossen?

Zieldatei:

• reflection_frontiers.md

---

D3. Muster und Entwicklung

Ziel:

Langfristige Entwicklung sichtbar machen, ohne vorschnelle Persönlichkeitsdiagnosen.

Leitfragen:

• Ab wann ist etwas ein Muster?
• Welche zeitliche Mindestbasis braucht es?
• Welche Rolle spielt Nutzerbestätigung?
• Wie werden Gegenbeispiele einbezogen?
• Welche Entwicklungen sollen sichtbar werden?
• Wie präsentiert Kanshō Veränderungen über Jahre?

Zieldateien:

• pattern_detection.md
• longitudinal_development.md

---

D4. Reflection Outputs

Ziel:

Definieren, welche Artefakte aus einem Dialog entstehen können.

Kandidaten:

• Journal Entry,
• Reflection Memory,
• Knowledge Delta,
• Action Candidate,
• aktualisierter Thread,
• neue oder geänderte Hypothese.

Leitfragen:

• Was entsteht automatisch?
• Was benötigt Zustimmung?
• Wo wird was gespeichert?
• Welche Outputs sind sichtbar?
• Welche existieren nur intern?

Zieldateien:

• reflection_outputs.md
• journal_entries.md
• reflection_memories.md
• knowledge_deltas.md
• action_candidates.md
• confirmation_and_human_in_the_loop.md

---

Phase E – Journaling, Achtsamkeit und Meditation

E1. Journaling

Ziel:

Das Tagebuch als hochwertigen Bestandteil ausformen, ohne Kanshō darauf zu reduzieren.

Leitfragen:

• Welche Funktionen des vom Nutzer explizit genannten Referenzrahmens Day One im „Gold“-Abo werden benötigt?
• Welche dieser Referenzfunktionen sollen bewusst anders gelöst oder nicht übernommen werden?
• Welche Funktionen sind für Kanshō zusätzlich erforderlich, weil Journaling hier in einen KI-gestützten Reflexionsdialog eingebettet ist?
• Welche Medien?
• Welche Metadaten?
• Welche Timeline?
• Welche Suche?
• Welche Rückblicke?
• Wie wird der aus einer täglichen Reflexion generierte Tagebucheintrag erzeugt, bestätigt, bearbeitet und abgelegt?
• Welche weiteren automatisch erzeugten Inhalte?
• Wie viel Nachbearbeitung durch den Nutzer?

Zieldateien:

• gesamter Ordner journaling/

---

E2. Achtsamkeit

Ziel:

Ein eigenes Achtsamkeitsverständnis für Kanshō definieren.

Leitfragen:

• Was bedeutet Achtsamkeit im Produkt?
• Welche Rolle spielt Wahrnehmung?
• Welche Rolle spielt Akzeptanz?
• Welche Rolle spielt Reflexion?
• Was unterscheidet Kanshō von klassischen Mindfulness Apps?
• Welche kurzen situativen Übungen sind sinnvoll?

Zieldateien:

• mindfulness_concept.md
• contextual_micro_interventions.md

---

E3. Meditation

Ziel:

Meditation funktional und methodisch definieren.

Leitfragen:

• vorgefertigt oder generiert?
• personalisiert oder allgemein?
• Stimme und Audio?
• Länge?
• aktuelle Lebenssituation als Kontext?
• sichere Grenzen?
• Nachreflexion?
• Historie?

Zieldateien:

• meditation_concept.md
• guided_meditations.md
• post_meditation_reflection.md

---

Phase F – Integration und technische Architektur

F1. mindnet und Obsidian

Ziel:

Die langfristige Wissens- und Archivarchitektur festlegen.

Leitfragen:

• Welche Informationen liest Kanshō aus mindnet?
• Welche schreibt es zurück?
• Was bleibt kanonisch in Obsidian?
• Was bleibt strukturiert in Datenbanken?
• Wie werden IDs und Backlinks erzeugt?
• Welche Edges werden benötigt?
• Wie werden Reflection Frontiers repräsentiert?

Zieldateien:

• mindnet_integration.md
• obsidian_integration.md

---

F2. Kairo, Mitai und Shinkan

Ziel:

Klare Integrationsverträge statt Funktionsduplikation.

Leitfragen:

• Welche Daten darf Kanshō lesen?
• Welche Daten darf es schreiben?
• Was wird nur vorgeschlagen?
• Was benötigt Bestätigung?
• Welche Events sind relevant?
• Welche Daten gehören fachlich weiterhin ausschließlich in die Quellanwendung?

Zieldateien:

• kairo_integration.md
• mitai_integration.md
• shinkan_integration.md
• integration_principles.md

---

F3. AI Architecture

Ziel:

Die technische Umsetzung der kollaborativen KI definieren.

Leitfragen:

• ein Modell oder mehrere Rollen?
• Reflection Agent?
• Memory Agent?
• Context Builder?
• Journal Writer?
• Critic/Verifier?
• Model Routing?
• lokale Modelle?
• Cloud Modelle?
• Prompt Registry?
• Evaluation?

Zieldateien:

• gesamter Ordner ai_architecture/

---

F4. Datenarchitektur

Ziel:

Kanonische Datenmodelle definieren.

Leitfragen:

• Conversation
• Message
• Thread
• Reflection Space
• Memory
• Hypothesis
• Insight
• Journal Entry
• Context Reference
• Action Candidate
• Writing Profile
• Self Model

Zieldateien:

• gesamter Ordner data_architecture/

---

Phase G – Experience, Voice, PWA und Offline

G1. Mobile-First Experience

Ziel:

Die Hauptnutzung auf dem Smartphone definieren.

Leitfragen:

• Was sieht der Nutzer beim Öffnen?
• Wie schnell kann eine Reflexion beginnen?
• Sprache oder Text?
• Einhandbedienung?
• Wie werden lange Dialoge dargestellt?
• Wie erscheinen frühere Threads?
• Wie vermeidet man Informationsüberladung?

Zieldateien:

• experience_principles.md
• mobile_first.md
• home_and_entry_points.md
• conversation_ui.md

---

G2. Desktop Experience

Ziel:

Desktop nicht nur als vergrößerte Mobile UI behandeln.

Leitfragen:

• Welche Tätigkeiten sind auf Desktop besser?
• Welche Mehrspaltenansichten?
• Journal und Dialog nebeneinander?
• Recherche in alten Reflexionen?
• Mindnet-Verbindungen?

Zieldatei:

• desktop_experience.md

---

G3. Sprache und Transkription

Ziel:

Voice als primäre mobile Interaktion prüfen.

Leitfragen:

• Push-to-talk?
• kontinuierliche Aufnahme?
• Live-Transkription?
• Audio speichern oder nach Transkription löschen?
• Korrektur vor Übergabe?
• offline?
• Unterbrechungen?
• Mischform Text + Sprache?

Zieldateien:

• gesamter Ordner voice_and_media/

---

G4. PWA und Offline

Ziel:

Festlegen, was ohne Netz noch funktioniert.

Leitfragen:

• lokale Journaleinträge?
• lokale Dialoge?
• lokale Transkription?
• lokale kleine Modelle?
• Sync Queue?
• Verschlüsselung?
• Konfliktauflösung?
• Installation auf iOS/Android/Desktop?

Zieldateien:

• gesamter Ordner pwa_and_offline/

---

Phase H – Datenschutz, Sicherheit und Vertrauen

H1. Privacy by Design

Ziel:

Besonders sensible persönliche Langzeitdaten schützen.

Leitfragen:

• Welche Daten sind besonders kritisch?
• Verschlüsselung at rest und in transit?
• lokale Speicherung?
• Cloud Verarbeitung?
• Export?
• vollständiges Löschen?
• selektives Vergessen?
• Zugriff anderer Jinkendo-Apps?

Zieldateien:

• privacy_principles.md
• sensitive_personal_data.md
• encryption_and_access.md
• export_delete_and_portability.md

---

H2. Memory Transparency

Ziel:

Der Nutzer muss verstehen und kontrollieren können, was Kanshō über ihn „weiß“.

Leitfragen:

• Kann man gespeicherte Memories ansehen?
• Quelle anzeigen?
• Confidence?
• korrigieren?
• löschen?
• Herleitung anzeigen?
• Self Model editieren?

Zieldatei:

• memory_transparency.md

---

H3. Safety Boundaries

Ziel:

Grenzen bei psychisch belastenden, medizinischen oder anderweitig hochriskanten Themen definieren.

Zieldateien:

• ai_safety_boundaries.md
• crisis_and_high_risk_scenarios.md
• conversation_safety_and_boundaries.md

---

Phase I – MVP und Delivery

I1. MVP-Schnitt

Ziel:

Nach vollständiger fachlicher Konzeption eine erste vertikale Produktversion definieren.

Wichtig:

Der MVP soll nicht dadurch entstehen, dass beliebige Features gestrichen werden. Er soll eine vollständige kleine Reflexionsschleife ermöglichen.

Eine mögliche spätere vertikale Scheibe könnte sein:

1. Reflexionsraum auswählen oder erkennen,
2. kontextbezogenes Gespräch starten,
3. Dialog führen,
4. Thread Memory erzeugen,
5. Tagebucheintrag generieren,
6. Nutzer bestätigt,
7. Eintrag nach Obsidian überführen,
8. Reflection Memory in mindnet schreiben.

Dies ist noch keine endgültige MVP-Entscheidung.

Zieldateien:

• gesamter Ordner product_delivery/

---

Phase J – Research und Benchmarking

Diese Phase kann parallel zu den anderen Phasen laufen.

Zu untersuchen sind insbesondere:

• Day One,
• KI-Journaling-Produkte,
• Reflection Apps,
• Mindfulness Apps,
• Meditation Apps,
• Personal Memory Systeme,
• Long-Term-Memory-Architekturen,
• Voice Journaling,
• Privacy Patterns,
• Personal AI.

Zieldateien:

• gesamter Ordner research/

---

5. Empfohlene Reihenfolge des weiteren Interviews

Die unmittelbar nächste Sequenz sollte lauten:

1. Reflection Spaces — fachliche Baseline abgeschlossen, spätere Konkretisierung möglich
2. typische Nutzungssituationen — nächster Interviewblock
3. Gesprächseinstieg
4. Dialogmethodik
5. Threads und Branching
6. Dialogabschluss und Outputs
7. Memory Architecture
8. Self Model
9. Writing Profile
10. Context Builder
11. Reflection Frontiers
12. Journaling
13. Achtsamkeit
14. Meditation
15. Integrationen
16. AI Architecture
17. Mobile UX / Voice
18. Offline
19. Privacy / Safety
20. MVP

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

Für jedes Kapitel wird derselbe Arbeitsmodus empfohlen.

Schritt 1 – Ausgangshypothese

Auf Basis der bisherigen Entscheidungen wird eine erste strukturierte Hypothese formuliert.

Schritt 2 – gezielte Fragen

Es werden nur Fragen gestellt, die echte Produktentscheidungen verändern können.

Schritt 3 – Szenarien

Die Entscheidung wird anhand konkreter Situationen geprüft.

Schritt 4 – Gegenbeispiele und Grenzfälle

Bewusst problematische oder widersprüchliche Situationen werden getestet.

Zusätzlich wird bei strukturellen Vereinfachungen ein Capability-Check durchgeführt, damit keine bereits vorgesehenen Kernfähigkeiten unbeabsichtigt verloren gehen.

Schritt 5 – Entscheidung

Ergebnis wird klassifiziert als:

• entschieden,
• bevorzugte Richtung,
• Hypothese,
• offen,
• verworfen.

Schritt 6 – Dokumentation

Das betreffende Kapitel wird als eigene Datei aktualisiert.

---

7. Definition of Done für ein Konzeptkapitel

Ein Kapitel gilt konzeptionell als ausreichend bearbeitet, wenn mindestens folgende Punkte beantwortet sind:

• Zweck,
• Begriffe,
• fachliche Verantwortung,
• zentrale Regeln,
• Nutzerinteraktion,
• Daten-/Informationsbedarf,
• Schnittstellen zu anderen Bereichen,
• Edge Cases,
• offene Punkte,
• getroffene Entscheidungen,
• bewusste Nicht-Ziele.

Technische Kapitel erhalten zusätzlich:

• Datenmodell,
• API-/Event-Bedarf,
• Persistenz,
• Fehlerfälle,
• Security-/Privacy-Auswirkungen,
• Offline-Auswirkungen,
• Testbarkeit.

---

8. Aktueller Fortschrittsstatus

Themenbereich	Status
Produktvision	weitgehend geklärt; spätere Präzisierungen möglich
Produktidentität	weitgehend entschieden
Produktgrenzen zu Jinkendo	weitgehend entschieden
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	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
Tiefe Reflexion / biografische Frage	vorläufig ausreichend geklärt; epistemische Vorsicht, Self-Model-Bestätigung und abgestufte Safety-Baseline 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 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
Lived Experience / Point-in-Time Self	als zusätzliche Ebene des digitalen Zwillings entschieden
Writing Profile	erste Prinzipien vorhanden
Reflection Frontiers	Konzeptidee vorhanden
Journaling	Kernanforderungen und zweistufige Generierung vorhanden
Meditation	nur grob
Achtsamkeit	nur grob
UX	fachliche Leitplanken vorhanden; Detailkonzept offen
Voice/Transkription	Anforderung vorhanden
Offline	Anforderung vorhanden
Integrationen	Produktgrenzen vorhanden, technische Verträge offen
Guardrails / Privacy Gateway	fachliche Baseline angelegt; Pseudonymisierung, lokale Identität und External-AI-Egress als Invarianten entschieden
AI Architecture	offen
Data Architecture	offen
Security / Privacy Detailarchitektur	offen; Guardrail-Baseline vorhanden
MVP	offen

---

9. Nächster Interviewblock

Die Nutzungssituation 2. Tagesreflexion ist vorläufig ausreichend geklärt.

Bereits geklärt sind insbesondere:

• der Einstieg mit einem intelligent priorisierten Hauptimpuls,
• wenige sichtbare Alternativen plus explizit aufrufbarer Themenkatalog,
• Vorrang der aktuellen Nutzerintention,
• grundsätzlich aktueller Tag vor älteren Threads,
• ältere Themen nur bei expliziter Fortsetzung oder erkennbarem aktuellem Bezug,
• adaptive Anpassung an persönlichen Denk-, Antwort- und Reflexionsstil,
• Vermeidung flacher und repetitiver Fragen,
• explizite Wiedervorlage für später / morgen / nächsten passenden Kontext,
• 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.

Tagesreflexion – vorläufig ausreichend geklärt

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.
• 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.

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: 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.

Nutzungssituation 5 – Tiefe Reflexion / biografische Frage: vorläufig ausreichend geklärt

Der gezielte Dokumentationsaudit ist erfolgt. Bereits entschieden sind:

• Kanshō darf bei diesem Intent gezielter und tiefer nachfragen als beim bloßen Festhalten eines Erlebnisses.
• Beobachtung, Nutzeräußerung, bestätigte Erkenntnis, Interpretation, Hypothese, vermuteter Zusammenhang und offene Frage müssen unterscheidbar bleiben.
• Ungesicherte Kausalzusammenhänge dürfen nicht als Tatsachen dargestellt werden; ungeklärte Zusammenhänge bleiben Reflection Frontiers.
• Ein grundlegendes persönliches Muster oder eine Identitätsaussage wird zunächst als Hypothese behandelt und erst nach bewusster Nutzerbestätigung Bestandteil des stabilen Self Models.
• Kanshō modelliert die zeitgebundene geäußerte Innenperspektive, nicht einen behaupteten objektiven psychischen Zustand.
• Bei Bedarf gelten Quellenbindung und Re-Grounding.

Die grundlegende Safety-Grenze ist entschieden:

• Kanshō bleibt Reflexions- und Achtsamkeitsbegleiter und wird kein medizinischer oder psychotherapeutischer Therapeut.
• Schmerzhaftes oder emotional intensives Material löst nicht automatisch einen Krisenmodus aus.
• Bei erheblicher Überforderung wird die Vertiefung nicht forciert; Kanshō verlangsamt, bietet Pause oder gegenwartsbezogene Wahrnehmung an und fragt nach dem aktuellen Bedarf.
• Wenn professionelle Unterstützung angemessen erscheint, wird sie vorsichtig, transparent und konkret empfohlen, ohne Diagnose oder generische Standardwarnung.
• Bei konkreten Anzeichen möglicher akuter Selbst- oder Fremdgefährdung hat Sicherheit Vorrang; Kanshō beendet die Tiefenexploration und unterstützt den Kontakt zu realen Menschen, professioneller Akuthilfe oder geeigneter Notfallhilfe.
• Sicherheitsreaktionen bleiben verhältnismäßig und kontextbezogen.

Konkrete Erkennungsindikatoren, Eskalationsstufen, Formulierungsleitlinien, regionale Hilfsangebote und technische beziehungsweise rechtliche Safety-Anforderungen verbleiben in Phase H3. Sie sind keine Voraussetzung mehr für den Abschluss dieses Nutzungsszenarios.

Aktiver Interviewblock: Nutzungssituation 6 – Entscheidung / Orientierung

Vor der ersten neuen Fachfrage wird erneut gezielt geprüft, welche Entscheidungen zu Reflection before Action, Werteabgleich, Perspektivwechsel, Action Candidates und der Produktgrenze zu Kairo bereits dokumentiert sind. Erst danach wird der nächste tatsächlich offene, praxisrelevante Entscheidungspunkt bestimmt.

Danach werden die verbleibenden Nutzungssituationen schrittweise nach derselben Interviewmethode ausgearbeitet.

Migrationshinweis

Dieses Dokument ist seit der Dokumentenaufteilung das kanonische Home für Interviewreihenfolge, Interviewmethode, Definition of Done und Fortschrittsstatus. Inhaltliche Aktualisierungen erfolgen künftig hier.