Dateien nach "docs/architecture/functional" hochladen

docs/architecture/functional/fachliche_zielarchitektur.md

@@ -95,6 +95,28 @@ Jede Datei erhält mindestens:
 
 ---
 
+
+## 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.
+
 # 3. Vorgeschlagene Repository-Struktur
 
 ```text
@@ -318,11 +340,21 @@ Nicht nur einzelne User Stories, sondern die langfristige Beziehung zwischen Men
 
 # Phase B – Reflection Spaces und Dialog
 
-## B1. Reflection Contexts und Reflection Spaces
+## B1. Reflection Contexts, Reflection Spaces und Reflection Intent
 
 **Ziel:**
 
-Das zentrale Kontextmodell definieren.
+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.
 
 **Leitfragen:**
 
@@ -333,6 +365,10 @@ Das zentrale Kontextmodell definieren.
 - 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:**
 
@@ -348,6 +384,14 @@ Das zentrale Kontextmodell definieren.
 
 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?
@@ -1141,7 +1185,7 @@ Technische Kapitel erhalten zusätzlich:
 | Produktvision | begonnen / bereits relativ klar |
 | Produktidentität | weitgehend entschieden |
 | Produktgrenzen zu Jinkendo | weitgehend entschieden |
-| Reflection Spaces | als nächster Dialogschritt vorgesehen |
+| Reflection Spaces | in Bearbeitung; Grundmodell und Entry-Logik teilweise entschieden |
 | Dialogmodell | erste Leitplanken vorhanden |
 | Threads | Grundidee vorhanden |
 | Memory Architecture | erstes Schichtenmodell vorhanden |
@@ -1167,24 +1211,19 @@ Technische Kapitel erhalten zusätzlich:
 
 Der nächste konzeptionelle Block ist:
 
-# **Reflection Spaces**
+# **Reflection Spaces – fachliche Mindestlogik**
 
-Ziel ist, zu beantworten:
+Der nächste Interviewblock soll bewusst einfach bleiben.
 
-> Wie organisiert Kanshō die unterschiedlichen Lebens-, Situations- und Themenkontexte, in denen Reflexion stattfindet?
+Ziel ist nicht, bereits eine vollständige interne Taxonomie oder technische Automatik zu entwerfen, sondern nur die fachlichen Mindestfragen zu beantworten:
 
-Dabei werden wir insbesondere zwischen folgenden Begriffen unterscheiden müssen:
+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. Welche Räume soll der Nutzer sichtbar sehen können?
+4. Welche Struktur darf rein intern bleiben?
+5. Wann sollte Kanshō eine neue Struktur vorschlagen?
+6. Wann darf Kanshō ähnliche oder überholte Strukturen wieder konsolidieren?
+7. Welche Kontrolle benötigt der Nutzer über diese Entscheidungen?
+8. Welche Autonomiestufen sollen konfigurierbar sein?
 
-- Lebensbereich,
-- Rolle,
-- Kontext,
-- Situation,
-- Ereignis,
-- Thema,
-- Reflexionsraum,
-- Dialog,
-- Thread,
-- Projekt,
-- Ziel.
-
-Erst danach sollte das detaillierte Dialogmodell weiter ausgearbeitet werden.
+Erst wenn diese fachliche Mindestlogik steht, wird entschieden, ob überhaupt unterschiedliche interne Space-Typen oder komplexere Lifecycle-Modelle notwendig sind.

docs/architecture/functional/produktvision_und_produktidentitaet.md

@@ -303,8 +303,155 @@ Dazu kann Kanshō beispielsweise berücksichtigen:
 
 Ziel ist ein Einstieg, der sich wie die Fortsetzung eines bestehenden persönlichen Denkprozesses anfühlt.
 
+
+## 8.1 Adaptives Entry-Modell
+
+Für den Einstieg in Kanshō wurde ein abgestuftes Modell festgelegt.
+
+### Stufe 1 – Contextual Continuation (Default)
+
+Kanshō eröffnet die Nutzung primär mit einem intelligent priorisierten Vorschlag, der an den bisherigen persönlichen Kontext anknüpft.
+
+Mögliche Ausgangspunkte sind beispielsweise:
+
+- der letzte Dialog,
+- ein noch offener Dialogfaden,
+- eine unbeantwortete Frage,
+- ein aktueller Reflection Space,
+- ein naheliegender Tagesrückblick,
+- ein länger offenes, aktuell relevantes Thema.
+
+Der Vorschlag ist immer als Einladung formuliert und nicht als Vorgabe.
+
+Kanshō priorisiert grundsätzlich **einen Hauptvorschlag**. Daneben können wenige diskrete Alternativen angeboten werden.
+
+### Stufe 2 – Free Reflection
+
+Der Nutzer kann jederzeit ohne vorherige Auswahl frei sprechen oder schreiben.
+
+Kanshō versucht dann aus dem Gespräch heraus:
+
+- den passenden Kontext,
+- einen vorhandenen Reflection Space,
+- mögliche Threads,
+- die aktuelle Nutzungsabsicht
+
+zu erkennen.
+
+### Stufe 3 – Explicit Navigation
+
+Wenn der Nutzer gezielt an etwas anknüpfen möchte, kann er bewusst navigieren, beispielsweise zu:
+
+- einem früheren Dialog,
+- einer offenen Frage,
+- einem offenen Thread,
+- einem Reflection Space,
+- einem bestimmten Tagebucheintrag,
+- einem konkreten Urlaubstag.
+
+Die Reihenfolge C → B/A ist keine starre Prozesslogik, sondern die bevorzugte Interaktionshierarchie. Der Nutzer kann jederzeit direkt in Stufe 2 oder 3 wechseln.
+
+## 8.2 Reflection Intent
+
+Neben dem Kontext wird eine zweite Dimension benötigt: die **aktuelle Absicht der Reflexion**.
+
+Ein Reflection Space beschreibt, **worüber beziehungsweise in welchem Lebenszusammenhang** reflektiert wird.
+
+Der Reflection Intent beschreibt, **was der Nutzer in diesem Moment mit der Interaktion erreichen möchte**.
+
+Beispiele:
+
+- `Space: Urlaub / Lošinj 2026` + `Intent: Tageserlebnisse festhalten`
+- `Space: Urlaub / Lošinj 2026` + `Intent: tiefer reflektieren`
+- `Space: Persönliche Entwicklung / Gestaltungsdrang` + `Intent: offenen Thread fortsetzen`
+- `Space: Beruf / aktuelle Rolle` + `Intent: Entscheidung einordnen`
+
+Der Intent kann:
+
+- explizit gewählt werden,
+- aus dem Einstieg erkannt werden,
+- sich im Verlauf des Gesprächs verändern.
+
+Kanshō soll sein Dialogverhalten am Intent ausrichten.
+
+Beispielsweise:
+
+- beim autobiografischen Festhalten stärker zuhören und strukturieren,
+- bei tiefer Reflexion gezielter nachfragen,
+- beim Fortsetzen eines Threads den bisherigen Denkstand rekonstruieren,
+- bei einer offenen Frage vorhandene Perspektiven und frühere Erkenntnisse einbeziehen.
+
+## 8.3 Konsequenz für die Startoberfläche
+
+Die Startoberfläche soll nicht primär als klassische Funktionsnavigation mit gleichwertigen Modulen wie „Tagebuch“, „Meditation“, „Reflexion“ und „Achtsamkeit“ aufgebaut werden.
+
+Primär soll sie die **Kontinuität des persönlichen Dialogs** sichtbar machen.
+
+Ein mögliches Muster ist:
+
+- ein intelligent priorisierter Hauptvorschlag,
+- wenige Alternativen wie freie Reflexion, Tagebuch, offene Threads oder Reflection Spaces,
+- jederzeitiger Wechsel in gezielte Navigation.
+
+Damit wird Kanshō als langfristiger Begleiter erlebt und nicht als Sammlung einzelner Tools.
+
 ---
 
+
+## 8.4 Fachliche Autonomie der KI bei Strukturierung
+
+Kanshō soll die interne Strukturierung von Reflexionen möglichst weitgehend im Hintergrund übernehmen.
+
+Dabei gilt als fachliches Prinzip:
+
+> **Die KI erkennt, schlägt vor, strukturiert und konsolidiert – der Nutzer soll aber nicht zum Verwalter der internen Struktur werden.**
+
+Der Umfang dieser Eigenständigkeit soll konfigurierbar sein.
+
+Mögliche Ausprägungen reichen von:
+
+- stark bestätigungsorientiert: Kanshō schlägt neue Räume, Threads oder Zusammenführungen vor und wartet auf Bestätigung,
+- ausgewogen: offensichtliche Strukturierungen erfolgen automatisch, bedeutsame Änderungen werden vorgeschlagen,
+- weitgehend autonom: Kanshō darf neue Räume oder Threads selbst anlegen und später konsolidieren, solange dies transparent und korrigierbar bleibt.
+
+Diese Einstellung ist eine fachliche Produktanforderung. Die genaue technische Umsetzung ist noch offen.
+
+Wichtig ist dabei insbesondere:
+
+- Nicht jedes Seitenthema erzeugt automatisch einen neuen sichtbaren Thread.
+- Nicht jede semantische Abweichung benötigt einen neuen Reflection Space.
+- Kanshō soll Relevanz, Wiederkehr, Tiefe und Dauer eines Themas berücksichtigen.
+- Mehrere schwach ausgeprägte oder verwandte Strukturen dürfen später konsolidiert werden.
+- Der Nutzer muss eine falsche Zuordnung, Trennung oder Zusammenführung korrigieren können.
+
+Damit soll verhindert werden, dass Kanshō über Jahre eine unüberschaubare Menge kleinteiliger Reflexionsräume und Threads erzeugt.
+
+## 8.5 Fachliche Ebene versus technische Umsetzung
+
+Für die weitere Konzeption wird grundsätzlich zwischen zwei Ebenen getrennt:
+
+### Fachliche Zielarchitektur
+
+Sie beschreibt:
+
+- welches Verhalten Kanshō aus Sicht des Nutzers zeigen soll,
+- welche fachlichen Objekte und Verantwortlichkeiten benötigt werden,
+- welche Entscheidungen der Nutzer treffen können muss,
+- welche Informationen und Beziehungen grundsätzlich relevant sind.
+
+### Technische Architektur
+
+Sie beschreibt später:
+
+- wie diese Anforderungen implementiert werden,
+- welche Datenmodelle und Speicher verwendet werden,
+- wie Agenten, Modelle, Retrieval und Synchronisation funktionieren,
+- welche Heuristiken oder Algorithmen eingesetzt werden.
+
+Technische Architekturentscheidungen werden im fachlichen Konzept nur dann vorgezogen, wenn sie eine wesentliche Produktgrenze oder eine später kaum reversible Grundentscheidung darstellen.
+
+Die fachliche Konzeption soll bewusst vermeiden, aus jeder Produktidee frühzeitig ein komplexes technisches Subsystem abzuleiten.
+
 # 9. Dialogfäden
 
 Ein Gespräch kann mehrere Themen oder Reflexionsfäden enthalten.
@@ -1014,9 +1161,10 @@ Kanshō soll derzeit ausdrücklich nicht zu folgenden Produkten werden:
 
 Die folgenden Punkte sind bewusst noch nicht entschieden.
 
-1. Genaue Struktur der Reflection Spaces.
-2. Feste Kategorien versus dynamische Kontexte.
-3. Lebenszyklus von Dialogfäden.
+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.
@@ -1066,6 +1214,13 @@ Die folgenden Punkte sind bewusst noch nicht entschieden.
 | Writing Profile | eigener langfristiger Bestandteil | entschieden |
 | Tagebuchgenerierung | Inhalt/Bedeutung und Stil getrennt erzeugen | bevorzugte Richtung |
 | Action Candidates | Übergabe an Kairo | entschieden |
+| Adaptiver Einstieg | Contextual Continuation als Default, freie Reflexion und Navigation jederzeit möglich | entschieden |
+| Hauptvorschlag | ein priorisierter Vorschlag plus wenige diskrete Alternativen | entschieden |
+| Reflection Intent | eigene Dimension neben Reflection Space | entschieden |
+| Primäre Startlogik | Kontinuität des Dialogs statt Funktions-Dashboard | entschieden |
+| Strukturierungsautonomie | KI erkennt, schlägt vor und kann abhängig von Konfiguration selbständig strukturieren/konsolidieren | entschieden |
+| Strukturpflege | Nutzer soll nicht zum Verwalter von Threads/Spaces werden | entschieden |
+| Fachlich vs. technisch | grundsätzlich getrennte Konzeptstränge; technische Vorentscheidungen nur bei wesentlichen Architekturzwängen | entschieden |
 | Produktname Kanshō | Arbeitstitel | offen |
 
 ---