--- title: "Kanshō – MVP" status: "MVP-Spezifikation / freigegebener erster vertikaler Slice" date: "2026-08-21" product_family: "Jinkendo" document_role: "Konkrete MVP-Spezifikation auf Basis der Implementation Foundation" --- # Kanshō – MVP ## 1. Zweck und Scope Dieses Dokument spezifiziert den **ersten vertikalen, real nutzbaren Kanshō-Slice**. Der MVP ist bewusst kleiner als das vollständige Kanshō-Zielmodell. Er soll: - früh real nutzbar sein, - die Implementation Foundation respektieren, - keine später teuren strukturellen Sackgassen erzeugen, - aber nicht vorsorglich das gesamte Target Model implementieren. Leitgedanke: > **Ein dialoggeführtes persönliches Tagebuch, bei dem Kanshō aus dem Gespräch über einen Tag einen Tagebucheintrag im Stil und möglichst mit den Worten des Nutzers erzeugt.** Der Nutzer kann den erzeugten Eintrag anschließend redigieren, mit Medien anreichern und später chronologisch wiederfinden. Der besondere Kanshō-Mehrwert gegenüber einem klassischen Journal ist: > **Der Dialog berücksichtigt den bereits erzählten Tagesverlauf, den aktuellen Reflection Space, relevante frühere Aussagen und die typische Erzählweise des Nutzers, sodass die Gesprächsführung nicht auf generischen Standardfragen basiert.** --- # 2. Produktversprechen des MVP Der MVP unterstützt den folgenden Kernablauf: > **Erzählen → Reflektieren → Tagebucheintrag generieren → redigieren → bewahren → später wiederfinden** Dabei bleibt der Dialog die primäre Erfassungs- und Reflexionsform. Der erzeugte Tagebucheintrag ist eine aus dem Dialog abgeleitete, lesbare autobiografische Darstellung. --- # 3. Sichtbare fachliche Einheiten ## 3.1 Reflection Space Ein Reflection Space bildet den übergeordneten Kontext. Beispiele: - `Lošinj 2026` - `Kleinwalsertal 2026` - `Alltag` Für den MVP ist ein Reflection Space sichtbar und auswählbar. Ein Reflection Space kann mehrere Journal Days und Journal Entries enthalten. Reflection Spaces werden im MVP nicht als komplexe Graph- oder Wissensstruktur dargestellt. ### MVP-Funktionen Der Nutzer kann: - Reflection Space erstellen, - Reflection Space umbenennen, - Reflection Space auswählen, - chronologische Journal Entries dieses Spaces anzeigen. --- ## 3.2 Journal Day Der Journal Day ist die **chronologische Bezugseinheit eines Tages**. Beispiel: > Donnerstag, 20. August 2026 Wichtig: > **Journal Day ist nicht Thread.** Ein Journal Day beschreibt den Tag, über den erzählt wird. Der Zeitpunkt des Dialogs kann davon abweichen. Beispiel: - Journal Day: `2026-08-20` - Dialogfortsetzung: `2026-08-21 07:15` Damit kann der Nutzer einen Tag am selben Abend, in mehreren Phasen oder am Folgetag ergänzen. --- ## 3.3 Dialog / Source Der Originaldialog ist die primäre Quelle. Er enthält insbesondere: - User Messages, - AI Messages, - Session-/Message-Zeitpunkte, - Bezug zum Journal Day, - Bezug zum Reflection Space, - gegebenenfalls Medien oder weitere Quellen. Der Originaldialog bleibt erhalten und wird durch generierte Journaltexte nicht ersetzt. Der Nutzer kann ein Gespräch ausdrücklich aus dem Tag entfernen. Das löscht diese Dialogquelle, nicht einen bereits bewahrten Journal Entry. Eine Zusammenführung mehrerer Gespräche wird nur im Moment der Generierung angeboten, nicht als Dauerzustand auf der Seite. --- ## 3.4 Journal Draft Ein Journal Draft ist eine von Kanshō aus dem relevanten Dialog erzeugte Fassung. Er ist: - Derived, - noch nicht automatisch die kanonische Nutzerfassung, - veränderbar, - erneut generierbar. Ein neuer Draft darf eine bereits gespeicherte Nutzerfassung nicht stillschweigend überschreiben. --- ## 3.5 Journal Entry Ein Journal Entry entsteht, sobald der Nutzer eine erzeugte oder bearbeitete Fassung als Tagebucheintrag übernimmt beziehungsweise speichert. Der Journal Entry: - besitzt stabile Identität, - gehört zu einem Reflection Space, - besitzt einen Journal Day, - besitzt eine Versionshistorie, - kann Medien enthalten, - verweist auf seine zugrunde liegenden Quellen/Dialoge. Ein Journal Entry bleibt später bearbeitbar. --- # 4. Mehrere Dialoge am selben Tag ## 4.1 Mehrere Dialogphasen im selben Reflection Space Mehrere zeitlich getrennte Dialoge können denselben Journal Day betreffen. Beispiel: - morgens erste Erzählung, - abends Fortsetzung, - am Folgetag Ergänzung. Sie müssen nicht automatisch einen einzigen Dialogthread bilden. ### Konsolidierungsregel Wenn mehrere Dialogverläufe: - dieselbe oder sehr ähnliche Erzählweise besitzen, - denselben narrativen Typ besitzen, - vergleichbare Tiefe besitzen, - inhaltlich eng zusammengehören, kann Kanshō eine **Konsolidierung zu einem gemeinsamen Tagebucheintrag anbieten**. Beispiel: - chronologischer Bericht morgens, - chronologische Fortsetzung abends. ### Getrennt lassen Wenn Dialogverläufe deutlich unterschiedliche: - Tiefen, - Fokusse, - Erzählweisen, - Reflexionsmodi besitzen, bleiben sie standardmäßig getrennt. Beispiel: - chronologischer Urlaubsbericht, - separate tiefe emotionale Selbstreflexion. ### Verbindliche Regel > **Konsolidierung wird angeboten, nicht erzwungen.** --- ## 4.2 Gleicher Tag in unterschiedlichen Reflection Spaces Dialoge oder Journal Entries desselben Kalendertags in unterschiedlichen Reflection Spaces bleiben im MVP **standardmäßig getrennt**. Beispiel: - `Lošinj 2026` → chronologischer Urlaubstag - `Meditationsreise` → tiefe Reflexion über eine Meditation am selben Tag Eine gemeinsame Quelle oder dasselbe Erlebnis darf später referenziell verbunden werden, ohne die beiden Journal-Kontexte automatisch zusammenzuführen. --- # 5. Dialogführung ## 5.1 Ziel Kanshō führt keinen Tagebuch-Fragebogen. Die Gesprächsführung soll sich wie ein **kontextsensitiver Reflexionspartner** anfühlen. Der nächste Gesprächsimpuls entsteht aus: - dem bereits erzählten Teil des Journal Day, - der aktuellen Erzählweise, - relevanten früheren Aussagen im Reflection Space, - bekannten Plänen und Erwartungen, - wiederkehrenden Aktivitäten, - auffälligen Veränderungen, - emotionalen Signalen, - narrativen Lücken, - der typischen Erzählweise des Nutzers. MVP-Umsetzung des Space-Kontexts: keine Content Memory, sondern die letzten gespeicherten Journal Entries desselben Spaces als Recency-Ausschnitte. Der laufende Journal Day bleibt die führende Quelle des Impulses. --- ## 5.2 Allgemeine Dialogoperationen Für den MVP werden keine Intent-Graphen oder elf technischen Dialogmodi gebaut. Kanshō kann stattdessen wenige allgemeine Dialogoperationen verwenden: 1. **Fortführen** Den aktuellen Erzählfluss sinnvoll weiterführen. 2. **Konkretisieren** Relevante fehlende Person-, Orts-, Zeit- oder Zusammenhangsinformation klären. 3. **Plan oder Erwartung aufgreifen** Bekannte Vorhaben zeitlich passend vor oder nach dem Ereignis aufgreifen. 4. **Abweichung erkunden** Eine relevante Veränderung gegenüber bisherigem Verlauf oder wiederkehrender Aktivität vorsichtig ansprechen. 5. **Erleben vertiefen** Emotion, Wahrnehmung oder persönliche Wirkung aufgreifen, wenn der Nutzer selbst entsprechende Signale setzt. 6. **Bedeutung erkunden** Einen erkennbar bedeutsamen Punkt weiterführen, ohne künstlich Tiefe zu erzwingen. Diese Operationen sind keine getrennten Nutzungsmodi. --- ## 5.3 Auswahl-Policy für Folgeimpulse Kanshō soll den Gesprächsimpuls wählen, der: > **den aktuellen Erzählmodus respektiert und zugleich den höchsten zusätzlichen autobiografischen oder reflexiven Wert besitzt.** Dabei gelten für den MVP folgende Regeln: 1. Erzählfluss respektieren. 2. Bei ausführlichem Erzählen wenig unterbrechen. 3. Pro Antwort höchstens einen dominanten Anschlussimpuls setzen. 4. Lokal an das zuletzt Erzählte anschließen. 5. Nicht redundant fragen und nicht nacherzählen: schon Gesagtes nicht als Impuls umformulieren. 6. Starke emotionale oder bedeutungsvolle Signale bevorzugen, wenn der Nutzer selbst diese Ebene geöffnet hat. 7. Bekannte Pläne und Erwartungen zeitlich passend aufgreifen. 8. Relevante Abweichungen vorsichtig formulieren. 9. **Nicht erwähnt bedeutet nicht nicht geschehen.** 10. Ein unspektakulärer Tag darf unspektakulär bleiben. 11. Nicht jede Antwort muss eine Frage enthalten. 12. Generische Standardfragen sind nur Fallback. 13. Bei hoher Erzählaktivität begleitet Kanshō stärker, statt den Nutzer zu interviewen. 14. Ein starker emotionaler oder narrativer Wendepunkt darf einen rein chronologischen Anschluss überstimmen. 15. Bereits ausdrücklich beantwortete emotionale Informationen werden nicht erneut trivial abgefragt; Kanshō kann stattdessen Ursache, Bedeutung oder Spannung vertiefen. 16. Wenn der Nutzer den Tag oder die Szene selbst schließt, hält Kanshō den Schluss. Keine neue Frage, keinen Tagesbogen nacherzählen. ### 5.3.1 Internes Register (MVP-Umsetzung) Ein zweites generatives Modell nur für Ton und Erzählmodus ist nicht der MVP-Weg. Kanshō bestimmt Dichte, Plan, Erleben und Schluss lokal (`register_hint`) und gibt sie zusammen mit einem Writing-Profile-Hinweis in denselben Dialog-Prompt. Die sichtbaren Operationen bleiben die sechs allgemeinen; keine Intent-Engines. Die Stimme ist die eines Vertrauten im natürlichen Gesprächsfluss, nicht die einer Maschine, eines Interviewprotokolls oder einer App. Interne Register- und Operationsworte gehören nicht in den Impuls. Für die Tagesreflexion: ein kurzer Impuls zum nächsten Gedanken und abgeleitete Denkanstöße sind erwünscht. Nacherzählen nur bei Widerspruch oder Logikbruch, um ihn zu klären. Lokale Wächter greifen bei erfundenem Vollzug, erfundener Empfindung, bei Nacherzählen ohne solchen Bruch (auch als Zusammenfassung plus Anschlussfrage), bei Systemfloskeln und bei Frage beziehungsweise Tagesbogen nach einem selbst gesetzten Schluss – nicht bei einer knappen Anschlussfrage ohne Zusammenfassung. Wenn der Impuls lokal ersetzt wird, lädt Kanshō zur Fortsetzung ein („Ich bin gespannt, wie es weitergeht.“ / „Erzähl bitte weiter.“), statt Anwesenheit zu melden; bei selbst gesetztem Schluss bleibt der Schluss. ### 5.3.2 Drei Schichten (MVP, später wiederverwendbar) Maskierung, Dialogzug und Journalentwurf sind getrennte Verantwortungen. „Detect“ entscheidet keine Operation. „Generate“ meint im Produkt den Journalentwurf, nicht den Dialogzug. | Schicht | Aufgabe | Aufruf | |---|---|---| | Maskierung | nur schützenswerte Muster (Namen, benannte Orte) | Muster + Wörterbuch; Testphase: OpenRouter-Detect; Produktivziel: lokal / Ollama | | Dialogzug | eine Operation + ein Impuls, Ton und Tiefe | ein maskierter Modell-Call (`mvp.dialogue_turn`) | | Journalentwurf | Tagebuchtext aus den Worten der Person | zweiter maskierter Call, nur explizit (`mvp.journal_generate`) | Die Maskierung gilt unabhängig vom späteren Dialogtyp. Neue Dialoge bekommen eigene Prompts, nicht eine zweite Maskierungs-Logik. Es gibt keinen dritten Call, der nach der Operation noch einmal antwortet. Intern in der Testspur ist die lokale Klartext-Vorlage des Dialogzugs, nicht ein eigener KI-Call. Egress ist dieselbe Vorlage, maskiert. Die sichtbare Kanshō-Zeile ist das Feld `impulse` aus diesem einen Dialogzug. In der Testphase darf Detect Klartext über OpenRouter sehen; das ist ein bewusster Übergang, nicht der Produktivpfad. --- ## 5.4 Beispiel: bekannter Tagesplan Wenn am Vortag im selben Reflection Space festgehalten wurde: > „Morgen wollen wir nach Cres fahren.“ kann Kanshō abhängig vom Zeitpunkt beispielsweise fragen: ### Vor dem Ereignis > „Heute steht doch eure Fahrt nach Cres an. Seid ihr schon bei den Vorbereitungen?“ oder bei vorher erkennbarer emotionaler Spannung: > „Heute ist eure Fahrt nach Cres. Gestern klangst du gleichzeitig gespannt und etwas nervös – wie fühlt es sich jetzt an?“ ### Nach dem Ereignis > „Heute stand doch eure Fahrt nach Cres an. Wie war sie schließlich?“ --- ## 5.5 Beispiel: wiederkehrende Aktivität Wenn in mehreren bisherigen Morgenbeschreibungen desselben Reflection Space Japanischlernen vorkam und es heute bisher nicht erwähnt wurde, darf Kanshō dies vorsichtig aufgreifen. Geeignet: > „Die letzten Tage hast du morgens häufig Japanisch gelernt. Heute ist es bisher noch nicht zur Sprache gekommen. War der Morgen heute anders oder ist es nur noch nicht erwähnt worden?“ Nicht geeignet: > „Warum hast du heute kein Japanisch gelernt?“ --- ## 5.6 Beispiel: emotionaler Bericht Wenn der Nutzer sagt: > „Ich war erst richtig sauer und habe dann gemerkt, dass ich eigentlich eher enttäuscht war.“ soll Kanshō nicht erneut trivial fragen: > „Wie hast du dich gefühlt?“ Sinnvoller kann sein: > „Was war für dich enttäuschender – das konkrete Verhalten oder dass du in diesem Moment etwas anderes erwartet hattest?“ --- # 6. Start eines Journal-Dialogs Ein neuer Journal-Dialog beginnt nicht zwingend mit: > „Erzähl mir von deinem Tag.“ Wenn relevanter Kontext verfügbar ist, soll Kanshō daraus einen sinnvolleren Einstieg erzeugen. Mögliche Kontextquellen: - bereits bekannte Tagespläne, - vorher angekündigte Ereignisse, - laufende Erzählung desselben Journal Day, - relevante wiederkehrende Aktivitäten im Reflection Space, - offene narrative Punkte. Nur wenn kein sinnvoller Kontext verfügbar ist, wird ein neutraler Einstieg verwendet. Der erste Gesprächsimpuls unterliegt derselben Dialog-Policy wie spätere Folgeimpulse. ### 6.1 Implementierungsstand (Freeze Candidate 2026-08-25) **Status: Code vorhanden, journalspezifisch, keine universelle Continuation-Engine.** Ein neu gestarteter Journal-Dialog erhält einen ersten Kanshō-Impuls. Belegte Vorhaben und offene user-Punkte desselben Journal Day dürfen den Einstieg stützen. Recency allein ist kein Muster. Assistententext ist Kontext, kein Nutzerfakt. Ohne relevanten Kontext: kurzer neutraler lokaler Einstieg. Fehlgeschlagener Modelloutput speichert keine beschädigte Nachricht. --- # 7. Unterbrechen und Fortsetzen Der Nutzer kann einen Journal-Dialog jederzeit unterbrechen. Beim späteren Öffnen desselben Journal Day berücksichtigt Kanshō: - was bereits erzählt wurde, - welche Abschnitte des Tages schon abgedeckt sind, - relevante offene narrative Punkte, - gegebenenfalls inzwischen zeitlich eingetretene geplante Ereignisse. Eine Fortsetzung am Folgetag bleibt dem ursprünglichen Journal Day zugeordnet, sofern der Nutzer über diesen Tag weitererzählt. --- # 8. Generierung des Tagebucheintrags ## 8.1 Nutzersteuerung Die Erzeugung eines Journal Draft erfolgt im MVP **explizit durch den Nutzer**. Beispiel: > **Tagebucheintrag generieren** Kanshō generiert nicht automatisch nach jeder Session einen fertigen Tagebuchtext. --- ## 8.2 Eingaben für die Generierung Für die Generierung dürfen verwendet werden: 1. die relevanten Originaldialoge des Journal Day, einschließlich der Kanshō-Impulse als Gesprächskontext (nicht als Erlebtes), 2. der aktuelle Reflection-Space-Kontext, soweit er für Verständnis und Kohärenz nötig ist, 3. das Writing Profile, 4. gegebenenfalls ausgewählte eigene Stilbeispiele, 5. bei einer Aktualisierung ein bereits bestehender Draft oder Journal Entry, sofern dies explizit Teil des gewünschten Vorgangs ist. Im MVP ist der Space-Kontext im Dialogzug die letzten gespeicherten Journal Entries desselben Spaces als kurze Recency-Ausschnitte, keine inhaltliche Space-Memory (keine Threads, keine wiederkehrenden Aktivitäten, keine Relevanzauswahl). Für den laufenden Tag ist der Dialog des Journal Day die führende Quelle. Ein Space Content Memory bleibt später. ### 8.2.1 Freeze Candidate: Space-Kontext bei Generate (2026-08-25) **Status: bewusst begrenzt, entschieden für diesen Slice.** Fachliche Inhaltsquelle der Journalgenerierung sind die ausdrücklich ausgewählten Conversations des Journal Day. Stufe 2 erhält ausschließlich das lokal erzeugte Verified Artifact. Frühere Space Entries sind keine zusätzliche Faktenquelle in Generate. Das Writing Profile darf nur die Form beeinflussen. Space-Kontext kann die Dialogführung stützen, wird aber nicht still zur Journalquelle. **Additiv 2026-08-29:** Ob Core, Facet, Traits und Style Examples überhaupt in den Prompt gelangen, bestimmt die gewählte Stilanwendungsausprägung (`writing_profile_and_journaling.md`). `Ohne persönliches Profil` ist eine profilfreie Kontrollgruppe. Der aktuelle Tagesdialog bleibt Inhaltsquelle, nicht Stilvorlage. --- ## 8.3 Generierungsprinzip Priorität: > **Eigene Formulierungen des Nutzers erhalten → sprachlich verbinden → Struktur verbessern → Writing Profile anwenden.** Kanshō soll nicht zuerst den Inhalt abstrakt extrahieren und anschließend vollständig in generischem KI-Stil neu schreiben. Ein leeres oder nur aus Formhinweisen bestehendes Writing Profile rechtfertigt kein bloßes Durchreichen des Dialogs. Verbinden, Glätten, Absätze und eine Überschrift bleiben Pflicht. Der Quelldialog des zu erzeugenden Tages wird nicht ein zweites Mal als Stil-Exzerpt in den Brief gelegt. Wenn das Modell den Dialog trotzdem nur durchreicht (gleicher Wortlaut, ein Block), formt eine lokale Nachbereitung Absätze an Phasengrenzen. Sie ändert den Wortlaut nicht und erfindet nichts. Wiederholte Personennamen in einer Passage (nach Demaskierung) werden lokal auf ein- bis zwei Nennungen plus Pronomen zurückgeführt, anhand der Pronomen im user-Text; indirekte Rede wird nicht in den Namen zurückgebogen. **Additiv 2026-08-28:** Die lokale Namens-zu-Pronomen-Heuristik nach Demaskierung ist für den MVP zurückgenommen. Sie riet Genus, Numerus und Kasus und konnte akzeptierte Personenbezüge beschädigen. Nach erfolgreicher Demaskierung bleiben nur Titel-/Texttrennung, Zeilenenden und äußerer Whitespace. Eine Wiederholung ist besser als ein falscher Personenbezug. Das Qualitätsziel, übermäßige Namenswiederholungen zu vermeiden, bleibt beim Modell. Wenn das Writing Profile substanzielle finale Fassungen oder Importe enthält, kommt die **Formulierung** aus dieser Stimme, der **Inhalt** weiter nur aus den user-Zeilen. Kurze oder stichwortartige Passagen dürfen zu ganzen Sätzen ausformuliert werden; es werden keine Fakten, Gefühle oder Zeiten erfunden. Fehlt das Profile, bleiben Verbinden und Glätten der user-Formulierungen der Weg. Kanshō-Zeilen im Quelldialog erklären, worauf eine user-Zeile antwortet. Sie werden nicht als Geschehen in den Eintrag übernommen. ### Kanshō darf - Wiederholungen reduzieren, - fragmentierte Erzählteile und denselben Erzählstrang verbinden, - Uhrzeiten und zeitliche Anschlüsse aus dem Gesagten zusammenführen, ohne Zeiten zu erfinden, - Grammatik und Lesbarkeit glätten, - chronologische Struktur verbessern, - sinnvolle Absätze bilden, - eine Überschrift vorschlagen, - vom Nutzer selbst eingeführte Reflexionen sinnvoll integrieren. ### Kanshō darf nicht - Ereignisse erfinden, - fehlende Details plausibel auffüllen, - nicht geäußerte Gefühle hinzufügen, - Motivationen erfinden, - Unsicherheit in Gewissheit umwandeln, - den Ton unnötig dramatisieren, - den Nutzertext in einen generischen KI-Schreibstil überführen, - Kanshō-Impulse als Geschehen in den Eintrag schreiben, - Pronomen durch ständige Wiederholung des Namens ersetzen, - in der indirekten Rede den Namen einsetzen, wo die Person von sich als sie/er spricht. --- # 9. Writing Profile im MVP ## 9.1 Ziel Der generierte Journal Entry soll sich zunehmend wie ein eigener Text des Nutzers lesen. Das Writing Profile darf aus mehreren Quellen entstehen. ### Quellenpriorität 1. **vom Nutzer final redigierte Journal Entries** 2. **vom Nutzer ausdrücklich importierte eigene frühere Texte** 3. **charakteristische Formulierungen und Erzählmerkmale aus dem Dialog** 4. **KI-generierter Draft** Der KI-generierte Draft ist **keine positive Stilreferenz**, solange er nicht durch den Nutzer als eigene Fassung übernommen beziehungsweise redigiert wurde. Verbindliche Regel: > **Finale Nutzerfassungen sind die stärkste Stilquelle. KI-Text darf nicht unbeaufsichtigt auf sich selbst zurücklernen.** --- ## 9.2 Initialisierung Der Nutzer kann vorhandene eigene Texte bereitstellen. Diese dienen als Bootstrap-Material für ein erstes Writing Profile. Der Nutzer muss jedoch nicht zwingend Alttexte importieren. Ohne Import kann sich das Writing Profile schrittweise aus: - Dialogstil, - ersten Journal Entries, - Nutzerkorrekturen entwickeln. --- ## 9.3 Lernsignale Für den MVP können insbesondere berücksichtigt werden: - bevorzugter Detailgrad, - chronologische versus stärker thematische Erzählweise, - typische Satzlänge, - Grad emotionaler Reflexion, - Humor und Witz, - Umgang mit Namen, - Nutzung von Uhrzeiten und konkreten Details, - typische Übergänge, - Wortwahl, - Verhältnis von sachlicher Beschreibung und Reflexion. Eine vollständige Persönlichkeitsmodellierung ist dafür nicht erforderlich. ## 9.4 Implementierungsstand **Status: Code vorhanden (2026-08-25).** Der Current Brief wird lokal zusammengesetzt, ohne zusätzlichen Modell-Call: 1. Erzählmerkmale als lokale Heuristik aus Nutzertext (Satzlänge, Chronologie, Uhrzeiten, Reflexionsanteil, Humor). Keine Diagnose, kein Self Model. 2. Exzerpte finaler Journal Entries, dann Importe, dann charakteristische `user:`-Zeilen. 3. Ein rollierender `dialogue_style`-Eintrag pro Profil, nach jedem Dialogzug aktualisiert. Vor der Journalgenerierung werden die Quellgespräche dieses Entwurfs aus den Stil-Exzerpten ausgenommen; Formhinweise aus demselben Text dürfen bleiben. Sobald finale Journal Entries existieren, gehen Dialog-Exzerpte nicht mehr in den Brief; sie bleiben höchstens ein Hinweis. 4. Der Dialogzug selbst erhält nur die Formhinweise (Erzählmerkmale), keine Dialog-Exzerpte anderer Tage und nicht den gerade offenen Turn. Exzerpte bleiben der Journalgenerierung vorbehalten. 5. KI-Drafts bleiben ausgeschlossen. Finale Nutzerfassungen haben höheres Gewicht (mehr und längere Exzerpte, Stimme vor Dialog). Ohne Import ist der erste Generate-Tag nicht stil-leer (Formhinweise), aber nicht eine zweite Kopie desselben Dialogs. **Additiv 2026-08-29:** Die Stilanwendungsausprägung filtert, welche dieser lokal zusammengesetzten Stilquellen den Provider überhaupt erreichen. Ohne Freigabe entfallen Core, Facet, Traits und Beispiele vollständig, einschließlich Formhinweisen aus dem Tagesdialog. Das ändert die Quellenpriorität nicht; es begrenzt den Egress. --- # 10. Journal Editor Nach der Generierung kann der Nutzer den Journal Draft im Bearbeitungsmodus redigieren. Der Nutzer kann: - Text ändern, - Text ergänzen, - Passagen löschen, - Absätze formatieren (Absatz, Überschrift, Zwischenüberschrift, Listen), - markierte Bereiche formatieren (fett, kursiv, unterstrichen), - Überschrift des Eintrags ändern, - Bilder und Videos an der Schreibmarke einbetten und im Fließtext verschieben, - Zeichnungen beziehungsweise Bilddateien ergänzen, - Bildunterschriften ergänzen. Der Eintrag wird im Fließtext redigiert und als Markdown gespeichert. Medien liegen als lokale Dateien in `media_assets`; im Text stehen Referenzen `![Unterschrift](kansho-media:)`. Alte Marker `[[media:|…]]` werden beim Speichern nach Markdown überführt. Referenzen gehen nicht an externe Modelle. Unterschriften zählen als Nutzerwortlaut. Bilder (JPEG, PNG, GIF, WebP) und einzelne Videos (MP4, WebM, MOV) werden im Editor direkt dargestellt. Dateien verlassen die Local Trusted Zone nicht. Nicht Bestandteil des MVP: - komplexe Audioverwaltung, - Videobibliothek oder Schnitt, - Dokumentarchive, - Karten-/GPS-Timelines. Einzelne, vom Nutzer eingebettete Videos im Journaltext sind damit Teil des Slices; eine Videoverwaltung ist es nicht. ### 10.2 Dialogmedien (Freeze Candidate 2026-08-25) **Status: bewusst nicht im Slice.** Zielarchitektur für Voice/visuellen Egress bleibt unberührt. Keine Medien als direkte Dialogquelle in diesem MVP. Bilder und Videos können im Journal Editor ergänzt werden. Sicherer visueller Modell-Egress, Maskierung und Provenance sind nicht Teil dieses Slices. Dialogmedien werden in einem eigenen späteren Slice umgesetzt. --- ## 10.1 Tagesstichpunkte (Arbeitsstand) Während der Tagesreflexion kann der Mensch eine kurze Stichpunktliste **parallel** zum Dialog führen: sich nicht verlieren, Inhalte nicht vergessen, abhaken wenn erzählt. Das ist **kein** Aufgabenmanager und **keine** Abschluss-Checkliste. Reflexion bleibt das Gespräch. **Bevorzugte Richtung (2026-08-24):** Die Liste ist lokal, nur für die Person, Klasse A. Sie geht nicht in Dialogzug, Journalentwurf, Writing Profile oder Recency-Ausschnitte. Return erzeugt eine neue leere Zeile und setzt den Cursor dorthin. **Offen:** Ob eine spätere, bewusst gewählte und maskierte Nutzung als Gesprächskontext sinnvoll ist. Nicht stillschweigend einschalten. Solange unklar, Fail Closed: kein Egress. --- # 11. Versionierung und Schutz vor unbeabsichtigter Änderung ## 11.1 Version History Sobald ein Journal Entry gespeichert wurde, werden spätere gespeicherte Änderungen versioniert. Beispiel: - v1 – generierter Draft / erste übernommene Fassung - v2 – Nutzerredaktion - v3 – Textkorrektur und Bilder - v4 – spätere Ergänzung Frühere gespeicherte Versionen bleiben wiederherstellbar. Die aktuell geladene Fassung darf in der Liste stehen, wird dort aber nicht wiederhergestellt. Offene, noch nicht gespeicherte Editoränderungen können lokal verworfen werden („Alle Änderungen rückgängig machen“). Verlassen des Editors mit solchen Änderungen wird bestätigt, nicht still verworfen. Browser-Zurück bleibt für diesen Freeze über die vorhandene Warnung und `beforeunload` ausreichend; keine Router-Großmigration nur für einen perfekten Zurück-Blocker. --- ## 11.2 Kein stilles Überschreiben Kanshō darf eine gespeicherte Nutzerfassung nicht automatisch durch eine neue KI-Fassung ersetzen. Eine erneute Generierung erzeugt: - einen neuen Draft, - oder eine neue vorgeschlagene Version. Die bestehende Journal-Version bleibt erhalten, bis der Nutzer eine Änderung ausdrücklich übernimmt. Die Oberfläche öffnet den neuen Entwurf (`?draft=1`), nicht still die gespeicherte Fassung. Übernehmen schreibt eine neue Version des bestehenden Entry; Speichern aus dem Entwurf kann auch einen weiteren Entry anlegen. --- ## 11.3 Löschen Versehntliches endgültiges Löschen soll verhindert werden. Für den MVP: - Entfernen eines Journal Entry führt zunächst zu Soft Delete / Papierkorb, - endgültiges Löschen ist eine separate explizite Aktion, - Version History schützt zusätzlich vor unbeabsichtigten Textänderungen. ### 11.3.1 Implementierungsstand (Freeze Candidate 2026-08-25) **Status: Code vorhanden.** Soft Delete legt in den Papierkorb. Wiederherstellen aus dem Papierkorb ist nicht die Versions-Restore-Semantik. Endgültiges Löschen ist ausdrücklich bestätigt, transaktional, löscht Quelldialoge nicht und entfernt nur unreferenzierte Medien. --- # 12. Journal als Nachschlagewerk ## 12.1 MVP-Navigation Retrieval wird im ersten MVP bewusst klein gehalten. Der Nutzer erhält primär Navigation statt intelligenter Langzeitsuche. Mindestens verfügbar: - chronologische Liste der erzeugten Journal Entries, - Navigation nach Reflection Space, - Datum, - Journal Entry öffnen, - vom Journal Entry zum zugrunde liegenden Quelldialog wechseln. --- ## 12.2 Nicht im MVP Noch nicht erforderlich: - semantische Freitextsuche über die gesamte Biografie, - Natural-Language-Questions über Jahre, - Personen- oder Themencluster, - automatische Jahresrückblicke, - komplexes Source-oriented Retrieval, - Graphnavigation. Die technische Foundation soll späteres Retrieval ermöglichen, ohne es jetzt vollständig zu implementieren. --- # 13. MVP-Screens Der MVP soll bewusst wenige sichtbare Bereiche besitzen. ## 13.1 Journal / Reflection Spaces Zeigt: - verfügbare Reflection Spaces, - chronologische Journal Entries des ausgewählten Spaces, - Möglichkeit, neuen Space anzulegen, - Möglichkeit, bestehenden Space umzubenennen, - Möglichkeit, einen Journal Day zu öffnen oder zu starten. --- ## 13.2 Journal Day / Dialog Zeigt: - Bezugstag, - Reflection Space, - bisherigen Dialog, - Eingabefeld, - optionale persönliche Stichpunkte parallel zum Gespräch (nicht KI-Kontext, siehe §10.1), - Medienoptionen soweit für Dialogquellen nötig, - Aktion `Tagebucheintrag generieren`, - vorhandenen Draft-/Entry-Status. Der Dialog soll sich wie ein natürlicher Chat anfühlen. --- ## 13.3 Journal Editor Zeigt: - generierten beziehungsweise gespeicherten Journaltext, - Überschrift, - Fließtexteditor mit Absatz- und Auswahlformaten, - eingebettete Bilder und Videos samt Unterschrift, - Speichern, - Versionshistorie, - gegebenenfalls neue Draft-Fassung übernehmen. --- ## 13.4 Source Dialog Vom Journal Entry kann der Nutzer auf den zugrunde liegenden Originaldialog wechseln. Diese Ansicht dient: - Nachvollziehbarkeit, - persönlichem Nachlesen, - Provenance, - späterem Re-Grounding. Eine komplexe technische Provenance-UI ist im MVP nicht erforderlich. --- # 14. Minimaler technischer/fachlicher Datenbedarf des Slices Die konkrete technische Implementierung bleibt der technischen Architektur vorbehalten. Der MVP benötigt fachlich mindestens: - User - Reflection Space - Journal Day - Session / Dialog - Message / Source - Journal Draft - Journal Entry - Journal Entry Version - Media Reference - grundlegende Source References - Writing Profile beziehungsweise Writing-Style-Kontext Threads, Open Questions, Experiences und Insights müssen für den ersten Slice nicht als sichtbare oder vollständige produktive Objektmodelle implementiert werden. --- # 15. MVP Acceptance Cases ## A. Einfacher Journal Day Der Nutzer führt einen Dialog über seinen Tag. Er löst `Tagebucheintrag generieren` aus. Kanshō erstellt einen lesbaren Journal Draft. Der Nutzer korrigiert einige Formulierungen und speichert den Journal Entry. **Bestanden, wenn:** - Originaldialog erhalten bleibt, - Journal Entry lesbar und quellentreu ist, - Nutzeränderungen gespeichert werden, - der Entry chronologisch im Reflection Space erscheint. --- ## B. Mehrphasiger Tag Der Nutzer: - erzählt morgens, - setzt den Dialog abends fort, - ergänzt am Folgetag noch einen Punkt. Alle Beiträge beziehen sich auf denselben Journal Day. **Bestanden, wenn:** - Journal Day und tatsächliche Message-Zeitpunkte getrennt bleiben, - alle relevanten Quellen einem Journal Entry zugrunde liegen können, - genau der gewünschte Tag chronologisch angezeigt wird. --- ## C. Kontextsensitiver Dialog Ein Tagesplan wurde zuvor im selben Reflection Space erwähnt. Oder eine Aktivität ist in mehreren vorherigen Tagen wiederholt aufgetreten. **Bestanden, wenn:** - Kanshō einen relevanten Plan oder eine relevante Abweichung sinnvoll aufgreifen kann, - keine generische Standardfrage nötig ist, - Kanshō `nicht erwähnt` nicht mit `nicht geschehen` verwechselt. --- ## D. Ausführliche Erzählung Der Nutzer erzählt mehrere Absätze mit hoher Informationsdichte. **Bestanden, wenn:** - Kanshō nicht jede Einzelinformation mit einer Frage beantwortet, - höchstens ein dominanter Folgeimpuls gesetzt wird, - der Erzählfluss nicht unnötig unterbrochen wird. --- ## E. Emotionaler Abschnitt Der Nutzer benennt selbst eine emotionale Veränderung oder Bedeutung. **Bestanden, wenn:** - Kanshō keine bereits beantwortete triviale Gefühlsfrage wiederholt, - eine Vertiefung nur erfolgt, wenn sie zum Erzählfluss passt, - Kanshō keine zusätzliche emotionale Bedeutung erfindet. --- ## F. Unterschiedliche Dialogtypen am selben Tag Am selben Tag entstehen: - ein chronologisch-autobiografischer Dialog, - ein deutlich tieferer emotionaler Reflexionsdialog. **Bestanden, wenn:** - Kanshō diese nicht automatisch konsolidiert, - der Nutzer getrennte Journal Entries beziehungsweise Darstellungen behalten kann. --- ## G. Ähnliche Dialoge am selben Tag Morgens und abends entstehen zwei chronologisch zusammengehörige Dialogphasen. **Bestanden, wenn:** - Kanshō eine Konsolidierung anbieten kann, - der Nutzer entscheidet, - keine Konsolidierung erzwungen wird. --- ## H. Unterschiedliche Reflection Spaces Am selben Tag existieren Inhalte in zwei Reflection Spaces. **Bestanden, wenn:** - beide standardmäßig getrennt bleiben, - keine automatische Zusammenführung allein aufgrund des Datums erfolgt. --- ## I. Persönlicher Stil Der Nutzer hat eigene frühere Texte importiert und/oder bereits Journal Entries redigiert. **Bestanden, wenn:** - finale Nutzerfassungen stärker gewichtet werden als KI-Drafts, - typische Erzählmerkmale erkennbar berücksichtigt werden, - eigene Formulierungen aus dem Dialog soweit sinnvoll erhalten bleiben, - der erzeugte Text nicht in generischen KI-Stil driftet. --- ## J. Versionsschutz Der Nutzer bearbeitet einen bestehenden Journal Entry mehrfach. **Bestanden, wenn:** - frühere gespeicherte Fassungen erhalten bleiben, - eine frühere Version wiederhergestellt werden kann, - eine neue KI-Generierung die aktuelle Nutzerfassung nicht stillschweigend überschreibt. --- ## K. Nachschlagen Der Nutzer möchte einen früheren Urlaubstag wieder ansehen. **Bestanden, wenn:** - der Eintrag über Reflection Space und chronologische Liste auffindbar ist, - er nach Datum geöffnet werden kann, - vom Entry auf den Quelldialog gewechselt werden kann. --- # 16. Explizite Non-Goals des MVP Nicht Bestandteil dieses MVP sind: - sichtbares Self Model, - langfristige Pattern-Ansicht, - Insights-Verwaltung, - sichtbare Thread-Verwaltung, - Open-Question-Verwaltung, - vollständiger Reflection Graph, - automatische Lebensanalyse, - Values-Ansicht, - komplexe Resurfacing Engine, - mindnet-Frontend, - elf technische Intent Engines, - Mood Tracking, - Habit Tracking, - Gamification, - komplexe Dashboards, - Kalender-/Taskmanagement, - semantische Langzeitsuche, - Natural-Language-Biografieabfragen, - automatische Jahres- oder Lebensrückblicke, - komplexe Admin-/Governance-Oberfläche, - automatische langfristige Persönlichkeitsanalyse. Kanshō darf im Dialog einfache relevante Wiederholungen oder Abweichungen erkennen, ohne daraus bereits ein sichtbares Habit-, Pattern- oder Self-Model-Modul zu machen. --- # 17. Scope-Freeze Mit dieser Spezifikation gilt der erste Kanshō-MVP fachlich als ausreichend definiert. Neue Funktionen werden vor Beginn der Implementierung nur aufgenommen, wenn: 1. sie für einen der beschriebenen Acceptance Cases zwingend erforderlich sind, 2. ihr späteres Nachrüsten sonst eine grundlegende Refaktierung kanonischer Daten oder Verantwortlichkeiten verursachen würde, 3. oder ein echter Widerspruch zur Implementation Foundation entdeckt wird. Ansonsten gilt: > **Nicht weiter horizontal konzipieren. Den vertikalen Slice bauen, real nutzen und aus der Nutzung lernen.** Der nächste Schritt ist die Ableitung eines konkreten technischen Implementierungsplans aus: - `implementation_foundation.md` - dieser `mvp.md` - und nur den jeweils dafür benötigten kanonischen Fachkapiteln. Der erste vertikale Slice ist im Code vorhanden. Der Abgleich von Code gegen diese Spezifikation, die Foundation und das Gesamtziel steht in `mvp_stand_und_abgleich.md` (2026-08-25). Er ersetzt diese Spezifikation nicht.