From 2115ac57580cf4f889dbe283bb76fec254470344 Mon Sep 17 00:00:00 2001 From: Lars Date: Tue, 18 Aug 2026 11:49:21 +0200 Subject: [PATCH] Dateien nach "docs/architecture/functional" hochladen --- .../functional/fachliche_zielarchitektur.md | 79 ++++++--- .../produktvision_und_produktidentitaet.md | 161 +++++++++++++++++- 2 files changed, 217 insertions(+), 23 deletions(-) diff --git a/docs/architecture/functional/fachliche_zielarchitektur.md b/docs/architecture/functional/fachliche_zielarchitektur.md index 3e01c57..b4fd332 100644 --- a/docs/architecture/functional/fachliche_zielarchitektur.md +++ b/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. diff --git a/docs/architecture/functional/produktvision_und_produktidentitaet.md b/docs/architecture/functional/produktvision_und_produktidentitaet.md index a87aac8..8083f4f 100644 --- a/docs/architecture/functional/produktvision_und_produktidentitaet.md +++ b/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 | ---