govoplan-views provides governed, task-focused interface projections for GovOPlaN. A View selects modules, navigation entries, routes, sections, and actions that should be shown for a particular task without changing the underlying authorization decision.

The module owns versioned View definitions, immutable revisions, assignments at system, tenant, group, and user scope, effective-view resolution, and the user's current selection. Core owns the surface contract and applies the effective projection to the shared shell. Modules announce their selectable surface hierarchy in their manifests and WebUI contributions.

Views are presentation filters, never security boundaries. Hidden routes still use their normal permission checks. Required Views retain the View selector and administration surfaces needed to inspect and change the assignment, preventing administrators from locking an installation out of its own configuration. The selector is the titlebar eye button next to the language control. It opens the available-View menu and uses the accent color whenever a specialized View is active; the full interface keeps the icon neutral. The selector announces the views.selector help context so F1 opens the matching Views guidance.

Views are also the canonical user/group module-visibility mechanism. Core creates a root <module>.module surface for every WebUI module, so a View may hide or reveal a tenant-effective module without creating a second personal module-state store. A View cannot make a module operationally available when system tenant policy excludes it, and it cannot grant the Access permissions needed to use the module.

Administration

The module contributes Views sections to system and tenant administration. Administrators can:

create a draft from the currently installed surface catalogue
choose modules, navigation entries, routes, sections, and actions
publish immutable revisions
make a published View available, default, or required at system, tenant, group, or user scope
pin an assignment to its published revision or let it follow later published revisions
inspect and remove references to surfaces retired by a module

Accounts with the corresponding definition permission can also design personal Views, or reusable Views owned by one of their groups, from Settings > Views. Publishing an owned View automatically makes it available to its owner; administrators can still distribute it more broadly through explicit assignments.

Required assignments are validated by the backend. They must retain the Views selector, the Access administration route, and the administration section able to remove the assignment. If an installed-module change leaves an active View without a reachable navigation entry and route, Core shows the normal authorized interface and reports the stale projection instead of trapping the user.

The surface inventory, consequence classes, availability explanations, and accessibility evidence for the shared interface language are recorded in docs/INTERFACE_PATTERN_MIGRATION.md.

Development

Install the module as an editable package alongside Core and include views in ENABLED_MODULES. Core's registered-module migration runner applies the Views migration on startup.

pip install -e ../govoplan-views
python -m unittest discover -s ../govoplan-views/tests -v

Workflow declares the resolver as an optional contract. The resolver accepts an optional workflow-selected View and applies it below required administrative assignments but above user/default selection. The View must already be available to the account, so Workflow cannot bypass assignment policy. Persisting a workflow instance's pinned View revision remains owned by the Workflow module.