Enhance documentation for the Kanshō project by adding a Foundation-Checkpoint and Continuity Capability Contract. These sections outline the architectural framework and core capabilities necessary for the implementation of the Memory/Continuity-Core, ensuring clarity on critical paths and implementation principles. Historical intent statuses are preserved for reference, while emphasizing a streamlined approach to development.

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.
+

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.
+