Kansho/docs/architecture/functional/fachliche_zielarchitektur.md

title	version	status	date	product_family	document_role
Kanshō – Fachliche Zielarchitektur und Interviewplan	0.1	Arbeitsstand	2026-08-18	Jinkendo	Fachliche Zielarchitektur / Master Structure / Interview Plan

Kanshō – Fachliche Zielarchitektur

1. Zweck dieses Dokuments

Dieses Dokument definiert die fachliche Zielarchitektur der Kanshō-Produktdokumentation.

Jedes fachlich relevante Kapitel soll später als eigenständige Markdown-Datei in Gitea geführt werden.

Damit werden drei Ziele verfolgt:

1. Die Dokumentation bleibt modular und versionierbar.
2. Einzelne Themen können weiterentwickelt werden, ohne andere Inhalte unbeabsichtigt zu verdichten oder zu überschreiben.
3. Die Kapitelstruktur bildet gleichzeitig den Fahrplan für den weiteren Konzeptdialog beziehungsweise das Interview.

Dieses Dokument ist somit:

• das erste und führende Referenzdokument der fachlichen Konzeption,
• Inhaltsverzeichnis,
• Dokumentationsarchitektur,
• Interviewplan,
• Fortschrittsübersicht.

Die übrigen fachlichen Dokumente werden aus dieser Zielarchitektur abgeleitet und fachlich hier eingeordnet.

---

2. Dokumentationsprinzipien

2.1 Keine stillschweigende Verdichtung

Ein bestehendes Kapitel wird nicht dadurch „verbessert“, dass ältere Inhalte ohne Kennzeichnung verschwinden.

Änderungen erfolgen durch:

• Ergänzung,
• explizite Ersetzung,
• Kennzeichnung als überholt,
• Decision Record,
• Gitea-Versionierung.

---

2.2 Entscheidungen und Ideen trennen

Jedes Kapitel soll klar unterscheiden zwischen:

• Entschieden
• Bevorzugte Richtung
• Hypothese
• Offen
• Verworfen
• Später prüfen

---

2.3 Herkunft von Aussagen erhalten

Wo sinnvoll soll kenntlich bleiben, ob ein Punkt stammt aus:

• expliziter Nutzeranforderung,
• gemeinsam getroffener Entscheidung,
• Architekturvorschlag,
• technischem Zwang,
• späterer Validierung,
• externem Research.

---

2.4 Keine unnötige Duplizierung

Ein Thema hat möglichst ein fachliches „Home“.

Andere Kapitel verlinken darauf, statt denselben Inhalt mehrfach vollständig zu kopieren.

---

2.5 Kapitel sind unabhängig versionierbar

Jede Datei erhält mindestens:

• Titel,
• Version,
• Status,
• Datum,
• Rolle des Dokuments.

Die Dateinamen selbst bleiben stabil und enthalten keine Versionsnummern oder laufenden Nummerierungspräfixe. Versionierung erfolgt über Gitea beziehungsweise die Dokumentmetadaten, nicht durch Umbenennen der Datei.

---

2.6 Trennung von fachlicher und technischer Konzeption

Die fachliche Zielarchitektur ist führend.

Im Interview wird zunächst beschrieben:

• welches Nutzererlebnis gewünscht ist,
• welche fachlichen Verantwortlichkeiten bestehen,
• welche Objekte oder Beziehungen für das Produktverständnis notwendig sind,
• welche Entscheidungen oder Kontrollen beim Nutzer liegen.

Die technische Umsetzung wird bewusst nachgelagert.

Ausnahmen sind nur dann sinnvoll, wenn eine technische Grundentscheidung:

• die fachliche Produktgrenze unmittelbar beeinflusst,
• später nur mit sehr hohem Aufwand revidierbar wäre,
• oder zwingende Auswirkungen auf Datenschutz, Offline-Fähigkeit, Sicherheit oder Integrationen hat.

Ziel ist, eine fachlich klare, aber handhabbare Architektur zu entwickeln und unnötige Frühkomplexität zu vermeiden.

2.7 Transparenz- und Diagnoseprinzip

Die normale Nutzeroberfläche soll interne KI-Strukturen bewusst abstrahieren.

Für Entwicklung, Test und Administration wird jedoch eine gesonderte Admin-/Developer View vorgesehen.

Diese dient insbesondere dazu, fachliche und später technische Entscheidungen nachvollziehen zu können, ohne die reguläre Nutzung mit interner Komplexität zu belasten.

Die Diagnoseansicht soll perspektivisch unter anderem Einblick geben in:

