# govoplan-portal

<!-- govoplan-repository-type:start -->
**Repository type:** module (domain).
<!-- govoplan-repository-type:end -->

The service-directory route, state, blocker, and accessibility mapping is
recorded in
[`docs/INTERFACE_PATTERN_MIGRATION.md`](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](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.