[Feature] Define versioned view-addressable UI surface and effective-view runtime contracts #271

New Issue

zemion · 2026-07-28T18:59:02+02:00

zemion commented

2026-07-28 18:59:02 +02:00

Outcome

Core exposes a module-neutral, versioned contract through which installed modules describe the interface surfaces that a governed View may show or hide. Core applies an optional effective View to the shell and gives modules one shared way to respect it inside their pages.

Boundary

A View is a presentation projection, never an authorization mechanism. Permission checks, tenant isolation, resource guards, and backend enforcement remain authoritative. A View may narrow what an authorized actor sees, but can never grant access or make an unauthorized route callable.

Core owns the contract and resolution hooks. govoplan-views owns persisted definitions, assignments, selection, inheritance, and the effective projection. Feature modules declare surfaces and consume the shared hooks; they must not import Views internals.

Acceptance criteria

Add stable, namespaced surface descriptors to backend/frontend module contracts for the useful levels: module, navigation item, route/workspace, section/panel, and command/action.
Descriptors include a stable id, parent id, kind, label, default visibility, ordering, and dependency/closure metadata where hiding a parent or prerequisite must hide children.
Surface ids are semantic contract ids, not CSS selectors or component implementation paths.
Expose a registry of surfaces from installed modules and an optional views.resolver capability/context for the effective projection.
Filter shell navigation and contributed routes/sections centrally; expose a shared WebUI hook/component for module-owned sections and actions.
When Views is absent or disabled, preserve the normal permission-derived interface unchanged.
Permission/resource checks run independently of and before presentation filtering.
Define deep-link behavior: an authorized route outside the current View offers an explicit temporary escape or View switch; it is not presented as a permission denial.
Unknown/removed surface ids produce diagnostics and provenance without breaking startup; revisions remain interpretable across module upgrades.
Contract and module-permutation tests cover no-Views fallback, nested surfaces, hidden routes, direct links, and an attempted View-based privilege expansion.

Dependency

This is the foundation for the future govoplan-views module and Workflow step integration.

## Outcome Core exposes a module-neutral, versioned contract through which installed modules describe the interface surfaces that a governed View may show or hide. Core applies an optional effective View to the shell and gives modules one shared way to respect it inside their pages. ## Boundary A View is a presentation projection, never an authorization mechanism. Permission checks, tenant isolation, resource guards, and backend enforcement remain authoritative. A View may narrow what an authorized actor sees, but can never grant access or make an unauthorized route callable. Core owns the contract and resolution hooks. `govoplan-views` owns persisted definitions, assignments, selection, inheritance, and the effective projection. Feature modules declare surfaces and consume the shared hooks; they must not import Views internals. ## Acceptance criteria - Add stable, namespaced surface descriptors to backend/frontend module contracts for the useful levels: module, navigation item, route/workspace, section/panel, and command/action. - Descriptors include a stable id, parent id, kind, label, default visibility, ordering, and dependency/closure metadata where hiding a parent or prerequisite must hide children. - Surface ids are semantic contract ids, not CSS selectors or component implementation paths. - Expose a registry of surfaces from installed modules and an optional `views.resolver` capability/context for the effective projection. - Filter shell navigation and contributed routes/sections centrally; expose a shared WebUI hook/component for module-owned sections and actions. - When Views is absent or disabled, preserve the normal permission-derived interface unchanged. - Permission/resource checks run independently of and before presentation filtering. - Define deep-link behavior: an authorized route outside the current View offers an explicit temporary escape or View switch; it is not presented as a permission denial. - Unknown/removed surface ids produce diagnostics and provenance without breaking startup; revisions remain interpretable across module upgrades. - Contract and module-permutation tests cover no-Views fallback, nested surfaces, hidden routes, direct links, and an attempted View-based privilege expansion. ## Dependency This is the foundation for the future `govoplan-views` module and Workflow step integration.

zemion added the

labels 2026-07-28 18:59:02 +02:00

zemion referenced this issue from GovOPlaN/govoplan

2026-07-28 18:59:03 +02:00

[Task] Initialize `govoplan-views` and implement governed View definitions #16

zemion referenced this issue from GovOPlaN/govoplan

2026-07-28 18:59:03 +02:00

[User Story] Task-focused Views reduce GovOPlaN to the interface needed for the current job #17

zemion commented

2026-07-28 21:08:58 +02:00

Codex State: done

Summary

Implemented the version 1 View surface contract, stable derived and custom surface identifiers, parent closure, ownership/duplicate/cycle validation, and platform API metadata.
Core now applies effective Views to navigation, direct-link route boundaries, settings/admin sections, dashboard widgets, embedded capabilities, and organization actions while keeping authorization independent.
Unknown or stale surfaces fail open for recovery, required surfaces remain visible, and the no-Views module graph preserves existing behavior.

Changed Files

govoplan-core@ce9ef8d

Verification

tests.test_view_surfaces: 9 passed
tests.test_module_system: 114 passed
all 22 WebUI module permutations and full-product build passed

## Codex State: done ### Summary - Implemented the version 1 View surface contract, stable derived and custom surface identifiers, parent closure, ownership/duplicate/cycle validation, and platform API metadata. - Core now applies effective Views to navigation, direct-link route boundaries, settings/admin sections, dashboard widgets, embedded capabilities, and organization actions while keeping authorization independent. - Unknown or stale surfaces fail open for recovery, required surfaces remain visible, and the no-Views module graph preserves existing behavior. ### Changed Files - `govoplan-core@ce9ef8d` ### Verification - `tests.test_view_surfaces: 9 passed` - `tests.test_module_system: 114 passed` - `all 22 WebUI module permutations and full-product build passed`

zemion closed this issue

2026-07-28 21:08:59 +02:00

zemion removed the

status

ready

label 2026-07-28 21:10:16 +02:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: GovOPlaN/govoplan-core#271