Add approved OrgSuite implementation tasks

.agents/skills/work-in-nextcloud-app/SKILL.md

@@ -57,7 +57,9 @@ Stop immediately if production systems, Git history rewriting, new production de
 - Develop executable UI logic test-first; additionally cover layout, accessibility, and Nextcloud integration with suitable smoke or browser checks.
 - Treat a time-boxed exploratory spike or hard-to-isolate Nextcloud integration as an explicitly justified deviation. Discard spike code or characterize it before adoption; choose the truthful broader integration level when isolation would hide the real contract.
 - Use the local fast entries named by `AGENTS.md`, normally `php tests/run.php` and `node tests/run-js.mjs`; dependency-light PHP smokes run in isolated processes. Run LocalBase and every affected consumer contract/smoke suite after a LocalBase contract change.
-- In local pre-production, app tests may use shared LocalBase test helpers through relative repository paths. Add heavier packaging/autoload structure or a larger test framework only when path handling, runners, assertions, mocks, or fixtures are materially duplicated or impair readability.
+- PHP classes must not remain coupled through distributed relative `require` or `require_once` chains. Production classes under `lib/` use Nextcloud's PSR-4 app autoloader; a bundled category-A dependency uses exactly one reproducibly generated, app-local, namespace-isolated Composer autoloader. Never use a shared workspace autoloader, shared cross-app `vendor/`, or neighboring production repository path as a delivery mechanism. Category-B services remain separate runtime apps and are consumed only through their public activation- and version-aware contracts.
+- Every app uses one central app-local test bootstrap/autoloader for dependency-light PHP tests. It may resolve a test-only LocalBase helper through exactly one central transition point until a versioned development dependency exists, but individual tests must not retain direct relative LocalBase class paths after migration. Nextcloud integration tests may load the documented Nextcloud test bootstrap; template partials, explicit process/test entrypoints, and the one-time bootstrap of a bundled Composer autoloader remain justified includes rather than class-load chains.
+- When a writing task first touches executable PHP or PHP tests in an app that has not yet migrated, include that app's complete autoload migration as a separate preparatory step in the same app scope. An app is complete only when distributed manual class requires and production fallback requires are gone, allowed includes are limited and reviewable, relevant app and provider/consumer PHP tests are green, and release checks contain neither development dependencies nor foreign repository paths. Documentation-only, formatting-only, and JavaScript-only work does not trigger an artificial PHP migration.
 - Known overall and app coverage must not decline unnoticed. Aim for at least 85 percent line coverage for new or materially changed executable code, report PHP and JavaScript separately, and fully cover security invariants regardless of percentages. Coverage is a warning and delivery indicator, not a substitute for meaningful assertions.
 - Do not prepare a commit or release with red relevant fast tests, contract tests, security checks, coverage gates, or delivery gates.
 
@@ -82,6 +84,7 @@ Stop immediately if production systems, Git history rewriting, new production de
 
 ## Git and completion report
 
+- When Simon asks for the next open steps, priorities, remaining work, or a similar outlook, include every applicable pending migration and unresolved decision from accepted ADRs and documented rollout plans. Report its current status, trigger, and required approval gate, and distinguish work executable now from work triggered by a later app change and work that is currently undecidable. Mentioning an item does not expand the current write scope or authorize a gated change.
 - Do not commit, push, release, deploy, or use `git add .` without Simon's explicit authorization. Stage individual files only when staging was requested.
 - Before a commit, show `git status --short`, `git diff --stat`, and `git diff --name-only`. Never use `git reset --hard`, `git clean`, force-push, history rewrite, or versioned backup copies.
 - Run relevant local tests, `git diff --check`, and the repository's own structure/fast check. For an explicitly authorized cross-app contract change, validate every provider and consumer repository from its own root and use the Parent workspace check only as an additional coordinator.

.github/workflows/tests.yml

@@ -106,3 +106,12 @@ jobs:
             --check-coverage \
             --lines=95.71 \
             node tests/run-js.mjs
+
+  deploy-staging:
+    name: Staging-Deployment
+    if: github.event_name == 'push'
+    needs: [php, javascript]
+    uses: Filzmann/br-nextcloud-apps/.github/workflows/deploy-staging.yml@main
+    with:
+      app-id: orgsuite
+    secrets: inherit

AGENTS.md

@@ -19,15 +19,16 @@ Die priorisierte Produktplanung und offene Entscheidungen stehen in `ROADMAP.md`
 
 OrgSuite stellt genau zwei Haupteinstiege im Nextcloud-Appmenue bereit:
 
