1029 lines
27 KiB
Markdown
1029 lines
27 KiB
Markdown
---
|
||
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?
|
||
- 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.
|
||
|
||
**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?
|
||
- Was benötigt Bestätigung?
|
||
- Was darf später vergessen werden?
|
||
|
||
**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 | 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 |
|
||
| Reflection Saturation | querschnittliches Fachkonzept entschieden; konkrete technische Berechnung später |
|
||
| Memory Architecture | erstes Schichtenmodell vorhanden |
|
||
| 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
|
||
|
||
Aktiv ist weiterhin die Nutzungssituation **2. Tagesreflexion**.
|
||
|
||
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.
|
||
|
||
### 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 Inhalte verbleiben als quellengebundene Kontinuitätsstruktur und wann werden daraus Reflection Memory, Knowledge Delta oder andere langfristige Ableitungen?
|
||
2. Nach welchen Kriterien entstehen Reflection Memory, Knowledge Delta und Action Candidate tatsächlich?
|
||
3. Wann wird ein Journal Entry automatisch vorbereitet, wann nur angeboten und wann bewusst nicht erzeugt?
|
||
|
||
Nach vorläufigem Abschluss der Tagesreflexion folgt:
|
||
|
||
### Nutzungssituation 3 – Spontaner Gedanke / Moment
|
||
|
||
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.
|