Dateien nach "docs/architecture/functional" hochladen

docs/architecture/functional/fachliche_zielarchitektur.md

@@ -1283,14 +1283,14 @@ Bereits entschieden:
 - 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.
+- Ein Reflection Space ist kein bloßer Ablageort, sondern eine laufend aktualisierte Sicht auf einen zusammenhängenden persönlichen Denk- und Erfahrungsraum.
+- Ein Reflection Space soll Orientierung, Fortsetzung, offene Fragen, Historie und Entwicklung unterstützen.
+- Der aktuelle Zustand eines Reflection Space muss auf zugrunde liegende Quellen zurückführbar sein.
 
-Noch zu klären sind auf fachlicher Ebene:
+Als Nächstes zu klären:
 
-1. Was ist aus Nutzersicht überhaupt ein Reflection Space?
+1. Welche Informationen müssen in der **aktuellen Sicht** eines Reflection Space zwingend enthalten sein?
-2. Wann ist ein eigener Space hilfreich und wann reicht ein Thread innerhalb eines vorhandenen Kontexts?
+2. Welche Informationen sollen nur bei Bedarf sichtbar werden?
-3. Wann sollte Kanshō eine neue Struktur vorschlagen?
+3. Welche Elemente sind immer menschlich lesbar und welche dürfen rein intern bleiben?
-4. Wann darf Kanshō ähnliche oder überholte Strukturen wieder konsolidieren?
+4. Wie stark soll die aktuelle Sicht verdichten, ohne relevante Nuancen zu verlieren?
-5. Welche Kontrolle benötigt der Nutzer über diese Entscheidungen?
+5. Wie werden widersprüchliche oder noch ungeklärte Erkenntnisse in dieser Sicht dargestellt?
-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

@@ -499,6 +499,49 @@ 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.
 
 
+
+## 8.7 Reflection Space als lebendiger Denk- und Erfahrungsraum
+
+Ein Reflection Space ist fachlich **kein bloßer Ablageort für Dialoge oder Tagebucheinträge**.
+
+Er bildet vielmehr eine laufend aktualisierte Sicht auf einen zusammenhängenden persönlichen Denk- und Erfahrungsraum.
+
+Ein Reflection Space kann dabei mehrere Elemente verbinden:
+
+- frühere und aktuelle Dialoge,
+- relevante Threads,
+- Tagebucheinträge,
+- offene Fragen,
+- bereits entstandene Erkenntnisse,
+- zeitliche Entwicklung,
+- Verbindungen zu anderen Reflection Spaces,
+- relevante Informationen aus mindnet,
+- bei Bedarf relevante Kontexte aus anderen Jinkendo-Anwendungen.
+
+Der Reflection Space soll dem Nutzer vor allem fünf Dinge ermöglichen:
+
+1. **Orientierung** – Worum geht es in diesem Raum aktuell?
+2. **Fortsetzung** – Wo kann die Reflexion sinnvoll weitergehen?
+3. **Offene Fragen** – Welche Themen oder Fragen sind noch nicht abgeschlossen?
+4. **Historie** – Welche Dialoge, Erlebnisse und Einträge haben den Raum geprägt?
+5. **Entwicklung** – Was hat sich über die Zeit in Wahrnehmung, Haltung oder Erkenntnis verändert?
+
+### Aktueller Zustand eines Reflection Space
+
+Jeder Reflection Space besitzt aus Nutzersicht einen aktuellen fachlichen Zustand.
+
+Dieser Zustand beschreibt nicht die vollständige Historie, sondern den derzeit relevanten Stand des Denk- und Erfahrungsraums.
+
+Wichtig:
+
+- Der aktuelle Zustand muss auf zugrunde liegende Reflexionen, Erinnerungen oder andere Quellen zurückführbar sein.
+- Er darf kein frei erfundenes KI-Summary sein.
+- Veränderungen des Zustands müssen nachvollziehbar aus neuen Dialogen, Erkenntnissen oder bestätigten Informationen hervorgehen.
+- Die vollständige Historie bleibt weiterhin zugänglich.
+- Interne technische Strukturen können deutlich umfangreicher sein als die sichtbare Zusammenfassung.
+
+Damit wird der Reflection Space zu einer **lebendigen, kontextuellen Sicht auf persönliche Entwicklung innerhalb eines bestimmten Zusammenhangs**.
+
 # 9. Dialogfäden
 
 Ein Gespräch kann mehrere Themen oder Reflexionsfäden enthalten.
@@ -1329,6 +1372,9 @@ Die folgenden Punkte sind bewusst noch nicht 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 |
+| Reflection Space | kein Ablageort, sondern lebendiger Denk- und Erfahrungsraum | entschieden |
+| Reflection-Space-Zustand | laufend aktualisierte, quellengebundene Sicht auf den aktuellen Stand | entschieden |
+| Kernnutzen eines Space | Orientierung, Fortsetzung, offene Fragen, Historie und Entwicklung | entschieden |
 | Produktname Kanshō | Arbeitstitel | offen |
 
 ---