govoplan/docs/PRODUCT_EXPERIENCE_AND_MODULE_BOUNDARIES.md

Product Experience and Module Boundaries

Problem

GovOPlaN's runtime modularity is a strength, but the implementation structure is exposed too directly in the product. Ordinary users encounter module names, one top-level route per module, one navigation item per repository, package and provider identifiers, and errors framed as missing modules. This makes the system look like a toolbox of adjacent applications instead of one operating environment for institutional work.

The correction is not a monolithic frontend and not hidden provenance. It is a separate product information architecture assembled from typed module contributions.

Implementation is tracked in Core #283. The accepted configurable product-area and task-local tool design is defined in Quick Access And Product Areas.

Current Exposure Inventory

Surface	Direct exposure	Appropriate audience	Product-facing alternative
Side rail	One icon and route for many installed modules	Administrators and power users	Work areas, services, inboxes, records, communication, data and assurance
Route paths	Technical owners such as /dataflow, /forms, or /postbox	Deep links and diagnostics	Stable product aliases and journey routes that resolve to owner surfaces
Dashboard	Installed module count and module-owned widget library	Operators	Outcome, obligation, work, exception, and service widgets
Administration	Package names, database state, capabilities, providers	Module and system administrators	Guided product/package configuration with technical details on demand
Errors	"Module/capability not installed"	Diagnostics	Explain the unavailable outcome, responsible administrator, and enabling path
Documentation	Topics grouped primarily by module	Administrators	Task, role, service, and object documentation with module provenance secondary
Permissions	Module-namespaced scopes	Access administrators	Human-readable responsibility bundles; exact scopes remain inspectable
Search	Provider/module as a result facet	Advanced filtering	Object type, institution, time, purpose, case/service, and source authority
Workflow	Steps can expose target route/module details	Workflow designers	User-facing action and expected result; technical binding in definition details
Connector state	Provider IDs and source types	Integration owners	Named source, authority, freshness, health, last effect, and recovery state

Boundary Decision

Three layers remain distinct:

1. Technical module layer: package ownership, dependencies, capabilities, permissions, migrations, routes, and provider identifiers.
2. Product composition layer: work areas, object types, journeys, commands, inboxes, configuration packages, and role-based defaults.
3. Presentation projection: active view, tenant policy, current task, temporal context, language, accessibility preferences, and device layout.

Modules own implementation and contribute typed product metadata. Core assembles it. Views filters it. Policy constrains it. Access authorizes the underlying actions. No consumer imports another optional module's UI directly.

Product Surface Contract

Each WebUI module should be able to announce:

• product_areas: stable areas to which a route, command, widget, or object belongs;
• object_types: user-facing nouns, icons, search context, detail route, and owner provenance;
• work_item_sources: open work, exceptions, deadlines, and responsible capacity;
• journey_actions: launch, resume, review, correct, decide, publish, and reconcile commands;
• workspace_surfaces: embeddable but owner-rendered list, detail, editor, and status surfaces;
• configuration_contributions: guided settings with consequence and prerequisite metadata;
• help_contexts: user/admin documentation for the product identity as well as the technical owner;
• technical_provenance: module, interface version, capability, and provider identifiers shown only in details and evidence.

The contract references surfaces. It does not permit Core or a product package to import their implementation.

Navigation Model

The default shell should prioritize:

1. global search and create/resume commands;
2. personal and function-bound work;
3. configured product areas;
4. pinned user destinations;
5. administration and technical module inspection when authorized.

The baseline product areas are Work, Services and Cases, Records and Documents, Communication, Meetings and Decisions, Data and Assurance, and People and Responsibility. They are configurable system/tenant defaults and Views projections, not hard-coded repository groups. Empty areas disappear; single-destination areas may link directly; familiar tools may remain pinned.

The complete permission-derived module rail remains available as All available tools. Its ability to scroll is useful and is not itself the product defect. The defect is requiring people to infer a task or outcome from repository topology.

Task-local Work, Calendar, Messages and Files tools may be contributed to the optional govoplan-quick-access rail. Messages composes Mail, Postbox and future governed chat presentation without merging their channel semantics or state.

A module route remains a valid deep link. A product area may combine links and owner-rendered surfaces from several modules. When a required contribution is absent, the area explains the missing outcome rather than rendering a broken placeholder.

Views remain the projection mechanism. They may select product areas, routes, sections, commands, widgets, and fields. A view must not grant a permission or change data semantics. Policy can force, allow, or prohibit a surface at system, tenant, group, or user scope.

Error And Provenance Language

Normal errors answer:

• what the person was trying to achieve;
• why it is unavailable or failed;
• whether data was saved or an external effect may have occurred;
• who can resolve it and where;
• the correlation/evidence reference.

An expandable technical section may then identify the module, capability, provider, request, and version. This keeps the product intelligible without hiding operational truth.

Migration

Core's product-area and Quick Access contracts, the optional Quick Access module, the first five providers and immutable View presentation revisions are implemented. The migration below now concerns broader classification and product-language adoption; it is not a prerequisite for safely enabling the first rail slice.

Slice 1: inventory and aliases

• classify every route, navigation item, widget, setting, search object, and help context by product area and object type;
• add product aliases without removing existing deep links;
• flag raw module IDs in ordinary-user labels and errors.

Slice 2: work-first shell

• provide a generic work/exception/deadline aggregation capability;
• make work areas and configured packages the default navigation;
• move the complete module catalogue to administration and an optional power- user surface.
• implement the configurable Quick Access rail through Core-mediated contributions, system/tenant/user resolution and View/Policy ceilings.

Slice 3: composite journeys

• let product packages define journey launch/resume actions and default views;
• let Workflow Engine activate a view and focus an owner surface without controlling authorization;
• expose provider provenance and technical bindings on demand.

Slice 4: enforceability

• make product classification mandatory for user-visible manifest surfaces;
• reject duplicate product identities and missing owner routes in CI;
• add browser tests proving that reference users can complete a journey without knowing module names.

Acceptance Criteria

• An ordinary user can describe every primary navigation item as work or an institutional object, not as a package.
• A product package can remove irrelevant navigation while retaining deep-link and help integrity.
• Missing optional modules produce an actionable product explanation.
• Administrators can still inspect exact module, capability, provider, schema, and evidence provenance.
• Module permutation tests prove that no product surface assumes an optional owner is installed.