Kansho/docs/architecture/technical/admin_diagnostics.md

title	version	status	date	product_family	document_role	parent_document
Kanshō – Admin- und Diagnoseansicht	0.1	Arbeitsstand	2026-08-19	Jinkendo	Technical Chapter / Admin / Diagnostics	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.

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)

Status: Code vorhanden, Testphase. Nach jedem Dialogzug und nach Generate erhält die Admin-Rolle decision und trace in der API-Antwort. Die Journal- und Dialogseite zeigen Zweck, Prompt, Provider/Modell, Detect, maskierten Egress und Antworten. Dialogzug bleibt einstufig. Nach Journal-Generate zeigt die Testspur zwei Stufen (Rekonstruktion, Journalformulierung) plus trace.budget (geschätzte und tatsächliche Tokens, Kosten soweit geliefert, Fenster, Output-Reserve, Marge, Compression-Status, Abbruchgrund). Klasse-A-Mapping bleibt unsichtbar. Ohne Admin-Rolle fehlen diese Felder. Nicht persistiert, nicht für den Regelbetrieb gedacht. Volle Prompts bleiben Test-Einblick des aktuellen Responses, nicht Audit-Default und nicht globale Historie.

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