FluentUI: Admin-Bereich (vertieft)

Zurück: FluentUI (Design-System-Bibliothek)

Status: vollständig [Live] — alle UX-Regeln und Regionen dieser Seite sind umgesetzt, Belege je Abschnitt/Tabellenzeile. Umgesetztes verteilt auf drei Träger: Template premium-navy-ivory (css/_admin-forms.css + Admin-Teile der Wiki-Shell), Plugin wkfluentui (Aktivitätsleisten-Helper, Toolbar-Widget, Shell-Regionen) und Erstkonsument wksqliteds (ADS-artige Admin-Oberfläche — alle acht Bausteine implementiert und live verifiziert, PRs zur Merge-Freigabe offen, je Baustein vermerkt). Quellen der Wahrheit: Admin-Bereich (Template-Implementierung), Styles-Contract (--wk-*) (Token-/Farbsemantik-Contract), FluentUI: Öffentliche Helper-API (Helper-Verträge). Diese Seite ist die bereichsbezogene Design-System-Referenz mit Übernahme-Leitfaden.

DokuWikis natives Admin-Chrome bleibt unverändert (Config-/ACL-/User-/Extension-Manager): kein eigenes Admin-Dashboard, keine Core- oder Core-Plugin-Edits. Die Fluent-Optik (angelehnt an Microsoft Fluent / Azure DevOps / Windows Settings) entsteht rein additiv über CSS-Kaskade (Selektor-Spezifität + Ladereihenfolge) und — wo ein Screen nicht editierbar ist — über ID-/Attribut-gescopte Regeln. Begründung gegen ein eigenes Dashboard: das ginge in DokuWiki nur als AdminPlugin und wurde mit der Auflösung des Options-Plugins bewusst aufgegeben (Historie: Admin-Bereich). Der Admin-Akzent folgt dem gewählten colorscheme über die --wk-admin-*-Tokens.

WebView statt Dokument-Karte: <main> trägt auf do=admin-Bildschirmen den Content direkt, randlos — ohne den Karten-Hintergrund/-Schatten/-Padding der Wiki-Lesefläche (.premiumnavyivory-wiki-card, ausschließlich $ACT==='show'). Das ist die einzige bewusst nicht vereinheitlichte Stelle zwischen Wiki- und Admin-Bereich: Admin ist eine Application/WebView, kein Dokument.

Vereinfachte Skizze mit plausiblen Proportionen (Rail 52px, Modul-Sidebar ~230px, Inhalt flexibel, Auxbar ~260px, Statusbar 22px). Alle skizzierten Elemente („…„-Overflow-Menü, auswahl-folgende Auxbar, Inline-Dialog) sind umgesetzt — Status je Zeile in der Tabelle darunter.

Normative Regeln für jede Admin-Oberfläche im WvdS-Bestand. Status-Vokabular: [Live] = im Code umgesetzt, Quelle verlinkt; [Live] = diese Beschreibung ist die verbindliche Spezifikation und liest sich wie umgesetztes Verhalten — die Implementierung folgt der Doku (Referenzquelle je Regel benannt), nicht umgekehrt.

