feat(devkit): add resumable workspace automation and UI review tooling

Verified with the coordinated workspace changes by devkit full run
2026-09-08T225814-186389-0000-3e3ed7cd (all seven phases passed).
This shared UI pass does not mark the individual module reviews complete.

docs/project/UI_REVIEW_PROGRAM.md

@@ -0,0 +1,164 @@
+# Product-wide UI review program
+
+The [central Gitea epic](https://git.add-ideas.de/GovOPlaN/govoplan/issues/56)
+coordinates the review; its linked module issues are the canonical backlog,
+progress and evidence log. The [issue inventory](ui-review-issue-inventory.json)
+is a discovery/link snapshot, **not a second progress tracker**. All reviews were
+initialized pending. Implementing a shared component or moving a help icon does
+not by itself complete a module review.
+
+The visual and interaction rules live in Core's
+[UI design principles](https://git.add-ideas.de/GovOPlaN/govoplan-core/src/branch/main/docs/UI_DESIGN_PRINCIPLES.md).
+This document defines how to apply and verify those principles across repositories;
+it does not fork their definitions. The usual [Gitea issue contract](GITEA_ISSUES.md)
+still applies. At the user's request, this cross-product program is coordinated in
+Meta; shared primitives and their implementation remain owned by Core.
+
+## Scope and initial inventory
+
+The September 2026 source/catalog baseline contains **77 review tracks**:
+
+- **73 implemented scopes:** Core/shared shell and 72 manifest-backed modules.
+- **4 registered placeholders:** Appointments, Ledger, XÖV and XTA/OSCI. They have
+  README-only repositories at initialization. Their separate readiness tracks
+  remain pending for future interfaces; they are not counted as implemented or
+  reviewed modules.
+
+Meta and the public website are not business-module review scopes. Module IDs
+come from actual manifests, not repository-name guesses: for example,
+`govoplan-campaign` owns `campaigns` and `govoplan-dist-lists` owns `dist_lists`.
+The inventory is derived from `repositories.json`, trusted module manifests and
+the owning repository's source files. Changes to the catalog must be reconciled
+with the central epic rather than silently dropping a module.
+
+A module with no standalone WebUI is still in scope. Review its configuration
+and administrator experience, contributed operator/public surfaces, widgets,
+documentation, permissions, errors and interactions exposed through other
+modules. A missing standalone page is not evidence of conformance. A reviewer
+may mark a particular principle not applicable only with a concrete explanation
+and source/runtime evidence. A placeholder likewise needs an explicit future-UI
+gate, not a fabricated page inventory or an automatic green review.
+
+## Work order and ownership
+
+Prioritize user-visible defects, usability and consistent interactions before
+broader features. Start with Core/shared-shell contracts and Campaign's complete
+workflow, then Files, Mail, Templates, Notifications, Docs/Help, Dashboard, Quick
+Access and Views. The remaining queue is ordered by observed defects, shared
+dependencies and risk. This is a starting order, not a claim that those reviews
+have started or finished; the central issue records the current focus.
+
+For Campaign, use a compact, read-only campaign settings overview with explicit,
+scoped edit dialogs. Large recipient or attachment grids may use the UI-02 bulk
+editing exception: clearly entered edit mode, explicit Save and Cancel, dirty
+navigation protection, and no silent loss or accidental save. This direction
+must be implemented and verified in the Campaign review, not marked complete by
+the program bootstrap.
+
+Fix a repeated problem in the owning shared primitive or semantic contract first,
+then migrate consumers and verify representative actual-module fixtures. Keep
+module business behavior in its own repository and preserve optional module
+boundaries. Do not replace concrete user evidence with a generic fixture alone.
+Parallel reviewers may own different modules, but they must coordinate shared
+Core files and browser fixtures instead of racing the same resources.
+
+## Per-module review workflow
+
+1. **Inventory.** Verify and extend the issue's source-derived seed: navigation,
+   pages, nested routes, dialogs, labels/forms, tables/trees, admin/system/tenant/
+   user settings, public/operator interfaces, widgets and optional-module
+   contributions. Follow actual module entrypoints and runtime contributions;
+   filename heuristics and manifest routes are a starting point, not an exhaustive
+   runtime audit. Note roles, permission boundaries and installed optional modules.
+2. **Observe.** Exercise realistic narrow and wide viewports, German and English,
+   keyboard navigation and focus, empty/loading/error/success states, clean/dirty
+   edit modes, reload, navigation away and return, and restoration of personal
+   preferences. Include realistic row counts, long labels, horizontal overflow,
+   pagination and two-way column resizing with fixed columns between text fields.
+3. **Record.** Keep a findings/TODO/done ledger in the module issue. Every finding
+   names the surface, reproduction, expected principle, impact, owner and linked
+   implementation/evidence. A source inventory, planned fix or green generic
+   test is not a completed finding. State product decisions and manual checks
+   explicitly with enough context to resolve them.
+4. **Implement.** Prefer reusable shared primitives and action/page contracts.
+   Keep display mode readable and editing intentional. Preserve authorization,
+   server validation, save/cancel behavior and data integrity. Never send mail,
+   delete records, change live configuration or trigger other irreversible effects
+   merely to obtain UI evidence; use authorized fixtures or a safe test context.
+5. **Verify.** Run proportionate unit, structure and actual-module browser tests.
+   Record commands, results, source revision and safe runtime evidence. Update the
+   owning module's manifest-driven EN/DE documentation for behavior changes; run
+   `tools/checks/check-manifest-shapes.py` and relevant cross-module checks.
+6. **Conclude honestly.** Complete the principle matrix, evidence and manual
+   checks. Link unresolved follow-ups and blockers; do not close a supposedly
+   complete review while required work is still pending. Closing an issue requires
+   explicit reviewed scope and the applicable design-principle revision.
+
+## Principle ledger and back-propagation
+
+Use the stable IDs from Core in each issue. The initial revision covers UI-01
+heading/label help placement; UI-02 display-first/scoped editing; UI-03 actions;
+UI-04 table/card geometry; UI-05 loading/error/progress; UI-06 tree interaction;
+UI-07 accessibility and German; UI-08 data integrity; and UI-09 propagation of
+revised principles. Core remains the authoritative definition.
+
+Each module maintains this matrix, initially entirely pending:
+
+| Principle/revision | Applicable surfaces / justified N/A | Applied / remaining work | Evidence | Exception / owner / follow-up |
+| --- | --- | --- | --- | --- |
+| UI-01 … UI-09 | Pending inventory | Pending review | Not yet recorded | None approved |
+
+Whenever a principle is added or changed:
+
+1. Update Core's rule with its rationale, stable ID and revision/change reference.
+2. List **all already-reviewed modules**, not just the current implementation's
+   consumers. Check whether the changed rule applies to each.
+3. Record unchanged conformance with evidence, or reopen the review / create a
+   linked follow-up with owner, exact affected surfaces and required checks.
+4. Update the central epic's propagation ledger. Previously reviewed modules with
+   outstanding applicable work are **follow-up required**, not silently green.
+5. Resolve the propagation sweep only after every affected module has current
+   evidence or an explicit, owned and justified exception. Exceptions do not
+   silently change the shared rule.
+
+Suggested central ledger:
+
+| Principle change | Already-reviewed modules checked | Conformant evidence | Reopened / follow-up required | Exceptions / owner | Sweep state |
+| --- | --- | --- | --- | --- | --- |
+| Initial UI-01–UI-09 baseline | None reviewed at initialization | None | All module reviews pending | None approved | Pending |
+
+## Safe inventory/bootstrap automation
+
+`tools/gitea/gitea-ui-review-program.py` derives the current scopes from the
+catalog and source manifests, inventories routes and UI source entrypoints,
+then deduplicates issues by a stable hidden marker and normalized exact title.
+It includes closed issues in duplicate checks and never reopens, closes or
+overwrites existing module issues. Ambiguous or unmanaged duplicates stop the
+operation for review. Existing issue bodies, labels and review progress are
+preserved. A failed POST is not automatically retried; a subsequent run checks
+the marker again before deciding whether another create is needed.
+
+Dry-run is the default. An authenticated dry-run performs only Gitea reads:
+
+```sh
+.venv/bin/python tools/gitea/gitea-ui-review-program.py \
+  --env-file /home/zemion/.config/gitea/gitea.env --epic 56
+```
+
+Creating missing review issues requires explicit `--apply`. Initial population
+of the central epic's module-link block additionally requires
+`--initialize-links`; it is accepted only for the untouched bootstrap placeholder.
+Later runs must not rewrite checkboxes or human-maintained progress. Existing
+complete links are verified read-only. The token is loaded through the shared
+Gitea helpers and is never emitted in reports. A scoped `--ipv4` option works
+around host-specific IPv6 connectivity while retaining HTTPS certificate and
+hostname verification.
+
+The tool emits a JSON result to stdout with source counts and issue links. The
+checked-in inventory is a reviewed initialization snapshot of that result;
+refreshing links does not authorize replacing live review status with the
+snapshot. Test the automation offline with:
+
+```sh
+.venv/bin/python -m pytest tests/test_ui_review_program.py -q
+```