From cd2fb4c4ea338fe7479c2a7c937932ed0e6ea4c2 Mon Sep 17 00:00:00 2001 From: Lars Date: Tue, 18 Aug 2026 12:03:44 +0200 Subject: [PATCH] Dateien nach "docs/architecture/functional" hochladen --- .../functional/fachliche_zielarchitektur.md | 18 ++++---- .../produktvision_und_produktidentitaet.md | 46 +++++++++++++++++++ 2 files changed, 55 insertions(+), 9 deletions(-) diff --git a/docs/architecture/functional/fachliche_zielarchitektur.md b/docs/architecture/functional/fachliche_zielarchitektur.md index ad88d75..64668b1 100644 --- a/docs/architecture/functional/fachliche_zielarchitektur.md +++ b/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? -2. Wann ist ein eigener Space hilfreich und wann reicht ein Thread innerhalb eines vorhandenen Kontexts? -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. +1. Welche Informationen müssen in der **aktuellen Sicht** eines Reflection Space zwingend enthalten sein? +2. Welche Informationen sollen nur bei Bedarf sichtbar werden? +3. Welche Elemente sind immer menschlich lesbar und welche dürfen rein intern bleiben? +4. Wie stark soll die aktuelle Sicht verdichten, ohne relevante Nuancen zu verlieren? +5. Wie werden widersprüchliche oder noch ungeklärte Erkenntnisse in dieser Sicht dargestellt? diff --git a/docs/architecture/functional/produktvision_und_produktidentitaet.md b/docs/architecture/functional/produktvision_und_produktidentitaet.md index 582231e..2346630 100644 --- a/docs/architecture/functional/produktvision_und_produktidentitaet.md +++ b/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 | ---