-- `AD` fuer AD Kalender, Assistenzplanung, AD Urlaub und AD Raumplaner.
+- `AD` fuer AD Kalender, Assistenzplanung, AD Urlaub, AD Raumplaner und AD
+  Recruitment.
 - `BR` fuer BRTop, BR-Stunden und Berechtigungsmatrix.
 
 Die Fachapps bleiben eigenständige Repositories, Datenmodelle und Berechtigungsräume. OrgSuite besitzt keine Fachdaten und erweitert keine fachlichen Rechte. Zielapps erzwingen ihre Berechtigungen weiterhin serverseitig. OrgSuite stellt ab zwei AD-Fachprodukten ausschließlich Navigation, gemeinsame Assets und den Nextcloud-Adminadapter für in LocalBase persistierte Organisations- und Freigabeverträge bereit. Einstellungen, die nur eine Fachapp betreffen, erhalten einen eigenen Adminabschnitt in dieser Fachapp.
 
 ## Navigationsvertrag
 
 - Die Haupteinstiege werden dynamisch registriert und nur angezeigt, wenn mindestens eine Zielapp fuer die angemeldete Person aktiviert ist.
-- `AD` leitet bevorzugt zum AD Kalender weiter, `BR` bevorzugt zu BRTop. Ist das bevorzugte Ziel nicht aktiviert, wird die erste aktivierte Fachapp der Suite verwendet.
+- `AD` leitet bevorzugt zum AD Kalender weiter, `BR` bevorzugt zu BRTop. Ist das bevorzugte Ziel nicht aktiviert, wird die erste aktivierte Fachapp der Suite verwendet. AD-Ziele und ihre Reihenfolge stammen aus dem versionierten LocalBase-Produktkatalog.
 - OrgSuite lädt `js/suite-navigation.js` und `css/suite-navigation.css` zentral über `BeforeTemplateRenderedEvent`. Fachapps stellen nur einen wirkungslosen Host mit `data-orgsuite`, `data-suite` und `data-current-app` bereit und besitzen dadurch keine harte Asset-Abhängigkeit.
 - Die Menuestruktur wird ausschliesslich hier gepflegt. Fachapps duplizieren keine Linklisten oder Menuelogik.
 - Ein sichtbarer Link ist keine Berechtigung. Jeder Zielcontroller und jede API prueft Zugriffe selbst.

CHANGELOG.md

@@ -1,5 +1,11 @@
 # Changelog
 
+## 0.4.0-rc.1
+
+- AD-Navigation, Weiterleitungsreihenfolge und Menüdaten aus dem LocalBase-Produktkatalog abgeleitet.
+- AD Recruitment als kontobezogen aktiviertes Suite-Ziel ergänzt.
+- Sichtbare Produktlabels weiterhin im Übersetzungsbereich der jeweiligen App aufgelöst.
+
 ## 0.3.0-rc.1
 
 - OrgSuite als ab zwei AD-Produkten aktivierte Infrastruktur entkoppelt.

README.md

@@ -19,4 +19,9 @@ Nach der Aktivierung werden Organisationsdefinition und Freigaben im Nextcloud-A
 
 Geplante Erweiterungen und offene Produktentscheidungen stehen in der [Roadmap](ROADMAP.md).
 
