govoplan-core/docs/GOVOPLAN_MASTER_ROADMAP.md

GovOPlaN Master Roadmap

This roadmap is the technical and module-sequencing companion for GovOPlaN as a modular platform for administrative operations. It translates the cross-product outcome horizons into dependency waves without turning every possible public-sector need into an immediate implementation track.

Use this document for technical sequencing, module routing, and implementation gates. Issues are the active backlog; this document is durable architecture planning context and should be mirrored to the Gitea wiki.

The meta repository's Connected Governance Platform Roadmap describes the corresponding cross-product stakeholder visions, configurable service and operating configurations, connected outcome stories, and capability horizons. The selected five-stage delivery sequence and its gates are in the meta repository's Reference Journey Program. Those product documents are canonical; this Core roadmap remains their technical sequencing and module-routing companion.

Product Thesis

GovOPlaN should become a configurable operations platform for public institutions. It should help an institution model real administrative procedures, connect existing systems, keep durable evidence, and explain the configured system to users.

The goal is not to replace every existing system. GovOPlaN should connect existing systems, provide better workflows where the current landscape is weak, and make administrative processes configurable, auditable, and reusable.

The product should first provide a reliable administrative spine:

• identities, roles, tenants, policy, audit, and governance
• forms, files, cases, workflow, tasks, templates, and records
• postboxes, notifications, mail, portal, appointments, and booking
• identity trust, role-bound postboxes, and eventually encrypted administrative communication
• configuration packages that assemble modules into repeatable procedures
• docs that explain the configured system, not the full theoretical product

Domain modules should come after the spine can run a reference procedure end to end.

The platform should be a governance-capable runtime for modules, connectors, configuration, and administrative decisions. The kernel must stay free of domain semantics while still providing the contracts needed for modules to explain what they do, what they require, which effects they create, and how operators can verify or reverse those effects.

Design Principles

• Modules must stay independently installable, enableable, and disableable.
• Cross-module behavior should use core-mediated capabilities, commands, events, DTOs, and UI contribution points rather than direct imports.
• Configuration packages should turn installed modules into concrete, reusable administrative processes.
• Operators should be able to configure the platform through the UI.
• Every powerful configuration path needs preflight, preview, audit, rollback, RBAC, and policy checks.
• Context, decision, consequence, and traceability must be visible together for consequential actions. The full doctrine lives in INTERFACE_ETHICS_AND_DESIGN_DOCTRINE.md.
• Automation must use governed action/effect contracts, not hidden side effects. The first automation layer is defined in ACTION_EFFECT_AUTOMATION_LAYER.md and should start in govoplan-workflow unless a separate automation module becomes justified.
• Encrypted postboxes are a strategic target. Early postbox, access, and identity-trust contracts should stay compatible with the E2EE architecture in POSTBOX_E2EE_ARCHITECTURE.md.
• Integration should be a first-class product path: connect to existing systems, consume their data, and publish governed outputs back to them.
• GovOPlaN should scale from a small local installation to a larger deployment with separately scalable web, API, worker, storage, and database components.

User Experience Direction

GovOPlaN should expose the full power of the platform without forcing non-technical users to face every field, flag, and internal representation at once. The default experience should feel guided, explainable, and calm. Expert depth should remain available, but it should be layered behind deliberate interaction patterns.

Core UX rules:

