Kansho/docs/architecture/functional/Idea_seconmd_sclide.md

Du arbeitest im Kanshō-Repository als fachlicher Konzept-Worker.

Deine Aufgabe ist ausdrücklich nicht, Slice 2 zu implementieren oder technische Detailarchitektur vorwegzunehmen. Du sollst auf Basis der bestehenden kanonischen Fachkonzepte einen fachlich belastbaren Vorschlag und Anforderungsschnitt für den zweiten vertikalen Produktslice erarbeiten, der anschließend als Grundlage für einen Coding Agent dienen kann.

Ausgangslage

Der erste MVP-Slice ist abgeschlossen.

Er realisiert einen journalzentrierten Anwendungsfall innerhalb eines Reflection Space:

• Beispiel Reflection Space: Veli Lošinj 2026
• pro Tag kann es einen Journal Day geben
• pro Tag können mehrere Conversations/Chats geführt werden
• der Nutzer kann entscheiden, welcher Dialog bzw. welche Dialoge als Inputquelle für die Journalgenerierung verwendet werden
• der ausgewählte Dialog wird nicht direkt als Tagebucheintrag übernommen
• aus dem Dialog wird mehrstufig mit Hilfe der KI und des persönlichen Writing Profile ein persönlicher Journal Draft generiert
• dieser Draft kann anschließend redigiert und als Journal Entry übernommen werden
• das Ergebnis soll insbesondere bei Reise-/Urlaubstagebüchern eine zusammenhängende, menschenlesbare autobiografische Erinnerung ergeben

Diese Fähigkeit ist wertvoll und darf durch Slice 2 nicht verschlechtert oder fachlich entwertet werden.

Gleichzeitig bildet dieser MVP nur eine Teilmenge des Kanshō-Zielbilds ab.

Kanshō soll langfristig ein Personal Reflection Companion sein und nicht auf Tagesjournal bzw. Tagebuch beschränkt bleiben.

Bestehendes fachliches Zielbild

Die vorhandenen Fachkonzepte unterscheiden insbesondere:

Reflection Space

Der Reflection Space beschreibt den Bedeutungs-, Lebens- oder Erfahrungskontext.

Beispiele:

• Urlaub → Veli Lošinj 2026
• persönliche Entwicklung
• Beruf
• Familie
• ein konkretes längerfristiges persönliches Thema

Ein Reflection Space ist kein bloßer Ordner und kein Intent. Er bildet für den Nutzer einen verständlichen Denk- und Erfahrungsraum und soll ein wesentliches menschliches Ordnungsprinzip bleiben.

Nutzungssituation / Reflection Intent

Die bestehende Fachkonzeption beschreibt elf vorläufig vollständige Nutzungssituationen:

1. Erleben festhalten
2. Tagesreflexion
3. Spontaner Gedanke / Moment
4. Früheren Faden fortsetzen
5. Tiefe Reflexion / biografische Frage
6. Entscheidung / Orientierung
7. Inspiration / Vision / Kreativität
8. Achtsamkeit / Meditation / Check-in
9. Rückblick und persönliche Entwicklung
10. Geplante Reflexionszeit / Ritual
11. Wiederfinden und Revue passieren

Diese Nutzungssituationen sind keine elf Reflection Spaces und keine Verpflichtung zu elf technischen Intent Engines.

Sie beschreiben, was der Nutzer in einer konkreten Interaktion gerade erreichen möchte.

Der Reflection Intent kann:

• explizit durch den Nutzer gesetzt werden,
• von Kanshō aus Einstieg und Kontext erkannt werden,
• sich im Verlauf derselben Conversation verändern.

Ein Intent-Wechsel soll einen natürlichen Dialog nicht automatisch in mehrere Chats zerlegen.

Threads

Eine Conversation kann mehrere Reflexionsfäden enthalten.

Threads dienen langfristiger inhaltlicher Kontinuität und können über Conversations, Tage und ggf. Reflection Spaces hinweg weiterlaufen.

