Verwaltung als zwei Anwendungsverbünde

Angenommen und in Umsetzung: Der Betreiber hat den Bau am 20.09.2026 angeordnet. Gebaut und ausgeliefert sind die Bereichsleiste beider Verbünde mit dem mitreisenden Konto, das Ausgrauen fehlender Pakete, das Konto-Detail in der rechten Spalte mit Abschnitten je Modul, das Master-Detail im Tresor, der Seitenbaum der Social-Vorschau, das Leitobjekt Seite mit Seiten-Detail im Verbund „Inhalt & Veröffentlichung“ und die Bausatz-Regeln dazu (siehe „Konsequenzen“). Auch der Verbund als eine einzige Registerkarte ist gebaut. Offen sind der einheitliche Ablauf für Anlegen, Bearbeiten und Löschen in allen Modulen (eigener Vorgang) und die stufenweise Spaltenfaltung. Anlass war die Abnahme am gerenderten Bild vom 19.09.2026, bei der der Betreiber das Ergebnis der bisherigen Verwaltungsbildschirme als unbrauchbar bewertet hat: kein durchgängiger Arbeitsablauf, keine Konsistenz bei Schaltflächen, Symbolen, Befehlsleisten und Texten.

Was gemessen wurde. Alle Verwaltungsmodule der laufenden Instanz, geprüft im Quelltext auf vier Eigenschaften: Nutzt das Modul die Werkbank-Hülle des Bausatzes (Registerkarte, Activity Bar, Befehlsleiste, Rail, Statusleiste)? Hat es eine Befehlsleiste? Zeichnet es Listen als Bausatz-Raster? In wie vielen Sprachen liegt es vor? Dazu die Befunde des Betreibers am Bild.

Drei von dreizehn Suite-Modulen nutzen die Hülle, obwohl der Workbench Plugin Contract v1 seit seiner Einführung genau das vorsieht. Die Kern-Module sind vom Bausatz nachgezeichnet, tragen aber keine Befehlsleiste im Sinn des Vertrags.

Was der Betreiber verlangt. Wörtlich: Die Module Zugangsverwaltung, Repository-Zugang und Mounts, Einladungen, Post, Tresor und Zwei-Faktor müssen „wie eine Anwendung“ funktionieren, mit sanften Übergängen und ausgegrauten Befehlen, wenn das tragende Paket fehlt. Ebenso Blog, soziale Vorschau, Bausteine und Medien-Upload. Der Vorteil von Fluent UI soll gerade der Arbeitsablauf über Modulgrenzen hinweg sein; ohne ihn unterscheidet sich die Oberfläche nicht von der Standard-Verwaltung von DokuWiki.

Was bisher gebaut wurde. Ein Zielzustand wurde technisch abgehakt („Identität, Gruppen, Pflicht, eine Einladung“), nicht als Arbeitstag eines Wiki-Admins durchgespielt. Jedes Modul entschied Befehlsnamen, Symbole, Hinweise und Hülle für sich; nichts erzwang Gleichheit, und nichts beschrieb, welche Aufgabe ein Admin über mehrere Module hinweg erledigt.

1. Zwei Anwendungsverbünde statt dreizehn Module.

Ein Verbund ist eine Registerkarte in der Werkbank mit einer Hülle, einer Befehlsleiste, einer Rail für seine Bereiche und einer Statusleiste. Sein Leitobjekt bleibt über Bereichswechsel hinweg ausgewählt: Wer im Verbund „Identität & Zugang“ ein Konto wählt, sieht rechts dessen Gruppen, Rechte, Faktoren, offene Einladung, Postausgang und Repository-Zugang als Reiter eines Details – und wechselt zwischen ihnen, ohne das Konto neu zu suchen.

2. Master-Detail als Grundform. Links die Liste des Leitobjekts (Bausatz-Raster, immer responsiv, Suche, Auswahl), rechts das Detail mit Reitern je beteiligtem Modul. Die Befehlsleiste gilt für das gewählte Objekt; Befehle, deren Paket fehlt oder deren Voraussetzung nicht erfüllt ist, stehen ausgegraut mit Begründung da, nicht gar nicht (Fähigkeits-Erkennung nach dem Werkbank-Vertrag; Beispiel: „Repository-Zugang“ ausgegraut, wenn wkdoadogit nicht installiert ist; „Einladung senden“ ausgegraut, wenn kein Postausgang eingerichtet ist).

3. Arbeitsabläufe, gegen die gebaut und abgenommen wird. Jeder Ablauf hat Auslöser, Schritte, Ergebnis und Prüfung; die Abnahme misst die Zahl der Bildschirmwechsel und der Stellen, an denen der Admin etwas erneut eingeben muss.

4. Regeln, die in den Bausatz gehören – nicht in die Module.

