61 lines
3.0 KiB
Markdown
61 lines
3.0 KiB
Markdown
---
|
||
title: "Kanshō – Technische Integrationen"
|
||
version: "0.1"
|
||
status: "Arbeitsstand"
|
||
date: "2026-08-19"
|
||
product_family: "Jinkendo"
|
||
document_role: "Technical Chapter / Integrations"
|
||
parent_document: "technische_zielarchitektur.md"
|
||
---
|
||
# Kanshō – Technische Integrationen
|
||
|
||
Kanonisches Home für technische Handoffs. Fachliche Produktgrenzen: `../functional/integrations.md`. Verträge (APIs, Events, Auth zwischen Apps) sind **offen** (Interview F1/F2).
|
||
|
||
## 1. Prinzip
|
||
|
||
Integrationen folgen der Produktverantwortung, nicht der Bequemlichkeit gemeinsamer Tabellen.
|
||
|
||
Kein stilles Mitlesen fremder Datenbanken als Ersatz für einen Vertrag. Berechtigung und Zweckbindung gelten auch familienintern.
|
||
|
||
## 2. Handoff-Matrix
|
||
|
||
| Gegenüber | Kanshō darf | Kanshō darf nicht | Status Vertrag |
|
||
|---|---|---|---|
|
||
| **Kairo** | Ziele/Entwicklungskontext lesen; Action Candidates vorschlagen und zur Übernahme anbieten | Aufgaben, Projekte, Rituale führen | offen |
|
||
| **mindnet** | Wissen abrufen; Memories und Knowledge Deltas vorschlagen/schreiben gemäß späterem Schema | Working Memory laufender Dialoge ersetzen | offen |
|
||
| **Obsidian** | Journal und strukturierte Reflexionen ablegen, referenzieren | einziges geschlossenes Archiv sein | offen (Ablage/Sync) |
|
||
| **Mitai** | bei Kontext und Berechtigung körperlichen Kontext lesen | Vital-/Ernährungs-Tracking nachbauen | offen |
|
||
| **Shinkan** | Trainingskontext für Reflexion lesen | Trainingsplanung nachbauen | offen |
|
||
|
||
Action Candidate fachlich: `../functional/reflection_outputs.md`. Operationalisierung bleibt Kairo.
|
||
|
||
## 3. Technische Leitplanken bis zum Vertrag
|
||
|
||
- Lesen, Schreiben und „nur vorschlagen / Nutzer bestätigt“ sind drei verschiedene Rechte. Default: vorschlagen.
|
||
- IDs und Backlinks müssen später kanonisch sein; Format offen.
|
||
- Egress zu einer Schwester-App ist nicht dasselbe wie LLM-Egress, braucht aber ebenfalls Minimierung identifizierender Daten gegenüber nicht vertrauenswürdigen Netzen.
|
||
- Shinkan-Vereinsmodell wird nicht nach Kanshō gespiegelt, auch wenn Shinkan-Kontext gelesen wird: Mapping auf den Kanshō-Nutzer, nicht auf einen Verein.
|
||
|
||
## 4. Event vs. API
|
||
|
||
**Status: offen.** Fachlich sind externe Reflexionstrigger erlaubt (andere Komponenten dürfen Anlässe anbieten; Kairo plant, Kanshō reflektiert). Technische Trigger-Architektur ist bewusst noch nicht abgeleitet (`usage_situations.md`).
|
||
|
||
## 5. Entscheidungsstand
|
||
|
||
| Thema | Stand | Status |
|
||
|---|---|---|
|
||
| Keine Funktionsduplikation | ja | entschieden (fachlich) |
|
||
| Action Candidates → Kairo | ja | entschieden (fachlich) |
|
||
| Journal → Obsidian | primär | entschieden (fachlich) |
|
||
| Konkrete APIs/Events/Auth-Zertifikate | – | offen |
|
||
| Shared Database | als Integrationsmuster | verworfen als Default |
|
||
|
||
## 6. Offene Fragen
|
||
|
||
Interview F1/F2 vollständig: welche Daten kanonisch wo liegen, welche Edges mindnet braucht, Obsidian-Pfadkonvention, Bestätigungsdialoge vor Schreib-Handoffs.
|
||
|
||
## 7. Querverweise
|
||
|
||
- `data_architecture.md`, `privacy_gateway.md`
|
||
- Fachlich: `../functional/integrations.md`, `../functional/reflection_outputs.md`
|