1015 lines
25 KiB
Markdown
1015 lines
25 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.
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 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 und Resurfacing weitgehend 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.
|
|||
|
|
|
|||
|
|
### Als Nächstes: Abschluss und Outputs der Tagesreflexion
|
|||
|
|
|
|||
|
|
Noch fachlich zu entscheiden beziehungsweise zu bestätigen sind insbesondere:
|
|||
|
|
|
|||
|
|
1. Welche sichtbaren Ergebnisse entstehen standardmäßig am Ende einer Tagesreflexion?
|
|||
|
|
2. Welche internen Outputs entstehen immer, welche nur bei Relevanz?
|
|||
|
|
3. Wie verhalten sich Session Output, Journal Entry, Reflection Memory, Knowledge Delta und Action Candidate zueinander?
|
|||
|
|
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:
|
|||
|
|
|
|||
|
|
### 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.
|