• Use progressive disclosure. Common decisions stay visible; advanced, hazardous, or rarely used options live in collapsed panels, secondary steps, or explicit advanced areas.
• Do not use raw JSON as the primary configuration UI. Every configurable value should have an appropriate control, validation, and plain-language help. Import/export and diagnostics may show JSON as a secondary artifact.
• Prefer guided flows over option dumps. Connector setup, package import, module installation, policy changes, and destructive operations should use wizards that explain what is happening, why it matters, and what will happen next.
• Discover values when the system can infer them. For example, a Nextcloud file connection should start with the base URL, discover the WebDAV endpoint, and fill technical fields for review instead of asking the user to know them upfront.
• Make explanations always available without making every screen verbose. Inline helper text should be short; richer explanations should be reachable through expandable help, tooltips, side panels, or review steps.
• Explain blocked actions in actionable language. A disabled control or failed step should say what is missing, who can fix it, and where to go, for example "A system administrator must allow this provider" or "Configure the provider in Settings > File Providers before linking a folder here."
• Reuse visual language and placements consistently. Similar configuration, policy, connection, credential, review, and confirmation flows should share components, button placement, modal behavior, problem lists, and empty/error states.
• Use modals and step flows for focused creation/editing where they reduce page clutter. Reserve large always-open pages for overview, comparison, and repeated administration work.
• Treat diagnostics as product UX. Validation results, preflight blockers, policy explanations, permission denials, and missing capabilities should be understandable to a non-technical operator before exposing internal details.

This is a product quality gate. New admin/configuration surfaces should not be considered complete if they expose all options at once, require JSON editing, hide why an action is unavailable, or use a one-off layout where a shared pattern exists.

Focus Rules

1. Build one selected reference journey stage at a time; a later capability cluster is not an active program merely because it appears below.
2. Do not implement a module because the repository exists.
3. Do not add module-to-module imports for optional behavior.
4. Every new domain module must justify its own semantics beyond cases, workflow, tasks, forms, and files.
5. Prefer connector first when an external specialist system is likely to remain the system of record.
6. Keep active work in Gitea issues; keep durable context in docs and synced wiki pages.
7. A module moves from scaffold to implementation only when it has an owner, reference journey, boundary notes, capability contracts, and testable MVP.

Capability Map

Capability	Likely owner
Public application entry point	govoplan-portal
Structured forms and validation	govoplan-forms
Uploaded files and managed storage	govoplan-files
Case record and lifecycle	govoplan-cases
Workflow transitions and automation	govoplan-workflow
Action/effect catalogue and automation runner	first govoplan-workflow; possible future govoplan-automation if it outgrows workflow
Internal work queues and tasks	govoplan-tasks
Appointment proposals and booking	govoplan-appointments, govoplan-calendar
Postbox, email, and notifications	govoplan-postbox, govoplan-mail, govoplan-notifications
Canonical subjects and account links	govoplan-identity
Organizational structures, units, and functions	govoplan-organizations
Identity-to-function assignments and directory synchronization	govoplan-idm
Identity trust, device keys, and encrypted postbox key contracts	govoplan-identity-trust, govoplan-access, govoplan-postbox
Service directory/catalog	govoplan-portal
Permit/document generation	govoplan-templates, govoplan-dms
Payment capture and accounting handoff	govoplan-payments, govoplan-ledger
Authentication projection, roles, permissions, acting context	govoplan-access
Tenants, policy, and audit	govoplan-tenancy, govoplan-policy, govoplan-audit
External software integration	govoplan-connectors
Recurring extraction and transformation	possible future govoplan-datasources, possible future govoplan-dataflow
Reports, BI, and management visibility	govoplan-reporting

Configuration And Safety Target

The long-term target is that operators configure the platform through the UI instead of editing files for normal operation.

UI-managed configuration should include:

• module installation, enablement, lifecycle state, and health
• tenants, users, groups, roles, policies, and permissions
• connectors, credentials, secret references, and external service tests
• workflows, forms, templates, task queues, schedules, and notifications
• configuration package import/export and environment-specific data collection
• retention, audit, privacy, maintenance mode, and safety controls
• deployment-visible settings such as public URLs, mail senders, storage profiles, queues, and worker capabilities

Safety controls should include dry-run plans, field-level validation, policy explanations, two-person approval for destructive changes, versioned configuration history, rollback paths, audit events, and maintenance-mode guards.