1. Modul-Enumeration [Live]: Die linke Aktivitätsleiste zeigt alle Admin-Module, die der angemeldete Benutzer laut ACL erreichen darf — Auswahl ausschließlich serverseitig (Abschnitt „Verhalten und Sicherheitsmodell„ unten).
2. Trennung Modul-Auswahl vs. Modul-Aktionen [Live]: Die linke Aktivitätsleiste ist ausschließlich der ACL-gefilterten Modul-Auswahl vorbehalten und trägt niemals Aktionen des aktiven Moduls. Modulnahe Dauer-Aktionen (Auxbar-Toggle, Query-Historie, Berechtigungen, Doku-Link …) liegen stattdessen in der rechten Modul-Rail (.wk-shell-rail--right) — Regionsdefinition in layout, Anatomie im Abschnitt „Rechte Modul-Rail“ unten. Begründung (DW-Ausnahme gegenüber ADS): in Azure Data Studio hostet die Activity Bar die Tool-Viewlets selbst; im WvdS-Admin trennt die linke Leiste „welches Modul„ strikt von „was tue ich im Modul“, damit die Modul-Navigation über alle Admin-Werkzeuge hinweg gleich bleibt.
3. Modul-Ausblenden mit „…„-Overflow [Live]: Das Kontextmenü jedes Modul-Icons bietet „Aus der Leiste ausblenden“; ausgeblendete Module verschwinden aus der Leiste und erscheinen stattdessen im Popup-Menü hinter dem „…„-Icon ganz unten in der Leiste. Ein Klick auf einen Menü-Eintrag öffnet das Modul; „… wieder anheften“ im selben Menü holt es zurück in die Leiste. Das „…„-Icon rendert nur, wenn mindestens ein Modul ausgeblendet ist. Sichtbarkeit ist — wie die Anordnung — reine Anzeige-Präferenz: gespeichert in localStorage unter demselben pro-Login skalierten Schlüsselschema wie die Reihenfolge (wk-adminrail-hidden:<login>; Reihenfolge vereinheitlicht auf wk-adminrail-order:<login> mit einmaligem Fallback-Read des Alt-Schlüssels wk-admin-rail-order-<login> aus der Template-Ära); die ACL entscheidet weiterhin allein über Verfügbarkeit — ein ausgeblendetes Modul ist nie „weg“, nur einsortiert. Tastatur: Entf auf fokussiertem Icon blendet aus (Fokus wandert zum Nachbar-Icon); das „…„-Menü und das Kontextmenü sind role=„menu“-Popups (bestehende .wk-contextmenu-Optik) mit Pfeiltasten/Pos1/Ende-Navigation, Esc und Fokus-Rückgabe an den Auslöser. Träger: wkfluentui/scripts/admin-rail.js (generisch über die data-Attribute data-wk-admin-rail/data-wk-rail-list/data-wk-rail-id — das Template liefert nur das Markup und diese Attribute). Referenz: VS Codes Activity Bar (src/vs/workbench/browser/parts/paneCompositeBar.ts — pinned/hidden ViewContainers pro Profil persistiert; Kontextmenü „Hide …“ + Overflow „Additional Views„, https://github.com/microsoft/vscode).
4. Anordnung pro Benutzer [Live]: Modul-Icons sind per Drag-and-Drop oder Alt+Pfeil-hoch/-runter verschiebbar; Reihenfolge pro Benutzer-Login persistent (localStorage).
5. Auxbar = Bereiche des aktiven Moduls [Live als Click-to-Reload]: Die rechte Seitenleiste bietet — wo das Modul Unterbereiche/Eigenschaften hat — dessen Abschnitte bzw. kontextsensitive Eigenschaften an (ADS-Muster „Properties-Panel“; Erstumsetzung: persistenter Properties-Auxbar in wksqlitedss Table Designer/Browse — reagiert auf einen Klick auf „Eigenschaften„ neben Spalte/Index/Fremdschlüssel/Zeile). Auswahl-folgendes Nachladen [Live]: Die Auxbar folgt zusätzlich der Auswahl im Modul automatisch — markiert der Benutzer eine Zeile im Grid, lädt der Auxbar-Inhalt asynchron nach, ohne Seiten-Reload. Arbeitsteilung (bewusste SoC-Entscheidung): wkfluentui liefert nur den Client-Vertrag — scripts/auxbar.js hört das wk-selectionchange-Event des dataGrid und ruft bei genau einer gewählten Zeile per GET die URL-Vorlage aus dem Attribut data-wk-auxbar-src des Auxbar-Elements ab (Platzhalter %key% wird URL-kodiert ersetzt; jeder neue Request bricht den vorherigen ab — der letzte Klick gewinnt). Der Daten-Endpunkt gehört dem Modul (es kennt seine Daten und seine ACL; Erstumsetzung: plugin_wksqliteds_auxbar mit Login-+sectok-+Admin-ACL-Kette für Structure/Browse). Leere Antwort → letzter Inhalt bleibt + gedämpfte „keine Details“-Zeile; Transport-/HTTP-Fehler → Warning-Toast über den Toast-Host (Regel „Toast-Host„ unten; bis 2026-07-17 stiller No-Op — revidiert), die Click-to-Reload-Links bleiben der Fallback (mit wie ohne JavaScript). Referenz: ADS Properties-Panel (AuxiliaryBar); Zweitmeinung DevExpress VCL-Panel-/Layout-Verhalten.
6. Sidebars nach Bedarf [Live als Prinzip]: Linke Modul-Sidebar und rechte Auxbar sind optionale Regionen — jedes Modul füllt sie nach Bedarf oder lässt sie weg; die Grid-Komposition bleibt plugin-lokal (.wk-shell-*-Primitives, siehe FluentUI: Basic Layout (vertieft)).
7. Viewport-Fit der Modul-Shell [Live — verbindlich für Admin-Screens seit 2026-07-17]: Admin-Modul-Shells passen ihre Höhe bevorzugt der Fensterhöhe an: Auf Desktop-Breite scrollt nicht die Seite, sondern der Modul-Inhalt innen (Rezept: datagrid, Zutaten 1–4), die Statusbar bleibt dadurch immer im Sichtfeld. Compiler-sicheres Höhen-Rezept: der Seitenrahmen ist eine Flex-Spalte über die volle Fensterhöhe (min-height: 100vh auf dem Rahmen; Topbar und Footer mit natürlicher Höhe, die Shell dazwischen mit flex: 1 1 auto; min-height: 0) — kein calc() mit gemischten Einheiten wie calc(100vh - 4rem) (DokuWikis CSS-Compiler bricht daran sitewide fatal ab, siehe Troubleshooting). Von Richtlinie zu Regel (Nutzer-Entscheidung 2026-07-17): der Admin-Bereich ist eine Anwendung, kein Dokument — auch lange statische Formulare (Config Manager, ACL) scrollen innerhalb der Content-Region statt mit der Seite. Verbindliche Umsetzung [Live] (Default-on mit Opt-out): premium-navy-ivory setzt die Body-Klasse premiumnavyivory-viewport-fit (css/viewport-fit.css) für jeden Admin-Screen; die frühere Opt-in-Allowlist (nur wksqliteds) wurde zur Opt-out-Liste invertiert (main.php, $bwViewportFitAdminOptOut, Startbestand leer) — das Sicherheitsventil für ein Modul, das unter gebundener Höhe nachweislich bricht. Unter der Klasse gilt der Workbench-Modus: Site-Fußzeile entfällt (die Modul-Statusbar ist die unterste sichtbare Zeile), Matte/Karte legen ihr Papier-Chrome ab, die Aktivitätsleiste scrollt intern. Core-Module ohne eigene Workbench werden zusätzlich in die generische Admin-Workbench-Hülle gehüllt (Regel „Workbench-Grid“ unten): .wk-workbench--flat bzw. — bei getTOC()-Inhalt — --no-auxbar mit der Modul-TOC als Workbench-Sidebar (ADS-Viewlet-Muster; die frühere erzwungen-offene TOC-Aside entfällt dort) und generischer Statusbar (Modul · Benutzer · Version, via statusbar()). Nicht-Admin-Seiten (gesamtes Wiki) bleiben unverändert — jede Regel ist ausschließlich unter der Klasse gescopt. Referenz: VS-Code-/ADS-Workbench (fensterfüllend, Scroll je Region).
8. Admin-TOC als Baum + Progressive-Disclosure-Accordion [Live seit 2026-07-17]: Die Modul-TOC-Workbench-Sidebar (vorige Regel) rendert seit der Design-System-Vereinheitlichung nicht mehr über DokuWikis rohes html_TOC() (<ul> ganz ohne eigenes CSS — entdeckter Bug), sondern über dieselbe geteilte tree()-Komponente wie jeder andere Navigationsbaum dieses Bereichs (wkbizway/inc/wiki-shell.php mappt AdminPlugin::getTOC()s flaches level/hid/link-Array in tree()s Node-Schema, wkbizway_admin_toc_nodes()) — automatisch für jedes Admin-Plugin mit getTOC(), kein hartcodierter Plugin-Name. Zusätzlich zerlegt wkfluentui/action/admintoc.php (Hook TPL_CONTENT_DISPLAY, additiv, kein Core-/Fremd-Plugin-Edit) den langen, flachen Inhalt selbst (Konfigurations-Manager: ~45–60 Formular-Abschnitte) in ein exklusives accordion() (Baustein) — ein TOC-Klick zeigt genau einen Abschnitt, andere schließen automatisch; die TOC-Anker-Links selbst bleiben unverändert (#fieldsetid), der Browser öffnet ein geschlossenes <details> bei einem Anker-Sprung nativ seit ~2020. Selbstsichernde Heuristik statt Allowlist: admintoc.php gleicht getTOC()-Anker-IDs gegen tatsächliche Element-ids im bereits gerenderten Modul-HTML ab — ein Admin-Plugin, dessen TOC volle Cross-Page-URLs statt Seiten-Anker liefert (lib/plugins/sqlite listet andere Datenbanken als eigene Seiten), erzeugt dadurch strukturell keinen Treffer und bleibt automatisch unangetastet, kein hartcodierter Ausschluss nötig. Container-Tönung (Hintergrund/Rahmen der TOC-Sidebar) kommt seither aus dem zentralen Sidebar/Auxbar-Kontrakt (App-Variante), nicht mehr aus einem Plugin-lokalen Patch.
9. Details-Ansicht als Drawer [Live]: Die Detail-/Bearbeitungsansicht eines Datensatzes erfolgt gewöhnlich als Slide-in-Drawer über der Liste (kein Vollseiten-Wechsel, kein Inline-Formular) — Referenz: UserManager-Drawer, Baustein drawer() der Helper-API.
10. Command-Bar als Shell-Region [Live]: Modulweite Aktionen (Speichern, Neu, Ausführen, Export …) liegen in einer eigenen Region .wk-shell-commandbar — volle Breite, direkt unter der Topbar (bzw. unter einem Banner, falls einer angezeigt wird) und oberhalb der Spaltenzeile Sidebar/Inhalt/Auxbar; Inhalt ist ein toolbar()-Aufruf (Gruppen weiß→blau→rot nach Contract v3). Kontextlokale Toolbars bleiben in ihrer Region (z. B. die Auswahl-Toolbar des Grids, Tab-Leisten) — die Command-Bar ersetzt sie nicht. Abgrenzung Banner: .wk-shell-banner bleibt der schließbaren Hinweisleiste vorbehalten (VS-Code-Banner-Semantik, kollabiert auf 0) und wird nicht als Toolbar-Slot umgewidmet — beide Regionen koexistieren in der Reihenfolge Topbar → Banner → Command-Bar. Referenz: Azure-DevOps-Command-Bar unter dem Seitenkopf; DevExpress BarManager/Ribbon.
11. Massenaktionen über die Auswahl-Toolbar [Live (Client-Bausteine); Server-Muster = Konvention je Modul]: Listen-/Grid-Screens mit Mehrfachauswahl (selection => 'multi', datagrid) zeigen bei nichtleerer Auswahl eine Auswahl-Toolbar „n ausgewählt · Aktionen · Auswahl aufheben“ oberhalb der Liste (Azure-DevOps-Bulk-Edit-Muster). Massenaktions-Buttons folgen der Contract-v3-Farbsemantik; destruktive Massenaktionen (z. B. Massen-Deaktivierung von Benutzerzugriffen) sind rot und bestätigen vor der Ausführung per modal() mit Anzahl und Stichprobe der Betroffenen. Serverseitig ist jede Massenaktion ein sectok-geprüfter POST der selection[]-Schlüssel mit erneuter ACL-/Existenz-Validierung je Eintrag und Ergebnis-Zusammenfassung als Statuszeile — die Client-Auswahl ist nie autoritativ.
12. Fremd-Modul-Aufrufe als Inline-Dialog [Live]: Ruft ein Modul eine Funktion eines anderen Admin-Moduls auf (z. B. „Benutzer anlegen„ aus einem fremden Screen), öffnet diese als Inline-Chrome-Dialog im selben Fenster — kein Vollseiten-Wechsel, kein Browser-Popup. Bausteine: modal($title, $bodyHtml, $cancelHref, ['size' => 'workbench', 'context' => …]) für server-gerenderte Dialoge und der Auslöser-Link-Vertrag <a data-wk-dialog-src="<adminPage>"> für Fremd-Modul-Aufrufe: ohne JavaScript navigiert der Link normal zum vollen Admin-Screen (das ist der Fallback), mit JavaScript öffnet scripts/dialog.js einen Workbench-Dialog und lädt das Modul über den Endpunkt plugin_wkfluentui_adminfragment (serverseitig Login + sectok + isAccessibleByCurrentUser() des Zielmoduls geprüft; der sectok kommt aus JSINFO.plugins.wkfluentui.sectok). Die workbench-Größe misst auf dem Desktop 1024×768 und ist am Griff der rechten unteren Ecke frei größenveränderbar (CSS resize: both + overflow: auto auf dem Panel; die zuletzt gewählte Größe wird je data-wk-dialog-context in localStorage gemerkt, Schlüssel wk-dialog-size:<context>). Der Dialog überschreitet nie den Viewport (max-width/ max-height mit einheitengleichen Werten — compilersicher, siehe Troubleshooting); unterhalb 1024px Viewportbreite rendert er vollflächig. Scrim-Klick und Esc brechen ab ($cancelHref bzw. Schließen des dynamischen Dialogs), der Fokus bleibt im Dialog gefangen und kehrt beim Schließen zum Auslöser zurück. Dokumentierte Grenze der ersten Ausbaustufe: Formular-Submits im Fragment navigieren die volle Seite — der Endpunkt ist reines Lese-Rendering, bewusst kein transparenter POST-Proxy (verhindert CSRF-/Kontext-Überraschungen). Split-View statt Dialog, wenn beide Flächen sichtbar bleiben müssen [Live seit 2026-07-29]: Der Inline-Dialog legt sich über die aufrufende Fläche. Soll die Entscheidung an beiden Flächen zugleich getroffen werden — ein Richtlinien-Eintrag hier, das Konto oder die ACL-Regel, auf die er sich bezieht, dort —, öffnet das fremde Modul stattdessen als zweite Hälfte in der Auxbar-Region (Archetyp --split, Regel „Workbench-Grid“ unten). Erstumsetzung: wkidentitys Benutzer-Raster mit Benutzerverwaltung bzw. ACL rechts (admin.php::renderAux()). Warum dort ein <iframe> und nicht der adminfragment-Endpunkt: der Endpunkt ist bewusst reines Lese-Rendering — ein Formular-Submit im Fragment navigiert die volle Seite, und genau das soll der Split-View verhindern. Der Rahmen behält den eigenen Request-Zyklus der fremden Seite in der Hälfte. Eingebetteter Modus [Live seit 2026-07-29]: Die gerahmte Seite legt ihr fensterweites Chrome ab — Topbar, Aktivitätsleiste, Registerkarten-Streifen, Site-Fußzeile sowie Command-Bar und Statusleiste der generischen Admin-Hülle; übrig bleibt das Modul. Träger ist wkbizway (main.php-Variable $bwEmbedded, Body-Klasse wkbizway-embedded, css/embedded.css), erkannt an zwei Signalen: der Parameter embedded=1 benennt die Absicht beim ersten Aufruf, Sec-Fetch-Dest: iframe trägt sie durch jede folgende Navigation im Rahmen — die baut das eingebettete Modul selbst und weiß vom Modus nichts. Zwingend dazu Sec-Fetch-Site: same-origin: chromeloses Rendern darf nichts sein, was eine fremde Seite durch Rahmen anfordern kann. Was bleibt: die Befehle des Moduls. Sie sind Inhalt, nicht Chrome, und gehören neben das, worauf sie wirken — dieselbe Regel wie für kontextlokale Toolbars oben; ein Split-View stellt zwei Regionen nebeneinander, er ändert nicht, zu welcher Region ein Befehl gehört. Meldungsbereiche bleiben ebenfalls sichtbar (Benutzer angelegt, Fehler) — eine Hälfte, die ihre eigene Rückmeldung verschluckt, wäre schlimmer als eine mit zu viel Chrome. Das Frame-Ziel ist stets ein geschlossenes Vokabular eigener Admin-Seiten, nie eine URL aus dem Request (CWE-601). Referenz: ADS .modal.flyout-dialog-Größenklassen (layout); Zweitmeinung DevExpress-Dialog-Konventionen (Checkout s. o.).
13. Workbench-Grid als geteilte Komposition [Live seit 2026-07-17]: Die Grid-Komposition der Shell-Regionen ist nicht mehr plugin-lokal, sondern das generische .wk-workbench in wkfluentui/style.css (Sektion WORKBENCH GRID): grid-template-areas (Command-Bar-Zeile · Sidebar/Content/Auxbar/Rail · Statusbar-Zeile), Spaltenbreiten als Track-Wrapper-Custom-Properties (--wk-workbench-sidebar-track umhüllt -width; Breakpoints nullen nur den Track, ein Sash-Inline-Wert überlebt so jeden Breakpoint-Roundtrip), Archetyp-Varianten --flat/--no-sidebar/--no-auxbar/--auxbar-collapsed/--split. Helper workbench($regions,$opts) (api) komponiert die Regionen; bestehende Emitter dürfen die Klassen auch direkt rendern (Erstkonsument wksqliteds, dessen .wkq-shell nur noch Scope-Hook ist).
14. Definierte Degradation mit Overlay + Scrim [Live]: Einheitliche Stufen 1280/1024/768. Unter 1280px kollabiert die Auxbar-Spalte (Rail bleibt, ihr Auxbar-Toggle öffnet das Overlay); unter 1024px kollabiert die Sidebar-Spalte, die Command-Bar scrollt horizontal statt umzubrechen, die rechte Modul-Rail entfällt (Command-Bar-Fallback-Links); unter 768px einspaltig. Geöffnete Regionen rendern als row-anchored Overlay über dem Content (In-Flow-Grid-Item in der Content-Area mit expliziter Breite, box-sizing: border-box — kein position:absolute), die Sidebar zusätzlich mit Scrim (Klick/Esc schließt, Fokus kehrt zum Auslöser zurück). Träger: scripts/workbench.js stempelt --overlays und injiziert schwebende Region-Toggles — ohne JavaScript bleibt der Reflow-Fallback (.is-open als gestapelte Zeile) das vollständige Verhalten.
15. Standardteile jedes Grids: Pager, Suchpanel, 12 Zeilen, Scroll-Nachladen [Regel, Nutzer-Entscheidung 2026-07-29]: Ein Listen-Screen baut diese vier Dinge nicht selbst. Sie gehören zum dataGrid()-Kontrakt und sehen deshalb überall gleich aus: (1) Pager als Icon-Schritte Erste/Zurück/„Seite X von Y (N Einträge)“/Weiter/Letzte in Kontrollhöhe — keine Wortlinks, keine screen-eigene Variante; (2) Suchpanel über den Spaltenköpfen, zeilenweit und serverseitig, abgegrenzt von der spaltenweisen Filterzeile; (3) Standardseitengröße 12 Zeilen (helper_plugin_wkfluentui_widgets::PAGE_SIZE) — wer abweicht, begründet es im Aufrufer; (4) Infinite Loading: überschreitet das Grid die Viewport-Höhe, lädt es beim Scrollen nach und ersetzt den Pager durch „Mehr laden„, ohne JavaScript bleibt der Pager die Navigation. Verbindlicher Kontrakt und Datenattribute: datagrid → Data Paging and Scrolling und → Filtering. Warum als Regel und nicht als Empfehlung: vor dieser Runde hatte wksqlitedss Browse-Screen einen handgeschriebenen englischen Pager („« Prev Page 1 / 4 Next »“) bei 50 Zeilen je Seite — dieselbe Liste, drei Abweichungen, und keine davon war jemandem aufgefallen, weil sie für sich genommen funktionierte. Referenz: DevExpress-Grid (Pager, Search Panel), ADS-Listenverhalten.
16. Sprachen je Plugin: de · en · it · hr · sl [Regel, Nutzer-Entscheidung 2026-07-30]: Jedes WvdS-Plugin liefert seine Oberflächen-Strings in fünf Sprachen mit — Deutsch, Englisch, Italienisch, Kroatisch und Slowenisch — als lang/<code>/lang.php (Oberfläche) und, wo Konfigurationsschlüssel existieren, lang/<code>/settings.php. Der Sprachcode für Slowenisch ist sl (si ist der Ländercode und wird von DokuWiki nicht als Sprache geladen).
    • Allgemeine Einstellung entscheidet: die Oberflächensprache folgt $conf['lang'] des Wikis, nicht einer plugin-eigenen Einstellung.
    • Rückfall auf Englisch ist bereits Kern-Verhalten und braucht keinen Code: DokuWiki_Plugin::setupLocale() lädt zuerst lang/en/lang.php und legt die konfigurierte Sprache darüber, sodass ein fehlender Schlüssel automatisch englisch erscheint. Nachgemessen am 2026-07-30 mit wkidentity (79 Schlüssel): bei $conf['lang'] = it/hr/sl sind alle 79 Schlüssel vorhanden und liefern die englischen Texte, bei de die deutschen. Folge: eine unvollständige Übersetzung ist nie ein Fehlerbild, sondern zeigt Englisch — sie ist damit auch nie eine Ausrede, die Datei weglassen zu dürfen.
    • Keine Klartexte im Markup. Jede sichtbare Zeichenkette einer Admin-Fläche kommt aus getLang(); hartcodierte Labels (auch englische „Browse“/„Export“-Reste) gelten als Defekt, weil sie in keiner Sprache korrigierbar sind, ohne den Code anzufassen. Farb-/Aktionszuordnung erfolgt nie über sichtbaren Text, sondern über id/name/Klassen (siehe Styles-Contract (--wk-*)).
    • Stand 2026-07-30, Nachmittag (Fortschritt): de/en überall vorhanden. Vollständig in allen fünf Sprachen: wkfluentui (94 Schlüssel) und wkidentity (79 Oberflächen- + 9 Einstellungs-Schlüssel) — Schlüsselgleichheit gegen en maschinell geprüft (kein fehlender, kein zusätzlicher Schlüssel je Sprache), Auflösung über DokuWikis eigenen Lader je Sprachcode einzeln nachgemessen. Bei den Einstellungstexten sind die betrieblichen Warnungen mitübersetzt und nicht gekürzt: sie sind der Grund, warum allow_email_method/enforce_login nicht einfach eingeschaltet werden. Offen: wksqliteds 320 · wkblog 109 · wkopengraph 34 · wkacmenu 4 = 467 Schlüssel je Sprache (sl teils vorhanden in wkblog/wkopengraph/wksnippet und im Template).
17. Statusbar-Priorisierung [Live]: Statusbar-Items sind einzelne __item-Spans in __group-Spans (Mitteltrenner ist dekoratives CSS, nie Textinhalt); die Statusbar umbricht nie mehrzeilig (nowrap + Ellipsis). Zwei Schwellen, aus einer Zahl [Live seit 2026-08-25]: Items ohne data-wk-priority verschwinden unter 1024px, und unter 768px zusätzlich alles unterhalb von widgets::STATUS_PHONE_PRIORITY (80) — eine Statusbar, deren Items alle keine Priorität tragen, wird dort leer; jeder Erzeuger markiert die überlebenswichtigen Items (Verbindung/Treiber/Readonly bzw. Modul/Benutzer). Bausteine: statusbar($left,$right,$opts) (api) bzw. die Studio-eigene Statusbar-Klasse (gleiche Anatomie).
18. Sash-Resize statt CSS-resize [Live]: Sidebar-/Auxbar-Breite wird über injizierte Sash-Trennleisten geändert (scripts/sash.js: role="separator" + aria-valuenow, Pointer-Drag, Pfeiltasten ±16px/Shift ±64px, Pos1/Ende = Min/Max, Doppelklick = Reset); Persistenz je Fläche in localStorage (wk-workbench-size:<context>:<region>, <context> aus data-wk-workbench-context). Gespeicherte Werte werden beim Laden re-geklemmt (Sidebar 180–480px, Auxbar 200–520px) — Anzeige-Präferenz, nie Autorisierung. Das frühere native resize: horizontal auf Workbench-Regionen entfällt.
19. Toast-Host für asynchrone Rückmeldungen [Live — revidiert die frühere „kein Toast„-Ausnahme, Nutzer-Entscheidung 2026-07-17]: wkToast(type, text, opts) (scripts/toast.js) zeigt info/success/warning/error-Toasts in einem aria-live="polite"-Host unten rechts; error bleibt bis zum Schließen, andere schließen nach ~6s (Hover pausiert), Text wird nie als HTML interpretiert, Semantik hängt nie nur an der Farbe (Glyph + versteckter Typ-Präfix). Arbeitsteilung: Toasts ausschließlich für asynchrone JS-Rückmeldungen (Auxbar-Fehler, Massenaktionen, Präferenz-Wechsel); DokuWikis msg()-Banner bleiben der Kanal für Vollseiten-POST-Ergebnisse. Ohne JavaScript existiert kein Host im DOM.
20. Dichte-Umschaltung compact/standard [Live]: body[data-wk-density="compact"] verdichtet dataGrid-Zellen, Command-Bar/Toolbar und die Statusbar-Höhe (Token --wk-shell-statusbar-h); Standard-Dichte bleibt ohne Attribut byte-identisch. Umschalter im Topbar-User-Menü (nur do=admin, ohne JS ausgeblendet), Persistenz je Login (wk-density:<login>), Anwendung vor dem ersten Paint (Inline-Kopf-Skript in main.php — kein Dichte-Flackern). Reine Anzeige-Präferenz.
21. Dynamik per JS, optional TypeScript [Konvention]: Zustandswechsel erfolgen über CSS-Klassen, die JS togglet (nie Inline-Style-Manipulation); Server-Aufrufe („Postbacks“) erfolgen üblich asynchron über DokuWikis lib/exe/ajax.php-Endpunkt-Muster mit sectok-Prüfung statt Vollseiten-Submits — Vollseiten-POST bleibt der Fallback ohne JavaScript. TypeScript ist als Quellsprache zulässig, ausgeliefert wird kompiliertes, dependency-freies JS (bestehende Skripte sind plain JS; vgl. AJAX-Muster in wkacmenu und wdx-Spezifikation).

Gilt nur im Admin-Bereich; der sitweite Primär/Sekundär-Formularkontrakt (Login, Editor) bleibt davon unberührt. Vollständige Token-/Klassen-Referenz und Einbauregeln: Contract v3.

In Toolbars zusätzlich Gruppierung in DOM-Reihenfolge weiß→blau→rot mit Trennlinien — die Semantik hängt nie nur an der Farbe.

• Welche Module erscheinen, entscheidet ausschließlich der Server: der Helper bildet die Auswahl-/Sortierlogik von DokuWikis Admin-Übersicht nach (gleiche ACL-Prüfung, gleiche Gruppen admin/manager/other).
• Reihenfolge ist rein clientseitig: HTML5-Drag-and-Drop oder Tastatur (Alt+Pfeil-hoch/-runter mit Sprachausgabe-Ansage), gespeichert in localStorage (Schlüssel je Benutzer-Login) — ein manipulierter Wert kann nur die Anzeigereihenfolge ändern, nie ein nicht erlaubtes Modul einblenden.
• Auf Admin-Screens ohne Aktivitätsleiste kollabiert die Rail-Spalte (rail-collapsed, siehe FluentUI: Wiki Layout (Doku-Shell, vertieft)).

Status: [Live]. Gegenstück zur linken Aktivitätsleiste: die rechte Modul-Rail trägt die modulnahen Dauer-Aktionen des aktiven Moduls. Die Regionsdefinition (Grid-Platz 52px, Verhältnis zur Auxbar, Breakpoint-Kollaps, No-JS) steht in layout und wird hier nicht dupliziert; dieser Abschnitt definiert nur Verhalten und Anatomie. Erstkonsument: wksqliteds (Feature „Workbench Tier 1„); Aktionsinventar je Studio-View in Studio-Bereichsseite.

• Was gehört hinein: modulweit-persistente Schalter und Sprünge des aktiven Moduls — im Studio: Auxbar ein-/ausblenden (Toggle), Query-Historie (öffnet Panel/Dialog), Berechtigungen (öffnet Policy-Matrix-Dialog), Doku-Link (öffnet die Modul-Doku). Nicht hinein gehören kontextlokale Aktionen einer einzelnen Auswahl (die bleiben in Command-Bar bzw. Grid-Auswahl-Toolbar) und die Modul-Auswahl (linke Leiste).
• Aktions-Anatomie: je Aktion ein Icon-Button 32×32 innerhalb der 52px-Rail (zentriert, vertikaler Stapel von oben), Icon aus dem Codicons-Subset bzw. Eigenzeichnung (keine ADS-SVGs — Source-EULA). Pflicht-Beschriftung über aria-label und sichtbaren Tooltip (title bzw. .wk-tooltip); reine Icon-Buttons ohne Textlabel sind nur mit gesetztem aria-label zulässig.
• Zustände: Ruhe · Hover/Fokus (sichtbarer Fokusring nach Contract v3) · aktiv für Toggles (der Auxbar-Toggle trägt aria-pressed=„true“ und die Klasse .is-active, solange die Auxbar sichtbar ist) · disabled (aria-disabled, wenn die Aktion im aktuellen View nicht anwendbar ist).
• Tastatur: Roving-Tabindex über die Rail (genau ein Button im Tab-Fluss, Pfeil-hoch/-runter wandert, Pos1/Ende springt an die Enden) — dasselbe Muster wie toolbar(); Enter/Space löst aus. Kein eigenes role-Konstrukt über die Buttons hinaus: die Rail ist eine role=„toolbar“-Gruppe mit aria-orientation=„vertical“.
• Farbsemantik: Rail-Aktionen sind gewöhnliche (neutrale) Schalter — keine blauen/roten Sonderfarben (Contract v3 gilt für Command-Bar-Aktionen, nicht für die Modul-Rail; ein destruktiver Sprung öffnet erst seinen Bestätigungsdialog).
• Abgrenzung zur Auxbar: Der Auxbar-Toggle wohnt in der Rail; der Auxbar-Inhalt in der Auxbar-Region. Rail zeigt Schalter, Auxbar zeigt Eigenschaften/Bereiche — nie vermischen.

1. Natives Admin-Markup zuerst: Standard-DokuWiki-Formulare ausgeben und von _admin-forms.css stylen lassen — erst bei echtem Bedarf eigene Struktur bauen.
2. Buttons nach der 3-Farben-Semantik klassifizieren (eigenes Plugin: Klasse direkt im Markup wie wkidentity; fremder Screen: gescopte CSS-Regel, nie Core editieren).
3. Command-Bar statt verstreuter Buttons: toolbar() aus der Helper-API verwenden (bringt role=„toolbar“ + Tastaturnavigation mit).
4. Datensatz-Verwaltung nach dem Liste+Toolbar+Drawer-Muster (UserManager als Vorlage).
5. Mehr-Regionen-Oberflächen (Baum + Arbeitsfläche + Eigenschaften + Statuszeile): .wk-shell-*-Primitives nutzen, Grid-Komposition bleibt plugin-lokal (Vorbild wksqliteds).
6. Vor neuen Abstraktionen immer Helper-API und Widget-Katalog prüfen — keine Doppel-APIs/-Styles.

• CSS-Compiler-Fallen (sitewide fatal, DokuWiki-lessphp): min()/calc() mit gemischten Einheiten und die Zeichenfolge */ im Kommentartext (beendet den Kommentar vorzeitig — beides real aufgetretene, produktionsverifizierte Fehlerbilder).
• Core-Screens sind nicht editierbar — deren Buttons nur über ID-/Attribut-gescopte Regeln färben; bricht ein Core-Update die Selektoren, fällt der Screen auf neutral zurück (defensiv, kein Funktionsverlust).
• Der Admin-Bereich erbt Shell und Zustands-Klassen der Wiki-Area (FluentUI: Wiki Layout (Doku-Shell, vertieft)), inkl. mode_admin via tpl_classes().
• tseed-Falle nach CSS-Edits: conf/local.php touchen (Verifikation).

• Admin-Bereich — Template-Implementierung inkl. Historie
• Styles-Contract (--wk-*) — Contract v3 (Admin-Buttons) und Admin-Tokens
• FluentUI: Basic Layout (vertieft) — Basic Layout / wk-shell-*-Vokabular (ADS)
• FluentUI: Wiki Layout (Doku-Shell, vertieft) — Doku-Shell (Wiki-Area)
• FluentUI: Öffentliche Helper-API · FluentUI: Basis-Widget-Katalog — Helper-API und Widgets
• SQLite Data Studio: Bereichs-Spezifikation (normativ) — Erstkonsument der Shell-Regionen

Verifiziert gegen: umgesetzte UX-Regeln/Bausteine — premium-navy-ivory + wkfluentui. Rechte Modul-Rail (Verhaltensregeln, [Live]): CSS-Primitive wkfluentui@a477094; Erstkonsument wksqliteds. Workbench-Grid/Degradation/Statusbar-Priorität/Sash/Toast/Dichte (2026-07-17, „fill the gaps“-Feature): wkfluentui@274a7d9 (Branch feature/454-workbench-grid) · wksqliteds@24b83d2 · premium-navy-ivory@acbb8bc (Branch feature/458-admin-workbench-huelle); verifiziert per Playwright-Harness gegen die kompilierte CSS (40 Prüfungen, 5 Breiten, No-JS-Fallback, XSS-Probe). Träger-Entscheidung 2026-07-17: premium-navy-ivory ist das einzige Template der Instanz (drei Marken-Akzente; Site-, Wiki- und Admin-Bereich) und rendert die Admin-Workbench-Hülle.