Nicht jedes Seitenthema soll automatisch einen sichtbaren oder langlebigen Thread erzeugen.

Memory und Context

Die bestehende Baseline lautet insbesondere:

• aktueller Dialog zuerst
• Primary Reflection Space vor globalem Langzeitgedächtnis
• Long-Term Memory nur bei tatsächlichem Bedarf
• Minimum sufficient context
• Retrieval findet Kandidaten; Context-Auswahl entscheidet Relevanz
• semantische Ähnlichkeit allein ist kein Relevanznachweis
• Source bleibt kanonisch
• Derived ersetzt Source nicht
• Current Validity und History bleiben getrennt
• Nutzerkorrekturen haben Vorrang
• langfristige Dialogkontinuität muss unter Kontrolle von Kanshō bleiben

Die bestehende fachliche Eskalation ist sinngemäß:

Current Session → Primary Reflection Space → aktive Threads / offene Fragen → relevanter Reflection Context → relevantes Kanshō Long-Term Memory → mindnet → Original Sources / Re-Grounding

Reflection Outputs

Ein Dialog kann mehrere unterschiedliche Ergebnisse erzeugen.

Beispielsweise:

• Journal Entry
• Reflection Memory
• Knowledge Delta
• Action Candidate
• interne Kontinuitätsstrukturen wie Thread Memory oder offene Fragen

Nicht jede Conversation muss ein sichtbares Output-Artefakt erzeugen.

Zentrale Fragestellung für Slice 2

Der nächste Slice soll das heute journalzentrierte System zu einem allgemeineren dialogischen Reflexionsbegleiter weiterentwickeln.

Dabei muss insbesondere geprüft werden:

Wie kann ein Reflection Space unterschiedliche Reflection Intents und natürlich gemischte Conversations tragen, ohne dass dadurch die heute bereits gut funktionierende Fähigkeit verloren geht, aus einem oder mehreren ausgewählten Dialogen einen kohärenten persönlichen Tages- bzw. Reisetagebucheintrag zu generieren?

Beispiel:

Im Reflection Space Veli Lošinj 2026 beginnt eine Conversation mit der Beschreibung des Urlaubstags.

Während des Gesprächs sagt der Nutzer beispielsweise:

„Mir fällt auf, dass ich hier im Urlaub viel bewusster lebe als zu Hause.“

Daraus kann sich eine längere tiefere Reflexion entwickeln.

Danach erzählt der Nutzer möglicherweise wieder weiter vom Tagesgeschehen.

Die Conversation enthält damit mindestens:

• autobiografisches Tageserleben
• persönliche Reflexion
• möglicherweise einen längerfristig relevanten Reflexionsfaden

Trotzdem soll aus diesem Dialog weiterhin ein guter zusammenhängender Journal Entry über den Urlaubstag generiert werden können.

Dabei darf weder gelten:

• „der vollständige Dialog muss ungefiltert in den Journalentwurf einfließen“

noch:

• „alles, was während eines anderen Reflection Intents gesagt wurde, darf grundsätzlich nicht in das Journal“

Denn eine persönliche Reflexion kann sehr wohl ein wichtiger Teil der autobiografischen Erinnerung dieses Tages sein.

Deine Aufgabe

Erarbeite daraus einen fachlichen Vorschlag für Slice 2.

Prüfe dabei insbesondere folgende Punkte.

1. Produktthese des Slices

Formuliere präzise:

• welche neue Nutzerfähigkeit Slice 2 beweisen soll,
• warum diese nach dem Journal-MVP der sinnvollste nächste vertikale Schritt ist,
• welche Teile des Kanshō-Zielbilds dadurch erstmals real validiert werden.

Vermeide einen rein technischen „Memory-Ausbau“ als Produktthese.

2. Reflection Space als Ordnungsrahmen

Prüfe und konkretisiere:

• welche Rolle Reflection Spaces im Slice spielen,
• wie sie für den Nutzer als nachvollziehbares Ordnungsprinzip erhalten bleiben,
• wie Conversations mit unterschiedlichen Intents innerhalb desselben Space organisiert werden,
• wie verhindert wird, dass Threads, Memories, Intents und Derived Objects zu einer unübersichtlichen sichtbaren Struktur führen.

Beachte dabei die bestehende Leitlinie:

interne Reichhaltigkeit darf deutlich größer sein als die sichtbare Nutzerstruktur.

3. Multi-Intent Conversation

Definiere fachlich:

• wie der initiale Reflection Intent entsteht,
• wie expliziter Nutzer-Intent und automatische Erkennung zusammenspielen,
• wie sich Intent innerhalb derselben Conversation verändern darf,
• welche Auswirkungen Intent auf Dialogtiefe, Richtung, Initiative und Kontextnutzung besitzt,
• welche Zustände tatsächlich langlebig gespeichert werden müssen und welche nur operative Dialogsteuerung sein können.

Lege nicht vorschnell eine neue reduzierte Intent-Taxonomie fest.

Wenn mehrere fachliche Intents dieselbe technische Dialog-/Context-Policy verwenden könnten, darfst du dies als spätere technische Verdichtung benennen. Die elf fachlichen Nutzungssituationen sollen dadurch jedoch nicht stillschweigend ersetzt werden.

4. Erhalt des Journal-Workflows

Dies ist ein zentrales Acceptance-Thema des Slices.

Beschreibe fachlich, wie der bestehende Workflow erhalten bleiben kann:

Reflection Space → Journal Day → ein oder mehrere Dialoge als Input auswählen → mehrstufige KI-Generierung mit Writing Profile → Journal Draft → Nutzerredaktion → Journal Entry

Berücksichtige dabei insbesondere gemischte Conversations.

Klärungsbedarf:

• Wie entscheidet sich fachlich, welche Inhalte eines gemischten Dialogs für einen konkreten Journal Draft relevant sind?
• Welche Rolle spielen Reflection Intent, Tagesbezug, Ereignisbezug, Nutzerwahl und andere Signale?
• Kann ein und derselbe Gesprächsabschnitt für mehrere fachliche Ergebnisse relevant sein?
• Wie bleibt der Originaldialog die Quelle?
• Welche fachliche Provenance zwischen Quelle und Output wird benötigt?
• Muss dafür ein eigenes langlebiges Segmentobjekt entstehen oder reicht fachlich zunächst die Fähigkeit, Outputs auf relevante Message-/Source-Bereiche zurückzuführen?
• Welche dieser Fragen muss Slice 2 tatsächlich lösen und welche darf offen bleiben?

Wichtig:

Der Nutzer soll weiterhin auf grober Ebene entscheiden können, welche Conversation(s) eines Tages als Inputquelle für den Journal Draft dienen.

Kanshō darf innerhalb dieser Quellen eine feinere inhaltliche Relevanzbewertung übernehmen, ohne daraus eine komplexe Segmentverwaltungsoberfläche für den Nutzer zu machen.

5. Threads und Kontinuität

Bestimme den minimal notwendigen Umfang für Slice 2.

Prüfe:

• wann ein Nebenfaden lediglich temporärer Gesprächskontext bleibt,
• wann daraus ein Thread Candidate entstehen kann,
• wann ein langlebiger Thread erforderlich ist,
• wie ein bereits bestehender Thread später fortgesetzt werden kann,
• welches minimale Thread Memory dafür benötigt wird.

Vermeide eine vollständige Thread-Ontologie oder umfangreiche automatische Thread-Verwaltung, wenn sie für diesen Slice nicht erforderlich ist.

6. Memory und Context Builder

Beschreibe den minimal notwendigen fachlichen Memory-Ausbau.

Insbesondere:

• welche Memory-/Context-Schichten Slice 2 tatsächlich benötigt,
• wie der Reflection Intent die Context-Auswahl beeinflusst,
• welche früheren Informationen bei unterschiedlichen Intents eher relevant sind,
• wie Reflection Space first, Long-Term Memory on demand erhalten bleibt,
• wie verhindert wird, dass globale autobiografische Suche zum Normalfall jedes Turns wird.

Prüfe ausdrücklich, welche Fähigkeiten noch nicht notwendig sind.

7. Persistenz und Outputs

Klär fachlich, welche langlebigen Ergebnisse Slice 2 benötigt.

Beispielsweise:

• Journal Entry
• Thread Memory
• Open Question
• Reflection Memory / Insight
• ggf. andere Derived Objects

Nicht jedes mögliche Target-Objekt soll automatisch Bestandteil des Slices werden.

Für jedes vorgeschlagene langlebige Objekt beantworte:

• Warum benötigt der aktuelle Slice dieses Objekt jetzt?
• Würde ein späteres Nachrüsten sonst eine grundlegende Refaktierung erzwingen?
• Ist es sichtbares Nutzerartefakt oder primär interne Kontinuitätsstruktur?

Beachte die Implementation Foundation:

Neue Abstraktionen benötigen aktuellen Nutzen.

8. Current Validity, Correction und Provenance

Sobald Derived Memory produktiv für spätere Dialoge verwendet wird, müssen mindestens die bestehenden Foundation-Regeln eingehalten werden:

• Source bleibt kanonisch
• Derived ersetzt Source nicht
• Zeit und Provenance
• Current Validity vs. History
• User Correction > Model Inference

Prüfe, welcher minimale fachliche Korrektur- und Re-Grounding-Umfang für Slice 2 wirklich notwendig ist.

Baue daraus nicht automatisch eine umfangreiche Provenance- oder Memory-Administration als Produktfeature.

9. Auswahl der Nutzungssituationen für Slice 2

Mappe alle elf bestehenden Nutzungssituationen auf:

• bereits durch MVP abgedeckt / Regression Case
• Bestandteil Slice 2
• bewusst später

Begründe die Auswahl.

Prüfe insbesondere, ob für Slice 2 zusätzlich zum bestehenden Journalpfad folgende Situationen geeignet sind:

• Spontaner Gedanke / Moment
• Früheren Faden fortsetzen
• Tiefe Reflexion / biografische Frage
• Entscheidung / Orientierung

Übernimm diese Auswahl aber nicht ungeprüft. Wenn du einen engeren oder besseren vertikalen Schnitt begründen kannst, schlage ihn vor.

10. Acceptance Scenarios

Definiere wenige, aber harte End-to-End-Szenarien.

Mindestens zu prüfen:

A. Bestehendes Reisetagebuch als Regression

Space Veli Lošinj 2026.

Der Nutzer führt einen überwiegend autobiografischen Tagesdialog.

Der bestehende Journalworkflow funktioniert weiterhin mindestens so gut wie im MVP.

B. Gemischter Urlaubsdialog

Ein Dialog beginnt mit Tageserleben, geht in tiefere persönliche Reflexion über und kehrt anschließend zum Tageserleben zurück.

Aus dem Dialog kann weiterhin ein kohärenter persönlicher Journal Draft entstehen.

Die tiefere Reflexion darf dabei weder ungeprüft vollständig in das Journal übernommen noch pauschal ausgeschlossen werden.

C. Freie Nicht-Journal-Reflexion

Der Nutzer beginnt innerhalb eines Reflection Space mit einer persönlichen Frage.

Kein Journal Day ist zwingend erforderlich.

Kanshō führt intentgerecht einen tieferen Reflexionsdialog.

D. Früheren Faden fortsetzen

Nach mehreren Tagen wird ein bestehender relevanter Reflexionsfaden fortgesetzt.

Der Nutzer muss den bisherigen Denkstand nicht erneut vollständig erklären.

E. Intent-Wechsel

Der Intent verändert sich innerhalb derselben Conversation, ohne dass der Nutzer einen neuen Chat starten muss.