The initial safety metadata contract lives in govoplan_core.core.configuration_safety. It classifies known configuration fields as UI-managed or deployment-managed, assigns risk levels, marks secret handling as reference-only or env-only, and declares dry-run, policy explanation, audit, approval, rollback-history, maintenance-mode, and RBAC requirements. Admin UI editors should consume this metadata before exposing powerful settings.

The initial executable guardrail path is plan_configuration_change(...), exposed through:

• GET /api/v1/admin/configuration-safety
• POST /api/v1/admin/configuration-safety/plan

The planner reports missing scopes, dry-run requirements, maintenance-mode requirements, two-person approval status, secret-reference violations, rollback-history requirements, policy explanations, and audit event names before an editor applies a high-impact configuration change.

Reference Journeys

The active sequence is selected. Workflow remains deliberately deferred and is not a dependency of these journeys.

Journey 1: Campaign Demonstration Composition

Campaign is the first complete proof of modular composition. Campaign owns intent, recipient snapshots, personalization, execution state, and delivery evidence. Mail owns reusable profiles, credentials, protocol policy, and provider execution; Campaign stores only a selected profile reference. Files owns storage, connector profiles, file policy, and provenance.

The technical gate is a pinned Campaign/Mail/Files composition with central UI, adaptive user/admin/operator/integration documentation, target SMTP/IMAP and file-provider evidence, and explicit test/send/resend/retry/reconciliation semantics. Readers must not receive backend paths, worker claims, secrets, or raw provider diagnostics.

Journey 2: Function-Bound Postbox Delivery

Postbox accepts delivery to an addressable postbox or a function in an organizational unit. Organizations owns units and functions, Identity owns subjects, IDM owns identity-to-function assignments and upstream sync, and Access resolves current roles, delegation, acting context, and permission.

Campaign consumes a typed delivery-target capability without importing Postbox or identity internals. Reassignment changes future access without moving the message; vacancy or ambiguous acting context fails visibly; delivery, access, and correction remain auditable.

Journey 3: Data-Backed Templates, Reports, And Deep Launch

An authenticated user follows an opaque, short-lived launch reference from HIS or another specialist system. GovOPlaN re-authorizes the actor, resolves a curated data context server-side, displays source/freshness/version, and renders one reproducible document and report.

Templates owns definition/version/schema/rendering, Reporting owns source selection/parameters/execution/export, Files owns generated bytes, and connectors own protocol access. URLs do not carry credentials, arbitrary SQL, or trusted raw personal data. Retries are idempotent and generation evidence connects source, snapshot/reference, transformation, definition, parameters, output checksum, actor, and policy.

Journey 4: Governed University BI Path

Starting from the Journey 3 source contract, one bounded university dataset is catalogued, staged by snapshot or watermark, validated, transformed through a versioned lineage graph, and exposed as a policy-aware analytical data product. The result must preserve official-key mappings, organizational and reporting date semantics, quality findings, quarantine/replay, transparent calculation, and reproducible promotion between development, test, and production.

Reporting consumes the product. Create govoplan-datasources or govoplan-dataflow only after the concrete path proves repeated ownership that does not belong to connectors, Reporting, or the producing domain module.

Journey 5: Collaborative Document Lifecycle

An uploaded or generated artifact becomes a DMS document. Files continues to own bytes; DMS owns identity, versions, renditions, editing sessions, locks, comments, review, approval, comparison, and recovery; a collaboration connector owns provider-specific protocol behavior; Records owns later classification, hold, archive, and disposal.

The gate requires no silent lost updates, short-lived and currently authorized editing sessions, idempotent authenticated callbacks, visible uncertain saves, immutable accepted renditions, and a Records-ready handoff with stable content and provenance.

Capability Dependency Waves

The waves below remain a dependency and ownership catalogue for the wider product vision. They are not the active delivery order. The five selected journeys above and the meta roadmap decide what is implemented now; other clusters remain dormant until a selected journey consumes them or they are explicitly reprioritized.

Wave 0: Platform Spine

Goal: make the platform safe to configure and extend.

Refine:

• govoplan-core: module discovery, capabilities, events, migrations, release catalog, configuration package runtime, WebUI shell.
• govoplan-identity: canonical identities and account links.
• govoplan-organizations: organizational structures, units, and functions.
• govoplan-idm: identity-to-function assignments, directory synchronization, preview, conflicts, and reconciliation.
• govoplan-access: sessions, API keys, users, groups, roles, memberships, function-to-role projection, delegation, acting context, and RBAC decisions.
• govoplan-tenancy: tenant lifecycle and tenant boundaries.
• govoplan-identity-trust: initial trust contracts for device keys, public key directory, assurance, and later encrypted postbox key access.
• govoplan-policy: policy sources, policy decisions, retention inputs.
• govoplan-audit: audit sink, audit routes, trace context, retention cooperation.
• govoplan-admin: UI-managed configuration with preflight, rollback, audit, and approval controls.
• govoplan-dashboard: configurable user home assembled from module-provided widgets, with core providing only a minimal fallback when the module is absent.
• govoplan-docs: configured-system documentation and evidence-aware help.
• govoplan-ops: deployment profiles, health checks, worker split, sizing assumptions.

Do not expand domain scope in this wave. The output is a dependable platform surface for later modules.

Exit criteria:

• module enablement and capability lookup are stable
• configuration package preflight works for at least one simple package
• audit and policy decisions are visible in admin flows
• access distinguishes identity, account, function, role, and right in durable contracts
• action/effect automation contracts are specified before hidden side effects spread across modules
• docs can show installed/enabled modules and configured routes

Wave 1: Permit-To-Payment MVP

Goal: one complete public-administration process.

Create or refine in this order:

1. govoplan-forms-runtime: form submissions, drafts, validation, attachments, and submission evidence.
2. govoplan-portal: public authenticated and unauthenticated entry points.
3. govoplan-files: upload, evidence links, file spaces, and permissioned access.
4. govoplan-cases: case record, status, assignments, deadlines, and case evidence.
5. govoplan-workflow: state machine, transitions, commands, and module handoff.
6. govoplan-tasks: work queues, assignments, due dates, and follow-ups.
7. govoplan-templates: permit/decision document generation.
8. govoplan-postbox, govoplan-mail, govoplan-notifications: applicant and internal communication, with the postbox model compatible with later E2EE and role-bound access.
9. govoplan-calendar, govoplan-appointments, govoplan-booking: appointment or booking handoff for the reference process.
10. govoplan-payments, govoplan-ledger, govoplan-xrechnung: payment capture, payment evidence, and accounting/e-invoice handoff.

Exit criteria:

• a permit-to-payment package can be installed in a local demo
• every step has audit evidence
• every module integration uses capabilities, events, or DTOs
• user-facing documentation describes only the configured process

Wave 2: Booking And Resource Operations

Goal: make time, capacity, and resource allocation a reusable product area.

Create or refine in this order:

1. govoplan-booking: booking rules, capacity, quotas, waitlists, cancellation, attendance, no-shows, and approvals.
2. govoplan-resources: rooms, equipment, vehicles, counters, labs, capacity, availability, and maintenance blocks.
3. govoplan-calendar: event and availability integration.
4. govoplan-appointments: appointment-specific booking surfaces.
5. govoplan-facilities: buildings, rooms, maintenance, access zones, inspections, and defects.
6. govoplan-assets: inventory, assignment, lifecycle, maintenance, and handover evidence.

Reference journey: reserve a room/resource for a training or appointment and preserve all booking evidence.

Exit criteria:

• bookable resources are not hardcoded into appointments
• booking decisions are explainable and auditable
• resources can be blocked by maintenance or facility status

Wave 3: Training And Certificates

Goal: support university-style and internal public-sector training without building a full learning-management system first.

Create or refine in this order:

