[Feature] Hide package topology behind stable product surfaces #283

New Issue

2026-08-05T16:21:21+02:00

zemion commented

2026-08-05 16:21:21 +02:00

Problem

The shell currently exposes package and route architecture too directly through navigation, errors, configuration, and deep links. Users should work with tasks, objects, responsibilities, and outcomes; administrators still need an explicit technical module view.

Scope

Add a versioned product-surface contribution contract covering identity, routes, capabilities, task/reader/admin/operator presentations, search/help/docs, and unavailable/degraded explanations.
Compose duplicate or related module routes into one product entry and preserve stable deep links during ownership changes.
Keep package identifiers in module administration, diagnostics, evidence, and extension development, not ordinary task navigation.
Make Views filter product surfaces and actions rather than package IDs.
Standardize unavailable-capability, policy, disabled-module, offline, and provider-degraded states through central components.
Add migration aliases and telemetry before removing route/package terms from the ordinary UI.

Acceptance criteria

A reference journey can be completed without understanding repository/module names.
The shell renders one stable product entry for a composed capability and explains unavailable actions without exposing implementation errors.
Module permutations preserve stable navigation/help/search contracts.
Administrators retain a truthful package topology and provenance view.

Architecture: govoplan/docs/PRODUCT_EXPERIENCE_AND_MODULE_BOUNDARIES.md.

## Problem The shell currently exposes package and route architecture too directly through navigation, errors, configuration, and deep links. Users should work with tasks, objects, responsibilities, and outcomes; administrators still need an explicit technical module view. ## Scope - Add a versioned product-surface contribution contract covering identity, routes, capabilities, task/reader/admin/operator presentations, search/help/docs, and unavailable/degraded explanations. - Compose duplicate or related module routes into one product entry and preserve stable deep links during ownership changes. - Keep package identifiers in module administration, diagnostics, evidence, and extension development, not ordinary task navigation. - Make Views filter product surfaces and actions rather than package IDs. - Standardize unavailable-capability, policy, disabled-module, offline, and provider-degraded states through central components. - Add migration aliases and telemetry before removing route/package terms from the ordinary UI. ## Acceptance criteria - A reference journey can be completed without understanding repository/module names. - The shell renders one stable product entry for a composed capability and explains unavailable actions without exposing implementation errors. - Module permutations preserve stable navigation/help/search contracts. - Administrators retain a truthful package topology and provenance view. Architecture: `govoplan/docs/PRODUCT_EXPERIENCE_AND_MODULE_BOUNDARIES.md`.

zemion added the module/docs module/views area/governance

area/api area/webui module/core labels 2026-08-05 16:21:21 +02:00

zemion commented

2026-08-06 19:15:43 +02:00

Progress: commit 32c234f adds versioned product_areas and quick_access_tools manifest contracts, registry validation, platform metadata, product-area grouping, flat-mode fallback, and optional shell hosting. Dashboard stays pinned; authorized unclassified routes remain under More tools.

Contract tests, module-capability tests, full-product build, and module permutations pass.

Remaining here: classify the wider module catalogue and migrate breadcrumbs, search, unavailable states, documentation, and ordinary UI language away from package topology while preserving operator provenance.

Progress: commit `32c234f` adds versioned `product_areas` and `quick_access_tools` manifest contracts, registry validation, platform metadata, product-area grouping, flat-mode fallback, and optional shell hosting. Dashboard stays pinned; authorized unclassified routes remain under More tools. Contract tests, module-capability tests, full-product build, and module permutations pass. Remaining here: classify the wider module catalogue and migrate breadcrumbs, search, unavailable states, documentation, and ordinary UI language away from package topology while preserving operator provenance.

zemion added

and removed

labels 2026-08-06 19:15:44 +02:00

zemion commented

2026-08-24 13:41:54 +02:00

Codex State: progress

Published the first versioned product-surface slice.

