From aa86b25ecda02c3b87bc1ce4ffb763d1b19f7e4c Mon Sep 17 00:00:00 2001 From: Lars Date: Tue, 18 Aug 2026 12:03:04 +0200 Subject: [PATCH] Dateien nach "docs/architecture/functional" hochladen --- .../functional/fachliche_zielarchitektur.md | 33 +++++++++++ .../produktvision_und_produktidentitaet.md | 57 +++++++++++++++++++ 2 files changed, 90 insertions(+) diff --git a/docs/architecture/functional/fachliche_zielarchitektur.md b/docs/architecture/functional/fachliche_zielarchitektur.md index 12d8f45..ad88d75 100644 --- a/docs/architecture/functional/fachliche_zielarchitektur.md +++ b/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: diff --git a/docs/architecture/functional/produktvision_und_produktidentitaet.md b/docs/architecture/functional/produktvision_und_produktidentitaet.md index b4c1df8..582231e 100644 --- a/docs/architecture/functional/produktvision_und_produktidentitaet.md +++ b/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 | ---