1. govoplan-learning: course planning, course booking, participant lists, trainers, attendance, evaluations, and learning records.
2. govoplan-certificates: participation confirmations, certificates, verification, revocation, and evidence links.
3. govoplan-booking, govoplan-resources, govoplan-calendar: reuse booking and room/resource allocation.
4. govoplan-templates, govoplan-files, govoplan-records: certificate generation and durable retention.

Reference journey: plan a course, book resources, register participants, track attendance, and issue a certificate.

Exit criteria:

• attendance can produce certificate eligibility
• certificates can be verified later
• course operations do not depend on university-specific assumptions

Wave 4: Report-To-Resolution Operations

Goal: cover internal support and public issue reporting.

Create or refine in this order:

1. govoplan-issue-reporting: public/internal reports, categories, intake, location, evidence, and triage.
2. govoplan-helpdesk: service desk tickets, queues, SLAs, assignments, escalation, and resolution evidence.
3. govoplan-facilities and govoplan-assets: issue handoff to maintenance or asset lifecycle.
4. govoplan-cases, govoplan-workflow, govoplan-tasks: escalation into formal administrative matters.
5. govoplan-reporting: workload, SLA, recurring defects, and status reports.

Reference journey: report a facility issue, triage it, assign work, resolve it, and report recurring defects.

Exit criteria:

• issue reporting is not just a generic form inbox
• helpdesk tickets can remain lightweight unless formal case handling is needed
• operational metrics exist without custom SQL

Wave 5: Records, DMS, Transparency

Goal: make evidence legally and organizationally durable.

Create or refine in this order:

1. govoplan-dms: document lifecycle, collaboration, versions, locks, approvals, and DMS connectors.
2. govoplan-records: file plans, classification, retention schedules, disposal holds, archive handoff, and records evidence.
3. govoplan-policy and govoplan-audit: retention policy, legal hold, audit traceability.
4. govoplan-search: permissioned cross-module discovery.
5. govoplan-transparency: FOI/public-records requests, redaction, publication, and disclosure evidence.

Reference journey: close a case, classify records, apply retention, and answer a transparency request.

Exit criteria:

• files, documents, and records are not treated as the same concept
• transparency disclosure can redact and explain evidence
• retention and archive handoff are policy-governed

Wave 6: Finance, Procurement, Contracts, Grants

Goal: cover the back-office procedures around spending, obligations, funding, and revenue without replacing a finance system too early.

Create or refine in this order:

1. govoplan-procurement: purchase requests, approvals, vendor comparison, tender references, goods receipt, and handoff.
2. govoplan-contracts: contract register, obligations, renewals, reminders, and responsible units.
3. govoplan-grants: funding programs, applications, eligibility, awards, milestones, claims, and reporting duties.
4. govoplan-payments, govoplan-ledger, govoplan-xrechnung: payment, accounting, and e-invoice handoff.
5. govoplan-erp: integration with the actual system of record, not a full ERP replacement unless later justified.

Reference journey: purchase or grant approval through obligation tracking and financial handoff.

Exit criteria:

• ERP remains an integration point unless GovOPlaN must own semantics
• contracts and grants produce obligations, deadlines, and reporting tasks
• financial evidence links back to cases, files, and audit

Wave 7: Institutional Governance And Participation

Goal: support public bodies, municipalities, ministries, and universities in formal coordination.

Create or refine in this order:

1. govoplan-committee: committees, boards, councils, agendas, minutes, decisions, voting, and follow-up tasks.
2. govoplan-consultation: hearings, public consultations, stakeholder feedback, formal comments, response matrices, and publication workflows.
3. govoplan-campaign: communication campaigns, recipients, templates, review, sending control, and reports.
4. govoplan-addresses: persons, organizations, contacts, distribution lists, and recipient import/export.
5. govoplan-portal and govoplan-transparency: public participation and publication surfaces.

Reference journey: prepare a committee decision, publish consultation material, collect feedback, document the decision, and assign follow-up tasks.

Exit criteria:

