title: "Kanshō – Interviewplan und Konzeptfortschritt"
status: "Arbeitsstand"
date: "2026-08-18"
product_family: "Jinkendo"
document_role: "Interview Plan / Progress / Definition of Done"
parent_document: "fachliche_zielarchitektur.md"
---
# Kanshō – Interviewplan und Konzeptfortschritt
<!-- Migriert aus `fachliche_zielarchitektur.md`: ehemalige Abschnitte 4–9. Inhalt fachlich unverkuerzt; nur Heading-Level fuer die neue Dateistruktur angepasst. -->
## 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?
- 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?
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.
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:
-`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.
- 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.
- 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.
-`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.
- 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.
Der gezielte Dokumentationsaudit ist erfolgt. Bereits entschieden sind:
-`Reflection before Action`: Erst verstehen und einordnen, dann gegebenenfalls handeln.
- Kanshō unterstützt insbesondere Perspektivwechsel, Werteabgleich, innere Zielkonflikte, Prioritäten und die persönliche Bedeutung einer Entscheidung.
- Das Ziel einer Entscheidungsreflexion ist nicht automatisch die Erzeugung einer Aufgabe.
- Aus einer tatsächlich entstandenen Handlungsabsicht kann ein Action Candidate hervorgehen; Kanshō bietet die Übergabe an Kairo an.
- Kairo bleibt für Ziele, Planung, Operationalisierung, Rituale, Aufgaben und Next Best Actions zuständig. Kanshō übernimmt keine dauerhafte Aufgaben- oder Zielverwaltung.
- Entscheidungen mit persönlicher Tragweite können zusätzlich quellengebundene langfristige Persistierungen in Obsidian beziehungsweise mindnet begründen.
Der nächste tatsächlich offene, praxisrelevante Entscheidungspunkt ist die **Stärke der KI-Positionierung im Entscheidungsdialog**: Darf Kanshō nach ausreichender Reflexion eine begründete eigene Einschätzung oder Empfehlung aussprechen, oder soll es primär neutral spiegeln, Perspektiven öffnen und die Schlussfolgerung vollständig dem Nutzer überlassen?
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.
