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

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

**Additiv 2026-09-08:** Zwei Stufen mit je eigenem Modell. `GET /api/admin/providers/models` liefert den Katalog zur Auswahl (soft-fail). `remote_plaintext_reason` macht den Production-Übergang `KANSHO_ALLOW_REMOTE_DETECT` sichtbar, setzt ihn aber nicht.

**Additiv 2026-09-08 (LLM-Profile):** `GET/POST/PUT/DELETE /api/admin/llm-profiles`, `POST /api/admin/providers/{role}/activate`. Profile enthalten URL/Modell/ZDR, niemals Keys. LAN-Ollama (`192.168.2.144:11434`) ist lokal.

**Additiv 2026-09-08 (Detect-Lernmodus):** `PUT /api/admin/providers/detect-mode` mit `semantic` | `learning`. Statusfeld `detect_operating_mode`. Keine Wortlisten-Seite. Identitäten dürfen ein Badge „mehrdeutig“ aus Dialog-Sinnen zeigen. Dialog und Journal-Gespräch pausieren im Lernmodus mit Bestätigungs-Popup; Journal-Generate nicht.

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

**Additiv 2026-08-27:** Die Journal-Testspur zeigt ohne persistente Klartextdaten Modell, Prompt-Slug und Revision, Editorial Mode, Modelltext übernommen ja/nein, Antwort-Normalisierung, Provenienz, Abbruchgrund, Writing-Profile-Präsenz, Stilquellen nach Typ, budgetentfernte optionale Blöcke, lexikalische Ähnlichkeit und unvollständige Syntax als Diagnose sowie Tokens, Kosten und Laufzeit. Maskierung prüft den vollständigen gerenderten Egress. Ein verworfener Modelltext bleibt in der Admin-Antwort als maskierter Rohoutput sichtbar, wird aber nicht als erfolgreicher Entwurf geführt.

**Additiv 2026-08-27:** Die Journal-Testspur darf die vier Generation-Policy-Werte, die gewählten `variant_key`-Werte, die Konfigurationsrevision und den Editorial Mode zeigen (`generation_policy.values`, `generation_policy.stages`/`selection`, `config_revision`, Quelle, `remembered`). Das sind Ausgabeeinstellungen, keine Modelltemperatur. Kompilierte Anweisungstexte und Promptkörper werden dadurch nicht persistent gespeichert. Admin-Vorschau der Fragmente ist lokal und speichert keine Nutzertexte.

**Additiv 2026-08-27 (benannte Ausprägungen):** Die Testspur zeigt `generation_selection` mit IDs, Keys, Revisionen, automatischem Quellenmodus, Quelle `request`/`profile` und `remembered`. Keine 0–100-Werte. Der Entwurfssnapshot ist zusätzlich am Draft persistiert und im Editor als „Erzeugt mit …“ sichtbar. Admin-Übersicht rendert nicht alle Anweisungstexte gleichzeitig.

**Additiv 2026-08-27 (kein Quellenmodus in der Laufdiagnose):** Editorial Mode und automatischer Quellenmodus sind keine Laufentscheidung mehr. Die Testspur zeigt die vier Gestaltungsausprägungen, Prompt-Slug/-Revision und Modell. Veraltete Promptplatzhalter führen zu `prompt_contract_incompatible`.

**Additiv 2026-08-28 (Detect-Diagnose und gespeicherter Entwurf):** Die Testspur trennt technische Chunk-Verarbeitung, Anwendung der bestätigten Registry, semantische Treffer des aktuellen Requests, Detect-Modell und semantische Unsicherheit. `full_detection_coverage` darf nicht als vollständige Identitätserkennung gelesen werden. Nach Übernahme zeigt die Spur den gespeicherten Entwurf (`stored_title` / `stored_body` / `reply`); API, Draft und Trace müssen denselben Wortlaut haben. `generation_selection` zeigt die tatsächlich verwendete ID und Revision, nicht eine visuell benachbarte Ausprägung.

**Additiv 2026-08-29 (wirksame Stilanwendung):** Die Testspur zeigt `style_application` mit ID, Label, Revision, angeforderter Freigabe und tatsächlich gesendeten Stilblöcken (Core/Facet/Traits/Beispiele, Zeichen und geschätzte Tokens) sowie Auslassungsgründen inklusive Budget. Das beschreibt die Provider-Eingabe, nicht nur die Katalogkonfiguration.

**Additiv 2026-08-29:** `style_application` und der Snapshot nennen bei Nachfolgevarianten den Vorgänger (`cloned_from`).

## 4.3 Implementierungsstand (persistierte Debug-Testspur)

**Additiv 2026-08-28:** Die Live-Testspur unter dem Dialog ist entfernt. Persistenz unter `/admin/debug` (`GET/PUT /api/admin/debug`). Default aus. Ist der Schalter an, wird jeder Admin-Schritt (Dialogzug inkl. Opening, Journalentwurf, Profilreview) in `debug_runs` gespeichert und **Space / Tag / Gespräch / Schritt** zugeordnet (`GET /api/admin/debug/tree`). Mapping-Tabelle, `local_label` und Secrets gehören nicht in die Payload. Nicht-Admin-Profile werden nicht aufgezeichnet. Im Dialog selbst: Download der Gesprächs-JSON, solange Persistenz an ist (`GET /api/admin/debug/export?conversation_id=`). Am generierten Tagebucheintrag bleibt die Journal-Testspur sichtbar; Download `GET /api/admin/debug/export?purpose=journal_generate&journal_day_id=`, Nachladen `GET /api/admin/debug/latest`. Admin-Seite: Baum, Einzelschritt-Detail, Export JSON/Markdown. `kansho.debug_export` v2. Kein Gateway-Bypass, kein Provider-Upload, keine globale In-Memory-`debug_history`.

**Additiv 2026-08-29:** Persistierte Engine-Fehler führen `cost_report` (Detect-/Generate-Kosten, `billed`). Die Nutzer-Settings zeigen denselben Kostenstand bei fehlgeschlagener Profilanalyse; die Admin-Spur bleibt die Stelle für Compact-Trace ohne Mapping.

**Additiv 2026-08-29 (Detect-Abbruch der Journalgenerierung):** Ein vor dem Narrationsmodell abgebrochener Journal-Lauf wird bei aktiver Persistenz genau einmal als Fehlerlauf gespeichert (Purpose, Journal-Tag, Generierungsauswahl/Stilanwendung, Abbruchstufe, fachlicher Code, `generate_called: false`, Detect-Versuche). `debug_store.sanitize` bleibt bei zyklischen Containern begrenzt. Ein Persistenzfehler ersetzt den ursprünglichen `EngineError` nicht; die UI erhält den Detect-/Privacy-Code, nicht HTTP 500. Tests: `backend/tests/test_detect_contract_retry.py`.

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