• decisions create durable tasks and records
• consultations can publish evidence without exposing restricted material
• campaign and address behavior stays optional and capability-based

Wave 8: Integration, Data, And Reporting

Goal: connect the platform to real institutional landscapes.

Refine:

• govoplan-connectors: integration catalog, connector metadata, adapter lifecycle, test harnesses.
• govoplan-idm, govoplan-identity-trust: identity provider, directory, and assurance integration.
• govoplan-fit-connect, govoplan-xoev, govoplan-xta-osci: public-sector transport and standards integration.
• govoplan-reporting: operational reporting, scheduled outputs, exports, and dashboard data.
• govoplan-search: permissioned cross-module discovery.

Create only when justified:

• govoplan-datasources: source catalog, connection profiles, schema discovery, freshness, provenance.
• govoplan-dataflow: transformations, validation, lineage, scheduled runs, publication outputs.
• govoplan-projects: only if OpenProject connectors and existing cases/tasks cannot cover the required semantics.

Reference journey: monthly data extraction, transformation, validation, approval, publication, and reporting.

Recurring extraction/transformation should start as a configuration package across connectors, files, workflow, reporting, and templates. The package should register sources, declare schemas, define mapping/validation versions, schedule runs, produce previewable diffs, write governed outputs, and preserve lineage, hashes, operator actions, and audit evidence. Create govoplan-datasources or govoplan-dataflow only after this work exposes repeated contracts that do not belong to existing modules.

Exit criteria:

• connector catalog exists before building many adapters
• dataflow is created only after recurring transformation becomes product behavior
• reporting consumes governed sources with provenance

Implementation Gates

Before a module receives implementation work, it needs:

• one reference journey step it owns
• ownership and boundary notes
• initial manifest and permission list
• capability contracts or API DTOs
• audit and policy expectations
• Gitea issues for MVP tasks
• docs page that can sync to the wiki
• focused tests that can run from the core environment

Before a module becomes release-included, it needs:

• installable Python package metadata where applicable
• WebUI package metadata where applicable
• module manifest entry point
• release catalog entry
• smoke test or permutation test
• no required imports from optional modules

Technical Dependency Order Summary

Use this active order while respecting the ownership and implementation gates in the capability waves:

1. Keep the platform/release spine green and extend connector, identity, external-effect, provenance, documentation, focused-view, recovery, and version contracts only as the current journey requires.
2. Complete and package Campaign with Mail-owned profiles, Files, target delivery/recovery, central UI, and adaptive documentation.
3. Implement function-bound Postbox delivery through Organizations–Identity–IDM–Access and consume it from Campaign through a typed capability.
4. Implement one data-backed Templates/Reporting path and safe HIS-style deep launch.
5. Extend that concrete source into one governed university analytical data product before generalizing data-source or dataflow ownership.
6. Implement Files-backed DMS versions and one provider-neutral collaborative editing lifecycle, then connect Records handoff.
7. Maintain already integrated Calendar/Scheduling/Poll and other foundations; activate another capability cluster only when the current journey needs it or the product roadmap explicitly reprioritizes it.
8. Resume Workflow only by explicit product decision and constrain it with stable actions from one demonstrated package.

Deliberate Deferrals

Defer these until a reference journey proves the need:

• full ERP replacement
• native project management beyond connector support
• an unbounded general-purpose dataflow platform; the bounded governed BI reference journey is selected
• every possible public-sector protocol adapter
• rich LMS behavior beyond training administration
• full qualified digital signing/trust services beyond the identity-trust and encrypted-postbox contracts needed for early architecture safety
• mobile apps
• AI assistants embedded into workflows

These may become important, but they should not distract from the first complete administrative journeys.

Module And Integration Routing

This table maps current module and integration ideas to existing GovOPlaN repositories or to explicit missing-module decisions.

