From ee8613b5346d6b5147f097004540f56bcb264c16 Mon Sep 17 00:00:00 2001 From: Albrecht Degering Date: Wed, 8 Jul 2026 08:31:20 +0200 Subject: [PATCH] Sync wiki from project files --- Repo-docs-GOVOPLAN-MASTER-ROADMAP.md | 418 +++++++++++++++++++++++++++ 1 file changed, 418 insertions(+) create mode 100644 Repo-docs-GOVOPLAN-MASTER-ROADMAP.md diff --git a/Repo-docs-GOVOPLAN-MASTER-ROADMAP.md b/Repo-docs-GOVOPLAN-MASTER-ROADMAP.md new file mode 100644 index 0000000..bc81ceb --- /dev/null +++ b/Repo-docs-GOVOPLAN-MASTER-ROADMAP.md @@ -0,0 +1,418 @@ + + +> 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