664 lines
32 KiB
Markdown
664 lines
32 KiB
Markdown
# 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-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
|
|
|
|
## 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
|