230 lines
9.5 KiB
Markdown
230 lines
9.5 KiB
Markdown
---
|
||
title: "Kanshō – Implementation Foundation"
|
||
status: "Baseline / verbindliche Implementierungsleitplanke"
|
||
date: "2026-08-21"
|
||
product_family: "Jinkendo"
|
||
document_role: "Kompakte Leitplanke zwischen fachlichem Zielmodell und vertikaler Implementierung"
|
||
---
|
||
|
||
# Kanshō – Implementation Foundation
|
||
|
||
## 1. Zweck
|
||
|
||
Dieses Dokument ist **nicht** die vollständige Kanshō-Spezifikation.
|
||
|
||
Es enthält nur die Architekturregeln, die ein Implementierungsagent kennen muss, damit ein kleiner MVP nicht durch frühe Vereinfachungen spätere Kernfähigkeiten verbaut.
|
||
|
||
Die ausführlichen Fachkapitel bleiben Source of Truth für das Zielmodell. Sie sind **Referenz**, aber kein Auftrag, alle dort beschriebenen Fähigkeiten jetzt zu implementieren.
|
||
|
||
Code-Stand und Abgleich gegen diese Foundation plus `mvp.md` und das Gesamtziel: `mvp_stand_und_abgleich.md` (2026-08-25). Dieses Dokument ersetzt die Foundation nicht.
|
||
|
||
Leitgedanke:
|
||
|
||
> **Groß genug denken, um teure Sackgassen zu vermeiden. Klein genug bauen, um früh ein real nutzbares Produkt zu erhalten.**
|
||
|
||
Für jeden Implementierungsschritt gilt:
|
||
|
||
> **Implementiere nur den aktuellen Slice. Respektiere dabei die Foundation. Baue das Target Model nicht vorsorglich vor.**
|
||
|
||
---
|
||
|
||
## 2. Verbindliche Core-Regeln
|
||
|
||
### Datenhoheit und Historie
|
||
|
||
1. **Original Source bleibt kanonisch.**
|
||
User Messages, AI Messages und relevante Originaleingaben werden verlässlich erhalten.
|
||
|
||
2. **Derived ersetzt Source nie.**
|
||
Summaries, Insights, Memories, Patterns oder andere Ableitungen dürfen Originalquellen nicht überschreiben oder ersetzen.
|
||
|
||
3. **Stabile Identitäten von Anfang an.**
|
||
Sessions, Messages und die im jeweiligen Slice tatsächlich benötigten langlebigen Fachobjekte erhalten stabile IDs.
|
||
|
||
4. **Zeit und Provenance sind Core-Daten.**
|
||
Relevante Quellen und Ableitungen müssen auf Ursprung und Zeitpunkt zurückführbar sein.
|
||
|
||
5. **Current Validity und History sind getrennt.**
|
||
Eine neue Sicht, Korrektur oder Neubewertung darf einen früheren fachlich relevanten Zustand nicht unkenntlich machen.
|
||
|
||
6. **User Correction hat Vorrang vor Modellinferenz.**
|
||
Eine korrigierte Ableitung darf nicht weiter stillschweigend als aktuelle Wahrheit verwendet werden.
|
||
|
||
### KI-Ableitungen und persönliches Modell
|
||
|
||
7. **AI Hypothesis ist kein User Fact.**
|
||
Eine vom Modell erzeugte Interpretation wird nicht automatisch zu bestätigtem persönlichem Wissen.
|
||
|
||
8. **Current expressed state ist kein stabiles Self Model.**
|
||
Zeitgebundene Emotionen, Bewertungen oder spontane Selbstbeschreibungen werden nicht automatisch als dauerhafte Identitätsaussagen behandelt.
|
||
|
||
9. **Model proposes; policy decides; source preserves.**
|
||
Das Hauptmodell darf Signale oder Kandidaten liefern; die Anwendung entscheidet über Writes und spätere Promotion.
|
||
|
||
### Reflection Context
|
||
|
||
10. **Reflection Space ist ein Bedeutungs- und Kontextobjekt, kein bloßer Ordner.**
|
||
|
||
11. **Primary und Related Spaces müssen architektonisch möglich bleiben.**
|
||
Related Spaces müssen im ersten MVP nicht zwingend sichtbar oder vollständig automatisiert sein.
|
||
|
||
12. **Assignment ist nicht Identity.**
|
||
Mehrfachzuordnung erzeugt keine Kopie desselben fachlichen Objekts.
|
||
|
||
13. **Existing before new.**
|
||
Bestehende langlebige Strukturen werden bevorzugt angereichert, bevor neue erzeugt werden.
|
||
|
||
### Context und Retrieval
|
||
|
||
14. **Reflection Space first, Long-Term Memory on demand.**
|
||
Der normale Dialog beginnt im aktuellen Reflexionskontext, nicht mit globaler autobiografischer Suche.
|
||
|
||
15. **Context Builder ist eine eigene Verantwortlichkeit.**
|
||
Kontextselektion darf nicht unkontrolliert über Prompts, UI-Komponenten und Featurecode verteilt werden.
|
||
|
||
16. **Minimum sufficient context.**
|
||
Aktiviert wird nur der kleinste ausreichend relevante Kontext für den nächsten sinnvollen Reflexionsschritt.
|
||
|
||
17. **Retrieval ist Hilfsstruktur, nicht Source of Truth.**
|
||
Suchindizes, Embeddings und ähnliche Strukturen müssen austauschbar beziehungsweise rebuildable bleiben.
|
||
|
||
18. **Provider State ist Optimierung, nicht Memory Ownership.**
|
||
Langfristige Dialog- und Memory-Kontinuität bleibt unter Kontrolle von Kanshō.
|
||
|
||
### Verarbeitung und Erweiterbarkeit
|
||
|
||
19. **Ein wesentlicher generativer Hauptmodell-Call pro Turn ist der Normalfall.**
|
||
Zusätzliche Modellaufrufe sind begründete Ausnahme- oder Enrichment-Pfade.
|
||
**Umsetzung:** Der Dialogzug hat einen maskierten Modell-Call (Operation + Impuls). Der Journalentwurf ist ein zweiter, ausdrücklich getrennter Call. Maskierung entscheidet keine Operation. Erzählregister wird lokal gesetzt.
|
||
|
||
20. **Write Evaluation ist signal-driven, nicht exhaustive.**
|
||
Nicht jede Message löst die vollständige Analyse aller möglichen Memory-, Pattern- oder Self-Model-Objekte aus.
|
||
|
||
21. **Variable Policies nicht quer im Code hardcoden.**
|
||
Änderbare Write-, Promotion- oder Routing-Entscheidungen erhalten eine klar erkennbare zentrale Decision-/Policy-Grenze. Eine umfassende Policy Engine ist dafür im MVP nicht erforderlich.
|
||
|
||
22. **Interne Reichhaltigkeit rechtfertigt keine komplexe UI.**
|
||
Die sichtbare Oberfläche bleibt deutlich einfacher als das mögliche interne Zielmodell.
|
||
|
||
23. **Neue Abstraktionen brauchen aktuellen Nutzen.**
|
||
Eine Target Capability wird nicht allein deshalb implementiert, weil sie im Fachkonzept beschrieben ist.
|
||
|
||
24. **Nicht implementiert ist ein zulässiger Zustand.**
|
||
Spätere Fähigkeiten bleiben bewusst offen, solange der aktuelle Entwurf ihre spätere Ergänzung nicht strukturell verbaut.
|
||
|
||
---
|
||
|
||
## 3. Foundation Cut vor dem ersten vertikalen Slice
|
||
|
||
Vor dem ersten echten Produkt-Slice müssen nur die Strukturen vorhanden oder verbindlich entschieden sein, deren spätere Änderung eine teure grundlegende Refaktierung verursachen würde.
|
||
|
||
### Muss vorhanden sein
|
||
|
||
- persistente Session- und Message-Quellen,
|
||
- stabile IDs,
|
||
- Zeitbezug und grundlegende Provenance,
|
||
- klare Trennung `Source` / `Derived`,
|
||
- Reflection-Space-Grundmodell mit stabiler Identität,
|
||
- Primary-Space-Zuordnung,
|
||
- Datenmodell darf Related Spaces später zulassen,
|
||
- einfache Current-State-/History-Fähigkeit für bereits verwendete veränderliche Objekte,
|
||
- Nutzerkorrektur muss Current Validity beeinflussen können,
|
||
- zentrale Context-Builder-Schnittstelle,
|
||
- austauschbare Retrieval-Schnittstelle,
|
||
- Provider-Abstraktion,
|
||
- kleine zentrale Write-/Decision-Policy-Grenze.
|
||
|
||
### Nur bauen, wenn der erste Slice es wirklich benötigt
|
||
|
||
- Thread,
|
||
- Open Question,
|
||
- Insight,
|
||
- Experience Candidate,
|
||
- sichtbare Related Spaces,
|
||
- automatische Space-Erkennung,
|
||
- semantisches Retrieval,
|
||
- Session Summary,
|
||
- zusätzliche Enrichment-Verarbeitung.
|
||
|
||
Das Datenmodell darf diese Fähigkeiten später zulassen; sie müssen nicht vorsorglich funktionsfähig gebaut werden.
|
||
|
||
---
|
||
|
||
## 4. Explizite Non-Goals vor dem ersten MVP
|
||
|
||
Folgende Target Capabilities sind **kein Foundation-Auftrag**:
|
||
|
||
- vollständiger Reflection Graph,
|
||
- Graphdatenbank allein wegen des Reflection-Graph-Konzepts,
|
||
- automatische langfristige Pattern-Erkennung,
|
||
- ausgereiftes Self Model,
|
||
- Landmark-Experience-Engine,
|
||
- adaptive Policy- oder Threshold-Learning-Engine,
|
||
- automatische komplexe Space-Merges,
|
||
- vollständige mindnet-Synchronisation,
|
||
- komplexe Resurfacing Engine,
|
||
- longitudinale Persönlichkeitsanalyse,
|
||
- elf technische Intent Engines,
|
||
- umfangreiche Admin-/Governance-Oberfläche,
|
||
- Graphvisualisierung,
|
||
- komplexe Dashboard-Landschaft.
|
||
|
||
Ein Coding-Agent darf diese Funktionen nicht vorsorglich implementieren, wenn sie nicht Bestandteil eines ausdrücklich freigegebenen Slices sind.
|
||
|
||
---
|
||
|
||
## 5. Arbeitsregel für Coding-Agenten
|
||
|
||
Vor einer neuen Core-Abstraktion sind drei Fragen zu beantworten:
|
||
|
||
1. **Braucht der aktuelle Slice diese Abstraktion jetzt?**
|
||
2. **Würde ein späteres Nachrüsten ohne diese Vorbereitung eine grundlegende Refaktierung der bereits kanonischen Daten oder Verantwortlichkeiten erzwingen?**
|
||
3. **Ist die vorgeschlagene Lösung mit den Core-Regeln dieses Dokuments vereinbar?**
|
||
|
||
Wenn 1 und 2 beide mit **Nein** beantwortet werden, wird die Abstraktion nicht vorgebaut.
|
||
|
||
Wenn eine Entscheidung eine Foundation-Regel berührt oder unklar ist, wird gezielt das betreffende Fachkapitel unter `docs/architecture/functional/` konsultiert. Es sollen nicht vorsorglich sämtliche Kanshō-Dokumente in jeden Coding-Kontext geladen werden.
|
||
|
||
---
|
||
|
||
## 6. Iterationsprinzip
|
||
|
||
Die bevorzugte Entwicklung ist vertikal:
|
||
|
||
> **Foundation → kleiner real nutzbarer Slice → echte Nutzung → Abgleich mit Zielarchitektur → kleinste notwendige Erweiterung**
|
||
|
||
Das Ziel ist nicht, vor dem ersten Release die gesamte Kanshō-Intelligenz zu implementieren.
|
||
|
||
Das Ziel ist, **jede kleine Version bereits auf einer Foundation aufzubauen, die die bekannten teuren Sackgassen vermeidet**.
|
||
|
||
---
|
||
|
||
## 7. Rolle der Nutzungssituationen / Intents
|
||
|
||
Die bisher beschriebenen Nutzungssituationen bleiben wertvolle fachliche Szenarien.
|
||
|
||
Sie sind jedoch:
|
||
|
||
- kein Critical-Path-Gate für den ersten MVP,
|
||
- keine Verpflichtung zu elf technischen Betriebsmodi,
|
||
- kein Grund, vor dem ersten Slice eine universelle Intent Engine zu bauen.
|
||
|
||
Sie dienen später insbesondere als:
|
||
|
||
- UX-Szenarien,
|
||
- Acceptance Cases,
|
||
- Architektur-Validierung,
|
||
- Testkatalog für neue vertikale Slices.
|
||
|
||
---
|
||
|
||
## 8. Nächster Schritt
|
||
|
||
Nach dieser Foundation wird der erste vertikale MVP-Slice separat spezifiziert.
|
||
|
||
Aktuell bevorzugter Kandidat:
|
||
|
||
> **Journal / Daily Reflection als bewusst einfache Day-One-artige Keimzelle auf Kanshō-Foundations.**
|
||
|
||
Die konkrete Nutzeranwendung, UX, Datenflüsse, In-/Out-of-Scope-Funktionen und Acceptance Criteria gehören in die MVP-Spezifikation und nicht in dieses Dokument.
|