Kansho/docs/architecture/technical/data_architecture.md
Lars 36b9a2e424
Some checks failed
Deploy Development / deploy (push) Successful in 55s
Test Suite / backend-postgres (push) Failing after 7s
Test Suite / frontend-build (push) Successful in 16s
Run the backend suite on Dev Postgres instead of isolated SQLite.
Co-authored-by: Cursor <cursoragent@cursor.com>
2026-09-07 14:28:17 +02:00

96 lines
6.0 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

---
title: "Kanshō Datenarchitektur"
version: "0.1"
status: "Arbeitsstand"
date: "2026-08-19"
product_family: "Jinkendo"
document_role: "Technical Chapter / Data Architecture"
parent_document: "technische_zielarchitektur.md"
---
# Kanshō Datenarchitektur
Kanonisches Home für Persistenzgrenzen **ohne** vorgezogenes SQL-Schema. Ableitungen, die UI und KI gemeinsam brauchen, folgen dem Data-Layer-Muster in `platform_extensibility.md` (Layer 0/1/2), sobald der Fachstand konkrete Funktionen hergibt.
## 1. Speicherverantwortung
Herkunft: `../functional/memory_and_context.md` §11, bevorzugte Richtung, technisch zu validieren.
| System | Besitz | Nicht besitzen |
|---|---|---|
| Kanshō / PostgreSQL | laufender Dialog, Session, Thread-Arbeitsstand, Working Context, lokale Kontinuitätsstrukturen | langfristiges Wissensnetz als Primärgraph |
| mindnet | langfristiges Wissen, Retrieval, Edges, Reflection Memories, Knowledge Deltas | exakte Dialogreihenfolge, Offline-Branching |
| Obsidian | menschenlesbares Archiv, Journal Entries | interne Thread-Zustände |
**Status: bevorzugte Richtung** für die Verteilung; Validierung bleibt offen.
Kanshō erzeugt kein proprietäres geschlossenes Langzeitarchiv, das Obsidian ersetzen würde.
## 2. Aktueller Fach-Arbeitsstand (nicht final)
Die folgenden Punkte stehen heute in der Fachdoku. Sie sollen bei einer späteren Persistenz **nicht stillschweigend verloren gehen**. Sie sind **kein** Auftrag, jetzt Tabellen, Enums oder State Machines daraus zu bauen. Ändert die Fachkonzeption sie, gilt der neue Fachstand.
1. **Originaldialog ist Primärquelle.** Summaries, Thread Memories und Space-Zustände sind abgeleitet. Re-Grounding rekonstruiert aus Ursprungsquellen (`context_fidelity_and_regrounding.md`).
2. **Session Lifecycle ≠ Thread Lifecycle.** Das Ende einer Nutzungssitzung schließt Threads nicht automatisch (`reflection_outputs.md`). Tabellen und Statusfelder müssen beide Zyklen unabhängig abbilden können.
3. **Lived Experience / Point-in-Time Self.** Frühere Innenperspektiven werden nicht durch heutige Summaries überschrieben (`self_model_and_lived_experience.md`). Versionierung und Zeitbindung sind erforderlich, sobald Self-Model-Daten persistiert werden.
4. **Hypothese ≠ bestätigte Erkenntnis.** Self-Model-Änderungen nicht stillschweigend schreiben.
5. **Action Candidates** sind Handoffs nach Kairo, keine Kanshō-Aufgabenliste.
6. **Resurfacing ≠ Speicherung.** Langfristig gespeichert heißt nicht aktuell relevant (`resurfacing_and_saturation.md`).
## 3. Fachliche Entitäten (noch kein Schema)
Die folgende Liste spiegelt den **heutigen** Fachstand. Sie ist ein Merkzettel, keine Tabellendefinition und keine Zusage, dass all diese Objekte so bleiben. Welche Objektarten und Beziehungen ein späteres Schema **erfüllen** muss, steht als Vertrag in `memory_storage_and_offline.md` §3a.
| Entität | Fachliches Home | Technische Erwartung v0.1 |
|---|---|---|
| Profile / Session | dieses Kapitel + `auth_identity_and_roles.md` | Kanshō-DB, Rahmen |
| Conversation / Message | `dialogue_model.md` | Kanshō-DB, Originalrepräsentation |
| Thread (kein fertiges State Model) | `dialogue_model.md`, `resurfacing_and_saturation.md` | Kanshō-DB; Zustände nicht als geschlossene Enum vortäuschen |
| Reflection Space | `reflection_spaces.md` | Kanshō-DB, sichtbare vs. interne Struktur trennen |
| Working / Thread Memory | `memory_and_context.md` | Kanshō-DB, quellengebunden |
| Episodic / Journal / Memory / Knowledge Delta | `reflection_outputs.md` | Handoff-Ziele mindnet/Obsidian |
| Action Candidate | `reflection_outputs.md` | Handoff Kairo |
| Self Model Version | `self_model_and_lived_experience.md` | lokal, versioniert, Bestätigungspflicht |
| Writing Profile | `writing_profile_and_journaling.md` | lokal langfristig |
| Provenance / Confidence | `context_fidelity_and_regrounding.md` | an abgeleiteten Strukturen, nicht nur an Originalen |
| Privacy Mapping | `guardrails.md` | Klasse A, nur lokal |
Kein Thread-State-Machine-Kapitel in v0.1. Die fachlich genannten Zustände (`Open`, `Anchored / Resurface`, `Dormant`, `Resolved`) sind **nicht abschließend**.
## 4. Was nicht in der Kanshō-DB landen soll
- Vollständiges mindnet-Graphmodell als Kopie.
- Kairo-Projekte, Tasks, Rituale als führendes System.
- Mitai-Vital- und Trainingsrohdaten als zweites Tracking.
- Identity-Mapping in Backup-Logs oder Prompt-Archiven.
## 5. Entscheidungsstand
| Thema | Stand | Status |
|---|---|---|
| Kanshō besitzt den Dialogspeicher | ja | bevorzugte Richtung |
| mindnet besitzt langfristiges Gedächtnis | ja | bevorzugte Richtung |
| Obsidian menschenlesbares Archiv | ja | bevorzugte Richtung |
| Session ≠ Thread / Originaldialog / Handoffs | aktueller Fach-Arbeitsstand | nicht einfrieren |
| SQL-Schema / IDs / Edges | nein | offen |
| Thread-Zustandsmenge | nicht schließen | offen |
| Gemeinsame IDs mit mindnet/Obsidian | nötig, Form unbekannt | offen |
## 6. Offene Fragen
Entsprechen den Interview-Leitfragen Phase F1/F4 und werden hier nicht vorab beantwortet: kanonische IDs, Backlinks, welche Strukturen nur in Obsidian existieren, Schema für Reflection Memory und Knowledge Delta.
## 6a. Persistenzgrenzen Server vs. lokal (2026-09-07)
Additiv, ohne das Fachschema vorzuziehen:
- Windows-Checkout: SQLite unter `backend/data/` (gitignoriert) für die lokale App ohne Docker.
- Test-Suite und Gitea: dieselbe Dev-Postgres-Instanz, Datenbank `kansho_test` neben `kansho_dev` (keine dritte Instanz). Nicht `kansho` / `kansho_dev`, weil die Suite das Schema zurücksetzt.
- Docker auf dem Pi: PostgreSQL 16, eigene Instanz je Umgebung, Medien im Compose-Volume `kansho-media` / `dev-kansho-media`.
- Identity-Mappings bleiben Klasse A in der Local Trusted Zone (jetzt: Pi-Postgres, nicht Provider).
- Kein Shared-Schema mit Mitai.
## 7. Querverweise
- `memory_storage_and_offline.md`, `integrations_technical.md`, `privacy_gateway.md`, `platform_extensibility.md`
- Fachlich: `memory_and_context.md`, `reflection_outputs.md`, `self_model_and_lived_experience.md`