From a8caeb0dd48e16fa78676d81d473f42278e09161 Mon Sep 17 00:00:00 2001 From: Lars Date: Fri, 21 Aug 2026 18:27:23 +0200 Subject: [PATCH] =?UTF-8?q?Enhance=20documentation=20for=20the=20Kansh?= =?UTF-8?q?=C5=8D=20project=20by=20adding=20a=20Foundation-Checkpoint=20an?= =?UTF-8?q?d=20Continuity=20Capability=20Contract.=20These=20sections=20ou?= =?UTF-8?q?tline=20the=20architectural=20framework=20and=20core=20capabili?= =?UTF-8?q?ties=20necessary=20for=20the=20implementation=20of=20the=20Memo?= =?UTF-8?q?ry/Continuity-Core,=20ensuring=20clarity=20on=20critical=20path?= =?UTF-8?q?s=20and=20implementation=20principles.=20Historical=20intent=20?= =?UTF-8?q?statuses=20are=20preserved=20for=20reference,=20while=20emphasi?= =?UTF-8?q?zing=20a=20streamlined=20approach=20to=20development.?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- .../functional/fachliche_zielarchitektur.md | 77 ++++++++++++++++++ .../functional/memory_and_context.md | 79 +++++++++++++++++++ 2 files changed, 156 insertions(+) diff --git a/docs/architecture/functional/fachliche_zielarchitektur.md b/docs/architecture/functional/fachliche_zielarchitektur.md index 910bcaa..1be7c40 100644 --- a/docs/architecture/functional/fachliche_zielarchitektur.md +++ b/docs/architecture/functional/fachliche_zielarchitektur.md @@ -272,3 +272,80 @@ Die **technische** Zielarchitektur liegt parallel unter `docs/architecture/techn Der detaillierte Kapitelplan, die Interviewmethode, Definition of Done, Fortschrittsstatus und der nächste Interviewblock werden ab jetzt in `interview_plan.md` gepflegt. +--- + +# Foundation-Checkpoint vor Implementierungsstart – 2026-08-21 + +**Status: neue aktuelle Arbeitssteuerung; frühere Interview-/Intent-Statusangaben bleiben als historische Zwischenstände erhalten** + +## Anlass + +Die Fachkonzeption wurde bewusst weit genug entwickelt, um teure spätere Refaktierungen bei Memory, Context, Reflection Spaces, Provenance und langfristiger Kontinuität zu vermeiden. + +Gleichzeitig besteht das Risiko, dass eine vollständige Umsetzung des gesamten Zielmodells zu einer überkomplexen ersten Anwendung führt und ein Coding-Agent aus dem umfangreichen Konzept verkürzte oder falsche Implementierungsannahmen ableitet. + +Daher wird zwischen drei Ebenen unterschieden: + +> **Target Concept → Implementation Foundation → Vertical MVP Slices** + +Das ausführliche Fachkonzept beschreibt, wohin Kanshō wachsen können muss. + +Die Implementation Foundation definiert nur die Architekturregeln, die frühe Sackgassen verhindern sollen. + +Ein MVP Slice implementiert nur eine kleine real nutzbare Produktfunktion auf dieser Foundation. + +## Ergebnis des Foundation Audits + +### Kein grundlegender Widerspruch festgestellt + +Die aktuellen Kernentscheidungen sind fachlich miteinander vereinbar: + +- Originalquellen bleiben kanonische Referenzbasis. +- Kanshō besitzt die langfristige Dialog-, Erlebnis- und Reflexionsgeschichte; mindnet das langfristig integrierte persönliche Wissensnetz. +- Reflection Spaces sind lebendige Bedeutungs- und Kontextbereiche und keine bloßen Ablageordner. +- Reflection Space first / Long-Term Memory on demand begrenzt die aktive Kontextmenge. +- Provider State und Retrieval-Indizes sind Hilfs-/Optimierungsschichten und keine fachliche Source of Truth. +- AI Hypotheses, zeitgebundene Selbstaussagen und bestätigtes persönliches Wissen bleiben unterscheidbar. +- User Correction beeinflusst Current Validity, ohne historische Quellen zu verfälschen. +- Memory Write / Update ist signal-driven und soll nicht nach jedem Turn alle möglichen Objektarten analysieren. +- Ein wesentlicher generativer Hauptmodell-Call pro Turn bleibt der Normalfall. + +### Erkannte Status-Drift: 11 Intents + +Frühere Abschnitte dieses Dokuments behandeln die elf Nutzungssituationen als nächsten Interviewblock beziehungsweise als unmittelbar weiter auszuarbeitende Konzeptsequenz. + +Diese Arbeitssteuerung ist **nicht mehr aktuell**. + +Die elf Nutzungssituationen bleiben fachlich nützliche Szenarien, sind aber kein Critical-Path-Gate für den Implementierungsstart und müssen nicht als elf technische Intent Engines realisiert werden. + +Sie werden künftig primär betrachtet als: + +- UX- und Nutzungsszenarien, +- Acceptance Cases, +- Test- und Validierungskatalog, +- mögliche spätere Spezialisierungen, falls reale Nutzung dies rechtfertigt. + +## Aktueller Critical Path + +Vor dem Coding werden nur noch folgende Schritte als notwendig betrachtet: + +1. implementierungsrelevanten Memory-/Continuity-Core abschließen, +2. kompakte `implementation_foundation.md` als Coding-Leitplanke festziehen, +3. Foundation-/Drift-Audit durchführen, +4. ersten vertikalen MVP Slice konkret spezifizieren, +5. Coding beginnen. + +Der erste MVP Slice soll bewusst deutlich kleiner sein als das vollständige Kanshō-Zielmodell. + +Aktuell bevorzugter Kandidat: + +> **Journal / Daily Reflection als Day-One-artige Keimzelle auf Kanshō-Foundations** + +Die konkrete Nutzeranwendung, UX, In-/Out-of-Scope-Funktionen und Acceptance Criteria werden nach diesem Foundation-Abschluss separat spezifiziert. + +## Implementierungsprinzip + +> **Nicht das Zielmodell vorbauen. Nur die Foundations vorbauen, deren späteres Nachrüsten teuer wäre; danach vertikal und nutzungsgetrieben iterieren.** + +Damit ist die ausführliche Konzeptarbeit weiterhin verbindliche Leitplanke gegen strukturelle Sackgassen, aber kein monolithisches Lastenheft für den ersten Coding-Schritt. + diff --git a/docs/architecture/functional/memory_and_context.md b/docs/architecture/functional/memory_and_context.md index 5f94566..9571671 100644 --- a/docs/architecture/functional/memory_and_context.md +++ b/docs/architecture/functional/memory_and_context.md @@ -1686,3 +1686,82 @@ Nicht mehr grundsätzlich offen sind: - ob jede Objektart nach jedem Turn vollständig neu analysiert werden muss, - ob jede Enrichment-Entscheidung vor der sichtbaren Antwort abgeschlossen sein muss, - ob jede Verarbeitungsaufgabe einen eigenen starken LLM-Aufruf benötigt. + +--- + +## Continuity Capability Contract + +**Status: fachliche Abschluss-Baseline für den implementierungsrelevanten Memory-/Continuity-Core** + +Der Continuity Capability Contract definiert nicht eine weitere interne Ontologie, sondern die beobachtbaren Fähigkeiten, an denen die langfristige Reflexionskontinuität von Kanshō gemessen wird. + +Kanshō erfüllt den fachlichen Anspruch eines langfristigen persönlichen Reflexionsbegleiters, wenn folgende Fähigkeiten zuverlässig realisierbar sind: + +1. **Im aktuellen Reflexionsraum bleiben** + Der normale Dialog orientiert sich primär an aktueller Session, Primary Reflection Space, aktiven Threads und offenen Fragen. Das globale Langzeitgedächtnis wird nicht permanent aktiviert. + +2. **Sinnvoll fortsetzen** + Ein früher begonnener Reflexionsfaden kann später wiederaufgenommen werden, ohne dass der Nutzer wesentliche bereits vorhandene Zusammenhänge erneut erklären muss. + +3. **Relevant erinnern statt maximal erinnern** + Frühere Inhalte werden nur dann aktiviert, wenn sie den aktuellen Reflexionsschritt tatsächlich verbessern. + +4. **Aktuell und historisch unterscheiden** + Frühere Sichtweisen, Gefühle, Bewertungen und Interpretationen werden nicht stillschweigend mit dem heutigen Zustand gleichgesetzt. + +5. **Veränderung erkennbar machen** + Relevante Entwicklungen zwischen früheren und aktuellen Perspektiven müssen nachvollziehbar darstellbar sein. + +6. **Unsicherheit erhalten** + AI Hypothesis, Observed Pattern, Candidate, explizite Nutzeraussage und bestätigte Erkenntnis bleiben unterscheidbar. + +7. **Korrigierbar bleiben** + Eine ausdrückliche Nutzerkorrektur verändert Current Validity. Frühere Zustände bleiben historisch nachvollziehbar, werden aber nicht weiter als aktuelle Wahrheit verwendet. + +8. **Zur Quelle zurückkehren können** + Wenn Genauigkeit, Widerspruch, historische Rekonstruktion oder Re-Grounding es erfordern, kann Kanshō auf die zugrunde liegenden Originalquellen zurückgreifen. + +9. **Keine künstliche Memory-Produktion** + Eine Session muss nicht automatisch Experiences, Insights, Threads, Patterns, Reflection Memories oder andere langlebige Objekte erzeugen. + +10. **Kontinuität bleibt dienend** + Memory, mindnet und Personal Model unterstützen den Reflexionsdialog und dürfen ihn nicht durch unnötiges Erinnern, Strukturieren oder Psychologisieren dominieren. + +11. **Normale Nutzung bleibt effizient** + Ein wesentlicher generativer Hauptmodell-Call pro Dialogturn bleibt der Normalfall. Tieferes Retrieval und Enrichment werden signal- beziehungsweise bedarfsgesteuert aktiviert. + +12. **Providerunabhängige Kontinuität** + Die langfristige Kontinuität darf nicht davon abhängen, dass ein bestimmter KI-Provider Conversation State dauerhaft hält. + +### Referenz-Akzeptanzfall + +Wenn der Nutzer nach längerer Zeit sagt: + +> „Ich möchte noch einmal über meine Meditationserfahrungen nachdenken.“ + +soll Kanshō fachlich in der Lage sein: + +- den relevanten Reflection Space beziehungsweise Reflexionszusammenhang zu erkennen, +- den aktuellen Stand und relevante offene Fäden zu berücksichtigen, +- gezielt relevante frühere Experiences, Insights oder Quellen einzubeziehen, +- irrelevante autobiografische Bereiche nicht automatisch zu aktivieren, +- bei Bedarf eine frühere Aussage quellenorientiert zu rekonstruieren, +- damalige und heutige Perspektive voneinander zu unterscheiden, +- neue Erkenntnisse provenance-fähig und vorsichtig fortzuschreiben. + +### Abschlussgrenze dieses Fachblocks + +Mit Context Builder, Memory Write / Update Policy und diesem Continuity Capability Contract ist der implementierungsrelevante fachliche Memory-/Continuity-Core ausreichend spezifiziert. + +Nicht vor einem ersten produktiven Slice verbindlich auszudetaillieren sind insbesondere: + +- mathematische Promotion Scores, +- vollständige Relationsontologie, +- adaptive Policy-Learning-Algorithmen, +- umfassende longitudinale Pattern-Erkennung, +- ausgereiftes Self Model, +- vollständige mindnet-Promotion, +- finale technische Storage- und Retrieval-Architektur. + +Diese Punkte bleiben Ziel- beziehungsweise Ausbauarchitektur und blockieren den Start einer inkrementellen Implementierung nicht. +