• Threads und Thread-Kandidaten,
• Reflection-Space-Zuordnungen,
• Konsolidierungsentscheidungen,
• Memory-Provenance,
• Confidence und Unsicherheit,
• Hypothesen,
• Context-Builder-Ergebnisse,
• verwendete Wissensquellen,
• Strukturänderungen.

Der Zugriff ist rollenbasiert und nicht für reguläre Nutzer vorgesehen.

Dieses Prinzip ist fachlich bereits entschieden; genaue UI, Berechtigungen und technische Implementierung werden später spezifiziert.

2.8 Schutz vor Übervereinfachung

Die Zielarchitektur folgt ausdrücklich nicht dem Prinzip, den internen Kern möglichst klein oder einfach zu halten.

Ziel ist vielmehr:

maximale Nutzereinfachheit bei ausreichender interner Intelligenz und Differenzierung.

Daraus folgt für den Konzeptdialog:

• Fachliche Komplexität wird nicht allein deshalb entfernt, weil sie technisch unbequem ist.
• Interne Modelle dürfen komplex sein, wenn sie zur langfristigen Produktfähigkeit erforderlich sind.
• Die Benutzeroberfläche abstrahiert interne Komplexität.
• Automatisierung und KI-gestützte Strukturierung sollen Verwaltungsaufwand vom Nutzer fernhalten.
• Vor jeder größeren Vereinfachung ist ein Capability-Check durchzuführen.

Capability-Check vor Modellvereinfachungen

Vor einer strukturellen Vereinfachung wird geprüft:

1. Welche bereits beschlossenen Anforderungen benötigen die Struktur?
2. Welche später vorgesehenen Fähigkeiten könnten betroffen sein?
3. Welche Integrationen hängen davon ab?
4. Welche Langzeitfunktionen wie Memory, Self Model, Threading, Provenance oder Konsolidierung würden eingeschränkt?
5. Ist die Vereinfachung reversibel?
6. Kann die wahrgenommene Komplexität stattdessen auf UX-Ebene reduziert werden?

Erst wenn diese Prüfung keine relevanten Funktionsverluste zeigt, soll eine interne Vereinfachung vorgenommen werden.

2.8.1 Herleitung architekturrelevanter Entscheidungen

Architekturrelevante Entscheidungen mit langfristiger Tragweite oder späterem Vereinfachungsrisiko sollen nicht nur als Lösung dokumentiert werden.

Wo die Begründung für die spätere Nachvollziehbarkeit wesentlich ist, wird zusätzlich folgende Struktur festgehalten:

1. Root Cause – welches zugrunde liegende Problem oder welche Systembedingung erzeugt den Bedarf?
2. Risiko – welche fachlichen oder qualitativen Folgen entstehen ohne Gegenmaßnahme?
3. Fachliche Konsequenz – welche Eigenschaft muss das Produkt deshalb besitzen?
4. Abgeleitete Anforderung / Entscheidung – welcher Mechanismus oder welche Architekturleitplanke folgt daraus?

Dieses Prinzip soll verhindern, dass später nur noch ein Architekturmechanismus sichtbar ist, während sein ursprünglicher Zweck verloren geht und die Entscheidung deshalb fälschlich als entbehrliche Komplexität behandelt wird.

2.9 Querschnittliche Fachinvarianten

Die ausführlichen Herleitungen der querschnittlichen Fachinvarianten werden nicht mehr in diesem Root-Dokument gepflegt. Sie besitzen jeweils ein kanonisches Fachkapitel und müssen bei späteren Architekturentscheidungen explizit konsistenzgeprüft werden.

• Context Fidelity / Re-Grounding: context_fidelity_and_regrounding.md
• Thread Resurfacing / Reflection Saturation: resurfacing_and_saturation.md
• Session Lifecycle ≠ Thread Lifecycle: reflection_outputs.md und resurfacing_and_saturation.md
• Point-in-Time Self / Lived Experience: self_model_and_lived_experience.md
• Default-Quellbewahrung / skalierbare Informationsorganisation: memory_and_context.md
• Privacy Gateway / External-AI-Guardrails: guardrails.md
• Reflection Companion / Non-Therapy- und Safety-Grenze: produktvision_und_produktidentitaet.md und usage_situations.md

Keine dieser Invarianten darf durch spätere technische Vereinfachungen stillschweigend abgeschwächt werden.

2.10 Dokumentationsintegrität und Drift-Audit

Da die Produktkonzeption über einen langen Dialog hinweg entsteht, wird nicht nur der spätere Anwendungskontext, sondern auch die Konzeptdokumentation selbst gegen Drift geschützt.

Vor dem Wechsel in einen neuen größeren Themenblock oder vor einem Handover soll geprüft werden:

1. Sind alle expliziten Nutzeranforderungen seit dem letzten Audit dokumentiert?
2. Sind gemeinsam getroffene Entscheidungen vollständig erhalten?
3. Wurden ursprünglich konkrete Anforderungen ungewollt verallgemeinert oder abgeschwächt?
4. Wurden offene Punkte versehentlich als entschieden dargestellt oder umgekehrt?
5. Sind Root Causes und Begründungen architekturrelevanter Entscheidungen erhalten?
6. Widersprechen sich Zielarchitektur und Fach-/Produktdokumente?
7. Ist der Interviewstatus aktuell?
8. Wurden Inhalte stillschweigend gelöscht oder durch eine kürzere Formulierung ersetzt?
9. Sind Dateinamen und Repository-Struktur weiterhin mit den vereinbarten Gitea-Prinzipien konsistent?

Korrekturen aus einem Audit sollen additiv erfolgen. Inhaltliche Löschungen oder Verdichtungen dürfen nur vorgenommen werden, wenn sie als bewusste Änderung nachvollziehbar sind.

Audit-Checkpoint 2026-08-18

Vor dem Wechsel vom Reflection-Space-Block zu den typischen Nutzungssituationen wurde die bestehende Dokumentation gegen den bisherigen Konzeptdialog geprüft.

Dabei wurden keine bewussten fachlichen Entscheidungen verworfen. Es wurden jedoch mehrere Stellen identifiziert, an denen frühere konkrete Aussagen zu allgemein geworden oder der Dokumentstatus veraltet war. Additiv beziehungsweise strukturell korrigiert wurden insbesondere:

• explizite Verankerung von Kanshō als bewusst stärker KI-kollaborative Jinkendo-Komponente,
• Wiederherstellung des konkret genannten Referenzrahmens „Day One im Gold-Abo“ für die spätere Journaling-Analyse,
• explizite Sicherung des generierten Tagebucheintrags als vorgesehene Kernfunktion der täglichen Reflexion,
• Dokumentation der vorläufigen sichtbaren Reflection-Space-Baseline,
• explizite Nutzer-Provenance beziehungsweise Aufklappbarkeit verdichteter Aussagen,
• Dokumentation, dass Reflection Spaces sowohl kurz-/mittelfristig als auch langfristig relevant sein können,
• Aktualisierung des Interviewstatus: Reflection Spaces vorläufig ausreichend geklärt; typische Nutzungssituationen als nächster Block,
• Entfernung numerischer Präfixe aus den vorgeschlagenen Gitea-Datei- und Ordnernamen,
• Korrektur inkonsistenter Kapitel- und Listenummerierungen,
• strukturelle Verschiebung des Prinzips „Einfachheit an der Oberfläche, Intelligenz im Kern“ aus den Integrationsprinzipien in die Produktprinzipien, ohne inhaltliche Kürzung.

Dieser Checkpoint dokumentiert den Abgleich mit dem bis zu diesem Zeitpunkt vorliegenden Konzeptdialog. Spätere Erkenntnisse können bestehende Punkte konkretisieren oder bewusst ändern, sollen diese Änderungen jedoch nachvollziehbar dokumentieren.

3. Kanonische Dokumentstruktur

Die fachliche Dokumentation ist nach Themen aufgeteilt. Ein Thema soll möglichst genau ein kanonisches fachliches Home besitzen.

handover.md
fachliche_zielarchitektur.md
produktvision_und_produktidentitaet.md
documentation_index.md
interview_plan.md
usage_situations.md
reflection_spaces.md
dialogue_model.md
memory_and_context.md
resurfacing_and_saturation.md
context_fidelity_and_regrounding.md
self_model_and_lived_experience.md
writing_profile_and_journaling.md
reflection_intelligence.md
reflection_outputs.md
integrations.md
guardrails.md
migration_mapping.md
mvp.md
implementation_foundation.md
mvp_stand_und_abgleich.md

mvp_stand_und_abgleich.md ist das kanonische Home der Fit-Gap-Analyse: Code gegen Implementation Foundation, gegen den freigegebenen MVP-Slice und gegen das Gesamtziel. Es ersetzt weder mvp.md noch implementation_foundation.md noch produktvision_und_produktidentitaet.md. Technische Kapitel führen lokale Implementierungsstände; der Abgleich liegt hier.

Die unveränderten Quelldokumente vor der Aufteilung liegen im Verzeichnis checkpoint_originals/.

Die technische Zielarchitektur liegt parallel unter docs/architecture/technical/ und beginnt mit technische_zielarchitektur.md. Sie ist der Fachdoku nachgeordnet, ersetzt keine Fachkapitel und darf unfertige Interviewblöcke nicht als entschieden darstellen.

