Sync wiki from project files
418
Repo-docs-GOVOPLAN-MASTER-ROADMAP.md
Normal file
418
Repo-docs-GOVOPLAN-MASTER-ROADMAP.md
Normal file
@@ -0,0 +1,418 @@
|
||||
<!-- codex-wiki-sync:80fc42cf89cbc8e53feaf046 -->
|
||||
|
||||
> 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 orders GovOPlaN work so the product moves toward the government
|
||||
operations vision without turning every possible public-sector need into an
|
||||
immediate implementation track.
|
||||
|
||||
Use this document for sequencing. Use `GOVERNMENT_OPERATIONS_VISION.md` for the
|
||||
north star and `GOVOPLAN_MODULE_ROADMAP.md` for routing specific ideas to module
|
||||
repositories and issues.
|
||||
|
||||
## 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 product should not start by replacing every specialist system. It 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
|
||||
- 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.
|
||||
|
||||
## 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.
|
||||
|
||||
## Reference Journeys
|
||||
|
||||
The roadmap should be driven by three journeys.
|
||||
|
||||
### Journey 1: Permit To Payment
|
||||
|
||||
This is the primary public-administration journey.
|
||||
|
||||
1. Public portal submission.
|
||||
2. Structured form and file upload.
|
||||
3. Case and workflow creation.
|
||||
4. Internal task queue.
|
||||
5. Appointment or booking.
|
||||
6. Template-generated permit or decision document.
|
||||
7. Payment and accounting handoff.
|
||||
8. Postbox, notification, audit, retention, and records evidence.
|
||||
|
||||
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, RBAC decisions.
|
||||
- `govoplan-tenancy`: tenant and organizational-unit boundaries.
|
||||
- `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
|
||||
- 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.
|
||||
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.
|
||||
|
||||
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
|
||||
- advanced digital signing and trust features beyond certificate verification
|
||||
- mobile apps
|
||||
- AI assistants embedded into workflows
|
||||
|
||||
These may become important, but they should not distract from the first complete
|
||||
administrative journeys.
|
||||
|
||||
## 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
|
||||
Reference in New Issue
Block a user