1503 lines
44 KiB
Markdown
1503 lines
44 KiB
Markdown
---
|
||
title: "Kanshō – Fachliche Zielarchitektur und Interviewplan"
|
||
version: "0.1"
|
||
status: "Arbeitsstand"
|
||
date: "2026-08-18"
|
||
product_family: "Jinkendo"
|
||
document_role: "Fachliche Zielarchitektur / Master Structure / Interview Plan"
|
||
---
|
||
|
||
# Kanshō – Fachliche Zielarchitektur und Interviewplan
|
||
|
||
## 1. Zweck dieses Dokuments
|
||
|
||
Dieses Dokument definiert die fachliche Zielarchitektur der Kanshō-Produktdokumentation.
|
||
|
||
Jedes fachlich relevante Kapitel soll später als **eigenständige Markdown-Datei** in Gitea geführt werden.
|
||
|
||
Damit werden drei Ziele verfolgt:
|
||
|
||
1. Die Dokumentation bleibt modular und versionierbar.
|
||
2. Einzelne Themen können weiterentwickelt werden, ohne andere Inhalte unbeabsichtigt zu verdichten oder zu überschreiben.
|
||
3. Die Kapitelstruktur bildet gleichzeitig den Fahrplan für den weiteren Konzeptdialog beziehungsweise das Interview.
|
||
|
||
Dieses Dokument ist somit:
|
||
|
||
- das **erste und führende Referenzdokument** der fachlichen Konzeption,
|
||
- Inhaltsverzeichnis,
|
||
- Dokumentationsarchitektur,
|
||
- Interviewplan,
|
||
- Fortschrittsübersicht.
|
||
|
||
Die übrigen fachlichen Dokumente werden aus dieser Zielarchitektur abgeleitet und fachlich hier eingeordnet.
|
||
|
||
---
|
||
|
||
# 2. Dokumentationsprinzipien
|
||
|
||
## 2.1 Keine stillschweigende Verdichtung
|
||
|
||
Ein bestehendes Kapitel wird nicht dadurch „verbessert“, dass ältere Inhalte ohne Kennzeichnung verschwinden.
|
||
|
||
Änderungen erfolgen durch:
|
||
|
||
- Ergänzung,
|
||
- explizite Ersetzung,
|
||
- Kennzeichnung als überholt,
|
||
- Decision Record,
|
||
- Gitea-Versionierung.
|
||
|
||
---
|
||
|
||
## 2.2 Entscheidungen und Ideen trennen
|
||
|
||
Jedes Kapitel soll klar unterscheiden zwischen:
|
||
|
||
- **Entschieden**
|
||
- **Bevorzugte Richtung**
|
||
- **Hypothese**
|
||
- **Offen**
|
||
- **Verworfen**
|
||
- **Später prüfen**
|
||
|
||
---
|
||
|
||
## 2.3 Herkunft von Aussagen erhalten
|
||
|
||
Wo sinnvoll soll kenntlich bleiben, ob ein Punkt stammt aus:
|
||
|
||
- expliziter Nutzeranforderung,
|
||
- gemeinsam getroffener Entscheidung,
|
||
- Architekturvorschlag,
|
||
- technischem Zwang,
|
||
- späterer Validierung,
|
||
- externem Research.
|
||
|
||
---
|
||
|
||
## 2.4 Keine unnötige Duplizierung
|
||
|
||
Ein Thema hat möglichst ein fachliches „Home“.
|
||
|
||
Andere Kapitel verlinken darauf, statt denselben Inhalt mehrfach vollständig zu kopieren.
|
||
|
||
---
|
||
|
||
## 2.5 Kapitel sind unabhängig versionierbar
|
||
|
||
Jede Datei erhält mindestens:
|
||
|
||
- Titel,
|
||
- Version,
|
||
- Status,
|
||
- Datum,
|
||
- Rolle des Dokuments.
|
||
|
||
Die **Dateinamen selbst bleiben stabil und enthalten keine Versionsnummern oder laufenden Nummerierungspräfixe**. Versionierung erfolgt über Gitea beziehungsweise die Dokumentmetadaten, nicht durch Umbenennen der Datei.
|
||
|
||
---
|
||
|
||
|
||
## 2.6 Trennung von fachlicher und technischer Konzeption
|
||
|
||
Die fachliche Zielarchitektur ist führend.
|
||
|
||
Im Interview wird zunächst beschrieben:
|
||
|
||
- welches Nutzererlebnis gewünscht ist,
|
||
- welche fachlichen Verantwortlichkeiten bestehen,
|
||
- welche Objekte oder Beziehungen für das Produktverständnis notwendig sind,
|
||
- welche Entscheidungen oder Kontrollen beim Nutzer liegen.
|
||
|
||
Die technische Umsetzung wird bewusst nachgelagert.
|
||
|
||
Ausnahmen sind nur dann sinnvoll, wenn eine technische Grundentscheidung:
|
||
|
||
- die fachliche Produktgrenze unmittelbar beeinflusst,
|
||
- später nur mit sehr hohem Aufwand revidierbar wäre,
|
||
- oder zwingende Auswirkungen auf Datenschutz, Offline-Fähigkeit, Sicherheit oder Integrationen hat.
|
||
|
||
Ziel ist, eine fachlich klare, aber handhabbare Architektur zu entwickeln und unnötige Frühkomplexität zu vermeiden.
|
||
|
||
|
||
## 2.7 Transparenz- und Diagnoseprinzip
|
||
|
||
Die normale Nutzeroberfläche soll interne KI-Strukturen bewusst abstrahieren.
|
||
|
||
Für Entwicklung, Test und Administration wird jedoch eine gesonderte **Admin-/Developer View** vorgesehen.
|
||
|
||
Diese dient insbesondere dazu, fachliche und später technische Entscheidungen nachvollziehen zu können, ohne die reguläre Nutzung mit interner Komplexität zu belasten.
|
||
|
||
Die Diagnoseansicht soll perspektivisch unter anderem Einblick geben in:
|
||
|
||
- Threads und Thread-Kandidaten,
|
||
- Reflection-Space-Zuordnungen,
|
||
- Konsolidierungsentscheidungen,
|
||
- Memory-Provenance,
|
||
- Confidence und Unsicherheit,
|
||
- Hypothesen,
|
||
- Context-Builder-Ergebnisse,
|
||
- verwendete Wissensquellen,
|
||
- Strukturänderungen.
|
||
|
||
Der Zugriff ist rollenbasiert und nicht für reguläre Nutzer vorgesehen.
|
||
|
||
Dieses Prinzip ist fachlich bereits entschieden; genaue UI, Berechtigungen und technische Implementierung werden später spezifiziert.
|
||
|
||
|
||
## 2.8 Schutz vor Übervereinfachung
|
||
|
||
Die Zielarchitektur folgt ausdrücklich **nicht** dem Prinzip, den internen Kern möglichst klein oder einfach zu halten.
|
||
|
||
Ziel ist vielmehr:
|
||
|
||
> **maximale Nutzereinfachheit bei ausreichender interner Intelligenz und Differenzierung.**
|
||
|
||
Daraus folgt für den Konzeptdialog:
|
||
|
||
- Fachliche Komplexität wird nicht allein deshalb entfernt, weil sie technisch unbequem ist.
|
||
- Interne Modelle dürfen komplex sein, wenn sie zur langfristigen Produktfähigkeit erforderlich sind.
|
||
- Die Benutzeroberfläche abstrahiert interne Komplexität.
|
||
- Automatisierung und KI-gestützte Strukturierung sollen Verwaltungsaufwand vom Nutzer fernhalten.
|
||
- Vor jeder größeren Vereinfachung ist ein Capability-Check durchzuführen.
|
||
|
||
### Capability-Check vor Modellvereinfachungen
|
||
|
||
Vor einer strukturellen Vereinfachung wird geprüft:
|
||
|
||
1. Welche bereits beschlossenen Anforderungen benötigen die Struktur?
|
||
2. Welche später vorgesehenen Fähigkeiten könnten betroffen sein?
|
||
3. Welche Integrationen hängen davon ab?
|
||
4. Welche Langzeitfunktionen wie Memory, Self Model, Threading, Provenance oder Konsolidierung würden eingeschränkt?
|
||
5. Ist die Vereinfachung reversibel?
|
||
6. Kann die wahrgenommene Komplexität stattdessen auf UX-Ebene reduziert werden?
|
||
|
||
Erst wenn diese Prüfung keine relevanten Funktionsverluste zeigt, soll eine interne Vereinfachung vorgenommen werden.
|
||
|
||
|
||
|
||
## 2.8.1 Herleitung architekturrelevanter Entscheidungen
|
||
|
||
Architekturrelevante Entscheidungen mit langfristiger Tragweite oder späterem Vereinfachungsrisiko sollen nicht nur als Lösung dokumentiert werden.
|
||
|
||
Wo die Begründung für die spätere Nachvollziehbarkeit wesentlich ist, wird zusätzlich folgende Struktur festgehalten:
|
||
|
||
1. **Root Cause** – welches zugrunde liegende Problem oder welche Systembedingung erzeugt den Bedarf?
|
||
2. **Risiko** – welche fachlichen oder qualitativen Folgen entstehen ohne Gegenmaßnahme?
|
||
3. **Fachliche Konsequenz** – welche Eigenschaft muss das Produkt deshalb besitzen?
|
||
4. **Abgeleitete Anforderung / Entscheidung** – welcher Mechanismus oder welche Architekturleitplanke folgt daraus?
|
||
|
||
Dieses Prinzip soll verhindern, dass später nur noch ein Architekturmechanismus sichtbar ist, während sein ursprünglicher Zweck verloren geht und die Entscheidung deshalb fälschlich als entbehrliche Komplexität behandelt wird.
|
||
|
||
## 2.9 Context Fidelity und Re-Grounding
|
||
|
||
|
||
### Root-Cause-Herleitung
|
||
|
||
Die Anforderung an Context Fidelity und Re-Grounding entsteht nicht aus dem Wunsch nach zusätzlicher technischer Komplexität, sondern aus einer strukturellen Eigenschaft langfristiger KI-gestützter Dialogsysteme.
|
||
|
||
#### Root Cause
|
||
|
||
Kanshō soll Reflexionen, Dialoge, Threads und persönliche Entwicklung über Monate und Jahre hinweg fortführen können.
|
||
|
||
Dafür kann nicht bei jeder Interaktion der vollständige historische Originalkontext in das aktive Kontextfenster geladen werden. Langfristige Inhalte müssen daher selektiert, zusammengefasst, verdichtet oder in abgeleitete Memory- beziehungsweise Zustandsstrukturen überführt werden.
|
||
|
||
Jede Verdichtung ist jedoch zwangsläufig selektiv. Sie kann:
|
||
|
||
- Details weglassen,
|
||
- Gewichtungen verändern,
|
||
- Mehrdeutigkeiten reduzieren,
|
||
- zeitliche Zusammenhänge vereinfachen,
|
||
- Interpretationen stärker wirken lassen als die ursprünglichen Aussagen,
|
||
- frühere Hypothesen ungewollt stabilisieren.
|
||
|
||
Problematisch wird dies insbesondere dann, wenn spätere Verdichtungen nicht mehr auf Originalquellen, sondern auf bereits verdichteten Zuständen aufbauen.
|
||
|
||
Es entsteht dann potenziell eine Kette wie:
|
||
|
||
`Originaldialog → Summary → Thread Memory → Reflection-Space-State → aktualisierte Zusammenfassung → neue Interpretation`
|
||
|
||
Mit jeder weiteren Stufe kann sich der verwendete Kontext schrittweise vom ursprünglichen Bedeutungsgehalt entfernen.
|
||
|
||
#### Risiko
|
||
|
||
Ohne Gegenmechanismus besteht langfristig das Risiko, dass Kanshō nicht mehr primär auf die tatsächlichen Erlebnisse, Aussagen und dokumentierten Erfahrungen des Nutzers reagiert, sondern zunehmend auf seine eigenen früheren Verdichtungen und Interpretationen davon.
|
||
|
||
Dies kann insbesondere zu folgenden Problemen führen:
|
||
|
||
- Verlust relevanter Nuancen,
|
||
- Verstärkung früherer Fehlinterpretationen,
|
||
- Umdeutung von Hypothesen zu scheinbaren Tatsachen,
|
||
- falsche Musterbildung,
|
||
- unzutreffende Verknüpfungen zwischen Lebensbereichen,
|
||
- fehlerhafte Fortschreibung des Self Models,
|
||
- verzerrte Einordnung persönlicher Werte oder Entwicklungen,
|
||
- scheinbar konsistente, aber biografisch falsche Langzeitnarrative.
|
||
|
||
Besonders kritisch ist dieses Risiko bei Aussagen mit hoher persönlicher Bedeutung, etwa zu:
|
||
|
||
- Werten,
|
||
- Leitbild,
|
||
- Selbstbild,
|
||
- biografischen Wendepunkten,
|
||
- langfristigen Mustern,
|
||
- tiefen persönlichen Konflikten,
|
||
- Vergangenheitsbewältigung.
|
||
|
||
#### Fachliche Konsequenz
|
||
|
||
Provenance allein reicht nicht aus.
|
||
|
||
Es genügt nicht, nur zu wissen, **woher** eine verdichtete Aussage ursprünglich stammt. Kanshō muss zusätzlich beurteilen können, **wann die aktuell verwendete Verdichtung nicht mehr ausreichend zuverlässig ist und der Ursprungskontext erneut nachvollzogen werden sollte**.
|
||
|
||
Der langfristige Kontext darf daher nicht unbegrenzt rekursiv aus bereits abgeleiteten Zuständen fortgeschrieben werden.
|
||
|
||
#### Abgeleitete Anforderung
|
||
|
||
Kanshō benötigt einen fachlichen Mechanismus zur Bewertung der Kontexttreue beziehungsweise des Drift-Risikos.
|
||
|
||
Dieser Mechanismus muss bei Bedarf ein **Re-Grounding** auslösen können.
|
||
|
||
Re-Grounding bedeutet:
|
||
|
||
- relevante Ursprungsquellen erneut abrufen,
|
||
- den aktuell verwendeten verdichteten Kontext dagegen prüfen,
|
||
- Abweichungen, Widersprüche und Bedeutungsverschiebungen erkennen,
|
||
- den aktuellen Zustand gegebenenfalls neu ableiten,
|
||
- frühere Zustände und Änderungen nachvollziehbar erhalten.
|
||
|
||
Der Vorgang muss sowohl:
|
||
|
||
- automatisch beziehungsweise systemseitig,
|
||
- als auch ausdrücklich durch den Nutzer
|
||
|
||
ausgelöst werden können.
|
||
|
||
Die konkrete technische Realisierung – beispielsweise als numerischer Drift Index, mehrdimensionale Fidelity-Metrik oder zustandsbasierte Bewertung – wird erst in der technischen Architektur festgelegt.
|
||
|
||
Die fachliche Anforderung an Re-Grounding gilt unabhängig von dieser späteren technischen Ausgestaltung.
|
||
|
||
Verdichtete Zustände, Thread Memories und Reflection-Space-Sichten dürfen nicht unbegrenzt rekursiv aufeinander aufbauen, ohne den ursprünglichen Kontext erneut zu prüfen.
|
||
|
||
Die fachliche Zielarchitektur fordert deshalb einen **Context-Fidelity-/Drift-Mechanismus**.
|
||
|
||
Dieser soll beantworten:
|
||
|
||
> Wie sicher kann Kanshō sein, dass der aktuell verwendete verdichtete Kontext noch ausreichend treu zu den zugrunde liegenden Quellen ist?
|
||
|
||
Bei ausreichendem Drift-Risiko wird ein **Re-Grounding** ausgelöst.
|
||
|
||
Re-Grounding bedeutet:
|
||
|
||
- relevante Ursprungsquellen erneut abrufen,
|
||
- bisherigen verdichteten Kontext gegen diese Quellen prüfen,
|
||
- Widersprüche und Veränderungen erkennen,
|
||
- den aktuellen Zustand gegebenenfalls neu ableiten,
|
||
- Provenance und Änderungshistorie erhalten.
|
||
|
||
Der Mechanismus muss sowohl:
|
||
|
||
- automatisch beziehungsweise systemseitig ausgelöst werden können,
|
||
- als auch ausdrücklich durch den Nutzer anforderbar sein.
|
||
|
||
Die konkrete technische Berechnung eines Index, Scores oder Zustandsmodells wird bewusst noch nicht festgelegt.
|
||
|
||
Für Entwicklung und Test soll die Admin-/Developer View später mindestens sichtbar machen können:
|
||
|
||
- letzten vollständigen Re-Grounding-Zeitpunkt,
|
||
- relevante Drift-/Fidelity-Indikatoren,
|
||
- verwendete Quellschichten,
|
||
- Gründe für ausgelöstes Re-Grounding,
|
||
- Unterschiede zwischen vorherigem und neu abgeleitetem Kontext.
|
||
|
||
|
||
## 2.10 Dokumentationsintegrität und Drift-Audit
|
||
|
||
Da die Produktkonzeption über einen langen Dialog hinweg entsteht, wird nicht nur der spätere Anwendungskontext, sondern auch die **Konzeptdokumentation selbst** gegen Drift geschützt.
|
||
|
||
Vor dem Wechsel in einen neuen größeren Themenblock oder vor einem Handover soll geprüft werden:
|
||
|
||
1. Sind alle expliziten Nutzeranforderungen seit dem letzten Audit dokumentiert?
|
||
2. Sind gemeinsam getroffene Entscheidungen vollständig erhalten?
|
||
3. Wurden ursprünglich konkrete Anforderungen ungewollt verallgemeinert oder abgeschwächt?
|
||
4. Wurden offene Punkte versehentlich als entschieden dargestellt oder umgekehrt?
|
||
5. Sind Root Causes und Begründungen architekturrelevanter Entscheidungen erhalten?
|
||
6. Widersprechen sich Zielarchitektur und Fach-/Produktdokumente?
|
||
7. Ist der Interviewstatus aktuell?
|
||
8. Wurden Inhalte stillschweigend gelöscht oder durch eine kürzere Formulierung ersetzt?
|
||
9. Sind Dateinamen und Repository-Struktur weiterhin mit den vereinbarten Gitea-Prinzipien konsistent?
|
||
|
||
Korrekturen aus einem Audit sollen additiv erfolgen. Inhaltliche Löschungen oder Verdichtungen dürfen nur vorgenommen werden, wenn sie als bewusste Änderung nachvollziehbar sind.
|
||
|
||
|
||
### Audit-Checkpoint 2026-08-18
|
||
|
||
Vor dem Wechsel vom Reflection-Space-Block zu den typischen Nutzungssituationen wurde die bestehende Dokumentation gegen den bisherigen Konzeptdialog geprüft.
|
||
|
||
Dabei wurden keine bewussten fachlichen Entscheidungen verworfen. Es wurden jedoch mehrere Stellen identifiziert, an denen frühere konkrete Aussagen zu allgemein geworden oder der Dokumentstatus veraltet war. Additiv beziehungsweise strukturell korrigiert wurden insbesondere:
|
||
|
||
- explizite Verankerung von Kanshō als bewusst stärker KI-kollaborative Jinkendo-Komponente,
|
||
- Wiederherstellung des konkret genannten Referenzrahmens „Day One im Gold-Abo“ für die spätere Journaling-Analyse,
|
||
- explizite Sicherung des generierten Tagebucheintrags als vorgesehene Kernfunktion der täglichen Reflexion,
|
||
- Dokumentation der vorläufigen sichtbaren Reflection-Space-Baseline,
|
||
- explizite Nutzer-Provenance beziehungsweise Aufklappbarkeit verdichteter Aussagen,
|
||
- Dokumentation, dass Reflection Spaces sowohl kurz-/mittelfristig als auch langfristig relevant sein können,
|
||
- Aktualisierung des Interviewstatus: Reflection Spaces vorläufig ausreichend geklärt; typische Nutzungssituationen als nächster Block,
|
||
- Entfernung numerischer Präfixe aus den vorgeschlagenen Gitea-Datei- und Ordnernamen,
|
||
- Korrektur inkonsistenter Kapitel- und Listenummerierungen,
|
||
- strukturelle Verschiebung des Prinzips „Einfachheit an der Oberfläche, Intelligenz im Kern“ aus den Integrationsprinzipien in die Produktprinzipien, ohne inhaltliche Kürzung.
|
||
|
||
Dieser Checkpoint dokumentiert den Abgleich mit dem bis zu diesem Zeitpunkt vorliegenden Konzeptdialog. Spätere Erkenntnisse können bestehende Punkte konkretisieren oder bewusst ändern, sollen diese Änderungen jedoch nachvollziehbar dokumentieren.
|
||
|
||
# 3. Vorgeschlagene Repository-Struktur
|
||
|
||
```text
|
||
kansho/
|
||
│
|
||
├── fachliche_zielarchitektur.md
|
||
├── produktvision_und_produktidentitaet.md
|
||
├── README.md
|
||
├── docs/
|
||
│ ├── governance/
|
||
│ │ ├── documentation_principles.md
|
||
│ │ ├── glossary.md
|
||
│ │ └── decision_log.md
|
||
│ │
|
||
│ ├── product/
|
||
│ │ ├── product_vision.md
|
||
│ │ ├── product_identity.md
|
||
│ │ ├── product_principles.md
|
||
│ │ ├── scope_and_non_goals.md
|
||
│ │ └── jinkendo_product_boundaries.md
|
||
│ │
|
||
│ ├── users_and_context/
|
||
│ │ ├── target_users.md
|
||
│ │ ├── reflection_contexts.md
|
||
│ │ ├── reflection_spaces.md
|
||
│ │ ├── usage_situations.md
|
||
│ │ └── lifecycle_and_long_term_use.md
|
||
│ │
|
||
│ ├── dialogue/
|
||
│ │ ├── dialogue_model.md
|
||
│ │ ├── dialogue_entry.md
|
||
│ │ ├── guided_reflection.md
|
||
│ │ ├── threads_and_branching.md
|
||
│ │ ├── dialogue_closure.md
|
||
│ │ └── conversation_safety_and_boundaries.md
|
||
│ │
|
||
│ ├── memory/
|
||
│ │ ├── memory_architecture.md
|
||
│ │ ├── working_context.md
|
||
│ │ ├── thread_memory.md
|
||
│ │ ├── episodic_memory.md
|
||
│ │ ├── self_model.md
|
||
│ │ ├── writing_profile.md
|
||
│ │ ├── temporal_memory.md
|
||
│ │ ├── conflicts_forgetting_and_correction.md
|
||
│ │ ├── context_builder.md
|
||
│ │ └── context_drift_and_regrounding.md
|
||
│ │
|
||
│ ├── reflection_intelligence/
|
||
│ │ ├── reflection_model.md
|
||
│ │ ├── observation_interpretation_hypothesis.md
|
||
│ │ ├── reflection_frontiers.md
|
||
│ │ ├── pattern_detection.md
|
||
│ │ ├── values_and_inner_alignment.md
|
||
│ │ └── longitudinal_development.md
|
||
│ │
|
||
│ ├── journaling/
|
||
│ │ ├── journal_model.md
|
||
│ │ ├── daily_reflection.md
|
||
│ │ ├── entry_generation.md
|
||
│ │ ├── personal_writing_style.md
|
||
│ │ ├── media_and_metadata.md
|
||
│ │ ├── search_and_recall.md
|
||
│ │ └── review_and_retrospective.md
|
||
│ │
|
||
│ ├── mindfulness_and_meditation/
|
||
│ │ ├── mindfulness_concept.md
|
||
│ │ ├── meditation_concept.md
|
||
│ │ ├── guided_meditations.md
|
||
│ │ ├── contextual_micro_interventions.md
|
||
│ │ └── post_meditation_reflection.md
|
||
│ │
|
||
│ ├── outputs_and_actions/
|
||
│ │ ├── reflection_outputs.md
|
||
│ │ ├── journal_entries.md
|
||
│ │ ├── reflection_memories.md
|
||
│ │ ├── knowledge_deltas.md
|
||
│ │ ├── action_candidates.md
|
||
│ │ └── confirmation_and_human_in_the_loop.md
|
||
│ │
|
||
│ ├── integrations/
|
||
│ │ ├── integration_principles.md
|
||
│ │ ├── mindnet_integration.md
|
||
│ │ ├── obsidian_integration.md
|
||
│ │ ├── kairo_integration.md
|
||
│ │ ├── mitai_integration.md
|
||
│ │ ├── shinkan_integration.md
|
||
│ │ └── shared_jinkendo_services.md
|
||
│ │
|
||
│ ├── ai_architecture/
|
||
│ │ ├── ai_architecture_overview.md
|
||
│ │ ├── agent_roles.md
|
||
│ │ ├── prompt_architecture.md
|
||
│ │ ├── retrieval_strategy.md
|
||
│ │ ├── memory_write_policy.md
|
||
│ │ ├── model_routing.md
|
||
│ │ ├── local_vs_cloud_ai.md
|
||
│ │ └── evaluation_and_quality.md
|
||
│ │
|
||
│ ├── data_architecture/
|
||
│ │ ├── domain_model.md
|
||
│ │ ├── dialogue_data_model.md
|
||
│ │ ├── memory_data_model.md
|
||
│ │ ├── reflection_space_model.md
|
||
│ │ ├── identity_and_profile_model.md
|
||
│ │ ├── versioning_and_provenance.md
|
||
│ │ └── retention_and_deletion.md
|
||
│ │
|
||
│ ├── ux/
|
||
│ │ ├── experience_principles.md
|
||
│ │ ├── mobile_first.md
|
||
│ │ ├── home_and_entry_points.md
|
||
│ │ ├── conversation_ui.md
|
||
│ │ ├── journal_ui.md
|
||
│ │ ├── reflection_history.md
|
||
│ │ ├── desktop_experience.md
|
||
│ │ ├── accessibility.md
|
||
│ │ └── admin_developer_view.md
|
||
│ │
|
||
│ ├── voice_and_media/
|
||
│ │ ├── voice_interaction.md
|
||
│ │ ├── transcription.md
|
||
│ │ ├── audio_capture.md
|
||
│ │ ├── text_audio_switching.md
|
||
│ │ └── media_handling.md
|
||
│ │
|
||
│ ├── pwa_and_offline/
|
||
│ │ ├── pwa_architecture.md
|
||
│ │ ├── offline_capabilities.md
|
||
│ │ ├── local_storage.md
|
||
│ │ ├── sync_strategy.md
|
||
│ │ ├── conflict_resolution.md
|
||
│ │ └── notifications_and_background_behaviour.md
|
||
│ │
|
||
│ ├── privacy_security_safety/
|
||
│ │ ├── privacy_principles.md
|
||
│ │ ├── sensitive_personal_data.md
|
||
│ │ ├── encryption_and_access.md
|
||
│ │ ├── memory_transparency.md
|
||
│ │ ├── export_delete_and_portability.md
|
||
│ │ ├── ai_safety_boundaries.md
|
||
│ │ ├── crisis_and_high_risk_scenarios.md
|
||
│ │ └── roles_and_permissions.md
|
||
│ │
|
||
│ ├── product_delivery/
|
||
│ │ ├── mvp_definition.md
|
||
│ │ ├── release_slices.md
|
||
│ │ ├── dependencies.md
|
||
│ │ ├── test_strategy.md
|
||
│ │ └── acceptance_criteria.md
|
||
│ │
|
||
│ └── research/
|
||
│ ├── market_landscape.md
|
||
│ ├── day_one_benchmark.md
|
||
│ ├── ai_journaling_benchmark.md
|
||
│ ├── meditation_benchmark.md
|
||
│ └── research_evidence.md
|
||
│
|
||
└── decisions/
|
||
└── ADR-xxxx-*.md
|
||
```
|
||
|
||
Die genaue Ordnerstruktur kann später vereinfacht werden. Inhaltlich sollte die Trennung jedoch erhalten bleiben.
|
||
|
||
---
|
||
|
||
# 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 | begonnen / bereits relativ klar |
|
||
| Produktidentität | weitgehend entschieden |
|
||
| Produktgrenzen zu Jinkendo | weitgehend entschieden |
|
||
| Reflection Spaces | fachliche Baseline zunächst ausreichend geklärt; spätere Konkretisierung aus Dialog-, UX- und Memory-Kapiteln ausdrücklich vorgesehen |
|
||
| Dialogmodell | erste Leitplanken vorhanden |
|
||
| Threads | Grundidee vorhanden |
|
||
| Memory Architecture | erstes Schichtenmodell vorhanden |
|
||
| mindnet-Rolle | Grundrichtung vorhanden |
|
||
| Self Model | erste Prinzipien vorhanden |
|
||
| Writing Profile | erste Prinzipien vorhanden |
|
||
| Reflection Frontiers | Konzeptidee vorhanden |
|
||
| Journaling | Anforderungen grob |
|
||
| Meditation | nur grob |
|
||
| Achtsamkeit | nur grob |
|
||
| UX | technische Leitplanken vorhanden |
|
||
| Voice/Transkription | Anforderung vorhanden |
|
||
| Offline | Anforderung vorhanden |
|
||
| Integrationen | Produktgrenzen vorhanden, technische Verträge offen |
|
||
| AI Architecture | offen |
|
||
| Data Architecture | offen |
|
||
| Privacy/Safety | offen |
|
||
| MVP | offen |
|
||
|
||
---
|
||
|
||
# 9. Nächster Interviewblock
|
||
|
||
Der Reflection-Space-Block ist für den aktuellen Konzeptstand **vorläufig ausreichend geklärt**.
|
||
|
||
Die dort getroffenen Entscheidungen sind keine endgültige Detailausarbeitung. Insbesondere sichtbare Inhalte, Granularität und Interaktionsdetails dürfen in späteren Dialog-, UX- und Memory-Kapiteln konkretisiert werden, ohne die bisherige fachliche Baseline stillschweigend zu ersetzen.
|
||
|
||
## Als Nächstes: typische Nutzungssituationen
|
||
|
||
Ziel des nächsten Interviewblocks ist zu klären:
|
||
|
||
> In welchen konkreten Situationen nutzt ein Mensch Kanshō, mit welcher Absicht kommt er in die Anwendung und welches Verhalten erwartet er jeweils von der KI?
|
||
|
||
Dabei sollen insbesondere unterschiedliche Situationen betrachtet werden, zum Beispiel:
|
||
|
||
- tägliche Reflexion,
|
||
- einen Urlaubstag oder ein Erlebnis autobiografisch festhalten,
|
||
- einen spontanen Gedanken erfassen,
|
||
- an einen früheren Dialog anknüpfen,
|
||
- eine offene Frage beantworten,
|
||
- tiefe persönliche Reflexion,
|
||
- Beruf und Entscheidungen,
|
||
- Vergangenheitsbewältigung,
|
||
- Ziele und Visionen,
|
||
- Inspiration und Kreativität,
|
||
- allgemeines Befinden,
|
||
- Achtsamkeit,
|
||
- Meditation.
|
||
|
||
Dieser Block dient als Grundlage dafür, die spätere Dialogmethodik nicht abstrakt, sondern anhand realer Nutzungssituationen zu entwickeln.
|