Dateien nach "docs/architecture/functional" hochladen

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.

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 |
 
 ---