5

Repo docs GOVOPLAN MASTER ROADMAP

Albrecht Degering edited this page 2026-07-09 15:06:17 +02:00

Table of Contents

• GovOPlaN Master Roadmap
• Product Thesis
• Design Principles
• User Experience Direction
• Focus Rules
• Capability Map
• Configuration And Safety Target
• Reference Journeys
• Journey 1: Permit To Payment
• Journey 2: Training To Certificate
• Journey 3: Report To Resolution
• Roadmap Waves
• Wave 0: Platform Spine
• Wave 1: Permit-To-Payment MVP
• Wave 2: Booking And Resource Operations
• Wave 3: Training And Certificates
• Wave 4: Report-To-Resolution Operations
• Wave 5: Records, DMS, Transparency
• Wave 6: Finance, Procurement, Contracts, Grants
• Wave 7: Institutional Governance And Participation
• Wave 8: Integration, Data, And Reporting
• Implementation Gates
• Priority Order Summary
• Deliberate Deferrals
• Module And Integration Routing
• Next Practical Work

Mirrored from /mnt/DATA/git/govoplan-core/docs/GOVOPLAN_MASTER_ROADMAP.md. Origin: repository. Active tasks and changing state belong in Gitea issues; this wiki page is durable project context.

---

GovOPlaN Master Roadmap

This roadmap is the durable product north star and sequencing guide for GovOPlaN as a modular platform for administrative operations. It keeps the product moving without turning every possible public-sector need into an immediate implementation track.

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

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 reference journey per wave.
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
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
Roles, permissions, tenants, policy, audit	govoplan-access, 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 roadmap should be driven by three journeys.

Journey 1: Permit To Payment

This is the primary public-administration journey.

1. A person applies for a permit through the public portal.
2. The applicant uploads required files and submits structured form data.
3. Submission creates a case, a workflow instance, and an internal task.
4. Completing the task creates a postbox message, a notification, and an email notification with an appointment proposal.
5. The applicant accepts an appointment, which updates the calendar and the workflow state.
6. During the appointment, the case is opened and the permit is generated from a governed template.
7. The payment is processed and linked to the case and accounting handoff.
8. The permit, payment evidence, communication history, audit trail, retention state, and records evidence remain available according to policy.

This journey proves the platform can coordinate modules without core knowing module internals.

Journey 2: Training To Certificate

This is the best university-administration and internal-administration journey.

1. Course or training offer is planned.
2. Room, trainer, resource, and capacity are booked.
3. Participants register or are assigned.
4. Attendance is tracked.
5. Certificate or participation confirmation is issued.
6. Evidence remains available through records, files, audit, and docs.

This journey keeps booking, resources, learning, and certificates focused instead of becoming broad ERP replacements.

Journey 3: Report To Resolution

This is the internal operations and municipal issue-reporting journey.

1. A person reports an issue.
2. The issue is triaged into helpdesk, facilities, assets, or a case.
3. Work is assigned, tracked, and escalated.
4. Evidence, communication, and status updates are preserved.
5. Reports show workload, SLA, recurring problems, and completion.

This journey prevents helpdesk, issue-reporting, facilities, and assets from becoming disconnected ticket silos.

Roadmap Waves

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-access: identities, sessions, API keys, users, groups, roles, memberships, function assignments, delegation, RBAC decisions.
• govoplan-tenancy: tenant and organizational-unit 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-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

Priority Order Summary

1. Stabilize the platform spine.
2. Deliver permit-to-payment MVP.
3. Build booking and resource operations.
4. Add learning and certificates.
5. Add issue reporting and helpdesk.
6. Add records, DMS, search, and transparency.
7. Add procurement, contracts, grants, and finance handoff.
8. Add committee and consultation workflows.
9. Expand integration, dataflow, reporting, and operations.

Deliberate Deferrals

Defer these until a reference journey proves the need:

