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](https://git.add-ideas.de/GovOPlaN/govoplan/src/branch/main/docs/CONNECTED_GOVERNANCE_PLATFORM_ROADMAP.md)
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](https://git.add-ideas.de/GovOPlaN/govoplan/src/branch/main/docs/REFERENCE_JOURNEY_PROGRAM.md).
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`](https://git.add-ideas.de/GovOPlaN/govoplan/issues/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.