1. Jedes Verwaltungsmodul liefert Bereiche, Befehle, Ansichten und Detail-Reiter an einen Verbund; es baut keine eigene Hülle, keine eigene Befehlsleiste, keine eigenen Symbole.
2. Jedes Formular führt die Seitenkennung mit; die Sprache der Oberfläche darf sich durch Absenden nicht ändern.
3. Befehle tragen Symbole aus einem Satz und Farben nach der Aktionssemantik des Styles-Contracts; Sonderfälle je Modul gibt es nicht.
4. Listen sind immer das Bausatz-Raster: responsiv, Spalten nach Priorität in die Detailzeile, Überlauf vom Raster behandelt. Eingabespalten stehen erst dann in der Prioritätenliste, wenn die Detailzeile Eingaben beherrscht (heute klont sie die Zelle).
5. Ein Objekt wird aus einer Liste oder einem Baum gewählt, nie über eine getippte Kennung.
6. Ein Modul, das nicht in allen fünf Sprachen vorliegt, wird nicht ausgeliefert.
7. Ein fehlendes Paket nimmt einen Befehl nicht weg, sondern graut ihn aus und nennt das Paket.

5. Reihenfolge, vorgeschlagen. Zuerst „Identität & Zugang“: fünf der sieben Module gibt es, sie tragen Daten, und drei der Befunde vom 19.09.2026 liegen dort. „Inhalt & Veröffentlichung“ danach. Innerhalb eines Verbunds zuerst Hülle, Leitobjekt-Liste und Detail-Rahmen als Bausatz-Baustein, dann je Ablauf ein Reiter – abgenommen am Bild und am gezählten Ablauf, nicht am Quelltext.

