Kansho/docs/architecture/technical/admin_diagnostics.md

78 lines
3.6 KiB
Markdown
Raw Normal View History

---
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.
2026-08-25 13:57:23 +02:00
## 4.1 Implementierungsstand (Schnittstellen)
**Status: Code vorhanden.** Admin-Seite `/admin/providers` und `GET/PUT /api/admin/providers`. Zeigt URL, Modell, ZDR, No-Train, `ready` und `key_present` – niemals den Secret. Key-Schreiben aktualisiert nur `backend/.env`. Generate bleibt fail-closed ohne Key/ZDR/No-Train. Kein Gateway-Bypass.
## 4.2 Implementierungsstand (Dialog-Testspur)
**Additiv 2026-08-26:** Lokale Identitätsregistry unter `/admin/identities`. Detect-Vorschläge sind unbestätigt. Compact-Diagnose enthält Detect-Abdeckung, Chunks, Kosten und Laufzeit, aber keine Labels.
2026-08-25 13:57:23 +02:00
## 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