---
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`