diff --git a/docs/architecture/functional/fachliche_zielarchitektur.md b/docs/architecture/functional/fachliche_zielarchitektur.md index b4fd332..12d8f45 100644 --- a/docs/architecture/functional/fachliche_zielarchitektur.md +++ b/docs/architecture/functional/fachliche_zielarchitektur.md @@ -117,6 +117,31 @@ Ausnahmen sind nur dann sinnvoll, wenn eine technische Grundentscheidung: 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. + # 3. Vorgeschlagene Repository-Struktur ```text @@ -230,7 +255,8 @@ kansho/ │ │ ├── 05_journal_ui.md │ │ ├── 06_reflection_history.md │ │ ├── 07_desktop_experience.md -│ │ └── 08_accessibility.md +│ │ ├── 08_accessibility.md +│ │ └── 09_admin_developer_view.md │ │ │ ├── 13_voice_and_media/ │ │ ├── 01_voice_interaction.md @@ -254,7 +280,8 @@ kansho/ │ │ ├── 04_memory_transparency.md │ │ ├── 05_export_delete_and_portability.md │ │ ├── 06_ai_safety_boundaries.md -│ │ └── 07_crisis_and_high_risk_scenarios.md +│ │ ├── 07_crisis_and_high_risk_scenarios.md +│ │ └── 08_roles_and_permissions.md │ │ │ ├── 16_product_delivery/ │ │ ├── 01_mvp_definition.md @@ -355,6 +382,8 @@ Das zentrale Kontextmodell definieren und klar zwischen dem thematischen Lebensk - Der Grad der KI-Autonomie bei Anlage und Konsolidierung soll konfigurierbar sein. - Der Nutzer muss falsche Strukturierungen korrigieren können. - Die konkrete technische Heuristik zur Bewertung von Relevanz, Wiederkehr, Tiefe oder Dauer wird in dieser Phase noch nicht festgelegt. +- Interne Struktur darf deutlich detaillierter sein als die sichtbare Nutzerstruktur. +- Für Entwicklung und Test muss diese interne Struktur in einer berechtigten Diagnoseansicht inspizierbar sein. **Leitfragen:** @@ -1213,17 +1242,22 @@ Der nächste konzeptionelle Block ist: # **Reflection Spaces – fachliche Mindestlogik** -Der nächste Interviewblock soll bewusst einfach bleiben. +Bereits entschieden: -Ziel ist nicht, bereits eine vollständige interne Taxonomie oder technische Automatik zu entwerfen, sondern nur die fachlichen Mindestfragen zu beantworten: +- Kanshō soll die interne Strukturierung weitgehend im Hintergrund übernehmen. +- Der Nutzer soll nicht zum Verwalter von Threads und Spaces werden. +- Die KI darf neue Strukturen erkennen, vorschlagen und abhängig vom konfigurierten Autonomiegrad selbständig anlegen oder konsolidieren. +- Die normale Oberfläche zeigt nur relevante und kuratierte Strukturen. +- Eine gesonderte Admin-/Developer View macht interne Strukturen für Entwicklung, Test und Administration sichtbar. +- Diese Diagnoseansicht ist rollenbeschränkt. + +Noch zu klären sind auf fachlicher Ebene: 1. Was ist aus Nutzersicht überhaupt ein Reflection Space? 2. Wann ist ein eigener Space hilfreich und wann reicht ein Thread innerhalb eines vorhandenen Kontexts? -3. Welche Räume soll der Nutzer sichtbar sehen können? -4. Welche Struktur darf rein intern bleiben? -5. Wann sollte Kanshō eine neue Struktur vorschlagen? -6. Wann darf Kanshō ähnliche oder überholte Strukturen wieder konsolidieren? -7. Welche Kontrolle benötigt der Nutzer über diese Entscheidungen? -8. Welche Autonomiestufen sollen konfigurierbar sein? +3. Wann sollte Kanshō eine neue Struktur vorschlagen? +4. Wann darf Kanshō ähnliche oder überholte Strukturen wieder konsolidieren? +5. Welche Kontrolle benötigt der Nutzer über diese Entscheidungen? +6. Welche Autonomiestufen sollen konfigurierbar sein? Erst wenn diese fachliche Mindestlogik steht, wird entschieden, ob überhaupt unterschiedliche interne Space-Typen oder komplexere Lifecycle-Modelle notwendig sind. diff --git a/docs/architecture/functional/produktvision_und_produktidentitaet.md b/docs/architecture/functional/produktvision_und_produktidentitaet.md index 8083f4f..b4c1df8 100644 --- a/docs/architecture/functional/produktvision_und_produktidentitaet.md +++ b/docs/architecture/functional/produktvision_und_produktidentitaet.md @@ -452,6 +452,53 @@ Technische Architekturentscheidungen werden im fachlichen Konzept nur dann vorge Die fachliche Konzeption soll bewusst vermeiden, aus jeder Produktidee frühzeitig ein komplexes technisches Subsystem abzuleiten. + +## 8.6 Sichtbare und interne Struktur + +Kanshō darf intern wesentlich mehr Struktur kennen und verwalten, als dem normalen Nutzer in der Oberfläche angezeigt wird. + +Für die reguläre Nutzung gilt: + +- nur relevante Reflection Spaces werden sichtbar hervorgehoben, +- offene oder bewusst markierte Themen können sichtbar angeboten werden, +- frühere Dialoge und Tagebucheinträge bleiben zugänglich, +- kleinere Threads, vorläufig erkannte Themen und interne semantische Beziehungen müssen nicht unmittelbar sichtbar sein. + +Damit soll verhindert werden, dass die Anwendung zu einem Struktur- oder Wissensverwaltungswerkzeug wird. + +### Admin-/Developer View + +Für Entwicklung, Test, Qualitätssicherung und spätere Administration soll es jedoch eine besondere Diagnose- und Transparenzansicht geben. + +Diese Ansicht kann – abhängig vom späteren Berechtigungsmodell – insbesondere sichtbar machen: + +- erkannte interne Threads, +- Zuordnung von Dialogen zu Reflection Spaces, +- vorläufige Space- oder Thread-Kandidaten, +- Herkunft und Provenance verwendeter Memories, +- Confidence beziehungsweise Unsicherheit interner Zuordnungen, +- erkannte Zusammenhänge und Hypothesen, +- Gründe für Vorschläge zur Trennung oder Konsolidierung, +- Konsolidierungskandidaten, +- Context-Builder-Auswahl für einen Dialog, +- verwendete relevante Erinnerungen und Wissensknoten, +- vorgeschlagene beziehungsweise durchgeführte Strukturänderungen. + +Diese Ansicht ist **nicht Teil der normalen Nutzeroberfläche**. + +Sie soll später nur Rollen mit entsprechender Berechtigung zugänglich sein, beispielsweise: + +- Hauptadmin, +- Systemadministrator, +- Entwickler/Testrolle. + +Die konkrete Rollenbezeichnung und technische Berechtigungsumsetzung werden später festgelegt. + +Wesentliche Anforderung: + +> Interne KI-Strukturen müssen für Entwicklung und Qualitätssicherung nachvollziehbar und inspizierbar sein, ohne die reguläre Nutzung mit dieser Komplexität zu belasten. + + # 9. Dialogfäden Ein Gespräch kann mehrere Themen oder Reflexionsfäden enthalten. @@ -1188,6 +1235,7 @@ Die folgenden Punkte sind bewusst noch nicht entschieden. 24. technische API- und Event-Integration. 25. Sicherheits- und Krisengrenzen. 26. Produktname und Branding. +27. Ausprägung der Admin-/Developer-Diagnoseansicht und konkretes Rollen-/Berechtigungsmodell. --- @@ -1221,6 +1269,9 @@ Die folgenden Punkte sind bewusst noch nicht entschieden. | Strukturierungsautonomie | KI erkennt, schlägt vor und kann abhängig von Konfiguration selbständig strukturieren/konsolidieren | entschieden | | Strukturpflege | Nutzer soll nicht zum Verwalter von Threads/Spaces werden | entschieden | | Fachlich vs. technisch | grundsätzlich getrennte Konzeptstränge; technische Vorentscheidungen nur bei wesentlichen Architekturzwängen | 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 | | Produktname Kanshō | Arbeitstitel | offen | ---