1264 lines
32 KiB
Markdown
1264 lines
32 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.
|
||
|
||
---
|
||
|
||
|
||
## 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.
|
||
|
||
# 3. Vorgeschlagene Repository-Struktur
|
||
|
||
```text
|
||
kansho/
|
||
│
|
||
├── README.md
|
||
├── docs/
|
||
│ ├── 00_governance/
|
||
│ │ ├── 00_documentation_principles.md
|
||
│ │ ├── 01_glossary.md
|
||
│ │ └── 02_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
|
||
│ │
|
||
│ ├── 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
|
||
│ │
|
||
│ ├── 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
|
||
│ │
|
||
│ ├── 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
|
||
│ │
|
||
│ ├── 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
|
||
│ │
|
||
│ ├── 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
|
||
│ │
|
||
│ ├── 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
|
||
│ │
|
||
│ ├── 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
|
||
│ │
|
||
│ ├── 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
|
||
│ │
|
||
│ ├── 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
|
||
│ │
|
||
│ ├── 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
|
||
│ │
|
||
│ ├── 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
|
||
│ │
|
||
│ ├── 13_voice_and_media/
|
||
│ │ ├── 01_voice_interaction.md
|
||
│ │ ├── 02_transcription.md
|
||
│ │ ├── 03_audio_capture.md
|
||
│ │ ├── 04_text_audio_switching.md
|
||
│ │ └── 05_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
|
||
│ │
|
||
│ ├── 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
|
||
│ │
|
||
│ ├── 16_product_delivery/
|
||
│ │ ├── 01_mvp_definition.md
|
||
│ │ ├── 02_release_slices.md
|
||
│ │ ├── 03_dependencies.md
|
||
│ │ ├── 04_test_strategy.md
|
||
│ │ └── 05_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
|
||
│
|
||
└── 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:**
|
||
|
||
- 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:**
|
||
|
||
- `01_product_vision.md`
|
||
- `02_product_identity.md`
|
||
- `03_product_principles.md`
|
||
- `04_scope_and_non_goals.md`
|
||
- `05_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:**
|
||
|
||
- `01_target_users.md`
|
||
- `04_usage_situations.md`
|
||
- `05_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.
|
||
|
||
**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:**
|
||
|
||
- `02_reflection_contexts.md`
|
||
- `03_reflection_spaces.md`
|
||
- `04_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:**
|
||
|
||
- `02_dialogue_entry.md`
|
||
- `03_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:**
|
||
|
||
- `01_dialogue_model.md`
|
||
- `03_guided_reflection.md`
|
||
- `01_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:**
|
||
|
||
- `04_threads_and_branching.md`
|
||
- `02_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:**
|
||
|
||
- `05_dialogue_closure.md`
|
||
- `01_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:**
|
||
|
||
- `01_memory_architecture.md`
|
||
- `02_working_context.md`
|
||
- `03_thread_memory.md`
|
||
- `04_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:**
|
||
|
||
- `05_self_model.md`
|
||
- `05_values_and_inner_alignment.md`
|
||
- `05_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:**
|
||
|
||
- `06_writing_profile.md`
|
||
- `04_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:**
|
||
|
||
- `07_temporal_memory.md`
|
||
- `08_conflicts_forgetting_and_correction.md`
|
||
- `06_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:**
|
||
|
||
- `09_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:**
|
||
|
||
- `02_observation_interpretation_hypothesis.md`
|
||
- `06_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:**
|
||
|
||
- `03_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:**
|
||
|
||
- `04_pattern_detection.md`
|
||
- `06_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:**
|
||
|
||
- `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`
|
||
|
||
---
|
||
|
||
# Phase E – Journaling, Achtsamkeit und Meditation
|
||
|
||
## E1. Journaling
|
||
|
||
**Ziel:**
|
||
|
||
Das Tagebuch als hochwertigen Bestandteil ausformen, ohne Kanshō darauf zu reduzieren.
|
||
|
||
**Leitfragen:**
|
||
|
||
- Welche Day-One-artigen Funktionen werden benötigt?
|
||
- Welche Medien?
|
||
- Welche Metadaten?
|
||
- Welche Timeline?
|
||
- Welche Suche?
|
||
- Welche Rückblicke?
|
||
- Welche automatisch erzeugten Inhalte?
|
||
- Wie viel Nachbearbeitung durch den Nutzer?
|
||
|
||
**Zieldateien:**
|
||
|
||
- gesamter Ordner `06_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:**
|
||
|
||
- `01_mindfulness_concept.md`
|
||
- `04_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:**
|
||
|
||
- `02_meditation_concept.md`
|
||
- `03_guided_meditations.md`
|
||
- `05_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:**
|
||
|
||
- `02_mindnet_integration.md`
|
||
- `03_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:**
|
||
|
||
- `04_kairo_integration.md`
|
||
- `05_mitai_integration.md`
|
||
- `06_shinkan_integration.md`
|
||
- `01_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 `10_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 `11_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:**
|
||
|
||
- `01_experience_principles.md`
|
||
- `02_mobile_first.md`
|
||
- `03_home_and_entry_points.md`
|
||
- `04_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:**
|
||
|
||
- `07_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 `13_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 `14_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:**
|
||
|
||
- `01_privacy_principles.md`
|
||
- `02_sensitive_personal_data.md`
|
||
- `03_encryption_and_access.md`
|
||
- `05_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:**
|
||
|
||
- `04_memory_transparency.md`
|
||
|
||
---
|
||
|
||
## H3. Safety Boundaries
|
||
|
||
**Ziel:**
|
||
|
||
Grenzen bei psychisch belastenden, medizinischen oder anderweitig hochriskanten Themen definieren.
|
||
|
||
**Zieldateien:**
|
||
|
||
- `06_ai_safety_boundaries.md`
|
||
- `07_crisis_and_high_risk_scenarios.md`
|
||
- `06_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 `16_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 `17_research/`
|
||
|
||
---
|
||
|
||
# 5. Empfohlene Reihenfolge des weiteren Interviews
|
||
|
||
Die unmittelbar nächste Sequenz sollte lauten:
|
||
|
||
1. **Reflection Spaces**
|
||
2. **typische Nutzungssituationen**
|
||
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.
|
||
|
||
## 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. Fortschrittsstatus zum Start
|
||
|
||
| 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 |
|
||
| 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 nächste konzeptionelle Block ist:
|
||
|
||
# **Reflection Spaces – fachliche Mindestlogik**
|
||
|
||
Bereits entschieden:
|
||
|
||
- 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.
|
||
|
||
Noch zu klären sind auf fachlicher Ebene:
|
||
|
||
1. Was ist aus Nutzersicht überhaupt ein Reflection Space?
|
||
2. Wann ist ein eigener Space hilfreich und wann reicht ein Thread innerhalb eines vorhandenen Kontexts?
|
||
3. Wann sollte Kanshō eine neue Struktur vorschlagen?
|
||
4. Wann darf Kanshō ähnliche oder überholte Strukturen wieder konsolidieren?
|
||
5. Welche Kontrolle benötigt der Nutzer über diese Entscheidungen?
|
||
6. Welche Autonomiestufen sollen konfigurierbar sein?
|
||
|
||
Erst wenn diese fachliche Mindestlogik steht, wird entschieden, ob überhaupt unterschiedliche interne Space-Typen oder komplexere Lifecycle-Modelle notwendig sind.
|