+Für die manuelle Staging-Prüfung von Haupteinstiegen, Quermenüs und
+Adminadapter steht ein ausfüllbares
+[Abnahmeformular](docs/manual-acceptance.md) bereit. Es prüft ausdrücklich,
+dass OrgSuite keine Fachrechte erteilt und keine Fachdaten hält.
+
 Installations-, Betriebs- und Abnahmeunterlagen stehen im öffentlichen [AD-Suite-Projekt](https://github.com/Filzmann/ad-suite).

ROADMAP.md

@@ -2,8 +2,26 @@
 
 Diese Datei bündelt geplante Erweiterungen und offene Produktentscheidungen. Verbindliche Fach-, Sicherheits- und Architekturregeln stehen in `AGENTS.md`.
 
+## Zukunftsplanung – nicht freigegeben
+
+### ORGS-L10N – OrgSuite vollständig lokalisieren
+
+Status: später, nicht freigegeben; Pilot-App, Reihenfolge und Rohtext-Gate
+werden vor jeder Umsetzung appübergreifend separat freigegeben
+
+- Navigation, Adminadapter, Status- und Fehlermeldungen vertikal auf
+  Nextcloud-l10n umstellen.
+- Produkt-IDs, Routen, Menü-Suite-Schlüssel und Capability-Verträge
+  sprachneutral lassen.
+- Deutsche Ausgabe, eine weitere Locale, Fallback, Platzhalter,
+  Pluralformen, Escaping und JavaScript/PHP-Übergabe testen.
+- Erst nach vollständiger Migration einen Rohtext-Check für OrgSuite
+  verbindlich schalten.
+
 ## Aktueller Fokus
 
+- Die manuellen Prüfungen werden im ausfüllbaren
+  [`docs/manual-acceptance.md`](docs/manual-acceptance.md) dokumentiert.
 - Gemeinsame AD-/BR-Navigation und den administrativen Einstieg für Organisations- und Freigabeverträge auf einem realitätsnahen Staging abnehmen.
 - Dabei auch die globale, rein visuelle Links-rechts-Anordnung der LocalBase-Organigrammkarten prüfen; die fachliche Gruppenreihenfolge bleibt davon getrennt.
 - Standalone- und Mehrproduktzustände einschließlich deaktivierter Zielapps zuverlässig prüfen.

appinfo/info.xml

@@ -5,14 +5,14 @@
     <name>AD- und BR-Suite</name>
     <summary>Gemeinsame Navigation und Administration für die AD- und BR-Fachapps.</summary>
     <description>Bündelt die Einstiege der eigenständigen AD- und BR-Apps und stellt den administrativen Einstieg für organisationsweite Suite-Einstellungen bereit.</description>
-    <version>0.3.0-rc.1</version>
+    <version>0.4.0-rc.1</version>
     <licence>agpl</licence>
     <author>Simon</author>
+    <namespace>OrgSuite</namespace>
+    <category>organization</category>
     <website>https://github.com/Filzmann/ad-suite</website>
     <bugs>https://github.com/Filzmann/nextcloud-orgsuite/issues</bugs>
     <repository type="git">https://github.com/Filzmann/nextcloud-orgsuite</repository>
-    <namespace>OrgSuite</namespace>
-    <category>organization</category>
     <dependencies>
         <php min-version="8.3"/>
         <nextcloud min-version="34" max-version="34"/>

docs/manual-acceptance.md

@@ -0,0 +1,86 @@
+# Manuelles Abnahmeformular – OrgSuite
+
+Dieses Formular dokumentiert die fachliche, visuelle und sicherheitsbezogene
+Abnahme der gemeinsamen AD-/BR-Navigation und des administrativen
+OrgSuite-Einstiegs auf einem realitätsnahen Staging-System. OrgSuite enthält
+keine Fachdaten und erteilt keine Rechte in Zielapps.
+
+Pro Prüffall wird genau ein Ergebnis markiert. Keine Passwörter, Tokens,
+personenbezogenen Echtdaten, vollständigen Mitgliederlisten oder internen
+Kennungen eintragen. Ausschließlich neutrale Testkonten und synthetische
+Organisationsdaten verwenden.
+
+## Kopfdaten
+
+| Feld | Eintrag |
+|---|---|
+| Datum und Uhrzeit | |
+| Prüfer*in | |
+| Umgebung und URL | |
+| OrgSuite-Version | |
+| LocalBase-Version | |
+| Nextcloud-Version | |
+| Browser und Version | |
+| Fenstergröße / Zoom | |
+| Neutrale Testkonten und Zielapp-Rechte | |
+| Aktivierte AD- und BR-Apps | |
+
+Ergebniskennzeichnung: `[ ] erfolgreich` / `[ ] nicht erfolgreich` /
+`[ ] nicht geprüft`. Bei „nicht erfolgreich“ oder „nicht geprüft“ ist eine
+Begründung verpflichtend.
+
+## A. Haupteinstiege und Weiterleitung
+
+| ID | Was wird geprüft? | Auszuführende Schritte | Erwartetes Ergebnis | Ergebnis | Warum/Beleg/Abweichung |
+|---|---|---|---|---|---|
+| A1 | AD-Einstieg | Mindestens eine aktuelle AD-Zielapp aktivieren und den Nextcloud-Appbereich mit einem berechtigten Testkonto öffnen. | Genau ein Haupteinstieg `AD` erscheint und führt zu einer aktivierten, für das Konto nutzbaren Zielapp. | [ ] erfolgreich [ ] nicht erfolgreich [ ] nicht geprüft | |
+| A2 | BR-Einstieg | Mindestens eine BR-Zielapp aktivieren und denselben Weg prüfen. | Genau ein Haupteinstieg `BR` erscheint und führt zu einer aktivierten, nutzbaren BR-App. | [ ] erfolgreich [ ] nicht erfolgreich [ ] nicht geprüft | |
+| A3 | Bevorzugtes AD-Ziel | AD Kalender zusammen mit einer weiteren AD-App aktivieren und `AD` öffnen. | AD Kalender wird als bevorzugtes Ziel verwendet. | [ ] erfolgreich [ ] nicht erfolgreich [ ] nicht geprüft | |
+| A4 | AD-Fallback | Das bevorzugte AD-Ziel deaktivieren und den Einstieg erneut öffnen. | Die erste noch aktivierte Zielapp wird verwendet; es entsteht keine Schleife oder Fehlerseite. | [ ] erfolgreich [ ] nicht erfolgreich [ ] nicht geprüft | |
+| A5 | Bevorzugtes BR-Ziel und Fallback | BRTop mit weiterer BR-App prüfen, danach BRTop deaktivieren und wiederholen. | Zuerst wird BRTop verwendet, danach eine aktive BR-Fallback-App. | [ ] erfolgreich [ ] nicht erfolgreich [ ] nicht geprüft | |
+| A6 | Keine aktive Zielapp | Für eine Suite alle Zielapps deaktivieren und Navigation sowie direkte Suite-Route prüfen. | Der betreffende Haupteinstieg wird nicht angeboten; die Route leitet nicht auf eine deaktivierte App. | [ ] erfolgreich [ ] nicht erfolgreich [ ] nicht geprüft | |
+| A7 | Einzelproduktzustand | Eine AD-Installation mit genau einem Fachprodukt gemäß Installervertrag prüfen. | OrgSuite bleibt deaktiviert; das Fachprodukt besitzt seinen eigenen Standalone-Einstieg. | [ ] erfolgreich [ ] nicht erfolgreich [ ] nicht geprüft | |
+
+## B. Quermenü in Fachapps
+
+| ID | Was wird geprüft? | Auszuführende Schritte | Erwartetes Ergebnis | Ergebnis | Warum/Beleg/Abweichung |
+|---|---|---|---|---|---|
+| B1 | Zentrale Menüliste | In mehreren AD- und BR-Fachapps die angebotenen Quermenüs vergleichen. | Links und Reihenfolge stammen erkennbar aus OrgSuite; Fachapps zeigen keine abweichenden duplizierten Linklisten. | [ ] erfolgreich [ ] nicht erfolgreich [ ] nicht geprüft | |
+| B2 | Aktuelle App | Jede aktivierte Zielapp nacheinander öffnen. | Genau der aktuelle Link trägt `aria-current="page"` und eine verständliche sichtbare Markierung. | [ ] erfolgreich [ ] nicht erfolgreich [ ] nicht geprüft | |
+| B3 | Deaktivierte Zielapp | Eine Zielapp deaktivieren und die verbleibenden Fachapps neu laden. | Der nicht nutzbare Link verschwindet beziehungsweise wird nicht als aktives Ziel angeboten. | [ ] erfolgreich [ ] nicht erfolgreich [ ] nicht geprüft | |
+| B4 | Sticky und Scrollvertrag | Eine lange Fachansicht vertikal scrollen und zusätzlich eine breite Tabelle horizontal bewegen. | Das Quermenü bleibt innerhalb des App-Scrollcontainers oben sichtbar und erzeugt keinen globalen zweiten Scrollbereich. | [ ] erfolgreich [ ] nicht erfolgreich [ ] nicht geprüft | |
+| B5 | Schmales Fenster | Menü bei kleinem Viewport und vergrößertem Browserzoom prüfen. | Das Menü darf kompakt umbrechen; Links bleiben lesbar und bedienbar, ohne Fachinhalte zu überdecken. | [ ] erfolgreich [ ] nicht erfolgreich [ ] nicht geprüft | |
+| B6 | Tastatur und Fokus | Alle Menüpunkte nur mit Tastatur durchlaufen und aktivieren. | Fokus ist sichtbar, Reihenfolge ist nachvollziehbar und jedes Ziel lässt sich ohne Zeiger bedienen. | [ ] erfolgreich [ ] nicht erfolgreich [ ] nicht geprüft | |
+
+## C. Fachrechte bleiben in den Zielapps
+
+| ID | Was wird geprüft? | Auszuführende Schritte | Erwartetes Ergebnis | Ergebnis | Warum/Beleg/Abweichung |
+|---|---|---|---|---|---|
+| C1 | Sichtbarer Link ohne Fachrecht | Mit einem Testkonto einen sichtbaren Zielapp-Link aktivieren, für dessen Fachfunktion das Konto keine Berechtigung besitzt. | Die Zielapp verweigert den Zugriff serverseitig; OrgSuite erweitert das Fachrecht nicht. | [ ] erfolgreich [ ] nicht erfolgreich [ ] nicht geprüft | |
+| C2 | Direkter Zielaufruf | Dieselbe nicht erlaubte Zielroute und einen Ziel-API-Endpunkt direkt aufrufen. | Beide Aufrufe werden von der Zielapp abgewiesen; Navigation ist keine Zugriffskontrolle. | [ ] erfolgreich [ ] nicht erfolgreich [ ] nicht geprüft | |
+| C3 | OrgSuite ohne Fachdaten | OrgSuite-Routen, Oberfläche und administrativen Bereich auf Sitzungs-, Urlaubs-, Bewerbungs- oder andere Fachdaten prüfen. | OrgSuite hält und zeigt keine Fachdaten der Zielapps. | [ ] erfolgreich [ ] nicht erfolgreich [ ] nicht geprüft | |
+| C4 | Fehler einer Zielapp | Eine Zielapp in einer isolierten Testumgebung gezielt nicht erreichbar machen und eine andere Zielapp öffnen. | Die unabhängige Zielapp bleibt erreichbar; der Fehler erteilt keine Rechte und verändert keine Fachdaten. | [ ] erfolgreich [ ] nicht erfolgreich [ ] nicht geprüft | |
+
+## D. Administrativer Einstieg
+
+| ID | Was wird geprüft? | Auszuführende Schritte | Erwartetes Ergebnis | Ergebnis | Warum/Beleg/Abweichung |
+|---|---|---|---|---|---|
+| D1 | Adminadapter | Als Nextcloud-Admin mit mehreren AD-Produkten den OrgSuite-Adminabschnitt öffnen. | Die von LocalBase bereitgestellte Organisations- und Freigabeoberfläche erscheint einmal im OrgSuite-Kontext. | [ ] erfolgreich [ ] nicht erfolgreich [ ] nicht geprüft | |
+| D2 | Nichtadmin-Deny | Als Nichtadmin Adminabschnitt und direkte administrative Lese- sowie Schreibaufrufe versuchen. | Der Zugriff wird serverseitig verweigert; keine LocalBase-Konfiguration ändert sich. | [ ] erfolgreich [ ] nicht erfolgreich [ ] nicht geprüft | |
+| D3 | CSRF-Schutz | Einen schreibenden Adminaufruf mit Sitzung, aber ohne gültiges Requesttoken wiederholen. | Der Request wird abgewiesen und die bestehende Konfiguration bleibt unverändert. | [ ] erfolgreich [ ] nicht erfolgreich [ ] nicht geprüft | |
+| D4 | App-spezifische Einstellungen | Adminbereich auf Kalenderprovider-, Raum- oder andere nur eine Fachapp betreffende Einstellungen prüfen. | App-spezifische Administration bleibt im eigenen Fachapp-Abschnitt und wird nicht in OrgSuite dupliziert. | [ ] erfolgreich [ ] nicht erfolgreich [ ] nicht geprüft | |
+| D5 | Visuelle Diagrammordnung | Organigrammkarten in LocalBase über den OrgSuite-Adminadapter horizontal umordnen und danach fachliche Rollenreihenfolge sowie Rechte prüfen. | Nur die Darstellung ändert sich; fachliche Reihenfolge, Kalender und Berechtigungen bleiben unverändert. | [ ] erfolgreich [ ] nicht erfolgreich [ ] nicht geprüft | |
+| D6 | Datensparsame Abnahme | Formular und Screenshots prüfen. | Es wurden ausschließlich synthetische Organisationsdaten dokumentiert; keine Secrets oder realen Mitgliederlisten sind enthalten. | [ ] erfolgreich [ ] nicht erfolgreich [ ] nicht geprüft | |
+
+## Abschlussentscheidung
+
+| Feld | Eintrag |
+|---|---|
+| Anzahl erfolgreich | |
+| Anzahl nicht erfolgreich | |
+| Anzahl nicht geprüft | |
+| Kritische Abweichungen / Ticketreferenzen | |
+| Erneute Prüfung erforderlich bis | |
+| Gesamtentscheidung | [ ] abgenommen [ ] mit Auflagen abgenommen [ ] nicht abgenommen |
+| Begründung der Gesamtentscheidung | |
+| Name / Datum | |