4. Interviewsteuerung

Der detaillierte Kapitelplan, die Interviewmethode, Definition of Done, Fortschrittsstatus und der nächste Interviewblock werden ab jetzt in interview_plan.md gepflegt.

---

Foundation-Checkpoint vor Implementierungsstart – 2026-08-21

Status: neue aktuelle Arbeitssteuerung; frühere Interview-/Intent-Statusangaben bleiben als historische Zwischenstände erhalten

Anlass

Die Fachkonzeption wurde bewusst weit genug entwickelt, um teure spätere Refaktierungen bei Memory, Context, Reflection Spaces, Provenance und langfristiger Kontinuität zu vermeiden.

Gleichzeitig besteht das Risiko, dass eine vollständige Umsetzung des gesamten Zielmodells zu einer überkomplexen ersten Anwendung führt und ein Coding-Agent aus dem umfangreichen Konzept verkürzte oder falsche Implementierungsannahmen ableitet.

Daher wird zwischen drei Ebenen unterschieden:

Target Concept → Implementation Foundation → Vertical MVP Slices

Das ausführliche Fachkonzept beschreibt, wohin Kanshō wachsen können muss.

Die Implementation Foundation definiert nur die Architekturregeln, die frühe Sackgassen verhindern sollen.

Ein MVP Slice implementiert nur eine kleine real nutzbare Produktfunktion auf dieser Foundation.

Ergebnis des Foundation Audits

Kein grundlegender Widerspruch festgestellt

Die aktuellen Kernentscheidungen sind fachlich miteinander vereinbar:

• Originalquellen bleiben kanonische Referenzbasis.
• Kanshō besitzt die langfristige Dialog-, Erlebnis- und Reflexionsgeschichte; mindnet das langfristig integrierte persönliche Wissensnetz.
• Reflection Spaces sind lebendige Bedeutungs- und Kontextbereiche und keine bloßen Ablageordner.
• Reflection Space first / Long-Term Memory on demand begrenzt die aktive Kontextmenge.
• Provider State und Retrieval-Indizes sind Hilfs-/Optimierungsschichten und keine fachliche Source of Truth.
• AI Hypotheses, zeitgebundene Selbstaussagen und bestätigtes persönliches Wissen bleiben unterscheidbar.
• User Correction beeinflusst Current Validity, ohne historische Quellen zu verfälschen.
• Memory Write / Update ist signal-driven und soll nicht nach jedem Turn alle möglichen Objektarten analysieren.
• Ein wesentlicher generativer Hauptmodell-Call pro Turn bleibt der Normalfall.

Erkannte Status-Drift: 11 Intents

Frühere Abschnitte dieses Dokuments behandeln die elf Nutzungssituationen als nächsten Interviewblock beziehungsweise als unmittelbar weiter auszuarbeitende Konzeptsequenz.

Diese Arbeitssteuerung ist nicht mehr aktuell.

Die elf Nutzungssituationen bleiben fachlich nützliche Szenarien, sind aber kein Critical-Path-Gate für den Implementierungsstart und müssen nicht als elf technische Intent Engines realisiert werden.

Sie werden künftig primär betrachtet als:

• UX- und Nutzungsszenarien,
• Acceptance Cases,
• Test- und Validierungskatalog,
• mögliche spätere Spezialisierungen, falls reale Nutzung dies rechtfertigt.

Aktueller Critical Path

Vor dem Coding werden nur noch folgende Schritte als notwendig betrachtet:

1. implementierungsrelevanten Memory-/Continuity-Core abschließen,
2. kompakte implementation_foundation.md als Coding-Leitplanke festziehen,
3. Foundation-/Drift-Audit durchführen,
4. ersten vertikalen MVP Slice konkret spezifizieren,
5. Coding beginnen.

Der erste MVP Slice soll bewusst deutlich kleiner sein als das vollständige Kanshō-Zielmodell.

Aktuell bevorzugter Kandidat:

Journal / Daily Reflection als Day-One-artige Keimzelle auf Kanshō-Foundations

Die konkrete Nutzeranwendung, UX, In-/Out-of-Scope-Funktionen und Acceptance Criteria werden nach diesem Foundation-Abschluss separat spezifiziert.

Implementierungsprinzip

Nicht das Zielmodell vorbauen. Nur die Foundations vorbauen, deren späteres Nachrüsten teuer wäre; danach vertikal und nutzungsgetrieben iterieren.

Damit ist die ausführliche Konzeptarbeit weiterhin verbindliche Leitplanke gegen strukturelle Sackgassen, aber kein monolithisches Lastenheft für den ersten Coding-Schritt.