F. Kein relevantes Memory

Kanshō führt einen natürlichen Dialog, ohne künstlich frühere Erinnerungen oder Zusammenhänge anzudeuten.

11. Explizite Non-Goals

Grenze den Slice klar gegen das spätere Zielmodell ab.

Prüfe insbesondere als Non-Goals:

• vollständiges Self Model
• langfristige automatische Pattern-Erkennung
• globales semantisches Retrieval über die gesamte Biografie
• vollständiger Reflection Graph
• komplexes Resurfacing
• umfassende Thread-Ontologie
• automatische Promotion jedes Gedankens
• mindnet-/Kairo-/Obsidian-Vollintegration
• Meditation/Achtsamkeit als eigener großer Interaction Slice
• vollständiger Entwicklungsrückblick
• Revue-/Recall-System
• elf technische Intent Engines

12. Auswirkungen auf bestehende Fachkonzepte

Prüfe zum Abschluss:

• welche bestehenden Fachentscheidungen der Slice lediglich konkretisiert,
• wo tatsächlich eine neue fachliche Entscheidung erforderlich ist,
• welche Dokumente später additiv aktualisiert werden müssten,
• ob irgendwo bestehende Konzepte widersprüchlich oder für den Slice noch unzureichend sind.

Ändere keine kanonischen Dateien in diesem Arbeitsschritt.

Zu lesende kanonische Grundlage

Lade mindestens:

• docs/architecture/functional/produktvision_und_produktidentitaet.md
• docs/architecture/functional/usage_situations.md
• docs/architecture/functional/reflection_spaces.md
• docs/architecture/functional/dialogue_model.md
• docs/architecture/functional/memory_and_context.md
• docs/architecture/functional/reflection_outputs.md
• docs/architecture/functional/implementation_foundation.md

Zusätzlich gezielt, soweit für konkrete Entscheidungen erforderlich:

• resurfacing_and_saturation.md
• context_fidelity_and_regrounding.md
• writing_profile_and_journaling.md
• mvp.md
• aktuelle technische MVP-Dokumentation beziehungsweise Code nur zur Prüfung von Ist-Stand und Migrationsrisiko

Verwende mvp_stand_und_abgleich.md nur mit Vorsicht als historischen Snapshot, falls der aktuelle Repo-Stand inzwischen weiterentwickelt wurde.

Erwartetes Ergebnis

Liefere einen strukturierten fachlichen Slice-Vorschlag mit:

1. Executive Summary
2. Produktthese
3. fachlichem Zielbild des Slices
4. Fit-Gap zum abgeschlossenen Journal-MVP
5. Mapping der elf Nutzungssituationen
6. Rollen von Space, Conversation, Intent, Thread, Memory und Output
7. Journal-Regressionsmodell einschließlich gemischter Conversations
8. minimalem Memory-/Continuity-Umfang
9. notwendigen fachlichen Objekten und Beziehungen
10. Acceptance Scenarios und Acceptance Criteria
11. expliziten Non-Goals
12. offenen Produktentscheidungen
13. empfohlenen Dokumentationsänderungen
14. klarer Empfehlung, ob dieser Slice der optimale nächste vertikale Schritt ist oder ob ein kleinerer/besserer Schnitt vorzuziehen ist

Wichtig:

• Keine Implementierung beginnen.
• Keine Dateien verändern.
• Keine Target Capabilities allein deshalb vorbauen, weil sie im Gesamtmodell existieren.
• Fachliche Anforderungen und technische mögliche Umsetzung klar trennen.
• Bestehende Entscheidungen nicht stillschweigend ersetzen.
• Bei Widersprüchen zwischen Dokumenten diese explizit benennen.
• Den bestehenden Reisetagebuch-Workflow als harte Regression behandeln.
• Ziel ist ein umsetzbarer vertikaler Slice, nicht eine neue vollständige Kanshō-Gesamtarchitektur.