Dateien nach "docs/architecture/functional" hochladen

docs/architecture/functional/fachliche_zielarchitektur.md

@@ -142,6 +142,36 @@ 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.
+
 # 3. Vorgeschlagene Repository-Struktur
 
 ```text
@@ -1163,6 +1193,9 @@ Die Entscheidung wird anhand konkreter Situationen geprüft.
 
 Bewusst problematische oder widersprüchliche Situationen werden getestet.
 
+Zusätzlich wird bei strukturellen Vereinfachungen ein **Capability-Check** durchgeführt, damit keine bereits vorgesehenen Kernfähigkeiten unbeabsichtigt verloren gehen.
+
+
 ## Schritt 5 – Entscheidung
 
 Ergebnis wird klassifiziert als:

docs/architecture/functional/produktvision_und_produktidentitaet.md

@@ -1142,6 +1142,52 @@ Kanshō übernimmt kein Vital-, Ernährungs- oder Gesundheitstracking.
 
 ---
 
+
+## 20.1 Einfachheit an der Oberfläche, Intelligenz im Kern
+
+Ein zentrales Architektur- und Produktprinzip lautet:
+
+> **Kanshō soll für den Nutzer einfach wirken, ohne deshalb intern einfach sein zu müssen.**
+
+Die fachliche und technische Modellierung darf nicht allein mit dem Ziel reduziert werden, möglichst wenige interne Objekte, Zustände oder Beziehungen zu besitzen.
+
+Vereinfachung ist nur dann sinnvoll, wenn dadurch keine wesentlichen Fähigkeiten verloren gehen.
+
+Insbesondere muss die interne Architektur ausreichend differenziert bleiben, um langfristig folgende Anforderungen erfüllen zu können:
+
+- mehrere parallele und sich entwickelnde Dialogfäden,
+- langfristige Erinnerung über Monate und Jahre,
+- kontextabhängige Wiederaufnahme früherer Themen,
+- Reflection Spaces mit überlappenden Lebensbereichen und Rollen,
+- dynamische Bildung und Konsolidierung von Strukturen,
+- zeitliche Entwicklung von Erkenntnissen und Selbstbeschreibungen,
+- Unterscheidung zwischen Beobachtung, Interpretation, Hypothese und bestätigter Erkenntnis,
+- nachvollziehbare Provenance und Confidence,
+- ein versionierbares Self Model,
+- ein langfristig lernendes Writing Profile,
+- Reflection Frontiers und noch ungeklärte Zusammenhänge,
+- Integration von mindnet, Obsidian, Kairo, Mitai und Shinkan,
+- kontextabhängige Auswahl relevanter Informationen,
+- rollenbasierte Diagnose- und Transparenzansichten,
+- spätere Erweiterbarkeit ohne grundlegenden Umbau des Kernmodells.
+
+Die normale Benutzeroberfläche soll diese interne Differenzierung weitgehend abstrahieren.
+
+Damit gilt:
+
+**Komplexität darf unter der Motorhaube existieren, wenn sie fachlich notwendig ist.  
+Komplexität soll aber nicht ungefiltert an den Nutzer weitergereicht werden.**
+
+Eine interne Vereinfachung darf daher niemals ausschließlich mit dem Argument erfolgen, dass das zugrunde liegende Modell dadurch leichter implementierbar wird.
+
+Vor jeder wesentlichen Modellvereinfachung soll geprüft werden:
+
+1. Welche heutigen Fähigkeiten hängen von der betreffenden Struktur ab?
+2. Welche bereits vorgesehenen späteren Fähigkeiten würden dadurch erschwert oder unmöglich?
+3. Kann dieselbe Nutzervereinfachung auch durch UX, Automatisierung oder KI-gestützte Strukturierung erreicht werden?
+4. Ist die Entscheidung später ohne grundlegende Migration oder Redesign reversibel?
+
+
 # 21. Produktprinzipien
 
 Aus dem bisherigen Dialog lassen sich folgende Leitprinzipien ableiten.
@@ -1186,6 +1232,15 @@ Wichtige Inhalte sollen nicht ausschließlich in proprietären internen Datenstr
 
 Das System soll über Monate und Jahre eine nachvollziehbare persönliche Entwicklung unterstützen.
 
+## 21.11 Simple Experience, Rich Core
+
+Die Benutzererfahrung soll möglichst einfach, natürlich und wenig administrativ sein.
+
+Die interne fachliche und technische Architektur darf dagegen so differenziert sein, wie es zur Erfüllung der Produktvision notwendig ist.
+
+„Einfachheit“ ist primär ein UX-Ziel und kein Selbstzweck für die Kernarchitektur.
+
+
 ---
 
 # 22. Bewusste Nicht-Ziele
@@ -1272,6 +1327,8 @@ Die folgenden Punkte sind bewusst noch nicht entschieden.
 | Sichtbarkeit interner Struktur | normale Nutzer sehen nur relevante, kuratierte Strukturen | entschieden |
 | Admin-/Developer View | interne KI-Strukturen müssen für Test, Entwicklung und Administration inspizierbar sein | entschieden |
 | Zugriff Diagnoseansicht | nur für berechtigte Rollen, z. B. Hauptadmin / Entwickler | entschieden, Rollenmodell später zu spezifizieren |
+| Architekturprinzip | einfache UX bei maximal sinnvoller interner Intelligenz und Differenzierung | entschieden |
+| Vereinfachung | interne Modelle dürfen nicht so weit reduziert werden, dass bestehende oder geplante Kernfähigkeiten verloren gehen | entschieden |
 | Produktname Kanshō | Arbeitstitel | offen |
 
 ---