1. Stand der Umsetzung (20.09.2026). Im Bausatz, für alle Module: Bereichsleiste je Verbund in der Fensterregion der Hülle – damit auch auf Modulen mit eigener Hülle; das Konto reist über jeden Bereichswechsel mit und wird in die eigenen Parameter des Zielbildschirms übersetzt, Kern-Bildschirme eingeschlossen; ein Bereich, dessen Paket fehlt oder der dem Konto nicht zugänglich ist, steht ausgegraut mit Grund da, auch im Überlauf-Menü; Befehle ohne nachgewiesenen Faktor stehen ausgegraut in der Befehlsleiste; die Befehlsleiste faltet Befehl für Befehl und bleibt im Fenster; jedes Raster ist ohne Zutun des Aufrufers adaptiv; die Plugin-Eigenschaften öffnen auf Abruf statt als Dauerspalte; eine Registerkarte merkt sich den Ort im Modul; die Detailspalte eines Master-Details öffnet sich auf schmalen Breiten von selbst; die Schublade der Seitenleiste trägt ihren Namen.
2. In den Modulen: der Tresor ist ein Master-Detail (Eintrag wählen, rechts Zustand, Befehle und die Zugriffe dieses Eintrags); die Social-Vorschau wählt die Seite über einen Seitenbaum; die Mount-Liste und die Bausteine sind Bausatz-Raster mit Zeilenmenü.
3. Das Konto-Detail: ist ein Konto gewählt, zeigt die rechte Spalte auf jedem Bildschirm des Verbunds seine Stammdaten, die Zugriffsregeln, die es oder eine seiner Gruppen nennen, und Abschnitte der Module – beigesteuert über ein Ereignis des Bausatzes: Zwei-Faktor (eingerichteter Faktor, Vorgabe, offene Vorgänge), Post (hinterlegte Adresse und der zuletzt gemessene Zustand des Postausgangs – die Spalte misst nie selbst), Zugriffstoken des Repository-Zugangs (nur Metadaten, nie der Token selbst) und die Anfragen des Kontos. Abschnitte stehen untereinander, nicht als Reiter: fünf Modulnamen passen nicht in die Spaltenbreite. Das Leitobjekt gibt es nur für Superuser, weil die Verwaltung auch Managern offensteht. Gewählt wird das Konto in der Benutzerverwaltung durch einen Klick auf den Anmeldenamen – Filter und Seite der Liste bleiben dabei stehen – oder über das Feld in der Bereichsleiste.
4. Das Seiten-Detail: Leitobjekt des Verbunds „Inhalt & Veröffentlichung“ ist die Seite. Sie gilt nur, wenn es sie gibt und die Sitzung sie lesen darf – beides ist nach außen dieselbe Antwort. Die Social-Vorschau öffnet ihren Editor für die Seite, die Medienverwaltung den Namensraum der Seite; wer in der Social-Vorschau eine andere Seite öffnet, wählt sie damit für den ganzen Verbund. Die rechte Spalte zeigt Kennung, Titel und letzte Änderung, die von der Seite verwendeten Medien mit „vorhanden“ oder „fehlt“ und den Weg „Dateien hochladen“ in den Namensraum der Seite (ausgegraut mit Grund, wenn das Recht fehlt). Module steuern bei: die Social-Vorschau die eigenen Vorschau-Angaben der Seite („geerbt“, wo sie nichts setzt), der Blog – nur bei Beiträgen – Blog, Zustand und Kommentare, die Bausteine die auf der Seite verwendeten Schlüssel. Die Medienverwaltung zeigt die Bereichsleiste und behält die Seite beim Blättern; beides nur für Sitzungen mit Verwaltungsrecht.
5. Die Detailspalte öffnet sich als Überlagerung nur für eine Wahl, nicht bei jeder Anfrage, die das Leitobjekt noch trägt: bei 390 px lag sie sonst nach jedem Speichern wieder über dem Formular. Angedockt (ab 1280 px) steht sie dauerhaft.
6. Die Zwei-Faktor-Verwaltung setzt ihre Hülle selbst zusammen und zeigt das Konto-Detail trotzdem: als Ansicht des Bausatzes in der rechten Spalte, solange keine geteilte Ansicht geöffnet ist – die hat Vorrang, weil der Leser sie ausdrücklich geöffnet hat. Damit steht das Konto-Detail auf allen neun Bereichen des Verbunds.
7. Ein Verbund ist EINE Registerkarte: Die Registerkartenleiste zeigt alle gehaltenen Bildschirme eines Verbunds als einen Eintrag mit dem Namen des Verbunds. Von außen führt er zum zuletzt besuchten Bereich samt Ort; das Kreuz schließt den Verbund, Verschieben bewegt ihn als Ganzes. Gespeichert bleibt je Modul – die Leiste fasst nur zusammen, ein Rückbau verlöre nichts. Bildschirme außerhalb eines Verbunds bleiben einzelne Registerkarten.
8. Symbole: Jedes eigene Verwaltungspaket liefert ein einfarbiges Symbol im 24er-Raster für die Modulleiste; hat ein Paket mehrere Verwaltungsbildschirme, trägt jeder sein eigenes (Dateiname admin_<bildschirm>.svg, der Bausatz findet es ohne Code im Paket). Gemessen waren vorher 12 von 24 Einträgen Buchstabenkürzel. In den Befehlsleisten selbst tragen Befehle einheitlich keine Symbole; die Befehlsleiste der Zwei-Faktor-Verwaltung faltet jetzt wie alle anderen.
9. Befehlsleisten: Farben folgen der Drei-Farben-Regel des Styles-Vertrags (in der Kontenverwaltung waren „Hinzufügen“ und der Export genau vertauscht), die Befehle der Kontenverwaltung sprechen die Sprache der Installation („Neues Konto“, „Konten exportieren (CSV)“, „Konten importieren“), und ein Befehl, der nur auf den Bildschirm führt, auf dem er steht, entfällt dort.
10. Maßstab für alles Weitere (Vorgabe des Betreibers vom 20.09.2026): Fluent UI dient nicht dazu, DokuWiki-Funktionen schöner zu machen, sondern die Bedienung aus Azure DevOps ins Wiki zu bringen – EIN Weg je Art Vorgang (anlegen, bearbeiten, löschen, auswählen) in allen Modulen, alles im Fenster. Das gemeinsame Muster dafür (Liste, Kommandoleiste, Zeilenmenü, Schublade, Sekundärreiter) und die Umstellung aller Bildschirme laufen als eigener Vorgang; hier wird kein zweites Muster gebaut.
11. Noch nicht gebaut: der einheitliche Ablauf Anlegen/Bearbeiten/Löschen in allen Modulen, darin der durchgängige Ablauf der Mounts; die stufenweise statt der einmaligen Spaltenfaltung.
12. Die Reparaturen vom 19.09.2026 am Einladungsbildschirm (Formularbreite, Spaltenumbruch, Rasterspalten, Beschriftungen, Seitenkennung im Formular) bleiben bestehen; sie sind Bausatz-Korrekturen und gelten für jeden Verbund.
13. Der Werkbank-Vertrag bekommt einen Begriff „Verbund“ (Registerkarte mit Leitobjekt und Detail-Reitern) und einen Beitragspunkt für Detail-Reiter; das ist eine Erweiterung, keine Änderung bestehender Beiträge.
14. Die Kern-Module bleiben vom Bausatz nachgezeichnet und werden als Bereiche in den Verbund „Identität & Zugang“ eingehängt (Zugangsverwaltung, Benutzerverwaltung); sie werden nicht neu geschrieben.
15. Was ein Modul heute an eigener Hülle, Befehlsleiste oder Symbolen mitbringt, entfällt beim Einhängen; die Daten und Handlungen bleiben.

• Workbench Plugin Contract v1 – Bauflächen, Bereiche, Beiträge, Fähigkeits-Erkennung
• Styles-Contract – Aktionsfarben, Komponenten-Klassen, Compiler-Fallen
• wkfluentui – der Bausatz
• Identity – Konten, Faktoren, Einladungen