Kansho/docs/architecture/technical/integrations_technical.md

3.0 KiB
Raw Permalink Blame History

title version status date product_family document_role parent_document
Kanshō Technische Integrationen 0.1 Arbeitsstand 2026-08-19 Jinkendo Technical Chapter / Integrations 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