Core v0.1.40 (6e518fa) defines and validates product_surfaces, composes shared identities, resolves authorization and View visibility, preserves stable aliases, emits bounded route telemetry, and provides the central unavailable/degraded presentation.
Mail v0.1.25 (ecc1283) and Postbox v0.1.22 (aff2623) now contribute the shared communication.messages surface: stable /messages, migration alias /inbox, owner routes /mail and /postbox, and shared German/English product language.
Workspace v0.1.40 (3766e26) publishes the aligned release and architecture state.
The complete focused gate passes: 72 manifest contracts, backend suites, 63 WebUI module permutations, full-product bundle (159.1/160 KiB gzip), and 8 Playwright conformance tests.

This issue remains open for additional product-surface promotions, product-area navigation migration, and the reference journey acceptance criterion.

## Codex State: progress Published the first versioned product-surface slice. - Core v0.1.40 (`6e518fa`) defines and validates `product_surfaces`, composes shared identities, resolves authorization and View visibility, preserves stable aliases, emits bounded route telemetry, and provides the central unavailable/degraded presentation. - Mail v0.1.25 (`ecc1283`) and Postbox v0.1.22 (`aff2623`) now contribute the shared `communication.messages` surface: stable `/messages`, migration alias `/inbox`, owner routes `/mail` and `/postbox`, and shared German/English product language. - Workspace v0.1.40 (`3766e26`) publishes the aligned release and architecture state. - The complete focused gate passes: 72 manifest contracts, backend suites, 63 WebUI module permutations, full-product bundle (159.1/160 KiB gzip), and 8 Playwright conformance tests. This issue remains open for additional product-surface promotions, product-area navigation migration, and the reference journey acceptance criterion.

zemion commented

2026-08-24 18:32:09 +02:00

Completed and published as Core ac40774 / v0.1.44, with contributor releases Tasks v0.1.22, Calendar v0.1.23, Files v0.1.25, and root catalogue v0.1.44.

Acceptance evidence:

stable Work, Calendar, Files and existing Messages product entries replace authorized owner/package entries in the ordinary rail;
owner routes remain compatible deep links and are exposed in the permission-derived All available tools catalogue;
All available tools is deliberately independent of active View focus, while still enforcing authorization;
composed product entries remain active on owner paths and respect configured product-area ordering;
centralized bilingual labels and unavailable explanations avoid module-specific wording drift;
module administration/provenance remains available without leaking package topology into ordinary task navigation;
the Anwohnerparkausweis conformance journey renders Arbeit, Dateien, Nachrichten and Kalender without package labels and expands the technical catalogue accessibly.

Verification: 681 Core backend tests, module-capability tests, 63 module permutations, production bundle budget, 13 Playwright conformance journeys, 72/72 manifest validation and the complete workspace-focused check. The immutable release lock and all remote refs were verified after push.

Completed and published as Core `ac40774` / `v0.1.44`, with contributor releases Tasks `v0.1.22`, Calendar `v0.1.23`, Files `v0.1.25`, and root catalogue `v0.1.44`. Acceptance evidence: - stable Work, Calendar, Files and existing Messages product entries replace authorized owner/package entries in the ordinary rail; - owner routes remain compatible deep links and are exposed in the permission-derived **All available tools** catalogue; - All available tools is deliberately independent of active View focus, while still enforcing authorization; - composed product entries remain active on owner paths and respect configured product-area ordering; - centralized bilingual labels and unavailable explanations avoid module-specific wording drift; - module administration/provenance remains available without leaking package topology into ordinary task navigation; - the Anwohnerparkausweis conformance journey renders Arbeit, Dateien, Nachrichten and Kalender without package labels and expands the technical catalogue accessibly. Verification: 681 Core backend tests, module-capability tests, 63 module permutations, production bundle budget, 13 Playwright conformance journeys, 72/72 manifest validation and the complete workspace-focused check. The immutable release lock and all remote refs were verified after push.

zemion removed the

status

in-progress

label 2026-08-24 18:32:09 +02:00

zemion closed this issue

2026-08-24 18:32:10 +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#283