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
|