Idea	Owner	Tracking
Government operations backbone reference model	govoplan-core	GovOPlaN/govoplan-core#213
Permit-to-payment configuration package	govoplan-core plus participating modules	GovOPlaN/govoplan-core#214
Fully UI-managed configuration with safety controls	govoplan-admin, govoplan-core, govoplan-policy, govoplan-access, govoplan-audit	GovOPlaN/govoplan-core#218
Access as a module	govoplan-access	GovOPlaN/govoplan-access#7
Interface ethics and decision-consequence doctrine	govoplan-core plus all UI-owning modules	GovOPlaN/govoplan-core#227
Action/effect automation layer	first govoplan-workflow; possible future govoplan-automation	GovOPlaN/govoplan-workflow#1
E2EE role/function postbox architecture	govoplan-postbox, govoplan-identity-trust, govoplan-access, govoplan-policy, govoplan-audit	GovOPlaN/govoplan-postbox#15, GovOPlaN/govoplan-identity-trust#1
Identity, account, function, role, right semantic model	govoplan-access	GovOPlaN/govoplan-access#9
Role-based service directory/catalog	govoplan-portal	GovOPlaN/govoplan-portal#1
Unified inbox across tasks, postbox, notifications, and portal	govoplan-core coordination plus owning modules	GovOPlaN/govoplan-tasks#1, GovOPlaN/govoplan-notifications#1
OpenProject API / project management connector	govoplan-connectors	GovOPlaN/govoplan-connectors#1
Native project-management module decision	connector-first through govoplan-connectors; no native project module yet	GovOPlaN/govoplan-core#196, GovOPlaN/govoplan-connectors#1
Datasources for databases, CSV, files, APIs	no repository yet; start with connectors/files/reporting and create govoplan-datasources only after the first package proves shared source-catalog ownership	GovOPlaN/govoplan-core#197
Dataflow for pipelines, BI, publication	no repository yet; start with workflow/reporting/connectors and create govoplan-dataflow only after repeated pipeline/lineage contracts emerge	GovOPlaN/govoplan-core#198
Monthly datasource and transformation workflows	first as configuration package across connectors, files, workflow, reporting, and templates	GovOPlaN/govoplan-core#216
Templates for letters, emails, forms, reports	govoplan-templates, separate from reporting	GovOPlaN/govoplan-core#190, GovOPlaN/govoplan-templates#1
Reporting and BI	govoplan-reporting, separate from templates	GovOPlaN/govoplan-core#190, GovOPlaN/govoplan-reporting#1
File connectors: Nextcloud, Seafile, SMB, NFS	govoplan-files	GovOPlaN/govoplan-files#15
Public-sector software integration catalogue	govoplan-connectors with core strategy index	GovOPlaN/govoplan-core#191, GovOPlaN/govoplan-connectors#2
Public-sector integration landscape catalogue	govoplan-connectors with core tracking	GovOPlaN/govoplan-core#215
Cases module concept	govoplan-cases	GovOPlaN/govoplan-core#174
Workflow module concept	govoplan-workflow	GovOPlaN/govoplan-core#175
Connectors module concept	govoplan-connectors	GovOPlaN/govoplan-core#176
Adrema-style address and distribution-list management	govoplan-addresses	GovOPlaN/govoplan-addresses#1
Consume sources and become a governed source	govoplan-connectors plus possible future govoplan-dataflow	GovOPlaN/govoplan-connectors#3, GovOPlaN/govoplan-core#198
Governed connector configuration, dry-run, and simulation runtime	govoplan-connectors	GovOPlaN/govoplan-connectors#6
Terminfindung and meeting scheduling polls	govoplan-scheduling; calendar primitives remain in calendar	GovOPlaN/govoplan-core#193, GovOPlaN/govoplan-scheduling#1
Terminplaner and calendar primitives	govoplan-calendar	GovOPlaN/govoplan-core#193, GovOPlaN/govoplan-calendar#1
Terminbuchung appointment booking	govoplan-appointments	GovOPlaN/govoplan-core#193, GovOPlaN/govoplan-appointments#1
Collaborative documents	govoplan-dms	GovOPlaN/govoplan-dms#1
Forms	govoplan-forms for definitions and govoplan-forms-runtime for submissions/runtime behavior	GovOPlaN/govoplan-core#194, GovOPlaN/govoplan-forms#1
RSS consume and emit	govoplan-connectors	GovOPlaN/govoplan-connectors#4
LDAP, Active Directory, OpenDesk identity	govoplan-idm	GovOPlaN/govoplan-idm#1
OpenDesk stack integration map	integration profile across IDM/access, mail/calendar, files/DMS, and connectors; not a monolithic module	GovOPlaN/govoplan-core#195, GovOPlaN/govoplan-connectors#5
Open-Xchange mail/groupware	govoplan-mail	GovOPlaN/govoplan-mail#5
Open-Xchange calendar	govoplan-calendar	GovOPlaN/govoplan-calendar#2
Scalability profiles and autoscaling readiness	govoplan-ops, govoplan-core	GovOPlaN/govoplan-core#217
Hardware sizing matrix and requirements calculator	govoplan-ops, govoplan-core	GovOPlaN/govoplan-core#219
Collaboration suite integration strategy	govoplan-connectors, govoplan-dms, govoplan-workflow, govoplan-tasks, govoplan-appointments, govoplan-calendar	GovOPlaN/govoplan-core#220
Install/runtime configuration contract	govoplan-core, later govoplan-ops	GovOPlaN/govoplan-core#19
Installer/deployment operator flow	govoplan-core, later govoplan-ops	GovOPlaN/govoplan-core#26
Production-like deployment documentation	govoplan-core, later govoplan-ops	GovOPlaN/govoplan-core#28

