46 KiB
| title | status | date | product_family | document_role | parent_document |
|---|---|---|---|---|---|
| Kanshō – MVP-Stand und Abgleich gegen Foundation, Slice und Gesamtziel | Abgleich / Arbeitsstand | 2026-08-25 | Jinkendo | Ist-Stand des ersten vertikalen Slices gegen Implementation Foundation, MVP-Spezifikation und Produktziel; Gaps und Ungenauigkeiten | mvp.md |
Kanshō – MVP-Stand und Abgleich
Stand: 2026-08-25, gegen den lokalen Code unter frontend/ und backend/, inklusive Architecture-Correction-Pass am selben Tag.
Dieses Dokument ersetzt weder mvp.md noch implementation_foundation.md noch produktvision_und_produktidentitaet.md. Es sagt, was gebaut ist, was welche Spezifikation verlangt, und wo Doku, Tests oder UI den Code überzeichnen.
Es ist der Prüfbericht für eine unabhängige Gegenlesung: Slice gegen freigegebenen MVP-Text, Foundation gegen teure Sackgassen, Code gegen das langfristige Gesamtziel. Der Slice darf das Gesamtziel nicht erfüllen; er darf es nicht verbauen und nicht als schon erreicht verkaufen.
0. Für den prüfenden Agenten
0.1 Auftrag dieses Dokuments
Ein zweiter Agent soll damit prüfen:
- ob der gebaute Slice zum Gesamtziel (Personal Reflection Companion) noch als Keimzelle passt oder schon als Tagebuch-App driftet,
- ob die Implementation Foundation gehalten wird,
- ob der freigegebene MVP-Text in
mvp.mdeingelöst, untererfüllt oder überzeichnet ist, - welche Lücken Slice-Gaps sind (jetzt schließen oder Spec korrigieren) und welche Zielmodell-Lücken (bewusst später).
Nicht Auftrag: das Target Model nachbauen, den Slice horizontal erweitern, oder offene Fachinterviews als Implementierungsauftrag lesen.
0.2 Drei Ebenen, nicht vermischen
| Ebene | Quelle | Frage |
|---|---|---|
| Gesamtziel | produktvision_und_produktidentitaet.md, Guardrails, Memory/Self/Dialog-Kapitel |
Wird Kanshō der dialogische Reflexionsraum der Jinkendo-Familie? |
| Erster Slice | mvp.md + implementation_foundation.md |
Ist ein dialoggeführtes Journal auf der Foundation real nutzbar, ohne Sackgassen? |
| Code | frontend/, backend/ |
Was tut die laufende Anwendung tatsächlich? |
Der MVP-Leitgedanke in mvp.md §1 ist bewusst kleiner als die Vision: dialoggeführtes persönliches Tagebuch, Entwurf aus dem Gespräch. Die Vision in der Produktidentität ist größer: Wahrnehmen → Reflektieren → Verstehen → Einordnen, langfristige Kontinuität, Werte, offene Fäden, vorsichtige Zusammenhänge. Beides ist wahr. Der Slice ist die Keimzelle, nicht das Produkt.
0.3 Was laden (Context Bundle)
Pflicht:
- dieses Dokument (Fit-Gap)
mvp.mdimplementation_foundation.mdproduktvision_und_produktidentitaet.md(Identität, Prinzipien, Nicht-Ziele)guardrails.md(Invariante Datenschutz)- technische Umsetzung:
../technical/mvp_implementation.md - Vertiefung:
../technical/privacy_gateway.md§9.1–9.2,../technical/memory_storage_and_offline.md§6.2,../technical/frontend_pwa_shell.md§6.1,../technical/backend_and_api.md§5.1
Nur bei Bedarf, nicht vorsorglich den ganzen Ordner:
writing_profile_and_journaling.md– Stil und zweistufige Generierung (Ziel, nicht Slice)dialogue_model.md– Contextual Continuation als Default-IAmemory_and_context.md– Schichten Working / Thread / Episodicreflection_outputs.md– Journal vs Memory vs Knowledge vs Actionintegrations.md– Kairo / mindnet / Obsidian
0.4 Was der prüfende Agent nicht tun soll
- Foundation-Regel 24 ignorieren („nicht implementiert ist zulässig“) und fehlendes Self Model, Resurfacing oder mindnet als Slice-Bug werten.
- Recency-Ausschnitte (letzte fünf Entries × 400 Zeichen) als semantisches Gedächtnis oder Space Content Memory lesen.
- Admin-Testspur, Prompt-DB und
/dialogals produktive Nutzer-IA lesen. - Acceptance-Tests C/D/E als Beweis für Begleiter-Qualität lesen; sie sind oft Prompt- oder Call-Proxies.
- Detect über OpenRouter als erfüllte Guardrail-Produktivlage lesen; das ist Testphase.
- Empfehlen, das Target Model in diesem Slice vorzubauen.
0.5 Statuswörter
| Wort | Bedeutung |
|---|---|
| Erfüllt | Anforderung im Code und in der nutzbaren Oberfläche vorhanden |
| Teilweise | Kern da, fachliche Schärfe oder UI fehlt |
| Gap | Anforderung der jeweiligen Ebene nicht erfüllt |
| Ungenauigkeit | Spezifikation, Test oder Kommentar behauptet mehr als der Code leistet |
| Bewusst offen | Non-Goal, später, oder Foundation-Regel 24 |
| Abweichung | weicht vom technischen Zielrahmen ab, ohne die Foundation zu brechen |
| Spannung | Slice und Gesamtziel ziehen auseinander, ohne dass der Slice deshalb falsch ist |
1. Was der Slice heute ist
Kanshō ist lokal ein dialoggeführtes Journal auf FastAPI + SQLite und einer React/Vite-PWA-Shell.
Kernablauf, der geht: Space anlegen → Journal Day öffnen → Dialog führen → Entwurf explizit erzeugen → redigieren, Medien im Text, speichern als neue Version des bestehenden Eintrags (optional eigener Eintrag) → Versionen wiederherstellen oder lokale Edits verwerfen → Quelldialog öffnen. Parallel: lokale Stichpunkte (Checkliste), die Kanshō nicht sieht; Return erzeugt eine neue Zeile und setzt den Cursor dorthin. Ungespeicherte Editoränderungen werden beim Verlassen bestätigt.
Technische Keimzelle: Auth-Sessions, Prompt-DB, Platzhalter, Feature-Check, Privacy Gateway, zwei Provider-Rollen (Maskierung / Sprachmodell), Context Builder, Retrieval als SQL-Schnittstelle, Writing Profile ohne Extra-LLM, Pronomenbindung nur im Dialogzug.
Nicht gebaut und nicht behauptet als gebaut: Space Content Memory, Threads-UI, semantisches Retrieval, Self Model, Insights, Related Spaces in der Nutzung, Papierkorb-UI, PostgreSQL, lokales Detect-Modell, Voice, Offline-Sync, Obsidian/mindnet/Kairo-Handoff, Contextual Continuation als Start, zweistufige Journalgenerierung.
Produktidentität im Slice: der Kern ist Erzählen → reflektierender Impuls → Journalentwurf. Das ist eine legitime Keimzelle von „Personal Reflection Companion“, noch kein Begleiter über Monate, keine Wertearbeit, keine offenen Fäden.
2. Delta seit 2026-08-24
Additiv zum vorigen Abgleich, nicht an seiner Stelle:
| Thema | Änderung im Code | Wirkung auf den Abgleich |
|---|---|---|
| Generate → Entwurf | UI öffnet ?draft=1, nicht still den gespeicherten Entry |
Case J / §11.2 klarer erfüllt |
| Speichern aus Entwurf | Default: neue Version desselben Entry (accepted_draft); optional eigener Eintrag |
Keine stillen Doppel-Entries mehr als Normalpfad |
| Titel | clean_title / entryTitle entfernen führendes # |
Editor und Versionen zeigen denselben Titel |
| Versionen-UI | Aktuelle Fassung in der Liste als Aktuell, ohne Restore. Bei Dirty: Alle Änderungen rückgängig machen (lokal, keine DB-Version) | §11.1 eingelöst |
| Dirty-Flag | Snapshot nach Laden/Speichern; In-App-Navigation, Abmelden, Tab-Schließen fragen nach | Schutz vor stillem Verlust; Browser-Zurück nicht hart blockiert |
| Writing Profile | Finale Entries stärker (mehr/längere Exzerpte); Dialog-Exzerpte entfallen, sobald Entries existieren | §9 Priorität näher am Text |
| Journal-Prompt / Shape | Szenen verbinden, Stimme aus dem Brief; lokale Namensausdünnung nach Demask (naturalize_person_mentions) |
Qualität modellabhängig, Shape nur lokal |
| Pronomen | Bindung er/sie nur im Dialogzug; Journalentwurf ungebunden, sonst Demask-Klarnamen-Flut |
Guardrail-fein, nicht Identity-Mapping |
| Stichpunkte | Return erzeugt leere Folgezeile und fokussiert sie; „Punkt hinzufügen“ ebenso | UX von §10.1 |
local_hold |
Fallback-Impuls nicht mehr „Ich bin noch da“, sondern Fortsetzungsbitte | Dialogqualität, kein Architekturwechsel |
Historische Doppel-Entries aus der Zeit, als Speichern aus dem Entwurf neue Einträge anlegte, bleiben in der DB getrennt. Das ist Altbestand, kein aktueller Normalpfad.
2.1 Architecture Correction Pass (2026-08-25)
Additiv zu Abschnitt 2. Kein horizontaler Slice, kein Target-Model-Vorbau. Korrigierter Ist-Stand vs. bewusst offene Target-Fähigkeiten:
| Thema | Korrigierter Ist-Stand | Bewusst offen |
|---|---|---|
| Provenance Draft/Version | Relationale journal_*_source_refs; JSON-Listen werden verlustfrei migriert. Source unverändert. |
Provenance-UI, Re-Grounding |
| Context Selection | Context Builder fordert Specs (day_messages, space_entries, space_recent_sources, writing_profile). Recency ist Retrieval-Implementierung, keine fachliche API. |
Semantisches Retrieval, Minimum-sufficient nach Relevanz |
| Space-Source im Dialogzug | Begrenzte jüngere Original-Conversations desselben Space; aktuelle Conversation bleibt primär; Geschwister desselben Days werden nicht pauschal voll geladen. | Globales/semantisches Retrieval, Session-Summaries |
| Detect | Externes Klartext-Detect nur Development/Test. Produktiv: Muster oder lokale Detect-URL. | Lokales Detect-Modell (Ollama) |
| Response Validation | Blockiert Klartext-Identität in der Rohantwort vor Demask. | Quasi-Identifikatoren, Platzhalter-Vollständigkeit, Audit |
| Konsolidierung | Lokale Signale narrative_mode / reflection_depth / current_focus aus dem Hauptcall, kein Extra-LLM. Angebot nur bei hinreichender Ähnlichkeit; Nutzer entscheidet. |
Narrative Typ-Engine, UI-Feinheiten |
/dialog |
Nicht in der Produkt-Nav; Admin-only Dev/Test-Harness. | Start = offener Journal Day (Stub-Home bleibt) |
| Writing vs Interaction | WritingProfile nur Journal-Stil. Dialogue Kernel nutzt register_hint plus leeren interaction_hint-Slot. |
Interaction-Profile-Engine, UI, Persistenz |
| Reflection Space | Conversation kann space_id ohne journal_day_id tragen. Space ist nicht Journal-Container. |
Space-Typen, Related Spaces, Intents pro Space |
| Dialogue Kernel | Sechs Operationen bleiben allgemeine Gesprächsoperationen. Konsolidierung und Tages-Coverage liegen in Journal-Policy/Context. | Intent-Engines, Contextual Continuation |
Tests: backend/tests/test_architecture_correction.py plus Anpassungen in test_mvp_journal.py und test_privacy_detect.py.
2.2 Profile Governance (2026-08-25)
Additiv zu 2.1. Keine neue allgemeine Architekturphase.
| Thema | Ist-Stand | Bewusst offen |
|---|---|---|
| Writing Profile | Facets + Governance learning/advising/frozen. Brief abgeleitet. Bootstrap aus gespeicherten Entries. Kein Blind-Overwrite. |
Große Profile-UI, zeitliche Versionierung des Fachkapitels |
| Interaction Profile | Persistenz, gelabelte Produktdefaults, Hint-Slot, Default advising. Lernen nur explizit/manuell/angenommener Vorschlag. |
Volle Feedback-UI, Analytics, Intent-Engine |
| Dialogue State | Bleibt automatisch; zusätzlich emotional_intensity, long_story |
already_covered, known_plan, Intent-Taxonomie |
| JSON-Portabilität | Export/Restore von Writing-, Interaction- oder Sammeldokument (format_version 1). Restore ist ausdrücklich und ersetzt Facets/Prefs. |
Vollständiger Account-Export, Journal-Portabilität |
Persönliche Längen-/Impulsregeln liegen nicht mehr anonym im Dialog-Prompt, sondern im sichtbaren Interaction-Hint.
Tests: backend/tests/test_profile_governance.py.
2.3 Profile Review Pipeline (2026-08-25)
Additiv zu 2.2. Keine Review-Calls nach jedem Dialog, keine neue große Profil-Engine.
| Thema | Ist-Stand | Bewusst offen |
|---|---|---|
| Writing Review | Lokale Drift/Evidence, Queue, gebündelte semantische Review nur explizit. API und Copy/Paste derselben Paket-/Ergebnis-Verträge. Versionen nachvollziehbar. | Periodische Batch-UI, Interaction-AI-Review, zeitliche Facet-Historie im Fachkapitel |
| Governance-Übernahme | learning wendet unlocked Review-Änderungen an; advising queued; frozen nicht, außer explizites Paket ohne Apply |
Getrennter Bestätigungsschritt in der UI für learning |
| Interaction | Weiter nur explizit/manuell/angenommener Vorschlag. Dialog-Sample ist Writing-Evidence, kein Preference-Lernen. | Beobachtungs-Candidates in der Settings-UI |
Tests: backend/tests/test_profile_review.py.
2.4 Writing-Profile-Hülle und Initial Build (2026-08-25)
Additiv zu 2.2 und 2.3. Das statische Facet-Raster ist nicht die Profilstruktur.
| Thema | Ist-Stand | Bewusst offen |
|---|---|---|
| Hülle | Core, optionale Facets, dynamische Traits, Evidence, Exemplare, Governance, Versionen. Seed-Keys nur Ordnungshilfe. | Output-Facets jenseits Journal/Reflexion, zeitliche Trait-Historie im Fachkapitel |
| Initial Build | Historischer Korpus mit Zeitbezug; Existing-before-New; Confirm vor kontinuierlichem Lernen | Batch-Import-UI für Dateiordner, Gewichtung als Nutzersteuerung |
| Quellenarten | Urlaubstagebuch → autobiographical_journal; Core nur bei gemischten Arten |
Weitere context/output-Facets aus dem Fachkapitel |
| Heuristik | Lokal als Drift-/Triggerhilfe, nicht als persistierte Traits | — |
Tests: backend/tests/test_profile_governance.py, backend/tests/test_profile_review.py.
2.5 Profile Analysis Export / Import (2026-08-25)
Additiv zu 2.3 und 2.4. Copy/Paste ist in der Testphase ein vollwertiger Ausführungsweg, nicht nur Debug.
| Thema | Ist-Stand | Bewusst offen |
|---|---|---|
| Modi | initial_build (vollständiges Proposal) und review (inkrementell) |
Automatische Periodik, Interaction-Analyse |
| Vertrag | Gemeinsames kansho.profile_analysis_package / kansho.profile_analysis_result für API und Copy/Paste |
Provider-API ohne manuelles Paste |
| Externe Chat-Historie | Semantisch nutzbar als external_chat_history; keine erfundenen Kanshō-Source-IDs |
Import derselben Texte als echte Kanshō-Quellen |
| Import | Validieren, unbekannte Refs, Proposal, einzelne Übernahme/Ablehnung, erst dann Version. Baseline extra für initial_build. Kein Auto-Apply. |
Komplexere Diff-UI, Batch über mehrere Reviews |
| Current Brief | Runtime-Artefakt nach Acceptance; Journal Generate nur Task-Ausschnitt | Weitere Task-Compiler jenseits Journal |
Tests: backend/tests/test_profile_review.py.
3. Abgleich gegen das Gesamtziel
Quelle: produktvision_und_produktidentitaet.md, ergänzt um Dialog-, Memory- und Output-Kapitel. Das ist keine Slice-Checkliste. Ein „Gap“ hier heißt: das Zielmodell ist nicht da — erwartet, solange Foundation-Regel 23/24 gilt. Die spannenden Zeilen sind Spannung und Drift-Risiko.
3.1 Identität und Prinzipien
| Prinzip / Grenze | Slice-Stand | Befund für die Gesamtziel-Prüfung |
|---|---|---|
| Personal Reflection Companion, nicht Tagebuch-App | Spannung | Der sichtbare Kern ist ein dialoggeführtes Journal. Der Dialog ist Erfassung plus Impuls, nicht langfristige Begleitung. Drift-Risiko: UI und Sprache dürfen nicht als „KI-Tagebuch“ festgeschrieben werden. Der Slice bleibt zulässig, wenn Generate/Editor dem Gespräch nachgeordnet bleiben. |
| Kernkette Wahrnehmen → Reflektieren → Verstehen → Einordnen | Teilweise | Wahrnehmen und ein kurzes Reflektieren im Turn. Verstehen/Einordnen über Tage und Werte: nicht gebaut. Journalentwurf verdichtet den Tag, ist aber keine Erkenntnis-Schicht. |
| Dialog vor Formular | Erfüllt im Tag | Journal Day ist Chat. Settings-Import und Editor sind nachgelagert. Start / ist kein Dialog. |
| Kontext vor generischer Frage | Teilweise | Derselbe Day-Transcript geht in den nächsten Zug. Space ist Recency, nicht Relevanz. Kanshō eröffnet nicht. Neutraler Start ist Default, in der Vision Fallback. |
| Erinnerung mit Herkunft | Teilweise | Messages bleiben. Draft/Entry-Version tragen relationale Source-Refs (API weiterhin ID-Listen). Nutzer sieht „zum Quelldialog“, keine Provenance-Kette, kein Re-Grounding. |
| Hypothese statt Gewissheit | Teilweise | Impulse sind Nachrichten, nicht Fakten. Keine Hypothesen-Objekte, keine Confidence, keine Bestätigung vor Self-Aussagen (kein Self Model). |
| Mensch entscheidet über Identität | Erfüllt als Abwesenheit | Kein Self-Model-Schreibpfad. Writing Profile ist als Formhinweis gekennzeichnet. |
| Persönliche Sprache | Teilweise | Lokaler Brief + Exzerpte. Keine Wortwahl-/Übergangs-Signale. Eine generative Stufe, nicht Inhalt/Stil getrennt. |
| Reflection before Action | Bewusst offen | Keine Action Candidates, keine Kairo-Übergabe. Scratch ist lokale Merkhilfe, kein Aufgabenmanager — Grenze gehalten. |
| Keine Jinkendo-Duplikation | Erfüllt im Slice | Kein Tracker, keine Diagnose-UI, kein Kairo-Todo. /dialog ist Admin-Harness, kein zweiter produktiver Gesprächsraum. |
| Menschenlesbares Langzeitarchiv (Obsidian) | Gap zum Ziel | Entries liegen in SQLite. Kein Export. |
| Langfristige Kontinuität | Teilweise | Transcript und versionierte Entries überdauern Sitzungen. Kein Thread Memory, keine offenen Fragen, kein Point-in-Time Self. |
| Einfache UX, differenzierter Kern | Spannung | UX ist einfach. Der Kern ist noch nicht differenziert (ein Call, Recency, Regex-Register). Das ist Slice-angemessen; es darf nicht als „der Kern ist Recency“ kanonisch werden. |
| Start = Kontinuität des Dialogs, kein Dashboard | Gap zur Identität | / ist ein Stub mit Link zum Journal. /dialog ist nicht mehr Teil der Nutzer-IA. Primärstart ist nicht der offene Day. |
3.2 Dialog-IA (Ziel vs Slice)
Ziel (dialogue_model.md): Contextual Continuation als Default, Free Reflection, Explicit Navigation; Intent ≠ Dialogführung; Fäden intern möglich.
Slice: der Mensch schreibt die erste Zeile; Kanshō antwortet mit einem Impuls aus einem Call {operation, impulse}. Keine Entry-IA, keine Fortsetzung eines gestern offenen Fadens, keine Saturation, keine Wiedervorlage.
Prüffrage: Bleibt der Journal Day ein Gespräch über diesen Kalendertag? /dialog ist Admin-Testrest, nicht Ziel-IA.
3.3 Memory und Context (Ziel vs Slice)
Ziel: Working / Thread / Episodic, Space als Bedeutung, mindnet langfristig, Re-Grounding gegen Verdichtungsdrift.
Slice: Working Context ≈ aktuelle Conversation (Day-Cap) + begrenzte Recency-Ausschnitte finaler Space-Entries + begrenzte Original-Ausschnitte jüngerer Space-Conversations + Formhinweise nur beim Journalentwurf. Generate sieht keine Prior-Entries, nur Day-Dialog + Writing Profile. Scratch und Identity-Mapping sind Klasse A, kein Egress.
Prüffrage: Ist Recency als Hilfsstruktur erkennbar (retrieval.py nach kind), oder wird sie in Prompts/UI als „Kanshō erinnert sich“ verkauft? Der Code ist austauschbar; die Produktstimme darf das nicht überzeichnen.
3.4 Outputs und Integrationen (Ziel vs Slice)
Ziel: Journal Entry (Obsidian), Reflection Memory (mindnet), Knowledge Delta (mindnet), Action Candidate (Kairo). Tagesreflexion muss kein Artefakt erzeugen; Journal-Default im Ziel: bei substanzieller Reflexion dezent anbieten.
Slice: einziges sichtbares Derived-Produkt ist Journal Draft/Entry. Generate nur explizit (Button), nicht automatisch am Gesprächsende. Das weicht vom späteren Journal-Default der Tagesreflexion ab und hält Foundation „model proposes; policy decides“.
Prüffrage: Explizites Generate ist für den Slice richtig. Es darf nicht so verbaut werden, dass ein späteres dezenten Angebot am Abschluss den Entry still überschreibt (§11.2).
3.5 Privacy (Ziel vs Slice)
Ziel: Identität lokal, minimierter pseudonymisierter Egress, Detect lokal, Response-Validierung, Audit ohne Prompt, ZDR.
Slice: Gateway-Pfad existiert und ist nicht abschaltbar. Maskierung + Generate. Detect: Muster immer; externes Klartext-Detect nur Development/Test, Produktiv fällt auf Muster zurück. Minimale Response Validation vor Demask (Klartext-Identität). Keine inhaltliche Minimierung über Caps hinaus, keine Quasi-Identifikatoren, Mapping unverschlüsselt.
Das ist der größte Abstand zum Gesamtziel, der schon im Slice operativ relevant ist — nicht weil das Target Model fehlt, sondern weil Testdaten persönlich sein können.
3.6 Nutzungssituationen (Zieltypologie vs Slice)
Von elf Situationen ist nur ein Pfad gebaut: Tagesreflexion als Journal Day plus optionales Festhalten im Entry. „Erleben festhalten“ geht nur als Dialogtext, nicht als Voice. „Früheren Faden fortsetzen“, Tiefe Reflexion, Entscheidung, Revue, Nachschlagen jenseits Space→Tag→Entry: nicht als eigene IA.
Nachschlagen im Slice = Chronologie im Space. Das erfüllt MVP-Case K, nicht Natural-Language-Biografie.
3.7 Gesamtziel: Kurzurteil
Der Slice ist eine zulässige vertikale Keimzelle: Dialogquelle bleibt kanonisch, Journal ist Derived, Gateway sitzt vor Egress, Space/Day/Assignment sind trennbar, Retrieval ist austauschbar.
Er ist noch nicht Kanshō im Sinne der Vision. Die gefährlichen Drifts sind nicht die fehlenden Target-Module, sondern:
- Journal-Editor und Medien als Produktmitte statt Dialog,
- Recency und Regex als Ersatz für Context/Memory,
/dialogals Admin-Harness (geschlossen für die Nutzer-IA; Stub-Home bleibt),- Detect-Klartext als Gewohnheit im Produktivmodus (Development/Test bleibt erlaubt),
- Stub-Home statt Kontinuität.
4. Abgleich Implementation Foundation
4.1 Core-Regeln
| # | Regel | Stand | Befund |
|---|---|---|---|
| 1 | Original Source bleibt kanonisch | Erfüllt | messages bleiben bei Generate und Entry-Save. Löschen eines Gesprächs ist ausdrücklich und hart (Nachrichten weg). |
| 2 | Derived ersetzt Source nie | Erfüllt | Drafts und Entries sind eigene Tabellen. Generate prüft, dass current_version_id unangetastet bleibt. |
| 3 | Stabile Identitäten | Erfüllt | UUIDs für Profile, Spaces, Days, Conversations, Messages, Drafts, Entries, Versionen, Media. |
| 4 | Zeit und Provenance | Erfüllt im Datenmodell | Message-created ≠ journal_days.calendar_date. Drafts/Entries tragen relationale Source-Refs. Gap: keine nutzbare Provenance-Ansicht jenseits „zum Quelldialog“. |
| 5 | Current Validity und History getrennt | Erfüllt | journal_entry_versions; Restore hängt eine neue Version an. Offene Editor-Edits sind kein History-Write; Verwerfen ist lokal. |
| 6 | User Correction vor Modellinferenz | Erfüllt für Journal | Nutzerfassung ist Current. KI-Draft ist nicht Stilquelle. Teilweise für Derived-Hülle: derived_records werden bei Entry-Korrektur nicht invalidiert (im Slice ungenutzt). |
| 7 | AI Hypothesis ist kein User Fact | Erfüllt im Dialogpfad | Impulse sind assistant:-Nachrichten, nicht Entries. Generate: Impulse sind Kontext, nicht Erlebtes. |
| 8 | Expressed state ist kein Self Model | Erfüllt | Kein Self-Model-Schreibpfad. Writing Profile sind Formhinweise, als „keine Diagnose“ gekennzeichnet. |
| 9 | Model proposes; policy decides; source preserves | Erfüllt | Generate nur explizit (journal_policy.require_explicit_generate). Speichern nur per Nutzer. Übernehmen aus Entwurf schreibt eine Version, überschreibt History nicht. |
| 10 | Space ist Bedeutungskontext, kein Ordner | Teilweise | Space ist nutzbar und Isolationseinheit; Conversation kann dem Space ohne Journal Day zugeordnet werden. Inhaltlich bleibt er eine Liste von Tagen plus Recency-Ausschnitten. Keine Space-Bedeutungsschicht. |
| 11 | Primary und Related Spaces möglich | Teilweise | Primary Assignment: conversations.space_id / journal_day_id. Junction thread_spaces existiert. Gap: Related Spaces weder Datenmodell für Journal-Spaces noch UI. conversations.space_id ohne FK. |
| 12 | Assignment ist nicht Identity | Erfüllt | Conversation-ID bleibt; Space/Day sind Assignment-Felder. |
| 13 | Existing before new | Teilweise | Denselben Kalendertag im Space wiederzuverwenden öffnet denselben Day. Speichern aus Entwurf versioniert den bestehenden Entry. Recurring Activities erzeugen keinen bestehenden Faden, sondern nichts. |
| 14 | Space first, Long-Term Memory on demand | Erfüllt | Kein globales autobiografisches Retrieval. Dialog sieht den Day plus letzte Space-Entries. |
| 15 | Context Builder eigene Verantwortlichkeit | Erfüllt | context_builder.py + retrieval.py. Frontend baut keinen Prompt. |
| 16 | Minimum sufficient context | Teilweise | Day-Cap und Space-Ausschnitte sind Recency-Implementierung hinter Selection-Specs. Ungenauigkeit: das ist keine Relevanz. |
| 17 | Retrieval ist Hilfsstruktur | Erfüllt | SQL-Funktionen nach kind, keine Embeddings als Wahrheit. |
| 18 | Provider State ist nicht Memory | Erfüllt | Kontinuität in SQLite. Provider sieht maskierten Prompt. |
| 19 | Ein generativer Hauptcall pro Turn | Erfüllt | Ein Dialogzug-Call; optional ein lokaler Repair-Call. Detect ist Maskierung, nicht Operation. Journalentwurf getrennt und explizit. |
| 20 | Write Evaluation signal-driven | Erfüllt | Kein exhaustives Memory-/Pattern-Write nach jeder Message. remember_dialogue_style ist lokal und schmal. |
| 21 | Variable Policies nicht quer hardcoden | Teilweise | journal_policy.py ist die Journal-Grenze inkl. Konsolidierungsangebot aus lokalen Signalen. Register, Guards, UNMASKABLE liegen als Heuristiken im Code. Für den MVP laut Foundation keine Policy-Engine nötig. Ungenauigkeit: „Policy“ im Dialog ist Prompt + Regex, keine zentrale Decision-Tabelle. |
| 22 | Interne Reichhaltigkeit, einfache UI | Teilweise | Journal-UI ist schmal. /dialog ist Admin-Harness, nicht Produkt-Nav. Admin-Bereich (Prompts, Provider, Nutzer, Diagnose) bleibt Mitai-Rahmen. |
| 23 | Neue Abstraktionen brauchen Nutzen | Erfüllt | Threads/Derived/Handoffs sind Hüllen, ohne Nutzer-IA. |
| 24 | Nicht implementiert ist zulässig | Erfüllt | Space Memory, Related Spaces, semantisches Retrieval bewusst offen. |
4.2 Foundation Cut: muss vorhanden sein
| Muss | Stand | Befund |
|---|---|---|
| Persistente Session- und Message-Quellen | Erfüllt | usage_sessions, conversations, messages; Auth-sessions getrennt |
| Stabile IDs | Erfüllt | |
| Zeitbezug und grundlegende Provenance | Erfüllt | siehe Regel 4 |
| Trennung Source / Derived | Erfüllt | |
| Reflection-Space-Grundmodell | Erfüllt | spaces.visibility='user' |
| Primary-Space-Zuordnung | Erfüllt | Assignment-Felder; Journal-Day erzwingt Space |
| Datenmodell darf Related später zulassen | Teilweise | thread_spaces ja; Journal-Space-Related fehlt |
| Current-State-/History für verwendete Objekte | Erfüllt | Entries + Versionen; Dirty-State ist Session-UI, nicht History |
| Nutzerkorrektur beeinflusst Current Validity | Erfüllt | |
| Context-Builder-Schnittstelle | Erfüllt | |
| Austauschbare Retrieval-Schnittstelle | Erfüllt | |
| Provider-Abstraktion | Erfüllt | providers.py, Rollen generate/detect |
| Kleine Write-/Decision-Policy-Grenze | Erfüllt | journal_policy.py |
4.3 Foundation: nur bauen wenn der Slice es braucht
| Gegenstand | Im Code | Bewertung |
|---|---|---|
| Thread | Tabelle + Junction, visibility internal | Hülle, keine UI. Kein Gap, solange nicht als Produkt verkauft. |
| Open Question / Insight / Experience | Derived-Kind-Registry, keine Nutzung | Bewusst offen |
| Sichtbare Related Spaces | nein | Bewusst offen |
| Automatische Space-Erkennung | nein | Bewusst offen |
| Semantisches Retrieval | nein | Bewusst offen |
| Session Summary | nein | Bewusst offen |
| Zusätzliche Enrichment-Calls | Detect in Development/Test optional remote | Abweichung gegenüber Produktivziel „Detect lokal“; Produktivmodus lässt externes Klartext-Detect nicht als normalen Pfad zu |
4.4 Foundation Non-Goals
Nicht vorsorglich gebaut: Reflection Graph, Graph-DB, Pattern-Engine, Self Model, Landmark-Engine, Policy-Learning, Space-Merges, mindnet-Sync, Resurfacing, Persönlichkeitsanalyse, Intent-Engines, Graph-UI, Dashboards.
Spannung, kein Slice-Gap: Es gibt eine Admin-Oberfläche (Nutzer, Prompts, Platzhalter, Features, Provider, Dialogdiagnose). Das MVP-Non-Goal „komplexe Admin-/Governance-Oberfläche“ meint die Produkt-IA. Der Mitai-Produktrahmen sieht Operator-Admin vor. Die Testspur am Dialog ist bewusst Testphase, nicht Default-UX.
Foundation-Verletzungen, die ein Refactor erzwingen würden, sind nicht gefunden: Source/Derived, IDs, Space-Assignment, Context Builder, Gateway vor Egress, explizites Generate, Versionierung ohne History-Overwrite.
5. Abgleich MVP-Spezifikation
5.1 Produktversprechen (mvp.md §1–2)
| Anforderung | Stand | Befund |
|---|---|---|
| Dialoggeführtes Journal, Entwurf aus dem Gespräch | Erfüllt | Explizites Generate, Öffnen als Entwurf |
| Redigieren, Medien, chronologisch wiederfinden | Teilweise | Editor mit Absätzen, Listen, Inline-Bild/Video und Unterschrift. Navigation über Tage, nicht eine Entry-Liste |
| Dialog berücksichtigt Tagesverlauf, Space, frühere Aussagen, Erzählweise | Teilweise | Tagesverlauf: voller Day-Dialog. Erzählweise: Formhinweise. Space/Früheres: Recency-Ausschnitte gespeicherter Entries, 5×400 Zeichen. Ungenauigkeit von §1 gegenüber der Umsetzung in §5.1 letzter Absatz und §8.2 |
5.2 Sichtbare Einheiten
| Einheit | Stand | Befund |
|---|---|---|
| Space anlegen, umbenennen, auswählen | Erfüllt | |
| Chronologische Entries des Spaces | Teilweise | Space-Seite zeigt Tage. Entries liegen unter dem Tag. |
| Journal Day ≠ Dialogzeit | Erfüllt | |
| Originaldialog erhalten | Erfüllt | |
| Gespräch aus dem Tag entfernen | Erfüllt | Hartes Löschen der Conversation. Ungenauigkeit: härter als Entry-Soft-Delete; kein Papierkorb für Dialoge |
| Draft Derived, erneut generierbar, überschreibt Entry nicht | Erfüllt | UI öffnet den neuen Entwurf; Übernehmen ist explizit und versioniert den bestehenden Entry. |
| Entry mit Versionen, Space, Day, Quellen | Erfüllt | Medien am Entry; Position und Unterschrift im Body-Token |
5.3 Mehrere Dialoge (mvp.md §4)
| Anforderung | Stand | Befund |
|---|---|---|
| Mehrere Conversations pro Day | Erfüllt | |
| Konsolidierung anbieten, nicht erzwingen | Erfüllt im Slice-Schnitt | Angebot nur bei hinreichend ähnlichen lokalen Signalen (narrative_mode, reflection_depth, current_focus). UI: dieses Gespräch / alle des Tages. Nutzer entscheidet über conversation_ids. |
| Getrennte Tiefen nicht automatisch mergen | Erfüllt | Ohne Auswahl nur die letzte Conversation |
| Gleicher Kalendertag, verschiedene Spaces getrennt | Erfüllt | Unique (space_id, calendar_date) |
5.4 Dialogführung (mvp.md §5–7)
| Anforderung | Stand | Befund |
|---|---|---|
| Kein Fragebogen; Reflexionspartner | Teilweise | Prompt und Stimme zielen darauf. Qualität ist modellabhängig. Lokale Wächter gegen Recap, erfundenen Vollzug, erfundene Empfindung, Systemfloskeln, Schluss-Wiederöffnung. local_hold bittet um Fortsetzung statt Floskel. |
| Sechs Operationen, keine Intent-Engines | Erfüllt | Ein Call, JSON {operation, impulse}; sichtbar ist impulse |
| Register lokal, kein zweites Modell | Erfüllt | infer_register |
| Bekannter Tagesplan (Cres-Beispiel) | Teilweise / Ungenauigkeit | Plan kann aus begrenzten Recency-Ausschnitten gespeicherter Entries oder jüngerer Original-Conversations desselben Space kommen. Kein Plan-Objekt, keine zeitliche Vor/Nach-Logik, kein semantisches Retrieval. |
| Wiederkehrende Aktivität (Japanisch-Beispiel) | Gap | Keine Zählung über Morgenbeschreibungen. Recency kann den Treffer zufällig enthalten oder nicht. |
| Keine triviale Gefühlsfrage nach selbst benannter Emotion | Teilweise | Prompt + is_unearned_stance. Kein Dialogzustand „bereits beantwortet“. |
| Kontextsensitiver Einstieg statt „Erzähl von deinem Tag“ | Gap | Nutzer schreibt die erste Zeile. Kanshō eröffnet nicht aus Plan/Space. Neutraler Start ist der Default, nicht der Fallback. |
| Unterbrechen und Fortsetzen am selben Day | Erfüllt | Transcript bleibt. Teilweise: keine lokale Karte „welche Tagesabschnitte schon da sind“. |
| Folgetag-Fortsetzung dem ursprünglichen Day zuordnen | Erfüllt | Nutzer öffnet den Day; Message-Zeit ist unabhängig. |
5.5 Generierung (mvp.md §8)
| Anforderung | Stand | Befund |
|---|---|---|
| Nur explizit | Erfüllt | |
| Quellen: Day-Dialog inkl. Impulse als Kontext | Erfüllt | user: Erlebtes, assistant: Anschluss |
| Space-Kontext soweit nötig | Teilweise | Generate bekommt keinen Prior-Entry-Block; nur Writing Profile + Day-Dialog. Dialogzug sieht Prior-Entries. |
| Writing Profile | Erfüllt | Lokal, ohne Extra-LLM |
| Bestehenden Text einbeziehen | Teilweise | API include_existing. Gap: UI setzt das Flag nicht. |
| Verbinden, nicht durchreichen | Teilweise | Prompt: Szenen verbinden und Stimme aus dem Writing Profile; kurze Passagen ausformulieren ohne neue Fakten. journal_shape formt 1:1-Kopien und dünnt Namenswiederholungen. Qualität modellabhängig. Zweistufige Generierung (Inhalt, dann Stil) aus dem Fachkapitel: nicht gebaut, ein Call. |
| Nicht erfinden | Teilweise | Prompt; keine lokale Faktenprüfung gegen den Dialog |
5.6 Writing Profile (mvp.md §9)
| Anforderung | Stand | Befund |
|---|---|---|
| Priorität Entries > Import > Dialog | Erfüllt | Finale Entries: mehr/längere Exzerpte; Dialog-Exzerpte entfallen, sobald Entries existieren. |
| KI-Draft keine Stilquelle | Erfüllt | |
| Import optional | Erfüllt | Settings |
| Formhinweise ohne Self Model | Erfüllt | Heuristik |
| Semantische Review | Erfüllt als expliziter Pfad | Gebündelt, API oder Copy/Paste, nicht nach jedem Dialog. Siehe 2.3. |
| Profilhülle / dynamische Traits | Erfüllt als Keim | Core + Facets + datengetriebene Traits. Kein festes Raster. Siehe 2.4. |
| Initial Profile Build | Erfüllt als expliziter Pfad | Historischer Korpus, Confirm vor Continuous Learning. |
| Lernsignale §9.3 vollständig | Teilweise | Satzlänge, Chronologie vs. Thema, Uhrzeiten, Reflexionsanteil, Humor. Gap: Umgang mit Namen, typische Übergänge, Wortwahl als eigene Signale. |
| Dialogzug ohne Stil-Exzerpte des offenen Turns | Erfüllt |
5.7 Editor, Versionen, Nachschlagen, Screens
| Anforderung | Stand | Befund |
|---|---|---|
| Text ändern, Absätze, Überschrift | Erfüllt | Fließtext; Absatz/Überschrift/Liste; Fett/Kursiv/Unterstrichen auf der Markierung |
| Bilder ergänzen, anordnen | Erfüllt | Fließtext, Einfügen an der Schreibmarke, Ziehen im Text, Unterschrift. Alte Galerie-Dateien ohne Referenz: „Noch nicht im Text“. |
| Videos im Eintrag darstellen | Erfüllt | MP4/WebM/MOV, lokal, direkt abspielen. Keine Videobibliothek. Metadaten in Video-Containern werden nicht gestrippt (Gap / bewusst dünn). |
| Zeichnungen als Bilddatei | Erfüllt | als Upload |
| Soft Delete / Papierkorb | Teilweise | deleted_at + DELETE-API. Editor-Text: „In den Papierkorb“. Gap: keine Papierkorb-UI, kein Wiederherstellen Gelöschter, kein zweiter Schritt „endgültig löschen“. |
| Version History sichtbar, Restore | Erfüllt | Aktuelle Fassung ohne Restore auf sich selbst; offene Edits lokal verwerfen. Navigation mit Dirty-Flag bestätigt (Links, Abmelden, beforeunload). Browser-Zurück nicht hart blockiert. |
| Generate überschreibt Nutzerfassung nicht | Erfüllt | |
| Chronologische Liste, Space, Datum, Entry, Quelldialog | Teilweise | Über Space → Tage → Tag/Editor/Source. Keine Entry-Indexseite. |
| Screen Journal/Spaces | Erfüllt | |
| Screen Journal Day / Dialog | Teilweise | Chat + Generate + lokale Stichpunkte (Return fokussiert neue Zeile). Gap: keine Medienoption am Dialog (MVP §13.2 Dialogquellen). Draft/Entry nur Links. |
| Screen Editor | Erfüllt | Fließtexteditor, Markdown, Inline-Medien, Restore, Dirty-Schutz |
| Screen Source Dialog | Erfüllt | |
| Start = Kontinuität des Dialogs | Gap zur Produktidentität | / ist ein Stub. Primärstart ist nicht der offene Day. /dialog ist Admin-Harness, nicht Nutzer-IA. |
| Tagesstichpunkte §10.1 | Erfüllt als lokale Liste | Klasse A, kein Egress (Test). Kein Aufgabenmanager. Offen bleibt eine spätere bewusste, maskierte Nutzung als Kontext. |
5.8 Acceptance Cases
| Case | Stand | Was der Code prüft vs. was die Spezifikation meint |
|---|---|---|
| A Einfacher Day | Erfüllt | Dialog, Generate, Save, Space-Chronologie. Lesbarkeit/Quelltreue des Entwurfs ist modellabhängig, Shape nur bei 1:1-Paste. |
| B Mehrphasiger Tag | Erfüllt | Gleicher Day, spätere Messages, Kalenderdatum stabil. |
| C Kontextsensitiver Dialog | Teilweise / Ungenauigkeit | Test prüft, dass „Hafen“ im Prompt steht und die Regel „nicht geschehen“ im Template ist. Er prüft nicht, dass Kanshō den Plan als Impuls aufgreift. Wiederkehrende Aktivität: Gap. |
| D Ausführliche Erzählung | Teilweise | Ein Call, dichtes Register. Ob der Impuls nicht interviewt, ist modell- + wächterabhängig. Tests erzwingen keine inhaltsleere Fragefreiheit. |
| E Emotionaler Abschnitt | Teilweise | Prompt + Stance-Wächter. Test sucht die Phrase „Motivationen erfinden“ im Prompt, nicht das Dialogverhalten. |
| F Unterschiedliche Dialogtypen | Erfüllt im Schnitt | Zwei Conversations möglich, kein Zwangsmerge. Lokale Signale trennen Chronik und tiefe Reflexion; Angebot bleibt aus. |
| G Ähnliche Dialoge, Angebot | Erfüllt im Schnitt | Angebot nur bei ähnlichen Signalen. Nutzer entscheidet über conversation_ids. |
| H Zwei Spaces, gleicher Tag | Erfüllt | |
| I Persönlicher Stil | Teilweise | Import und Entries im Brief; Formhinweise. „Nicht in KI-Stil driftet“ ist Promptziel, nicht messbar erfüllt. |
| J Versionsschutz | Erfüllt | Restore hängt Version an; Generate ändert Entry nicht; Entwurf öffnet separat; Übernehmen versioniert. |
| K Nachschlagen | Erfüllt | Space → Datum → Entry → Source. |
6. Ungenauigkeiten (Doku, Tests, UI)
mvp.md§1 und §5.1 versprechen „relevante frühere Aussagen“ und „wiederkehrende Aktivitäten“. Der Code liefert Recency-Ausschnitte finaler Entries plus begrenzte Original-Ausschnitte jüngerer Space-Conversations. Der klarstellende Absatz in §5.1 und §8.2 ist der gültige Implementierungsstand; die Beispiele §5.4–5.5 und Case C bleiben schärfer als der Code (kein Plan-Objekt, keine Wiederholungszählung).mvp.md§17 sprach vom „nächsten Schritt: technischen Plan ableiten“. Der Slice ist gebaut. Dieses Dokument ist der Abgleich; die Formulierung in §17 bleibt historisch.mvp.md§4.1 Konsolidierung beschreibt narrative Kriterien. Der Slice nutzt lokale Signale derselben Dimensionen, keine LLM-Typklassifikation.mvp.md§6 Einstieg verlangt einen kontextsensitiven ersten Impuls. Implementiert ist: der Mensch beginnt.mvp.md§8.2 Punkt 2 Space-Kontext bei der Generierung: Generate sieht Prior-Entries nicht.mvp.md§9.3 listet Lernsignale, von denen nur ein Teil heuristisch existiert.mvp.md§11.3 / §13.1–13.2 Papierkorb-UI und Dialog-Medien fehlen weiter. Inline-Medien, Unterschriften, Versions-UI und Dirty-Schutz im Editor sind vorhanden.- Acceptance-Tests C/D/E sind oft Prompt- oder Call-Zähl-Proxies, keine fachlichen Verhaltensbeweise.
backend_and_api.mdbeschreibt PostgreSQL als Rahmen; der Slice läuft auf SQLite. Abweichung vom technischen Ziel, lokal zulässig.- Fehlerformat: Rahmen will
{detail: string}. Viele Router liefern{detail: {code, message}}. - Nav
/dialogist aus der Produkt-IA entfernt (Admin-Harness). Stub-Home bleibt. - Detect über OpenRouter darf Klartext nur in Development/Test sehen. Produktivmodus fällt auf Muster oder lokale Detect-URL zurück. Guardrail-Abstand zum lokalen Detect-Modell bleibt.
- Home
/widerspricht der Produktidentität „Kontinuität des Dialogs, kein Funktions-Dashboard“ nur schwach (Stub), erfüllt sie aber nicht. handover.mdist Konzept-Bootstrap (Interviewstand 2026-08-19) und kein Code-Stand. Code-Stand ist dieses Dokument.- Zweistufige Journalgenerierung im Fachkapitel Writing Profile ist Zielmodell. Der Slice hat einen Generate-Call.
mvp.mdverlangt das Zweistufenmodell nicht zwingend; das Fachkapitel schon. Nicht als Slice-Bug lesen, nicht als erfüllt behaupten. - Tagesreflexion-Journal-Default (Hintergrund-Entwurf am Abschluss, dezent anbieten) ist Fachstand der Nutzungssituation, nicht MVP-Text. Der Slice verlangt den Button. Kein Widerspruch, solange später kein stilles Überschreiben entsteht.
7. Bewusst offen (kein Gap des Slices)
Zielmodell und Non-Goals, nicht „vergessen im MVP“:
- Space Content Memory, Threads-UI, Open Questions, Insights, Experiences
- Semantisches Retrieval, Session-Summaries, Related Spaces
- Self Model, Pattern-Ansicht, Resurfacing, mindnet, Obsidian-Ablage, Kairo-Handoff
- Voice, Videobibliothek, Dokumentarchive, Karten
- Video-Metadaten (GPS im Container) strippen
- Tagesstichpunkte als Dialogkontext (bewusst lokal, siehe
mvp.md§10.1) - Encryption at rest, DSFA, Multi-Gerät-Sync, PWA-Offline-Ausprägung
- Lokales Detect-Modell (Ollama) als Ablösung der Testphase
include_existingin der UI (API existiert)- Zweistufige Journalgenerierung (Inhalt, dann Stil)
- Contextual Continuation als Start-IA
- Browser-Zurück als harter Unsaved-Blocker (Data-Router)
8. Zwei Listen: Slice schließen vs. Gesamtziel später
Keine neue Horizontal-Konzeption. Getrennt halten, sonst baut ein Agent das Target Model in den Slice.
8.1 Distanz zum freigegebenen MVP-Text (mvp.md)
- Kontextsensitiver Einstieg und Case C – Plan/Wiederholung nur, wenn sie wirklich im Space-Kontext liegen; sonst ehrlich kein Cres-Beispiel, oder §5.4–5.5 an Recency anpassen.
- Generate und Space-Ausschnitte – klären, ob Generate Prior-Entries braucht oder §8.2 korrigiert bleibt (Day-Dialog reicht).
- Editor-Lücken – Papierkorb oder zweiter Löschschritt; Dialog-Medien oder Streichung in §13.2.
- Startlogik – offenen Journal Day statt Stub-Home.
- Lokales Detect-Modell – Klartext an externe Detect-Provider ist in Production blockiert; Ollama als Ablösung der Dev/Test-Phase bleibt offen.
include_existing– UI oder Flag aus der Spezifikation nehmen.
8.2 Distanz zum Gesamtziel (nicht jetzt bauen)
- Memory-Schichten und Space als Bedeutung, nicht Recency-Liste.
- Contextual Continuation, Saturation, Wiedervorlage, Fäden.
- Outputs jenseits Journal (Memory, Knowledge, Action) und Integrationen.
- Self Model mit Bestätigung; Point-in-Time Self.
- Re-Grounding und Provenance-UI.
- Privacy Security Layer (Minimierung, lokales Detect, Response-Validierung, Audit, Encryption).
- Voice, Offline, Obsidian.
Ein Agent, der 8.2 in diesem Slice „schließt“, verletzt Foundation-Regeln 22–24.
9. Dateikarte für die Gegenprüfung
9.1 Fachlich führend
| Datei | Rolle in der Prüfung |
|---|---|
produktvision_und_produktidentitaet.md |
Gesamtziel, Prinzipien, Nicht-Ziele |
mvp.md |
Freigegebener Slice |
implementation_foundation.md |
Sackgassen-Verbot |
| dieses Dokument | Ist-Stand |
guardrails.md |
Datenschutz-Invariante |
writing_profile_and_journaling.md |
Stilziel; Zweistufenmodell ist Ziel, nicht Slice |
9.2 Code, der den Slice trägt
| Pfad | Verantwortung |
|---|---|
backend/privacy_gateway.py, entity_detect.py, pronoun_bind.py, identity_store.py |
Egress, Maskierung, Dialog-Pronomen |
backend/context_builder.py, retrieval.py, conversation_signals.py |
Interner Kontext, Selection-Specs, lokale Dialogsignale |
backend/dialogue_turn.py |
Ein Call, Operation/Impuls, lokale Wächter; kein Writing-Profile-Kernel |
backend/journal_generate.py, journal_shape.py, journal_body.py |
Entwurf, Shape, Titel/Markdown |
backend/journal_store.py, journal_policy.py |
Entries, Versionen, Scratch, explizites Generate |
backend/writing_profile_store.py |
Lokaler Brief |
backend/media_store.py |
Lokale Medien, Token im Body |
frontend/src/pages/JournalDayPage.jsx |
Dialog + Generate + Scratch |
frontend/src/pages/JournalEditorPage.jsx |
Editor, Versionen, Dirty |
frontend/src/context/UnsavedChanges.jsx |
Navigationsschutz |
frontend/src/components/DayScratch.jsx |
Lokale Checkliste |
frontend/src/journal/document.js |
Markdown ↔ TipTap |
9.3 Tests und ihre Grenze
| Suite | Was sie trägt | Was sie nicht trägt |
|---|---|---|
backend/tests/test_mvp_journal.py |
Day, Generate ändert Entry nicht, Scratch nicht im Egress, Spaces isoliert, Konsolidierung nach Signalen | Dialogqualität, Stil, Case C Verhalten |
backend/tests/test_architecture_correction.py |
Provenance-Migration, Space ohne Day, Space-Source-Plan, Detect-Env, Kernel-Grenzen | — |
backend/tests/test_privacy_detect.py |
Maskierung, Pronomen Dialog vs Journal, Response Validation, Production-Detect | Quasi-Identifikatoren, Provider-ZDR |
backend/tests/test_journal_shape.py |
Namensausdünnung | Quelltreue des Modells |
backend/tests/test_writing_profile.py |
Quellenpriorität | „klingt wie die Person“ |
backend/tests/test_frame.py |
Auth, Prompts, Rahmen | Journal-IA |
frontend/src/journal/document.test.js |
Markdown-Runde | Editor-UX, Dirty-Flag |
Laufzeit lokal: Frontend Port 5188, Backend 8018, SQLite backend/data/kansho.sqlite. Prompt-Templates in der DB werden bei unangetasteten Seeds durch init_db aktualisiert; nach Prompt-Änderungen Backend neu starten.
10. Empfohlene Prüffragen (für den zweiten Agenten)
Nicht als Implementierungsbacklog, sondern als Gegenlesung:
- Wird im Code oder in der UI etwas als Erinnerung, Verständnis oder Identität verkauft, das nur Recency, Regex oder ein Writing-Brief ist?
- Bleibt der Dialog die Primärquelle, oder zieht der Editor (Medien, Versionen) die Produktmitte auf das Journal?
- Ist das Gateway vor jedem persönlichen Generate-Call, und ist Detect-Klartext als Testphase kenntlich — in Admin-UI und Doku?
- Kann ein späteres Thread Memory / Related Space / Re-Grounding an IDs, Assignment und Retrieval andocken, ohne Messages oder Entries umzuschlüsseln?
- Welche der Lücken in Abschnitt 8.1 sind echte Spec-Schulden, welche sollten in
mvp.mdauf den Code zurückgeschrieben werden, damit Vision und Slice nicht weiter auseinanderlaufen? - Drift-Risiko Stub-Home: bleibt die Startlogik gegen „Kontinuität des Dialogs“ dünn, obwohl
/dialognicht mehr in der Nutzer-IA liegt? - Scratch: bleibt die Grenze „kein Aufgabenmanager, kein Egress“ in Copy und Tests klar?
Wenn diese sieben Punkte tragfähig beantwortet sind, ist der Slice gegen das Gesamtziel als Keimzelle prüfbar — ohne das Target Model einzufordern.