• full ERP replacement
• native project management beyond connector support
• broad BI/dataflow platform
• 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	add-ideas/govoplan-core#213
Permit-to-payment configuration package	govoplan-core plus participating modules	add-ideas/govoplan-core#214
Fully UI-managed configuration with safety controls	govoplan-admin, govoplan-core, govoplan-policy, govoplan-access, govoplan-audit	add-ideas/govoplan-core#218
Access as a module	govoplan-access	add-ideas/govoplan-access#7
Interface ethics and decision-consequence doctrine	govoplan-core plus all UI-owning modules	add-ideas/govoplan-core#227
Action/effect automation layer	first govoplan-workflow; possible future govoplan-automation	add-ideas/govoplan-workflow#1
E2EE role/function postbox architecture	govoplan-postbox, govoplan-identity-trust, govoplan-access, govoplan-policy, govoplan-audit	add-ideas/govoplan-postbox#15, add-ideas/govoplan-identity-trust#1
Identity, account, function, role, right semantic model	govoplan-access	add-ideas/govoplan-access#9
Role-based service directory/catalog	govoplan-portal	add-ideas/govoplan-portal#1
Unified inbox across tasks, postbox, notifications, and portal	govoplan-core coordination plus owning modules	add-ideas/govoplan-tasks#1, add-ideas/govoplan-notifications#1
OpenProject API / project management connector	govoplan-connectors	add-ideas/govoplan-connectors#1
Native project-management module decision	connector-first through govoplan-connectors; no native project module yet	add-ideas/govoplan-core#196, add-ideas/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	add-ideas/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	add-ideas/govoplan-core#198
Monthly datasource and transformation workflows	first as configuration package across connectors, files, workflow, reporting, and templates	add-ideas/govoplan-core#216
Templates for letters, emails, forms, reports	govoplan-templates, separate from reporting	add-ideas/govoplan-core#190, add-ideas/govoplan-templates#1
Reporting and BI	govoplan-reporting, separate from templates	add-ideas/govoplan-core#190, add-ideas/govoplan-reporting#1
File connectors: Nextcloud, Seafile, SMB, NFS	govoplan-files	add-ideas/govoplan-files#15
Public-sector software integration catalogue	govoplan-connectors with core strategy index	add-ideas/govoplan-core#191, add-ideas/govoplan-connectors#2
Public-sector integration landscape catalogue	govoplan-connectors with core tracking	add-ideas/govoplan-core#215
Cases module concept	govoplan-cases	add-ideas/govoplan-core#174
Workflow module concept	govoplan-workflow	add-ideas/govoplan-core#175
Connectors module concept	govoplan-connectors	add-ideas/govoplan-core#176
Adrema-style address and distribution-list management	govoplan-addresses	add-ideas/govoplan-addresses#1
Consume sources and become a governed source	govoplan-connectors plus possible future govoplan-dataflow	add-ideas/govoplan-connectors#3, add-ideas/govoplan-core#198
Governed connector configuration, dry-run, and simulation runtime	govoplan-connectors	add-ideas/govoplan-connectors#6
Terminfindung and meeting scheduling polls	govoplan-scheduling; calendar primitives remain in calendar	add-ideas/govoplan-core#193, add-ideas/govoplan-scheduling#1
Terminplaner and calendar primitives	govoplan-calendar	add-ideas/govoplan-core#193, add-ideas/govoplan-calendar#1
Terminbuchung appointment booking	govoplan-appointments	add-ideas/govoplan-core#193, add-ideas/govoplan-appointments#1
Collaborative documents	govoplan-dms	add-ideas/govoplan-dms#1
Forms	govoplan-forms for definitions and govoplan-forms-runtime for submissions/runtime behavior	add-ideas/govoplan-core#194, add-ideas/govoplan-forms#1
RSS consume and emit	govoplan-connectors	add-ideas/govoplan-connectors#4
LDAP, Active Directory, OpenDesk identity	govoplan-idm	add-ideas/govoplan-idm#1
OpenDesk stack integration map	integration profile across IDM/access, mail/calendar, files/DMS, and connectors; not a monolithic module	add-ideas/govoplan-core#195, add-ideas/govoplan-connectors#5
Open-Xchange mail/groupware	govoplan-mail	add-ideas/govoplan-mail#5
Open-Xchange calendar	govoplan-calendar	add-ideas/govoplan-calendar#2
Scalability profiles and autoscaling readiness	govoplan-ops, govoplan-core	add-ideas/govoplan-core#217
Hardware sizing matrix and requirements calculator	govoplan-ops, govoplan-core	add-ideas/govoplan-core#219
Collaboration suite integration strategy	govoplan-connectors, govoplan-dms, govoplan-workflow, govoplan-tasks, govoplan-appointments, govoplan-calendar	add-ideas/govoplan-core#220
Install/runtime configuration contract	govoplan-core, later govoplan-ops	add-ideas/govoplan-core#19
Installer/deployment operator flow	govoplan-core, later govoplan-ops	add-ideas/govoplan-core#26
Production-like deployment documentation	govoplan-core, later govoplan-ops	add-ideas/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 next planning step should create or update Gitea issues for Wave 0 and Wave 1 only. Later waves should stay as roadmap context until the permit-to-payment MVP is demonstrable.

Recommended immediate issue buckets:

• platform spine hardening
• configuration package preflight and rollback
• forms-runtime MVP
• portal submission MVP
• cases/workflow/tasks integration MVP
• template-generated decision document
• postbox/notification handoff
• appointment/booking handoff
• payment evidence handoff
• configured documentation for the reference process