zemion
2f5a69034a
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.
govoplan-portal
Repository type: module (domain).
The service-directory route, state, blocker, and accessibility mapping is
recorded in
docs/INTERFACE_PATTERN_MIGRATION.md.
Portal owns service discovery, presentation, and channel entry. Its
portal.service_directory capability projects provider-owned, versioned
service definitions into available, explainably unavailable, or undiscoverable
entries. It does not persist the institutional service promise or import Cases,
Forms, Workflow, Access, or Policy tables.
The capability works in a reduced composition without a Services provider by returning an empty directory. When a provider is present, provider-level access filtering remains authoritative and Portal adds only presentation-oriented availability checks for publication, effective time, audience, module, and capability requirements.
The tenant-scoped /api/v1/portal/services endpoint and /portal WebUI expose
the projection. Audience visibility is derived from trusted principal and
active function-assignment state on the server.
POST /api/v1/portal/services/{service_id}/launch re-fetches and re-evaluates
the exact Service revision before any effect. URL entries return a validated
redirect. Case, form, and workflow bindings delegate through the optional
cases.service_launcher, forms_runtime.service_launcher, and
workflow_engine.service_launcher contracts; each is tenant-bound and
replay-safe. A missing owner launcher makes the entry explainably unavailable.
Form launch resolves an exact published <form-id>/<revision> and returns the
owner's Form-instance route rather than persisting values in Portal.
The public /portal/status/:trackingId surface presents the bounded
application_status.projection owned by Forms Runtime. It supports the
configured authenticated, short-lived email-link, and permanent-link modes,
while Portal owns only the accessible presentation and reload/request actions.
Portal deliberately does not publish a DSAR provider because it persists no service-directory, launch, Postbox, application-status, applicant, or session records. Services owns definitions, each launch target owns its effects, Postbox owns mailbox data, and Forms Runtime owns status grants and submission data. Core and the deployment operator remain responsible for request/security logs. This reviewed boundary avoids duplicate or contradictory privacy exports.
See docs/SERVICE_DIRECTORY_CONCEPT.md.
Heading localization
Portal owns the English/German catalog entries for the function-postbox heading, authenticated-access heading, short-lived status-link request heading, and timeline heading. The native postbox heading translates during React rendering; status cards use Core's shared title translation contract. Provider-owned names and status access rules are not changed by this localization pass.
From the Meta checkout, run ./devkit docs audit --repo portal and
./devkit check --profile ui --repo portal. The latter discovers Portal's
test:translations script, which verifies module registration, both languages,
shared card rendering, and first-render native heading translation. These checks
do not claim that every Portal sentence or dynamic value is localized.
Git-source WebUI package
The repository root exposes @govoplan/portal-webui for Git-tagged release
dependencies. It mirrors the owning webui/package.json version, public
TypeScript/CSS exports and peer requirements, with entry paths under
webui/src. Consumers provide the shared Core/React peers; the facade runs no
development or install scripts. The source archive contains webui/src, this
README and any repository license file. Run module development checks from webui/; Python
installation remains governed by pyproject.toml.
Das Repository stellt @govoplan/portal-webui am Wurzelpfad für versionierte
Git-Abhängigkeiten bereit. Version, öffentliche TypeScript-/CSS-Exporte und
Peer-Anforderungen entsprechen webui/package.json; die Einstiegspfade liegen
unter webui/src. Gemeinsame Core-/React-Peers stellt die einbindende Anwendung
bereit. Die Fassade führt keine Entwicklungs- oder Installationsskripte aus.
Entwicklungsprüfungen bleiben in webui/, die Python-Installation weiterhin in
pyproject.toml definiert.