---
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