nexarch/docs/ARBEITSKARTEN.md

Arbeitskarten (Stand 2026-10-28)

Status: offen / wartet / Entscheidung nötig / erledigt. Regel je Karte: eigener Branch, eigener PR, Tests auf 131 bzw. 204 (nie archivdms), PR-Beschreibung nennt Auswirkungen.

Offene PRs, die auf Merge warten, stehen unter C-01. Merge-Reihenfolge: erst DB-Tests auf 204 (siehe A-08), dann #385 und #394 (common), danach die Modul-PRs.

A. common/-Modul

A-01 Tag common/v0.1.0 — erledigt

• Tag-Workflow hat common/v0.1.0 (Merge-Commit von #378) und common/v0.1.1 gesetzt. Der Runner auf 131 läuft als act_runner.service.
• Lehre: Die CI-Warteschlange staute sich (über 100 Läufe, 1 Job gleichzeitig); wartende Läufe wurden mit Freigabe des Users abgebrochen.

A-02 bis A-05 Umstellung auf common — PRs offen

Modul	PR	Umgestellt	Nicht umgestellt
archive	#383	apierror, auditclient, httpclient, httpharden, svcauth, tenantregistryclient	loadtest (andere API)
dms	#384	apierror, httpclient, tenantregistryclient (ersetzt #375)	httpharden, policyclient (dms-Varianten), migrate, testdb
mail	#386	httpclient, loadtest, policyclient	testdb (andere API)
ai	#387	auditclient, httpclient, loadtest, svcauth, tenantregistryclient	migrate, testdb
connect	#388	auditclient, httpclient, policyclient	loadtest (weicht ab), migrate, testdb
workflow	#389	svcauth, tenantregistryclient	migrate, testdb, loadtest

A-06 migrate mit Tabellenname — PR offen (#385, common v0.2.0)

• migrate.New(table) statt fester connect_schema_migrations; Tag-Workflow nutzt common/MINOR.
• Danach Umstellung in connect, ai (connect_schema_migrations), dms (dms_schema_migrations), workflow (workflow_schema_migrations). Der Tabellenname muss je Modul unverändert bleiben, sonst laufen auf Bestands-DBs alle Migrationen neu. Wartet auf Tag aus #385.

A-07 testdb aus common — PRs offen

• dms #390 (auf #384), ai #391 (auf #387), connect #392 (auf #388), workflow #393 (auf #389). Schemaname einheitlich connecttest_*. mail und archive bleiben.

A-08 CI-DB-Tests und DB-Tests auf 204 — Entscheidung nötig

• testdb.AdminDSN und .gitea/workflows/db-tests.yml (Label nexarch-test) sind in main; der Workflow deckt nur common/ ab.
• Fehlt vom User: Datei /root/.nexarch-testdb.env auf 204 (TEST_ADMIN_DSN für dms_dev, chmod 600) für manuelle Läufe; Runner mit Label nexarch-test auf 204 und Secret TEST_ADMIN_DSN für die CI.
• Danach: DB-Tests für #383 bis #394 laufen lassen, Ergebnis in die PRs eintragen.

A-09 Reviewer für common/ — Entscheidung nötig

• Gitea-Benutzernamen für CODEOWNERS/Review-Pflicht auf common/.

A-10 moduleauth in common — PR offen (#394)

• common/moduleauth (Verifier, JWKS, Bearer-Middleware) aus der mail-Fassung. Danach: mail auf common/moduleauth umstellen; dms hat eine eigene Middleware mit caller-Übergangsmodus und bleibt vorerst.

A-11 Root-Modul — offen

• Root-httpclient hat strengeren Wächtertest und bleibt. Prüfen, ob weitere Pakete des Root-Moduls (auditclient, svcauth, tenantregistryclient) identisch zu common sind.

B. Portal

B-01 bis B-04 — erledigt, in main (#372, #382)

• Gruppen, Mandant aus Sitzung, Port-Hrefs mit Override NEXARCH_MODULE_URL_<KEY>; /api/worklist; /api/system-status, /api/kennzahlen-summary; Umgebungsvariablen in web/portal/README.md.
• Bewusst nicht gebaut: Favoriten, Ampel an den Kacheln.

B-05 Zielmodul portal im Core — Entscheidung nötig

• Soll portal in NEXARCH_ACCOUNT_MODULE_AUDIENCES stehen und PORTAL_TOKEN_AUDIENCE=portal gesetzt werden? Dann muss die Sitzung ?module=portal mitschicken.

B-06 Workflow auf Bearer-Token — wartet auf A-10

• Entscheidungen: Verifier aus common; Übergang mit NEXARCH_WORKFLOW_ALLOW_HEADER_AUTH=1 (Default aus), Bearer bevorzugt.
• Betroffen: Workflow-Pakete approvalapi, taskapi, caseapi, caseoverviewapi, routingruleapi, backchannelapi; Frontend-Proxy-Routen in web/workflow-tasks, web/workflow-cases, web/routing-rules, web/workflow-approvals; Portal-BFF (/api/worklist).
• Danach Schalter entfernen. Gleiches Muster für Audit-Log in dms (caller-Query) als eigene Karte.

B-07 Betrieb des Portals — Entscheidung nötig

• Variablen setzen: PORTAL_WORKFLOW_API_URL, PORTAL_STATUS_API_URL, PORTAL_KENNZAHLEN_API_URL. Die Statusseite ist nicht authentifiziert und darf nur vom Portal-Server erreichbar sein.

C. Betrieb

C-01 Offene PRs

• Reihenfolge-Vorschlag: #385, #394 (common) → #383, #384, #386, #387, #388, #389 → #390, #391, #392, #393 (nach Umstellung ihrer Basis auf main).
• Weitere offene PRs: #373, #374, #380.
• #375 ist geschlossen (ersetzt durch #384).

C-02 Aufräumen — nur mit Freigabe

• /root/manticore-backup-pre29 auf 131; Dateileichen im Manticore-Datenverzeichnis auf 204 nur nach Sichtung durch den User.
• Verwaiste Test-Schemas dmstest_*, workflowtest_* können nach den testdb-Umstellungen als connecttest_* auftauchen.

D. Portal-Betrieb (Stand 2026-10-28)

• D-01 Portal-UI (PR #409) und account-api-Start (PR #410): gemergt.
• D-02 Portal auf 131: gebaut, Unit und nginx/nft offen, siehe docs/BETRIEB-PORTAL.md.
• D-03 account-api auf 131: DB-Passwort nexarch_core abgleichen (Betreiber), Unit aus Vorlage erneuern.
• D-04 204: localhost-Adressen in connect/connect-datev/rbac-admin behoben; Port 3113 offen.
• D-05 Frontends auf Bearer: workflow-approvals, workflow-tasks, workflow-cases, routing-rules, Portal-BFF (PR #412, #413), mail-search (#416), connect-setup, connect-status, datev-export, dms2-import mit connect-app-Prüfung (#419); gemeinsamer Helfer createBearerClient in @nexarch/shl (#417). Offen: Ende-zu-Ende-Test mit Anmeldung auf 204; CORS für Authorization an der Connect-API auf 131; connect in NEXARCH_ACCOUNT_MODULE_AUDIENCES; NEXARCH_CONNECT_APP_JWKS_URL und _TENANT_SLUG setzen; danach NEXARCH_WORKFLOW_APP_ALLOW_HEADER_AUTH und NEXARCH_CONNECT_APP_ALLOW_HEADER_AUTH entfernen.
• D-06 Workflow-Demo auf 204 läuft (siehe docs/BETRIEB-PORTAL.md).
• D-07 Issue #369 (RBAC in ai-search, workflow-tasks, connect-setup): gemergt (#418, #420). Rolle kommt als X-User-Role aus dem Token; connect.setup.write nur tenant_admin. Dienste starten ohne NEXARCH_{AI,WORKFLOW,CONNECT}_APP_POLICY_URL nicht (Übergang: …_POLICY_DISABLED=1). Offen: Migration 0029 auf allen Mandanten-DBs einspielen, bevor die Binaries ausgerollt werden; statusapi fragt weiter mit fester Rolle user; bearerauth liegt doppelt (workflow, connect) und gehört nach common/; datevapi ist in connect-app nicht registriert.