diff --git a/docs/GOVOPLAN_MASTER_ROADMAP.md b/docs/GOVOPLAN_MASTER_ROADMAP.md index 64a7023..cae001a 100644 --- a/docs/GOVOPLAN_MASTER_ROADMAP.md +++ b/docs/GOVOPLAN_MASTER_ROADMAP.md @@ -13,9 +13,11 @@ The meta repository's [Connected Governance Platform Roadmap](https://git.add-ideas.de/add-ideas/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. Its product horizons are canonical; the waves below give -their technical dependency order. This Core roadmap remains the technical -sequencing and module-routing companion. +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/add-ideas/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 @@ -121,7 +123,8 @@ pattern exists. ## Focus Rules -1. Build one reference journey per wave. +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`, @@ -197,56 +200,82 @@ an editor applies a high-impact configuration change. ## Reference Journeys -The roadmap should be driven by three journeys. +The active sequence is selected. Workflow remains deliberately deferred and is +not a dependency of these journeys. -### Journey 1: Permit To Payment +### Journey 1: Campaign Demonstration Composition -This is the primary public-administration journey. +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. -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. +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. -This journey proves the platform can coordinate modules without core knowing -module internals. +### Journey 2: Function-Bound Postbox Delivery -### Journey 2: Training To Certificate +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. -This is the best university-administration and internal-administration journey. +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. -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. +### Journey 3: Data-Backed Templates, Reports, And Deep Launch -This journey keeps `booking`, `resources`, `learning`, and `certificates` -focused instead of becoming broad ERP replacements. +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. -### Journey 3: Report To Resolution +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. -This is the internal operations and municipal issue-reporting journey. +### Journey 4: Governed University BI Path -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. +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. -This journey prevents `helpdesk`, `issue-reporting`, `facilities`, and `assets` -from becoming disconnected ticket silos. +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. -## Roadmap Waves +### 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 @@ -540,19 +569,28 @@ Before a module becomes release-included, it needs: ## Technical Dependency Order Summary -When the meta roadmap selects one of these product programs, use this order to -respect shared-spine dependencies. The list is not an active schedule or a -decision to start every program horizontally. +Use this active order while respecting the ownership and implementation gates +in the capability waves: -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. +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 @@ -560,7 +598,8 @@ Defer these until a reference journey proves the need: - full ERP replacement - native project management beyond connector support -- broad BI/dataflow platform +- 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 @@ -657,19 +696,24 @@ Release composition and tag-only repository handling are documented in ## 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. +The active cross-product story is +[`add-ideas/govoplan#14`](https://git.add-ideas.de/add-ideas/govoplan/issues/14). +Module repositories own implementation issues; do not clone their state here. -Recommended immediate issue buckets: +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 +- 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.