docs: align technical roadmap to reference program

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.