Boundary rationale lives in MODULE_ARCHITECTURE.md. Current decisions:

• templates and reporting are separate modules
• RSS/source consume-publish starts in connectors; datasources/dataflow are not repositories yet
• calendar, scheduling, and appointments are three separate modules
• forms definitions and forms runtime are separate responsibilities
• OpenDesk is an integration profile across modules, not a monolithic module
• OpenProject is connector-first; no native projects module yet
• public-sector integration strategy stays in core; executable catalogue work lives in connectors
• encrypted postbox and identity-trust are strategic contracts, not mail-module behavior
• automation starts as workflow-owned action/effect execution and may split into a dedicated module only after the runner becomes broader than workflow

The following modules are intentionally not created yet:

• govoplan-datasources
• govoplan-dataflow
• govoplan-projects

Create a repository only after a concrete implementation package proves that existing connector, files, reporting, workflow, or task ownership is too narrow.

Core keeps the strategy index in PUBLIC_SECTOR_INTEGRATION_STRATEGY.md: integration postures, default ownership, and prioritization rules. govoplan-connectors owns the detailed target inventory and connector entry shape in govoplan-connectors/docs/PUBLIC_SECTOR_INTEGRATION_CATALOGUE.md.

Release composition and tag-only repository handling are documented in RELEASE_DEPENDENCIES.md.

Next Practical Work

The active cross-product story is GovOPlaN/govoplan#14. Module repositories own implementation issues; do not clone their state here.

Immediate issue buckets:

• fail-closed connector destination pinning and private-network deployment control for every real transport
• Mail-profile-only Campaign authoring/build/delivery and safe legacy failure
• immediate audited secret deletion when a provider/profile is removed
• Campaign central-component and role-safe UI acceptance
• adaptive Campaign, Mail, and Files task/process/admin/operator/integration/ security/acceptance documentation
• target SMTP/IMAP, file-provider, queue/reconciliation, install/upgrade, and restore proof for the pinned Campaign reference composition

Once that gate is demonstrable, activate the existing Postbox model, access, API, inbox, and Campaign integration issues. Templates/Reporting, governed BI, and DMS collaboration remain durable selected direction, but should be decomposed only as the preceding stage stabilizes or a bounded independent contract can be implemented without pre-deciding target-system choices.