diff --git a/docs/architecture/functional/fachliche_zielarchitektur.md b/docs/architecture/functional/fachliche_zielarchitektur.md index 0198a0b..8da0689 100644 --- a/docs/architecture/functional/fachliche_zielarchitektur.md +++ b/docs/architecture/functional/fachliche_zielarchitektur.md @@ -93,6 +93,8 @@ Jede Datei erhält mindestens: - 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. + --- @@ -308,161 +310,202 @@ Für Entwicklung und Test soll die Admin-/Developer View später mindestens sich - 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/ -│ ├── 00_governance/ -│ │ ├── 00_documentation_principles.md -│ │ ├── 01_glossary.md -│ │ └── 02_decision_log.md +│ ├── governance/ +│ │ ├── documentation_principles.md +│ │ ├── glossary.md +│ │ └── decision_log.md │ │ -│ ├── 01_product/ -│ │ ├── 01_product_vision.md -│ │ ├── 02_product_identity.md -│ │ ├── 03_product_principles.md -│ │ ├── 04_scope_and_non_goals.md -│ │ └── 05_jinkendo_product_boundaries.md +│ ├── product/ +│ │ ├── product_vision.md +│ │ ├── product_identity.md +│ │ ├── product_principles.md +│ │ ├── scope_and_non_goals.md +│ │ └── jinkendo_product_boundaries.md │ │ -│ ├── 02_users_and_context/ -│ │ ├── 01_target_users.md -│ │ ├── 02_reflection_contexts.md -│ │ ├── 03_reflection_spaces.md -│ │ ├── 04_usage_situations.md -│ │ └── 05_lifecycle_and_long_term_use.md +│ ├── users_and_context/ +│ │ ├── target_users.md +│ │ ├── reflection_contexts.md +│ │ ├── reflection_spaces.md +│ │ ├── usage_situations.md +│ │ └── lifecycle_and_long_term_use.md │ │ -│ ├── 03_dialogue/ -│ │ ├── 01_dialogue_model.md -│ │ ├── 02_dialogue_entry.md -│ │ ├── 03_guided_reflection.md -│ │ ├── 04_threads_and_branching.md -│ │ ├── 05_dialogue_closure.md -│ │ └── 06_conversation_safety_and_boundaries.md +│ ├── dialogue/ +│ │ ├── dialogue_model.md +│ │ ├── dialogue_entry.md +│ │ ├── guided_reflection.md +│ │ ├── threads_and_branching.md +│ │ ├── dialogue_closure.md +│ │ └── conversation_safety_and_boundaries.md │ │ -│ ├── 04_memory/ -│ │ ├── 01_memory_architecture.md -│ │ ├── 02_working_context.md -│ │ ├── 03_thread_memory.md -│ │ ├── 04_episodic_memory.md -│ │ ├── 05_self_model.md -│ │ ├── 06_writing_profile.md -│ │ ├── 07_temporal_memory.md -│ │ ├── 08_conflicts_forgetting_and_correction.md -│ │ ├── 09_context_builder.md -│ │ └── 10_context_drift_and_regrounding.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 │ │ -│ ├── 05_reflection_intelligence/ -│ │ ├── 01_reflection_model.md -│ │ ├── 02_observation_interpretation_hypothesis.md -│ │ ├── 03_reflection_frontiers.md -│ │ ├── 04_pattern_detection.md -│ │ ├── 05_values_and_inner_alignment.md -│ │ └── 06_longitudinal_development.md +│ ├── reflection_intelligence/ +│ │ ├── reflection_model.md +│ │ ├── observation_interpretation_hypothesis.md +│ │ ├── reflection_frontiers.md +│ │ ├── pattern_detection.md +│ │ ├── values_and_inner_alignment.md +│ │ └── longitudinal_development.md │ │ -│ ├── 06_journaling/ -│ │ ├── 01_journal_model.md -│ │ ├── 02_daily_reflection.md -│ │ ├── 03_entry_generation.md -│ │ ├── 04_personal_writing_style.md -│ │ ├── 05_media_and_metadata.md -│ │ ├── 06_search_and_recall.md -│ │ └── 07_review_and_retrospective.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 │ │ -│ ├── 07_mindfulness_and_meditation/ -│ │ ├── 01_mindfulness_concept.md -│ │ ├── 02_meditation_concept.md -│ │ ├── 03_guided_meditations.md -│ │ ├── 04_contextual_micro_interventions.md -│ │ └── 05_post_meditation_reflection.md +│ ├── mindfulness_and_meditation/ +│ │ ├── mindfulness_concept.md +│ │ ├── meditation_concept.md +│ │ ├── guided_meditations.md +│ │ ├── contextual_micro_interventions.md +│ │ └── post_meditation_reflection.md │ │ -│ ├── 08_outputs_and_actions/ -│ │ ├── 01_reflection_outputs.md -│ │ ├── 02_journal_entries.md -│ │ ├── 03_reflection_memories.md -│ │ ├── 04_knowledge_deltas.md -│ │ ├── 05_action_candidates.md -│ │ └── 06_confirmation_and_human_in_the_loop.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 │ │ -│ ├── 09_integrations/ -│ │ ├── 01_integration_principles.md -│ │ ├── 02_mindnet_integration.md -│ │ ├── 03_obsidian_integration.md -│ │ ├── 04_kairo_integration.md -│ │ ├── 05_mitai_integration.md -│ │ ├── 06_shinkan_integration.md -│ │ └── 07_shared_jinkendo_services.md +│ ├── integrations/ +│ │ ├── integration_principles.md +│ │ ├── mindnet_integration.md +│ │ ├── obsidian_integration.md +│ │ ├── kairo_integration.md +│ │ ├── mitai_integration.md +│ │ ├── shinkan_integration.md +│ │ └── shared_jinkendo_services.md │ │ -│ ├── 10_ai_architecture/ -│ │ ├── 01_ai_architecture_overview.md -│ │ ├── 02_agent_roles.md -│ │ ├── 03_prompt_architecture.md -│ │ ├── 04_retrieval_strategy.md -│ │ ├── 05_memory_write_policy.md -│ │ ├── 06_model_routing.md -│ │ ├── 07_local_vs_cloud_ai.md -│ │ └── 08_evaluation_and_quality.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 │ │ -│ ├── 11_data_architecture/ -│ │ ├── 01_domain_model.md -│ │ ├── 02_dialogue_data_model.md -│ │ ├── 03_memory_data_model.md -│ │ ├── 04_reflection_space_model.md -│ │ ├── 05_identity_and_profile_model.md -│ │ ├── 06_versioning_and_provenance.md -│ │ └── 07_retention_and_deletion.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 │ │ -│ ├── 12_ux/ -│ │ ├── 01_experience_principles.md -│ │ ├── 02_mobile_first.md -│ │ ├── 03_home_and_entry_points.md -│ │ ├── 04_conversation_ui.md -│ │ ├── 05_journal_ui.md -│ │ ├── 06_reflection_history.md -│ │ ├── 07_desktop_experience.md -│ │ ├── 08_accessibility.md -│ │ └── 09_admin_developer_view.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 │ │ -│ ├── 13_voice_and_media/ -│ │ ├── 01_voice_interaction.md -│ │ ├── 02_transcription.md -│ │ ├── 03_audio_capture.md -│ │ ├── 04_text_audio_switching.md -│ │ └── 05_media_handling.md +│ ├── voice_and_media/ +│ │ ├── voice_interaction.md +│ │ ├── transcription.md +│ │ ├── audio_capture.md +│ │ ├── text_audio_switching.md +│ │ └── media_handling.md │ │ -│ ├── 14_pwa_and_offline/ -│ │ ├── 01_pwa_architecture.md -│ │ ├── 02_offline_capabilities.md -│ │ ├── 03_local_storage.md -│ │ ├── 04_sync_strategy.md -│ │ ├── 05_conflict_resolution.md -│ │ └── 06_notifications_and_background_behaviour.md +│ ├── pwa_and_offline/ +│ │ ├── pwa_architecture.md +│ │ ├── offline_capabilities.md +│ │ ├── local_storage.md +│ │ ├── sync_strategy.md +│ │ ├── conflict_resolution.md +│ │ └── notifications_and_background_behaviour.md │ │ -│ ├── 15_privacy_security_safety/ -│ │ ├── 01_privacy_principles.md -│ │ ├── 02_sensitive_personal_data.md -│ │ ├── 03_encryption_and_access.md -│ │ ├── 04_memory_transparency.md -│ │ ├── 05_export_delete_and_portability.md -│ │ ├── 06_ai_safety_boundaries.md -│ │ ├── 07_crisis_and_high_risk_scenarios.md -│ │ └── 08_roles_and_permissions.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 │ │ -│ ├── 16_product_delivery/ -│ │ ├── 01_mvp_definition.md -│ │ ├── 02_release_slices.md -│ │ ├── 03_dependencies.md -│ │ ├── 04_test_strategy.md -│ │ └── 05_acceptance_criteria.md +│ ├── product_delivery/ +│ │ ├── mvp_definition.md +│ │ ├── release_slices.md +│ │ ├── dependencies.md +│ │ ├── test_strategy.md +│ │ └── acceptance_criteria.md │ │ -│ └── 17_research/ -│ ├── 01_market_landscape.md -│ ├── 02_day_one_benchmark.md -│ ├── 03_ai_journaling_benchmark.md -│ ├── 04_meditation_benchmark.md -│ └── 05_research_evidence.md +│ └── research/ +│ ├── market_landscape.md +│ ├── day_one_benchmark.md +│ ├── ai_journaling_benchmark.md +│ ├── meditation_benchmark.md +│ └── research_evidence.md │ └── decisions/ └── ADR-xxxx-*.md @@ -486,6 +529,7 @@ Die folgende Reihenfolge ist nicht identisch mit der späteren Ordnernummerierun **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, @@ -501,11 +545,11 @@ Die folgende Reihenfolge ist nicht identisch mit der späteren Ordnernummerierun **Zieldateien:** -- `01_product_vision.md` -- `02_product_identity.md` -- `03_product_principles.md` -- `04_scope_and_non_goals.md` -- `05_jinkendo_product_boundaries.md` +- `product_vision.md` +- `product_identity.md` +- `product_principles.md` +- `scope_and_non_goals.md` +- `jinkendo_product_boundaries.md` --- @@ -526,9 +570,9 @@ Nicht nur einzelne User Stories, sondern die langfristige Beziehung zwischen Men **Zieldateien:** -- `01_target_users.md` -- `04_usage_situations.md` -- `05_lifecycle_and_long_term_use.md` +- `target_users.md` +- `usage_situations.md` +- `lifecycle_and_long_term_use.md` --- @@ -552,6 +596,24 @@ Das zentrale Kontextmodell definieren und klar zwischen dem thematischen Lebensk - 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? @@ -568,9 +630,9 @@ Das zentrale Kontextmodell definieren und klar zwischen dem thematischen Lebensk **Zieldateien:** -- `02_reflection_contexts.md` -- `03_reflection_spaces.md` -- `04_reflection_space_model.md` +- `reflection_contexts.md` +- `reflection_spaces.md` +- `reflection_space_model.md` --- @@ -599,8 +661,8 @@ Definieren, wie Kanshō einen Dialog beginnt. **Zieldateien:** -- `02_dialogue_entry.md` -- `03_home_and_entry_points.md` +- `dialogue_entry.md` +- `home_and_entry_points.md` --- @@ -622,9 +684,9 @@ Die eigentliche Gesprächsmethodik definieren. **Zieldateien:** -- `01_dialogue_model.md` -- `03_guided_reflection.md` -- `01_reflection_model.md` +- `dialogue_model.md` +- `guided_reflection.md` +- `reflection_model.md` --- @@ -646,8 +708,8 @@ Mehrere parallele Denkfäden modellieren. **Zieldateien:** -- `04_threads_and_branching.md` -- `02_dialogue_data_model.md` +- `threads_and_branching.md` +- `dialogue_data_model.md` --- @@ -669,8 +731,8 @@ Festlegen, was am Ende einer Reflexion geschieht. **Zieldateien:** -- `05_dialogue_closure.md` -- `01_reflection_outputs.md` +- `dialogue_closure.md` +- `reflection_outputs.md` --- @@ -694,10 +756,10 @@ Die Gedächtnisebenen endgültig definieren. **Zieldateien:** -- `01_memory_architecture.md` -- `02_working_context.md` -- `03_thread_memory.md` -- `04_episodic_memory.md` +- `memory_architecture.md` +- `working_context.md` +- `thread_memory.md` +- `episodic_memory.md` --- @@ -721,9 +783,9 @@ Definieren, wie Kanshō stabile persönliche Informationen repräsentiert. **Zieldateien:** -- `05_self_model.md` -- `05_values_and_inner_alignment.md` -- `05_identity_and_profile_model.md` +- `self_model.md` +- `values_and_inner_alignment.md` +- `identity_and_profile_model.md` --- @@ -744,8 +806,8 @@ Eine persönliche Stimme über Jahre erhalten. **Zieldateien:** -- `06_writing_profile.md` -- `04_personal_writing_style.md` +- `writing_profile.md` +- `personal_writing_style.md` --- @@ -766,9 +828,9 @@ Verhindern, dass das System vergangene und aktuelle Wahrheiten vermischt. **Zieldateien:** -- `07_temporal_memory.md` -- `08_conflicts_forgetting_and_correction.md` -- `06_versioning_and_provenance.md` +- `temporal_memory.md` +- `conflicts_forgetting_and_correction.md` +- `versioning_and_provenance.md` --- @@ -792,7 +854,7 @@ Definieren, welcher Kontext für eine konkrete LLM-Anfrage zusammengestellt wird **Zieldatei:** -- `09_context_builder.md` +- `context_builder.md` --- @@ -814,8 +876,8 @@ Ein erkenntnistheoretisch sauberes Modell schaffen. **Zieldateien:** -- `02_observation_interpretation_hypothesis.md` -- `06_versioning_and_provenance.md` +- `observation_interpretation_hypothesis.md` +- `versioning_and_provenance.md` --- @@ -836,7 +898,7 @@ Offene Bedeutungs- und Erkenntnisräume aus mindnet nutzbar machen. **Zieldatei:** -- `03_reflection_frontiers.md` +- `reflection_frontiers.md` --- @@ -857,8 +919,8 @@ Langfristige Entwicklung sichtbar machen, ohne vorschnelle Persönlichkeitsdiagn **Zieldateien:** -- `04_pattern_detection.md` -- `06_longitudinal_development.md` +- `pattern_detection.md` +- `longitudinal_development.md` --- @@ -887,12 +949,12 @@ Definieren, welche Artefakte aus einem Dialog entstehen können. **Zieldateien:** -- `01_reflection_outputs.md` -- `02_journal_entries.md` -- `03_reflection_memories.md` -- `04_knowledge_deltas.md` -- `05_action_candidates.md` -- `06_confirmation_and_human_in_the_loop.md` +- `reflection_outputs.md` +- `journal_entries.md` +- `reflection_memories.md` +- `knowledge_deltas.md` +- `action_candidates.md` +- `confirmation_and_human_in_the_loop.md` --- @@ -906,18 +968,21 @@ Das Tagebuch als hochwertigen Bestandteil ausformen, ohne Kanshō darauf zu redu **Leitfragen:** -- Welche Day-One-artigen Funktionen werden benötigt? +- 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? -- Welche automatisch erzeugten Inhalte? +- 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 `06_journaling/` +- gesamter Ordner `journaling/` --- @@ -938,8 +1003,8 @@ Ein eigenes Achtsamkeitsverständnis für Kanshō definieren. **Zieldateien:** -- `01_mindfulness_concept.md` -- `04_contextual_micro_interventions.md` +- `mindfulness_concept.md` +- `contextual_micro_interventions.md` --- @@ -962,9 +1027,9 @@ Meditation funktional und methodisch definieren. **Zieldateien:** -- `02_meditation_concept.md` -- `03_guided_meditations.md` -- `05_post_meditation_reflection.md` +- `meditation_concept.md` +- `guided_meditations.md` +- `post_meditation_reflection.md` --- @@ -988,8 +1053,8 @@ Die langfristige Wissens- und Archivarchitektur festlegen. **Zieldateien:** -- `02_mindnet_integration.md` -- `03_obsidian_integration.md` +- `mindnet_integration.md` +- `obsidian_integration.md` --- @@ -1010,10 +1075,10 @@ Klare Integrationsverträge statt Funktionsduplikation. **Zieldateien:** -- `04_kairo_integration.md` -- `05_mitai_integration.md` -- `06_shinkan_integration.md` -- `01_integration_principles.md` +- `kairo_integration.md` +- `mitai_integration.md` +- `shinkan_integration.md` +- `integration_principles.md` --- @@ -1039,7 +1104,7 @@ Die technische Umsetzung der kollaborativen KI definieren. **Zieldateien:** -- gesamter Ordner `10_ai_architecture/` +- gesamter Ordner `ai_architecture/` --- @@ -1066,7 +1131,7 @@ Kanonische Datenmodelle definieren. **Zieldateien:** -- gesamter Ordner `11_data_architecture/` +- gesamter Ordner `data_architecture/` --- @@ -1090,10 +1155,10 @@ Die Hauptnutzung auf dem Smartphone definieren. **Zieldateien:** -- `01_experience_principles.md` -- `02_mobile_first.md` -- `03_home_and_entry_points.md` -- `04_conversation_ui.md` +- `experience_principles.md` +- `mobile_first.md` +- `home_and_entry_points.md` +- `conversation_ui.md` --- @@ -1113,7 +1178,7 @@ Desktop nicht nur als vergrößerte Mobile UI behandeln. **Zieldatei:** -- `07_desktop_experience.md` +- `desktop_experience.md` --- @@ -1136,7 +1201,7 @@ Voice als primäre mobile Interaktion prüfen. **Zieldateien:** -- gesamter Ordner `13_voice_and_media/` +- gesamter Ordner `voice_and_media/` --- @@ -1159,7 +1224,7 @@ Festlegen, was ohne Netz noch funktioniert. **Zieldateien:** -- gesamter Ordner `14_pwa_and_offline/` +- gesamter Ordner `pwa_and_offline/` --- @@ -1184,10 +1249,10 @@ Besonders sensible persönliche Langzeitdaten schützen. **Zieldateien:** -- `01_privacy_principles.md` -- `02_sensitive_personal_data.md` -- `03_encryption_and_access.md` -- `05_export_delete_and_portability.md` +- `privacy_principles.md` +- `sensitive_personal_data.md` +- `encryption_and_access.md` +- `export_delete_and_portability.md` --- @@ -1209,7 +1274,7 @@ Der Nutzer muss verstehen und kontrollieren können, was Kanshō über ihn „we **Zieldatei:** -- `04_memory_transparency.md` +- `memory_transparency.md` --- @@ -1221,9 +1286,9 @@ Grenzen bei psychisch belastenden, medizinischen oder anderweitig hochriskanten **Zieldateien:** -- `06_ai_safety_boundaries.md` -- `07_crisis_and_high_risk_scenarios.md` -- `06_conversation_safety_and_boundaries.md` +- `ai_safety_boundaries.md` +- `crisis_and_high_risk_scenarios.md` +- `conversation_safety_and_boundaries.md` --- @@ -1254,7 +1319,7 @@ Dies ist noch keine endgültige MVP-Entscheidung. **Zieldateien:** -- gesamter Ordner `16_product_delivery/` +- gesamter Ordner `product_delivery/` --- @@ -1277,7 +1342,7 @@ Zu untersuchen sind insbesondere: **Zieldateien:** -- gesamter Ordner `17_research/` +- gesamter Ordner `research/` --- @@ -1285,8 +1350,8 @@ Zu untersuchen sind insbesondere: Die unmittelbar nächste Sequenz sollte lauten: -1. **Reflection Spaces** -2. **typische Nutzungssituationen** +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** @@ -1377,14 +1442,14 @@ Technische Kapitel erhalten zusätzlich: --- -# 8. Fortschrittsstatus zum Start +# 8. Aktueller Fortschrittsstatus | Themenbereich | Status | |---|---| | Produktvision | begonnen / bereits relativ klar | | Produktidentität | weitgehend entschieden | | Produktgrenzen zu Jinkendo | weitgehend entschieden | -| Reflection Spaces | in Bearbeitung; Grundmodell und Entry-Logik teilweise 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 | @@ -1408,28 +1473,30 @@ Technische Kapitel erhalten zusätzlich: # 9. Nächster Interviewblock -Der nächste konzeptionelle Block ist: +Der Reflection-Space-Block ist für den aktuellen Konzeptstand **vorläufig ausreichend geklärt**. -# **Reflection Spaces – fachliche Mindestlogik** +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. -Bereits entschieden: +## Als Nächstes: typische Nutzungssituationen -- Kanshō soll die interne Strukturierung weitgehend im Hintergrund übernehmen. -- Der Nutzer soll nicht zum Verwalter von Threads und Spaces werden. -- Die KI darf neue Strukturen erkennen, vorschlagen und abhängig vom konfigurierten Autonomiegrad selbständig anlegen oder konsolidieren. -- Die normale Oberfläche zeigt nur relevante und kuratierte Strukturen. -- Eine gesonderte Admin-/Developer View macht interne Strukturen für Entwicklung, Test und Administration sichtbar. -- Diese Diagnoseansicht ist rollenbeschränkt. -- Ein Reflection Space ist kein bloßer Ablageort, sondern eine laufend aktualisierte Sicht auf einen zusammenhängenden persönlichen Denk- und Erfahrungsraum. -- Ein Reflection Space soll Orientierung, Fortsetzung, offene Fragen, Historie und Entwicklung unterstützen. -- Der aktuelle Zustand eines Reflection Space muss auf zugrunde liegende Quellen zurückführbar sein. -- Verdichteter Langzeitkontext muss auf mögliche Context Drift geprüft und bei Bedarf aus den Ursprungsquellen neu geerdet (Re-Grounding) werden. -- Re-Grounding kann systemseitig oder ausdrücklich durch den Nutzer ausgelöst werden. +Ziel des nächsten Interviewblocks ist zu klären: -Als Nächstes 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? -1. Welche Informationen müssen in der **aktuellen Sicht** eines Reflection Space zwingend enthalten sein? -2. Welche Informationen sollen nur bei Bedarf sichtbar werden? -3. Welche Elemente sind immer menschlich lesbar und welche dürfen rein intern bleiben? -4. Wie stark soll die aktuelle Sicht verdichten, ohne relevante Nuancen zu verlieren? -5. Wie werden widersprüchliche oder noch ungeklärte Erkenntnisse in dieser Sicht dargestellt? +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. diff --git a/docs/architecture/functional/produktvision_und_produktidentitaet.md b/docs/architecture/functional/produktvision_und_produktidentitaet.md index 1733a79..e2d65ad 100644 --- a/docs/architecture/functional/produktvision_und_produktidentitaet.md +++ b/docs/architecture/functional/produktvision_und_produktidentitaet.md @@ -146,6 +146,8 @@ Eine endgültige Entscheidung über Produktname, Schreibweise, Markenfähigkeit, Kanshō soll ein **persönlicher KI-gestützter Reflexionsbegleiter** innerhalb der Jinkendo-Produktfamilie werden. +Im Vergleich zu den bereits bestehenden Jinkendo-Anwendungen soll Kanshō bewusst **stärker KI-kollaborativ** arbeiten. Die KI ist hier nicht nur unterstützende Funktion, sondern ein zentraler Dialog- und Reflexionspartner, der Kontext aufnimmt, frühere Denkwege kennt, Fragen entwickelt, Zusammenhänge vorsichtig anbietet und den Nutzer über längere Zeit begleitet. + Die App soll Menschen nicht primär dabei unterstützen, Aufgaben zu planen, Daten zu tracken oder Inhalte nur abzulegen. Ihr Schwerpunkt liegt auf: @@ -240,8 +242,16 @@ Ein Dialog kann beispielsweise ausgelöst werden durch: Die KI soll nicht nur generische Fragen stellen, sondern den bestehenden Kontext nutzen. +Für den laufenden Dialog gilt als fachliche Anforderung: + +- Der Gesprächsfluss soll sich auch über längere Reflexionen hinweg natürlich und zusammenhängend anfühlen. +- Wichtige Informationen aus dem aktuellen Gespräch dürfen nicht allein deshalb verloren gehen, weil sich mehrere Themen oder Threads entwickeln. +- Der Nutzer soll relevante Informationen nicht regelmäßig wiederholen müssen. +- Aktiver Reflection Intent, aktuelle Threads und wesentliche Aussagen müssen im Arbeitskontext erhalten beziehungsweise bei Bedarf gezielt wiederhergestellt werden. + --- + # 7. Reflexionskontexte Reflexionen finden in unterschiedlichen Lebensbereichen und Situationen statt. @@ -543,6 +553,52 @@ Wichtig: Damit wird der Reflection Space zu einer **lebendigen, kontextuellen Sicht auf persönliche Entwicklung innerhalb eines bestimmten Zusammenhangs**. +### Dauer und Granularität + +Reflection Spaces können unterschiedlich lange relevant sein. + +Sie können beispielsweise: + +- ein klar abgegrenztes Erlebnis oder einen Urlaub über Tage oder Wochen begleiten, +- ein über mehrere Wochen laufendes persönliches Thema bündeln, +- eine längerfristige berufliche oder persönliche Entwicklung abbilden, +- über Jahre hinweg wiederkehrende Fragen oder Lebenszusammenhänge begleiten. + +Die Dauer allein entscheidet nicht darüber, ob ein eigener Reflection Space sinnvoll ist. Maßgeblich ist, ob ein Zusammenhang für die Reflexion über mehrere Interaktionen hinweg eigenständige Bedeutung besitzt. + +Ältere oder aktuell nicht relevante Spaces dürfen in der normalen Oberfläche zurücktreten, bleiben aber auffindbar und können bei erneuter Relevanz wieder in den Vordergrund treten. + +Kanshō soll diese Komplexität weitgehend selbst organisieren. Der Nutzer soll nicht entscheiden müssen, ob ein Thema „groß genug“ für einen Space ist. + +### Vorläufige sichtbare Standardansicht + +Für die normale Nutzeroberfläche gilt als **vorläufige fachliche Baseline**, die in späteren Dialogkapiteln weiter konkretisiert werden kann: + +1. **Aktueller Stand** – eine kompakte, quellengebundene Sicht darauf, worum es in diesem Space aktuell geht und wo der Nutzer gedanklich steht. +2. **Was ist noch offen?** – nur die aktuell relevanten offenen Fragen, Spannungsfelder oder bewusst weiterzuverfolgenden Themen. +3. **Weiterdenken** – ein intelligent priorisierter Vorschlag zur Fortsetzung mit wenigen Alternativen. +4. **Bisheriger Weg** – eine kompakte zeitliche Sicht auf prägende Erlebnisse, Dialoge, Tagebucheinträge und Wendepunkte. + +Diese Darstellung ist bewusst nicht abschließend. Sie bildet den derzeit akzeptierten Ausgangspunkt und darf später auf Basis der konkreten Nutzungsszenarien erweitert oder verändert werden. + +### Aufklappbarkeit und Nutzer-Provenance + +Verdichtete Aussagen in der sichtbaren Space-Ansicht sollen für den Nutzer grundsätzlich auf die zugrunde liegenden Inhalte zurückführbar sein. + +Der Nutzer soll bei Bedarf nachvollziehen können: + +- auf welchen früheren Dialogen, +- Tagebucheinträgen, +- Memories, +- Obsidian-Inhalten, +- mindnet-Knoten oder +- bestätigten Erkenntnissen + +eine relevante Aussage oder Zusammenfassung basiert. + +Dieses **Aufklappen** ist eine Transparenzfunktion für den Nutzer und ist fachlich von dem internen Re-Grounding der KI zu unterscheiden. + + ## 8.8 Context Drift und Re-Grounding @@ -1052,14 +1108,18 @@ Der bisher genannte Funktionsumfang umfasst mindestens folgende Bereiche. - kontextbezogene Einstiegsfrage, - Dialog statt starrem Formular, - Erkennen offener Themen, -- Abschluss mit optionalem Tagebucheintrag, +- **Generierung eines Tagebucheintrags aus der täglichen Reflexion als vorgesehene Kernfunktion**, - Überführung relevanter Erkenntnisse in mindnet. +Noch offen ist, ob der Tagebucheintrag standardmäßig automatisch erzeugt, aktiv angefordert oder vor der Ablage ausdrücklich bestätigt werden soll. Diese offene Ausprägungsfrage ändert nichts an der ursprünglichen Anforderung, dass aus der täglichen Reflexion ein persönlicher Tagebucheintrag generiert werden können muss. + --- ## 18.2 Tagebuch -Als Referenzrahmen wurde ein Funktionsniveau ähnlich hochwertiger Journaling-Anwendungen genannt. +Als expliziter Referenzrahmen wurde vom Nutzer **Day One im „Gold“-Abo** genannt. Kanshō soll die für den Anwendungsfall relevanten hochwertigen Tagebuchfunktionen auf vergleichbarem Niveau abdecken, ohne dadurch zu einem reinen Day-One-Klon zu werden. + +Welche konkreten Funktionen des genannten Referenzprodukts übernommen, anders gelöst oder bewusst nicht benötigt werden, wird in einem eigenen Benchmark- und Journaling-Kapitel geprüft. Die aktuelle Produktbezeichnung und der konkrete Leistungsumfang des Referenzangebots sind dabei zum Zeitpunkt des Benchmarks nochmals zu verifizieren. Der genaue Funktionsumfang wird später spezifiziert. @@ -1277,50 +1337,6 @@ Kanshō übernimmt kein Vital-, Ernährungs- oder Gesundheitstracking. --- -## 20.1 Einfachheit an der Oberfläche, Intelligenz im Kern - -Ein zentrales Architektur- und Produktprinzip lautet: - -> **Kanshō soll für den Nutzer einfach wirken, ohne deshalb intern einfach sein zu müssen.** - -Die fachliche und technische Modellierung darf nicht allein mit dem Ziel reduziert werden, möglichst wenige interne Objekte, Zustände oder Beziehungen zu besitzen. - -Vereinfachung ist nur dann sinnvoll, wenn dadurch keine wesentlichen Fähigkeiten verloren gehen. - -Insbesondere muss die interne Architektur ausreichend differenziert bleiben, um langfristig folgende Anforderungen erfüllen zu können: - -- mehrere parallele und sich entwickelnde Dialogfäden, -- langfristige Erinnerung über Monate und Jahre, -- kontextabhängige Wiederaufnahme früherer Themen, -- Reflection Spaces mit überlappenden Lebensbereichen und Rollen, -- dynamische Bildung und Konsolidierung von Strukturen, -- zeitliche Entwicklung von Erkenntnissen und Selbstbeschreibungen, -- Unterscheidung zwischen Beobachtung, Interpretation, Hypothese und bestätigter Erkenntnis, -- nachvollziehbare Provenance und Confidence, -- ein versionierbares Self Model, -- ein langfristig lernendes Writing Profile, -- Reflection Frontiers und noch ungeklärte Zusammenhänge, -- Integration von mindnet, Obsidian, Kairo, Mitai und Shinkan, -- kontextabhängige Auswahl relevanter Informationen, -- rollenbasierte Diagnose- und Transparenzansichten, -- spätere Erweiterbarkeit ohne grundlegenden Umbau des Kernmodells. - -Die normale Benutzeroberfläche soll diese interne Differenzierung weitgehend abstrahieren. - -Damit gilt: - -**Komplexität darf unter der Motorhaube existieren, wenn sie fachlich notwendig ist. -Komplexität soll aber nicht ungefiltert an den Nutzer weitergereicht werden.** - -Eine interne Vereinfachung darf daher niemals ausschließlich mit dem Argument erfolgen, dass das zugrunde liegende Modell dadurch leichter implementierbar wird. - -Vor jeder wesentlichen Modellvereinfachung soll geprüft werden: - -1. Welche heutigen Fähigkeiten hängen von der betreffenden Struktur ab? -2. Welche bereits vorgesehenen späteren Fähigkeiten würden dadurch erschwert oder unmöglich? -3. Kann dieselbe Nutzervereinfachung auch durch UX, Automatisierung oder KI-gestützte Strukturierung erreicht werden? -4. Ist die Entscheidung später ohne grundlegende Migration oder Redesign reversibel? - # 21. Produktprinzipien @@ -1366,14 +1382,49 @@ Wichtige Inhalte sollen nicht ausschließlich in proprietären internen Datenstr Das System soll über Monate und Jahre eine nachvollziehbare persönliche Entwicklung unterstützen. -## 21.11 Simple Experience, Rich Core +## 21.11 Einfachheit an der Oberfläche, Intelligenz im Kern -Die Benutzererfahrung soll möglichst einfach, natürlich und wenig administrativ sein. +Ein zentrales Architektur- und Produktprinzip lautet: -Die interne fachliche und technische Architektur darf dagegen so differenziert sein, wie es zur Erfüllung der Produktvision notwendig ist. +> **Kanshō soll für den Nutzer einfach wirken, ohne deshalb intern einfach sein zu müssen.** -„Einfachheit“ ist primär ein UX-Ziel und kein Selbstzweck für die Kernarchitektur. +Die fachliche und technische Modellierung darf nicht allein mit dem Ziel reduziert werden, möglichst wenige interne Objekte, Zustände oder Beziehungen zu besitzen. +Vereinfachung ist nur dann sinnvoll, wenn dadurch keine wesentlichen Fähigkeiten verloren gehen. + +Insbesondere muss die interne Architektur ausreichend differenziert bleiben, um langfristig folgende Anforderungen erfüllen zu können: + +- mehrere parallele und sich entwickelnde Dialogfäden, +- langfristige Erinnerung über Monate und Jahre, +- kontextabhängige Wiederaufnahme früherer Themen, +- Reflection Spaces mit überlappenden Lebensbereichen und Rollen, +- dynamische Bildung und Konsolidierung von Strukturen, +- zeitliche Entwicklung von Erkenntnissen und Selbstbeschreibungen, +- Unterscheidung zwischen Beobachtung, Interpretation, Hypothese und bestätigter Erkenntnis, +- nachvollziehbare Provenance und Confidence, +- ein versionierbares Self Model, +- ein langfristig lernendes Writing Profile, +- Reflection Frontiers und noch ungeklärte Zusammenhänge, +- Integration von mindnet, Obsidian, Kairo, Mitai und Shinkan, +- kontextabhängige Auswahl relevanter Informationen, +- rollenbasierte Diagnose- und Transparenzansichten, +- spätere Erweiterbarkeit ohne grundlegenden Umbau des Kernmodells. + +Die normale Benutzeroberfläche soll diese interne Differenzierung weitgehend abstrahieren. + +Damit gilt: + +**Komplexität darf unter der Motorhaube existieren, wenn sie fachlich notwendig ist. +Komplexität soll aber nicht ungefiltert an den Nutzer weitergereicht werden.** + +Eine interne Vereinfachung darf daher niemals ausschließlich mit dem Argument erfolgen, dass das zugrunde liegende Modell dadurch leichter implementierbar wird. + +Vor jeder wesentlichen Modellvereinfachung soll geprüft werden: + +1. Welche heutigen Fähigkeiten hängen von der betreffenden Struktur ab? +2. Welche bereits vorgesehenen späteren Fähigkeiten würden dadurch erschwert oder unmöglich? +3. Kann dieselbe Nutzervereinfachung auch durch UX, Automatisierung oder KI-gestützte Strukturierung erreicht werden? +4. Ist die Entscheidung später ohne grundlegende Migration oder Redesign reversibel? --- @@ -1400,32 +1451,31 @@ Die folgenden Punkte sind bewusst noch nicht entschieden. 1. Fachliche Struktur und Lebenszyklus der Reflection Spaces. 2. Verhältnis von stabilen Lebenskontexten, dynamischen Reflexionsräumen und aktuellen Intents. 3. Regeln für Entstehung, Sichtbarkeit, Konsolidierung und Wiederaufnahme von Dialogfäden. -4. Konfigurierbarer Autonomiegrad der KI bei Strukturierung und Konsolidierung. -4. Technisches Working-Memory-Modell. -5. Datenbank für laufende Dialoge. -6. Synchronisation und Offline-Architektur. -7. Umfang und Rolle lokaler KI. -8. genaue Integration mit Obsidian. -9. Schema für Reflection Memories. -10. Schema für Knowledge Deltas. -11. Versionierung des Self Models. -12. Mechanismus zur Nutzerbestätigung persönlicher Hypothesen. -13. Aufbau und Training des Writing Profiles. -14. Umgang mit widersprüchlichen Erinnerungen. -15. zeitliche Gewichtung alter Informationen. -16. Vergessen, Löschen und Datenschutz. -17. genaue Journaling-Funktionen. -18. Meditationskonzept. -19. Achtsamkeitskonzept. -20. Mobile UX. -21. Spracheingabe und Transkription. -22. Rolle anderer Jinkendo-Anwendungen im Context Builder. -23. Agenten- und Prompt-Architektur. -24. technische API- und Event-Integration. -25. Sicherheits- und Krisengrenzen. -26. Produktname und Branding. -27. Ausprägung der Admin-/Developer-Diagnoseansicht und konkretes Rollen-/Berechtigungsmodell. - +4. Konkrete Stufen, Regeln und Nutzerkontrollen des bereits beschlossenen konfigurierbaren Autonomiegrads der KI bei Strukturierung und Konsolidierung. +5. Technisches Working-Memory-Modell. +6. Datenbank für laufende Dialoge. +7. Synchronisation und Offline-Architektur. +8. Umfang und Rolle lokaler KI. +9. genaue Integration mit Obsidian. +10. Schema für Reflection Memories. +11. Schema für Knowledge Deltas. +12. Versionierung des Self Models. +13. Mechanismus zur Nutzerbestätigung persönlicher Hypothesen. +14. Aufbau und Training des Writing Profiles. +15. Umgang mit widersprüchlichen Erinnerungen. +16. zeitliche Gewichtung alter Informationen. +17. Vergessen, Löschen und Datenschutz. +18. genaue Journaling-Funktionen. +19. Meditationskonzept. +20. Achtsamkeitskonzept. +21. Mobile UX. +22. Spracheingabe und Transkription. +23. Rolle anderer Jinkendo-Anwendungen im Context Builder. +24. Agenten- und Prompt-Architektur. +25. technische API- und Event-Integration. +26. Sicherheits- und Krisengrenzen. +27. Produktname und Branding. +28. Ausprägung der Admin-/Developer-Diagnoseansicht und konkretes Rollen-/Berechtigungsmodell. --- # 24. Aktueller Entscheidungsstand @@ -1470,6 +1520,12 @@ Die folgenden Punkte sind bewusst noch nicht entschieden. | Re-Grounding | bei Bedarf Rekonstruktion aus Ursprungsquellen statt erneuter Interpretation bestehender Summaries | entschieden | | Nutzer-Trigger | Nutzer kann erneuten Quellenabgleich ausdrücklich anfordern | entschieden | | Drift-Metrik | fachlich erforderlich, konkrete Berechnung und Bezeichnung später technisch zu spezifizieren | bevorzugte Richtung | +| KI-Kollaboration | Kanshō ist bewusst stärker KI-kollaborativ als die bisherigen Jinkendo-Komponenten | entschieden | +| Tägliche Reflexion | Generierung eines persönlichen Tagebucheintrags muss möglich sein; konkrete Automatik/Bestätigung noch offen | entschieden | +| Journaling-Referenz | Day One im vom Nutzer genannten „Gold“-Abo dient als expliziter Benchmark-Rahmen; konkrete Funktionen später zu verifizieren | entschieden als Referenz | +| Space-Dauer | Reflection Spaces können kurz-/mittelfristig oder langfristig relevant sein; Bedeutung statt Dauer ist ausschlaggebend | entschieden | +| Space-Standardansicht | Aktueller Stand, offene Punkte, Weiterdenken und bisheriger Weg als vorläufige sichtbare Baseline | bevorzugte Richtung / später konkretisierbar | +| Nutzer-Provenance | verdichtete Aussagen sollen für den Nutzer auf zugrunde liegende Inhalte aufklappbar sein | entschieden | | Produktname Kanshō | Arbeitstitel | offen | ---