86 lines
5.3 KiB
Markdown
86 lines
5.3 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.
|
||
|
||
## 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.
|
||
|
||
**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`.
|
||
|
||
## 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
|