70 lines
3.0 KiB
Markdown
70 lines
3.0 KiB
Markdown
|
---
|
|||
|
|
title: "Kanshō – Admin- und Diagnoseansicht"
|
|||
|
|
version: "0.1"
|
|||
|
|
status: "Arbeitsstand"
|
|||
|
|
date: "2026-08-19"
|
|||
|
|
product_family: "Jinkendo"
|
|||
|
|
document_role: "Technical Chapter / Admin / Diagnostics"
|
|||
|
|
parent_document: "technische_zielarchitektur.md"
|
|||
|
|
---
|
|||
|
|
# Kanshō – Admin- und Diagnoseansicht
|
|||
|
|
|
|||
|
|
Kanonisches Home für die technische Admin-/Developer View. Fachlich entschieden: `../functional/fachliche_zielarchitektur.md` §2.7, `../functional/reflection_spaces.md`. UI, Berechtigungen im Detail und Rollenfeinheit sind offen.
|
|||
|
|
|
|||
|
|
## 1. Zweck
|
|||
|
|
|
|||
|
|
Die normale Oberfläche abstrahiert interne KI-Strukturen.
|
|||
|
|
|
|||
|
|
Für Entwicklung, Test, Qualitätssicherung und Administration existiert eine **getrennte Realm** (Mitai-Muster: `/admin/*`, `AdminShell`, `RequireAdmin`).
|
|||
|
|
|
|||
|
|
Reguläre Nutzer erhalten diese Ansicht nicht. Zugriff: Rolle `admin` (v0.1), API und UI gegated (`auth_identity_and_roles.md`).
|
|||
|
|
|
|||
|
|
## 2. Vorgesehene Diagnoseobjekte
|
|||
|
|
|
|||
|
|
Herkunft: Fachdoku, hier nur als zu inspizierende technische Objekte:
|
|||
|
|
|
|||
|
|
- Threads und Thread-Kandidaten
|
|||
|
|
- Reflection-Space-Zuordnungen
|
|||
|
|
- Konsolidierungsentscheidungen
|
|||
|
|
- Memory-Provenance, Confidence, Unsicherheit
|
|||
|
|
- Hypothesen vs. bestätigte Aussagen
|
|||
|
|
- Context-Builder-Ergebnisse und verwendete Quellen
|
|||
|
|
- Strukturänderungen
|
|||
|
|
- Privacy: Datenklasse, maskierte Entitätstypen, Provider, ZDR, Policy-Allow/Deny, Response-Validation – **ohne** vollständige Prompts und ohne Mapping als Default
|
|||
|
|
|
|||
|
|
Echte Mapping-Tabelle nur soweit eine besonders berechtigte Rolle es braucht (`guardrails.md` §17).
|
|||
|
|
|
|||
|
|
## 3. Was die Diagnose nicht ist
|
|||
|
|
|
|||
|
|
- kein zweites Nutzerprodukt
|
|||
|
|
- keine Aufgabenverwaltung
|
|||
|
|
- kein Bypass des Privacy Gateway „zum Debuggen in der Cloud“
|
|||
|
|
- keine Anzeige fremder Nutzerdialoge ohne explizites, später zu definierendes Betriebsmodell (Support). Default: Admin sieht Systemzustand und eigene Tests, nicht fremde Lived Experience.
|
|||
|
|
|
|||
|
|
## 4. Mitai-Übernahme
|
|||
|
|
|
|||
|
|
Übernehmen: getrennte Nav-Config (`adminNav.js`-Muster), Shell, `RequireAdmin`, Backend `require_admin`, Admin für Prompts/Workflows/Preview/Import-Export analog Mitai (`platform_extensibility.md`).
|
|||
|
|
|
|||
|
|
Nicht übernehmen: Mitai-Admin für Körpertarife, Coupons, Training Types als Kanshō-Kern. Feature-Admin nur als Muster, wenn Entitlements genutzt werden.
|
|||
|
|
|
|||
|
|
## 5. Entscheidungsstand
|
|||
|
|
|
|||
|
|
| Thema | Stand | Status |
|
|||
|
|
|---|---|---|
|
|||
|
|
| Diagnoseansicht erforderlich | ja | entschieden (fachlich) |
|
|||
|
|
| Getrennte Admin-Realm + API-Guard | ja | entschieden |
|
|||
|
|
| Rolle v0.1 | `admin` | entschieden |
|
|||
|
|
| Feineres Rollenmodell | Hauptadmin vs. Entwickler | offen |
|
|||
|
|
| Konkrete Screens und Felder | – | offen |
|
|||
|
|
|
|||
|
|
## 6. Offene Fragen
|
|||
|
|
|
|||
|
|
1. Darf ein Admin auf einer Shared Instance jemals fremde Dialoge sehen (Break-glass)?
|
|||
|
|
2. Welche Diagnose-Events werden persistiert vs. nur live berechnet?
|
|||
|
|
3. Wie werden Thread-Kandidaten dargestellt, ohne ein falsches „fertiges“ State Model zu suggerieren?
|
|||
|
|
|
|||
|
|
## 7. Querverweise
|
|||
|
|
|
|||
|
|
- `auth_identity_and_roles.md`, `privacy_gateway.md`, `frontend_pwa_shell.md`, `platform_extensibility.md`
|
|||
|
|
- Fachlich: `../functional/reflection_spaces.md` Admin-/Developer View
|