272 lines
11 KiB
Markdown
272 lines
11 KiB
Markdown
---
|
||
title: "Kanshō – Fachliche Zielarchitektur und Interviewplan"
|
||
version: "0.1"
|
||
status: "Arbeitsstand"
|
||
date: "2026-08-18"
|
||
product_family: "Jinkendo"
|
||
document_role: "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`
|
||
|
||
> **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.
|
||
|
||
```text
|
||
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
|
||
```
|
||
|
||
Die unveränderten Quelldokumente vor der Aufteilung liegen im Verzeichnis `checkpoint_originals/`.
|
||
|
||
# 4. Interviewsteuerung
|
||
|
||
Der detaillierte Kapitelplan, die Interviewmethode, Definition of Done, Fortschrittsstatus und der nächste Interviewblock werden ab jetzt in `interview_plan.md` gepflegt.
|
||
|