docs: organize cross-product documentation
This commit is contained in:
@@ -0,0 +1,198 @@
|
||||
# GovOPlaN Platform Core Ideas
|
||||
|
||||
## Purpose
|
||||
|
||||
GovOPlaN is an institutional governance and operations layer. Its central
|
||||
promise is:
|
||||
|
||||
> Model the institution, orchestrate its work, connect its systems, and
|
||||
> preserve why and under whose authority it acted.
|
||||
|
||||
The platform should let people complete a real task without understanding its
|
||||
repository or module graph. It should let institutions retain control over
|
||||
their data, procedures, providers, and deployment while still sharing
|
||||
interoperable definitions and evidence.
|
||||
|
||||
This document is the stable summary of the ideas that every product package,
|
||||
module, interface, and integration must preserve. Current implementation state
|
||||
lives in [Strategy Status](STRATEGY_STATUS.md).
|
||||
|
||||
## Ten Core Ideas
|
||||
|
||||
### 1. Institutional context before application context
|
||||
|
||||
Work happens for a tenant, institution, organizational unit, function,
|
||||
mandate, jurisdiction, service, case, and represented party. The real actor
|
||||
and represented capacity remain distinct. Application permissions alone do not
|
||||
prove institutional competence.
|
||||
|
||||
### 2. Governance is executable
|
||||
|
||||
Policy is not explanatory prose around an operation. Consequential actions
|
||||
must expose applicable rules, authority, purpose, expected effects, review
|
||||
requirements, recovery behavior, and evidence. Inheritance may tighten a rule
|
||||
but must not silently loosen an upstream constraint.
|
||||
|
||||
### 3. Time has two independent meanings
|
||||
|
||||
Valid time answers when a fact applied. Recorded time answers what the system
|
||||
knew at a point in history. Historical browsing changes the business-data
|
||||
projection, never the current authorization context. Corrections and
|
||||
supersession remain visible rather than rewriting history.
|
||||
|
||||
### 4. One context, many owners
|
||||
|
||||
Cases, tasks, decisions, records, messages, files, appointments, reports, and
|
||||
external objects remain owned by their domain modules or source systems. Stable
|
||||
references create one navigable context without a universal copied master
|
||||
record or cross-module table access.
|
||||
|
||||
### 5. Native and connected operation are peers
|
||||
|
||||
For every integration, GovOPlaN states whether it is authoritative, mirrors an
|
||||
external source, synchronizes governed fields, adds a governance overlay, or
|
||||
keeps a link only. An external system can be used today and replaced later
|
||||
without losing provenance or institutional control.
|
||||
|
||||
### 6. Human work is a first-class system object
|
||||
|
||||
An intake becomes owned, reviewable work. A person can see the current context,
|
||||
next responsible action, reason, deadline, consequence, and completion
|
||||
evidence. Workflow Engine coordinates machine and human transitions; focused
|
||||
views guide people through the relevant platform surfaces.
|
||||
|
||||
Tasks owns explicit work items and the unified work inbox. Workflow Engine owns
|
||||
process execution and resumable handoffs. Notifications attract attention, and
|
||||
domain modules retain their business objects. These boundaries prevent an
|
||||
inbox, workflow, or notification from becoming a second copy of institutional
|
||||
state.
|
||||
|
||||
### 7. Views reduce complexity without changing authority
|
||||
|
||||
The interface is a task- and role-sensitive projection of installed
|
||||
capabilities. Views, dashboards, search, documentation, and workflow-guided
|
||||
surfaces may hide irrelevant functions, but they never grant access. Users can
|
||||
escape a focused mode when policy permits and can always understand why
|
||||
something is unavailable.
|
||||
|
||||
Configurable product areas organize authorized capabilities around work,
|
||||
services, records, communication, meetings, data and institutional
|
||||
responsibility. The optional Quick Access rail presents task-local Work,
|
||||
Calendar, Messages and Files contributions without merging their owners or
|
||||
turning presentation settings into permissions.
|
||||
|
||||
### 8. Evidence and recovery are part of the operation
|
||||
|
||||
Intent, exact input versions, approvals, external effects, receipts,
|
||||
outcome-unknown states, reconciliation, corrections, retention, and recovery
|
||||
belong to one evidence chain. A retry must be idempotent; rollback claims must
|
||||
distinguish reversible local state from effects already observed elsewhere.
|
||||
|
||||
### 9. Inclusion is multi-channel, not portal-only
|
||||
|
||||
Public portal, postbox, mail, telephone, paper, in-person assistance, APIs, and
|
||||
external systems are channels around the same governed work. Assisted entry
|
||||
records who entered information, for whom, from which source, with which
|
||||
attestation, and how the affected person receives a usable receipt and
|
||||
correction path.
|
||||
|
||||
Responsive, mobile, desktop, and embedded launch surfaces are additional ways
|
||||
to enter the same governed context, not separate products with weaker authority
|
||||
or evidence. Common task-local actions may open in bounded overlays while their
|
||||
owning modules retain validation, policy, and persistence.
|
||||
|
||||
### 10. Successful configurations are portable products
|
||||
|
||||
Modules are ingredients. A usable product is a signed configuration package
|
||||
with terminology, forms, policies, workflows, views, reports, provider
|
||||
profiles, documentation, migration rules, and evidence. Institutions derive
|
||||
local packages without forking code or weakening inherited constraints.
|
||||
|
||||
## Platform Planes
|
||||
|
||||
The planes below are ownership lenses, not navigation groups or mandatory
|
||||
deployment tiers.
|
||||
|
||||
| Plane | Responsibility |
|
||||
| --- | --- |
|
||||
| Experience | Shell, views, dashboard, search, help, accessibility, and task-focused composition |
|
||||
| Participation and channels | Portal, postbox, mail, campaigns, calendar, scheduling, consultation, and assisted channels |
|
||||
| Human work and procedure | Services, forms/runtime, cases, tasks, approvals, workflow execution, and domain procedures |
|
||||
| Content, records, and evidence | Files, templates, DMS, eAkte/records, audit, reporting, transparency, and publication |
|
||||
| Institutional governance | Identity, access, tenancy, organizations, functions, mandates, policy, trust, and formal decisions |
|
||||
| Data and integration | Connectors, datasources, dataflow, search, external references, provider health, and reconciliation |
|
||||
| Runtime and assurance | Module composition, operations, deployment, recovery, security evidence, and signed packages |
|
||||
|
||||
Collected product ideas and normalized actor outcomes are preserved in the
|
||||
[Product Input Register](PRODUCT_INPUT_REGISTER.md). They enter implementation
|
||||
only through a named journey, package, or explicit discovery issue.
|
||||
|
||||
## Canonical Distinctions
|
||||
|
||||
The platform must not collapse these pairs:
|
||||
|
||||
- identity vs account vs represented capacity;
|
||||
- role/permission vs function/mandate/competence;
|
||||
- valid time vs recorded time;
|
||||
- purpose for use vs general technical access;
|
||||
- document content vs managed file bytes vs institutional record;
|
||||
- task vs workflow definition vs workflow instance;
|
||||
- approval vs formal decision;
|
||||
- message intent vs transport delivery vs recipient acknowledgement;
|
||||
- source authority vs connector maturity;
|
||||
- current state vs historical evidence;
|
||||
- correction/compensation vs erasure of an observed effect;
|
||||
- a module boundary vs a user-visible product boundary.
|
||||
|
||||
## Product Experience Rule
|
||||
|
||||
The normal user interface speaks in services, work, records, messages,
|
||||
meetings, decisions, and outcomes. Module names, provider IDs, capability names,
|
||||
package coordinates, and schema details are technical provenance. They are
|
||||
visible to administrators and in expandable diagnostics, but they are not the
|
||||
primary information architecture for ordinary work.
|
||||
|
||||
The complete permission-derived tool catalogue remains deliberately available
|
||||
to power users. Product areas and Quick Access provide sensible system and
|
||||
tenant defaults plus governed user personalization; they do not make familiar
|
||||
tools harder to reach merely to conceal modular implementation.
|
||||
|
||||
## Maturity Rule
|
||||
|
||||
A repository, route, model, or unit test does not make a capability complete.
|
||||
Claims advance only with evidence appropriate to the claim:
|
||||
|
||||
1. `scaffold`: boundary and documentation exist;
|
||||
2. `vertical_slice`: useful behavior has focused tests;
|
||||
3. `reference_ready`: an end-to-end reference journey passed target,
|
||||
accessibility, privacy, security, operations, and recovery evidence;
|
||||
4. `supported`: upgrades, interoperability, support procedures, and release
|
||||
guarantees are defined;
|
||||
5. `lts`: compatibility and maintenance windows are contractual.
|
||||
|
||||
## Deliberate Non-Goals
|
||||
|
||||
GovOPlaN does not aim to:
|
||||
|
||||
- replace every specialist system, ERP, DMS, groupware, or data tool;
|
||||
- make one database authoritative for every connected fact;
|
||||
- expose every installed capability to every person;
|
||||
- infer authority from organizational membership alone;
|
||||
- make historical browsing weaken current security;
|
||||
- treat AI output as an unaccountable institutional decision;
|
||||
- create a repository for every noun in the information model;
|
||||
- claim production maturity from local development evidence.
|
||||
|
||||
## Decision Test
|
||||
|
||||
A proposed feature fits the platform when it improves at least one real
|
||||
institutional journey and can answer:
|
||||
|
||||
1. Who owns the object and source of truth?
|
||||
2. In which institutional and temporal context does it apply?
|
||||
3. For which declared purpose may it be used?
|
||||
4. Which policy and authority permit the action?
|
||||
5. What effect, evidence, retention, and recovery behavior result?
|
||||
6. How can it operate with an external owner without losing autonomy?
|
||||
7. How will a person discover and complete it without learning the module
|
||||
graph?
|
||||
@@ -0,0 +1,203 @@
|
||||
# GovOPlaN Product Input Register
|
||||
|
||||
## Purpose
|
||||
|
||||
This document preserves and normalizes product ideas and user-story notes that
|
||||
inform GovOPlaN without turning a private note file into a second backlog.
|
||||
Gitea issues remain the source of live work state; the stable platform direction
|
||||
remains in [Platform Core Ideas](PLATFORM_CORE_IDEAS.md), the
|
||||
[Connected Governance Platform Roadmap](reference/CONNECTED_GOVERNANCE_PLATFORM_ROADMAP.md),
|
||||
and the [Reference Journey Program](REFERENCE_JOURNEY_PROGRAM.md).
|
||||
|
||||
The register was reconciled on 2026-08-06 from:
|
||||
|
||||
- `/mnt/DATA/Nextcloud/ADD ideas UG/Products/govoplan/ideas.md`;
|
||||
- `/mnt/DATA/Nextcloud/ADD ideas UG/Products/govoplan/user_stories.txt`.
|
||||
|
||||
The source notes remain useful as the original capture. This maintained version
|
||||
uses consistent terminology, makes ownership explicit, and records where an
|
||||
idea enters the product program.
|
||||
|
||||
## Product Themes
|
||||
|
||||
### Operable and scalable installation
|
||||
|
||||
An operator should be able to install, update, reconfigure, scale, back up,
|
||||
restore, pause, and retire GovOPlaN through one explainable control plane.
|
||||
Existing infrastructure may be reused or managed components may be provisioned.
|
||||
The WebUI and CLI must invoke the same governed operations, show the planned and
|
||||
completed effects, preserve recovery evidence, and never claim rollback for an
|
||||
external effect that cannot actually be reversed.
|
||||
|
||||
This theme is owned by Core, Admin, Ops, Policy, Files, and the signed product
|
||||
package. It is tracked primarily by GovOPlaN #13 and the production evidence
|
||||
issues. It advances in parallel with, but does not replace, actor-facing
|
||||
reference journeys.
|
||||
|
||||
### Focused, consistent work
|
||||
|
||||
People should see the work and tools relevant to the current task, not the
|
||||
installed module graph. Views may be defined by administrators, groups, or
|
||||
users within policy. Workflow instances may pin a governed View. Contextual
|
||||
help, predictable action placement, consistent central components, visible
|
||||
intermediate results, and plain institutional terminology are product
|
||||
requirements.
|
||||
|
||||
Small task-local actions such as writing a Mail or Postbox message, completing
|
||||
a Template, or manipulating Files should be launchable without abandoning the
|
||||
current context. These actions remain owned by their modules and use bounded
|
||||
overlays or workspaces; the shell supplies discovery and return context rather
|
||||
than reimplementing them.
|
||||
|
||||
The accepted first presentation is the optional, configurable Quick Access
|
||||
rail: Work, Calendar, Messages and Files. Messages may compose Mail, Postbox
|
||||
and future chat contributions while preserving their separate authority and
|
||||
channel semantics. System and tenant administrators govern availability and
|
||||
forced entries; users select categories and ordering within those ceilings.
|
||||
Modules register typed contributions through Core and continue to work when
|
||||
Quick Access is absent.
|
||||
|
||||
This theme is owned by Core experience contracts, Views, Dashboard, Tasks,
|
||||
Workflow Engine, Quick Access, Docs, and the contributing feature modules. The
|
||||
first proof is the resumable service-to-decision/eAkte journey in GovOPlaN #42.
|
||||
|
||||
### Governed human work
|
||||
|
||||
An intake or event becomes owned work with a responsible actor or function,
|
||||
priority, deadline, current action, consequence, source context, and completion
|
||||
evidence. Tasks owns explicit work items and the unified work inbox. Workflow
|
||||
Engine owns process execution, waits, retries, and handoffs. Domain modules own
|
||||
the business objects and commands. Notifications attract attention but do not
|
||||
replace durable work state.
|
||||
|
||||
This distinction applies to service requests, technical support, approvals,
|
||||
data reconciliation, campaigns, meetings, decisions, records, and failed
|
||||
automation. It is the immediate shared implementation priority because users
|
||||
must be able to leave work and resume it safely.
|
||||
|
||||
### Institutional responsibility and workforce context
|
||||
|
||||
Organization units, functions, mandates, assignments, delegations, and acting
|
||||
context determine institutional responsibility. Presence, absence, illness,
|
||||
availability, and similar status are effective-dated operational facts used to
|
||||
route work, suppress or redirect notifications, explain planning, and trigger
|
||||
policy. They are not merely profile decorations and they do not replace the IDM
|
||||
lifecycle status of an identity or account.
|
||||
|
||||
Time recording, absence management, sickness reporting, return-to-work
|
||||
management, and applicant management form a possible workforce package. The
|
||||
first implementation must be driven by a real journey and legal/privacy
|
||||
profile; no new module boundary is implied solely by this register.
|
||||
|
||||
### Integration-first and provider-neutral operation
|
||||
|
||||
GovOPlaN should integrate tightly with software already used by an institution
|
||||
and offer native alternatives only where that produces a better governed
|
||||
outcome. Core-mediated provider contracts expose stable, vendor-neutral
|
||||
capabilities; adapters encapsulate specific products. Authority, synchronized
|
||||
fields, conflict behavior, health, credential custody, provenance, and
|
||||
retirement must be explicit.
|
||||
|
||||
The LBV Baden-Wuerttemberg idea is retained as a candidate workforce/payroll
|
||||
integration profile and as a test of provider-neutral contracts. Desktop and
|
||||
groupware integration for Microsoft Office, Outlook, LibreOffice, Thunderbird,
|
||||
file managers, Windows, Unix, and macOS should use standards, deep links,
|
||||
protocol handlers, synchronization, and governed connectors before custom
|
||||
desktop software is introduced.
|
||||
|
||||
### Inclusive channels and device surfaces
|
||||
|
||||
Portal, Postbox, Mail, telephone, paper, in-person assistance, API, desktop,
|
||||
and mobile are channels around the same governed work. A responsive or native
|
||||
mobile surface must not create a second authority or data model. Assisted work
|
||||
records representation, source, attestation, receipt, correction, and delivery
|
||||
choice. People may opt into permitted distribution channels while policy keeps
|
||||
mandatory channels and legal delivery requirements explicit.
|
||||
|
||||
Video meetings, chat, instant messaging, and forums are retained as governed
|
||||
collaboration-channel candidates. The default direction is integration with an
|
||||
established provider through typed message, meeting, participant, evidence, and
|
||||
retention contracts before building another communications stack.
|
||||
|
||||
### Meetings, deliberation, decisions, and voting
|
||||
|
||||
An institutional meeting spans scheduling, participants and mandates,
|
||||
documents, agenda, discussion, formal motions, votes, decisions, minutes,
|
||||
follow-up work, publication, and eligible expense settlement. Committee owns
|
||||
the meeting and deliberation semantics while Calendar, Scheduling, Files,
|
||||
Templates, Decisions, Tasks, Reporting, Ledger, and Voting contribute optional
|
||||
capabilities.
|
||||
|
||||
Voting requiring certified assurance remains a provider program. POLYAS is the
|
||||
first external profile; a native provider may progress only through the
|
||||
controlled assurance and certification program already tracked in Voting.
|
||||
|
||||
### Controlled data work and understandable reporting
|
||||
|
||||
People should manipulate data through immutable inputs, previewed operations,
|
||||
intermediate materializations, reversible definition changes, durable review
|
||||
decisions, quality rules, and complete lineage. Reports expose their definitions
|
||||
and source revisions so controllers can understand and change how a result is
|
||||
produced. Technical support may package controlled workflows that let
|
||||
non-technical users safely operate otherwise hidden data.
|
||||
|
||||
The monthly-data journey is the first proof. Sanctions screening follows on the
|
||||
same source, snapshot, transformation, review, reporting, workflow, and
|
||||
delivery contracts.
|
||||
|
||||
### Institutional memory and consequence
|
||||
|
||||
Decisions should be prepared, discussed, made, communicated, implemented, and
|
||||
filed with their authority and consequences visible. A record/eAkte provides
|
||||
the familiar administrative context across exact source revisions without
|
||||
copying ownership from Cases, Decisions, Files, Forms, Campaign, Postbox, or
|
||||
other modules. The institutional digital twin may later use governed
|
||||
projections to model and simulate organizational change, but simulation output
|
||||
never becomes authority without an explicit adoption decision.
|
||||
|
||||
## Normalized Story Catalogue
|
||||
|
||||
The following catalogue preserves the intent of the collected notes. It is an
|
||||
orientation index, not a completion checklist.
|
||||
|
||||
| Actor and desired outcome | Product owner or composition | First proof |
|
||||
| --- | --- | --- |
|
||||
| Operator installs, updates, scales, backs up, restores, and rolls back through one explainable workflow | Core, Admin, Ops, signed package | GovOPlaN #13 and target-evidence lane |
|
||||
| System and tenant module administrators govern module availability and lifecycle | Core, Admin, Policy, Tenancy | Module entitlement and lifecycle composition |
|
||||
| User works in a decluttered, consistent and task-sensitive interface | Views, Core, Dashboard, Workflow, Docs | Service-to-decision workspace |
|
||||
| Policy maker defines inherited, explainable and enforced rules | Policy plus every consequential owner | Information-governance adoption gate |
|
||||
| Controller and auditor reconstruct results, rules, evidence and correction paths | Audit, Reporting, Records, Dataflow | Monthly-data and eAkte journeys |
|
||||
| User sees institutional terminology, current progress, intermediate results and consequences | Domain owner, Tasks, Workflow, Views | All reference journey acceptance tests |
|
||||
| Voting body and voter obtain independently assured democratic voting | Voting, Committee, Identity Trust, Encryption | POLYAS profile and controlled native-provider program |
|
||||
| Support staff packages safe guided manipulation of hidden data | Workflow, Dataflow, Tasks, Views | Monthly reconciliation workflow |
|
||||
| Data worker performs controlled, understandable and recoverable transformations | Datasources, Connectors, Dataflow, Reporting | GovOPlaN #8 |
|
||||
| Decision maker prepares, deliberates, decides, records and follows consequences | Committee, Decisions, Tasks, Records, Reporting | Service-to-decision journey |
|
||||
| Management delegates responsibility and receives governed activity reports | Organizations, IDM, Access, Policy, Reporting | Function-bound Postbox and work inbox |
|
||||
| Institution models and simulates organizational change | Organizations, Policy, Dataflow, Reporting, Digital Twin | Later governed digital-twin package |
|
||||
| Sender distributes generated files to functions without knowing incumbents | Campaign, Distribution Lists, Postbox, Organizations, IDM | Governed communication package |
|
||||
| Function holder receives current and policy-selected historical work and information | IDM, Access, Postbox, Tasks, Records | Postbox reassignment/history tests |
|
||||
| Administrative worker accesses one familiar eAkte context across exact owned objects | Records and record-source providers | GovOPlaN #42 and Records #8 |
|
||||
| User invokes common message, template and file actions without leaving the current task | Core shell, Views, Workflow and contributing modules | Task-local action contract and service workspace |
|
||||
|
||||
## Idea Preservation Map
|
||||
|
||||
| Original idea cluster | Preserved direction |
|
||||
| --- | --- |
|
||||
| Time recording, absence, sickness, reintegration, applicant management | Governed workforce-context journey; effective-dated status and privacy profile before module expansion |
|
||||
| LBV BW interface | Candidate provider-neutral workforce/payroll connector profile |
|
||||
| Abstract interfaces | Versioned Core contracts with product adapters and explicit source authority |
|
||||
| Desktop and groupware integration | Standards, connectors, deep launch and synchronization before custom clients |
|
||||
| GovOPlaN app/mobile-first pages | Responsive shared semantics; native shell only when a proven journey needs device capabilities |
|
||||
| Video, chat, instant messaging and forum | Optional governed collaboration providers with retention/evidence contracts |
|
||||
| Somacos Session-style meeting management | Committee-led meeting composition across Calendar, Files, Decisions, Templates, Tasks, Reporting and Ledger |
|
||||
| Stronger software integration | Integration-first roadmap rule and first full external product connectors |
|
||||
|
||||
## Maintenance
|
||||
|
||||
When a source idea becomes actionable:
|
||||
|
||||
1. link it to a named reference journey or explicit discovery issue;
|
||||
2. identify the owning module and external authority;
|
||||
3. create or update the Gitea issue with acceptance criteria;
|
||||
4. keep live status out of this document;
|
||||
5. update this register only when the durable interpretation changes.
|
||||
@@ -0,0 +1,517 @@
|
||||
# GovOPlaN Reference Journey Program
|
||||
|
||||
## Status
|
||||
|
||||
This is the selected product-development sequence, originally chosen on
|
||||
2026-07-21 and reconciled with the implemented platform on 2026-07-31. It turns
|
||||
the long-term connected-platform roadmap into five demonstrable journeys.
|
||||
Workflow Engine and the optional Workflow editor now exist, but they are used
|
||||
by a stage only when its package explicitly composes and proves them; Workflow
|
||||
is not an automatic dependency of every journey.
|
||||
|
||||
The institutional semantics and source-authority model applied to these stages
|
||||
are defined in the
|
||||
[Institutional Governance Target Architecture](../architecture/INSTITUTIONAL_GOVERNANCE_TARGET_ARCHITECTURE.md).
|
||||
|
||||
The stages are ordered, but they are not monolithic releases. Each stage is
|
||||
delivered as small, reviewable, green increments and is complete only when its
|
||||
user journey, failure behavior, documentation, and operator evidence work in a
|
||||
pinned composition.
|
||||
|
||||
## 2026 outcome reset
|
||||
|
||||
Repository completion is not product completion. From 2026-08-05 onward, work
|
||||
is accepted primarily through three maintained real-life journeys:
|
||||
|
||||
1. **Governed communication:** select accountable recipients, prepare content
|
||||
and attachments, approve, deliver through Mail and/or a function-bound
|
||||
Postbox, reconcile uncertain outcomes, and file the evidence.
|
||||
2. **Inclusive service-to-decision:** accept a request through a digital or
|
||||
assisted channel, establish identity and purpose, guide the case through
|
||||
human and automatic work, decide, notify, and file the resulting eAkte.
|
||||
3. **Monthly data and sanctions:** acquire immutable source snapshots, validate
|
||||
and reconcile them interactively, preserve decisions and lineage, produce
|
||||
reports and files, and deliver the accepted result through Campaign.
|
||||
|
||||
The staged program below remains the architectural build order. These journeys
|
||||
are the acceptance lens across those stages. Every significant feature should
|
||||
identify the journey it improves, or provide security, operability, recovery,
|
||||
accessibility, or usability evidence that those journeys require. Work that
|
||||
does neither stays in the backlog until a concrete consumer exists.
|
||||
|
||||
The Records vertical now supplies the journey's native file plan, immutable
|
||||
record and item revisions, chronology, close/reopen, retention calculation,
|
||||
holds, appraisal, independent disposition approval, recovery-ledger evidence,
|
||||
and archive-neutral package simulation. Forms Runtime, Cases, and Decisions
|
||||
expose exact, permission-rechecked source revisions for explicit filing, and
|
||||
all three contribute metadata-only native Search projections that can be
|
||||
rebuilt from authoritative state. The executable fixtures prove those native
|
||||
transitions without claiming archival custody. A persisted Workflow Engine
|
||||
handoff is now reloaded through the Tasks aggregation surface and remains
|
||||
visible until the authoritative Workflow transition completes. The journey
|
||||
still needs pinned-composition reconstruction evidence and one target-tested
|
||||
archive profile.
|
||||
|
||||
## Why this sequence
|
||||
|
||||
The sequence grows one connected product rather than advancing repositories in
|
||||
isolation:
|
||||
|
||||
```text
|
||||
Campaign reference
|
||||
-> function-bound Postbox delivery
|
||||
-> data-backed templates and reports
|
||||
-> governed analytical data products
|
||||
-> collaborative document lifecycle
|
||||
```
|
||||
|
||||
Each stage reuses the preceding contracts:
|
||||
|
||||
- Campaign proves governed recipient selection, files, profiles, preview,
|
||||
durable delivery, retry, reconciliation, audit, and role-specific UI.
|
||||
- Postbox generalizes delivery from an email address to an institutional
|
||||
responsibility that survives personnel changes.
|
||||
- Templates and Reporting turn governed source data into reproducible outputs
|
||||
and provide a safe launch boundary for specialist systems such as HIS.
|
||||
- The BI path scales those source, transformation, quality, lineage, and report
|
||||
contracts from one document to reusable analytical data products.
|
||||
- DMS collaboration turns generated or uploaded artifacts into governed living
|
||||
documents without confusing storage, editing, approval, or records
|
||||
ownership.
|
||||
|
||||
## Continuous foundation lane
|
||||
|
||||
This lane is not a sixth product stage. It advances only as far as the next
|
||||
journey needs and supplies contracts shared by all five stages.
|
||||
|
||||
1. **Governed integrations.** Connector profiles declare endpoint, authority,
|
||||
source-of-truth mode, capabilities, health, limits, credential references,
|
||||
and lifecycle. Network destinations are resolved and pinned at connection
|
||||
time; private-network access is deployment-controlled and unpinned private
|
||||
transports fail closed. Deleting a connector or provider immediately
|
||||
deletes every secret it owns and records a non-secret audit event in the
|
||||
same lifecycle action; an unavailable external secret provider blocks the
|
||||
deletion or retirement rather than leaving an unaudited orphan.
|
||||
2. **External effects.** Requested action, durable command, observed effect,
|
||||
unknown outcome, retry, reconciliation, compensation/correction, and manual
|
||||
intervention remain distinct and auditable.
|
||||
3. **Institutional identity.** Identity owns subjects, Organizations owns units
|
||||
and functions, IDM owns identity-to-function assignments and upstream
|
||||
synchronization, and Access owns permission and acting-context decisions.
|
||||
4. **Stable composition.** Modules cooperate through versioned Core-mediated
|
||||
capabilities and typed references. Optional sibling modules are never
|
||||
imported as implementation dependencies.
|
||||
5. **Evidence and provenance.** Every imported datum, generated artifact,
|
||||
delivery, transformation, and later correction can identify its source,
|
||||
version, actor or system trigger, policy, and relevant execution evidence.
|
||||
6. **Focused experience.** Central components and the interface pattern
|
||||
language are mandatory. Views present only what the current task and actor
|
||||
need while preserving an explainable escape to the configured full system.
|
||||
7. **Adaptive documentation.** The owning module contributes canonical subject
|
||||
matter; GovOPlaN Docs composes it for the installed modules, enabled
|
||||
configuration, role, route, and task.
|
||||
8. **Release proof.** Version alignment, clean install/upgrade, module
|
||||
permutations, backup/restore, degraded-provider behavior, security checks,
|
||||
and target-environment acceptance gate product claims.
|
||||
9. **Artifact and infrastructure egress.** Tenant connectors use the pinned
|
||||
connector boundary. Installer artifacts use a separate deployment-owned
|
||||
trust path: approved origins, bounded pinned download or operator prefetch,
|
||||
signature/checksum verification, safe extraction, and offline package-manager
|
||||
execution. Database, broker, cache, and worker channels are constrained by
|
||||
deployment network policy and authenticated transport rather than treated as
|
||||
tenant connector profiles.
|
||||
10. **Information governance.** Temporal browsing, purpose-aware access,
|
||||
retention/legal-hold behavior, and institutional acting context are applied
|
||||
to every owned object type. Historical reads use current authorization.
|
||||
Module manifests state `contract_only`, `partial`, `enforced`, or
|
||||
`not_applicable` adoption with evidence; supported maturity is blocked until
|
||||
every applicable dimension is enforced.
|
||||
11. **Durable human work.** Tasks aggregates explicit work and module-owned
|
||||
attention items; Workflow Engine persists process state and handoffs;
|
||||
Notifications attracts attention; Views focuses the relevant surfaces.
|
||||
Leaving or refreshing the browser never becomes the only record that work
|
||||
remains unfinished.
|
||||
12. **Task-local tools.** Mail, Postbox, Templates, Files, and other common
|
||||
actions may contribute bounded launch surfaces with return context. The
|
||||
shell and Workflow compose them without copying their data or validation.
|
||||
The optional Quick Access module presents configurable Work, Calendar,
|
||||
Messages and Files categories; system/tenant/user settings and View/Policy
|
||||
ceilings resolve their availability and ordering.
|
||||
|
||||
## Documentation contract for every reference stage
|
||||
|
||||
Documentation is one connected knowledge model rendered through different
|
||||
perspectives, not separately maintained manuals that drift.
|
||||
|
||||
Every demonstrated journey provides:
|
||||
|
||||
- **Task guidance:** “I want to …” instructions using visible UI wording.
|
||||
- **Process view:** actors, inputs, states, decisions, handoffs, exceptions,
|
||||
completion, correction, and retention.
|
||||
- **Concept view:** domain language and ownership boundaries.
|
||||
- **Administrator view:** permissions, policies, profiles, configuration,
|
||||
module requirements, migrations, and audit effects.
|
||||
- **Operator view:** health, queues, retries, reconciliation, backup/restore,
|
||||
incident handling, and target-provider checks.
|
||||
- **Integration view:** capabilities, DTOs, APIs, events, idempotency,
|
||||
compatibility, deep-link/launch contracts, and example payloads.
|
||||
- **Security, privacy, and audit view:** threats, disclosure rules, secrets,
|
||||
provenance, evidence, retention, and destructive actions.
|
||||
- **Acceptance view:** runnable examples, expected results, failure injection,
|
||||
and release gates.
|
||||
- **Channel and records view:** assisted/non-digital intake and output,
|
||||
representation, provenance, filing, retention, legal hold, and archive
|
||||
consequences where the journey creates evidence or a record.
|
||||
|
||||
The Docs module selects and links these views according to installed
|
||||
capabilities and actor context. Feature repositories remain the source of
|
||||
truth for their behavior; Docs owns indexing, conditions, safe disclosure, and
|
||||
presentation. Generated API/contract reference may supplement, but never
|
||||
replace, the maintained behavioral explanation.
|
||||
|
||||
## Stage 1: Campaign as the demonstration module
|
||||
|
||||
### Product promise
|
||||
|
||||
> As a communications team, we can compose a campaign from governed recipient
|
||||
> data, managed files, reusable mail configuration, and policy; preview the
|
||||
> exact effect; authorize delivery; and resolve every recipient to a known or
|
||||
> explicitly uncertain outcome without exposing transport internals to normal
|
||||
> readers.
|
||||
|
||||
Campaign is the first reference composition, not an all-purpose mail client or
|
||||
contact database.
|
||||
|
||||
### Ownership and composition
|
||||
|
||||
- Campaign owns campaign intent, content, campaign-local recipient snapshots,
|
||||
personalization, execution state, and delivery evidence.
|
||||
- Mail owns reusable profiles, credentials, protocol adapters, profile policy,
|
||||
send/append execution, and provider-facing diagnostics. Campaign persists
|
||||
only a stable Mail profile reference, never SMTP/IMAP settings or secrets.
|
||||
- Files owns stored objects, provider connectors, file policy, and provenance.
|
||||
Campaign persists stable attachment references and frozen execution evidence.
|
||||
- Addresses or another directory may supply recipients, but Campaign freezes
|
||||
the execution-time recipient and source evidence needed to explain the send.
|
||||
- Policy, Access, Audit, Docs, Notifications, Organizations, Identity, IDM, and
|
||||
Postbox contribute only through declared capabilities when installed.
|
||||
|
||||
### Implementation slices
|
||||
|
||||
1. Enforce the Mail-profile-only boundary and reject inline transport material
|
||||
on authoring, import, update, build, and delivery paths. Legacy records are
|
||||
preserved but fail closed until explicitly migrated.
|
||||
2. Finish the central-component UI pass and consistent task-focused author,
|
||||
reviewer, operator, and reader surfaces. Normal readers receive business
|
||||
state, not paths, backend keys, worker claims, or raw provider diagnostics.
|
||||
3. Prove test, single-send, resend, batch, append-to-Sent, retry,
|
||||
reconciliation, quarantine, and manual intervention semantics against a
|
||||
target SMTP/IMAP environment.
|
||||
4. Complete adaptive Campaign, Mail, and Files documentation under the shared
|
||||
documentation contract, including runnable reference campaigns and failure
|
||||
drills.
|
||||
5. Package the composition with sample data, policies, roles, configured views,
|
||||
preflight, health checks, and pinned compatible versions.
|
||||
|
||||
### Gate
|
||||
|
||||
A clean installation can run the maintained examples through target providers;
|
||||
no Campaign payload contains transport credentials; worker/provider failures do
|
||||
not cause blind duplicate delivery; each supported role sees an appropriate
|
||||
surface and explanation; install, upgrade, restore, and release evidence are
|
||||
repeatable.
|
||||
|
||||
## Stage 2: Postbox and delivery to institutional responsibility
|
||||
|
||||
### Product promise
|
||||
|
||||
> As a sender, I can deliver a message to a named function in an organizational
|
||||
> unit without knowing which individual currently performs it. As the current
|
||||
> function holder or authorized delegate, I can discover, read, and act on that
|
||||
> message; when assignments change, access follows current responsibility while
|
||||
> the delivery and access history remains explainable.
|
||||
|
||||
### Ownership and composition
|
||||
|
||||
- Postbox owns addressable in-platform postboxes, messages, bindings,
|
||||
participants, attachment references, access-sensitive events, and retention
|
||||
inputs.
|
||||
- Organizations defines units and functions. Identity defines subjects. IDM
|
||||
assigns identities to functions and reconciles upstream directories. Access
|
||||
resolves roles, delegations, acting context, and permissions.
|
||||
- Mail is an optional external channel bridge. A Postbox is not an SMTP/IMAP
|
||||
account and is never owned by one login credential.
|
||||
- Campaign consumes a generic delivery-target capability. It may target an
|
||||
email recipient or a function-bound Postbox without importing either
|
||||
module's internals.
|
||||
- A Postbox exists independently of its current holders. Vacancy, one
|
||||
incumbent, several incumbents, and time-bounded delegation are valid states;
|
||||
none turns the Postbox into a personal account.
|
||||
- The E2EE target uses per-content keys and function/postbox key epochs.
|
||||
Assignment grants device-bound access to policy-selected history, while
|
||||
hand-over, revocation, and delegation expiry rotate or withdraw future key
|
||||
access without claiming to erase plaintext already obtained.
|
||||
- Content and signed manifests are immutable. Correction or replacement is a
|
||||
linked new object/version, never silent substitution.
|
||||
|
||||
### Implementation slices
|
||||
|
||||
1. Stabilize Postbox manifest, permissions, DTOs, migrations, directory,
|
||||
binding administration, access decisions, message create/list/read, and
|
||||
audit events.
|
||||
2. Define a typed delivery target and receipt contract for a Postbox id or an
|
||||
organization-unit/function address. Resolution never copies current holders
|
||||
into permanent mailbox ownership.
|
||||
3. Complete the Organizations–Identity–IDM–Access function-assignment and
|
||||
delegation path, including provenance and compatibility migration from
|
||||
legacy projections.
|
||||
4. Define the E2EE key-grant/epoch profile for vacancy, multiple incumbents,
|
||||
hand-over, history access, time-bounded delegation, recovery, and audit.
|
||||
5. Add Campaign delivery to a function-bound Postbox, file attachment
|
||||
references, optional external-mail bridge, and notification attention
|
||||
signals through capabilities.
|
||||
6. Document reassignment, delegation, vacancy, expired assignment, unavailable
|
||||
optional module, retention, and future E2EE limitations honestly.
|
||||
|
||||
### Gate
|
||||
|
||||
A campaign message can be delivered once to a function-bound Postbox; an
|
||||
authorized holder can act in an explicit context; a reassignment changes future
|
||||
access without moving or rewriting the message. A vacant Postbox remains
|
||||
addressable, retains the delivery, and visibly reports that no holder can
|
||||
decrypt or act until assignment; multiple incumbents and delegates receive
|
||||
independent key/access evidence. Delivery, key access, and later corrections
|
||||
remain auditable.
|
||||
|
||||
## Stage 3: Templates, reports, data sources, and deep launches
|
||||
|
||||
### Product promise
|
||||
|
||||
> As a staff member arriving from a specialist system such as HIS, I can open a
|
||||
> GovOPlaN report or document task with a governed source context already
|
||||
> selected, review the effective data and template version, generate the
|
||||
> document, and return or link the immutable result without re-entering data.
|
||||
|
||||
### Ownership and composition
|
||||
|
||||
- Templates owns reusable definitions, versions, merge schemas, localization,
|
||||
render profiles, preview, and rendering.
|
||||
- Reporting owns report definitions, parameters, curated data selection,
|
||||
execution history, dashboards, sharing, scheduling, publication, and export.
|
||||
- Connectors own protocol-specific access. A governed data-source catalog owns
|
||||
connection profiles, source contracts, freshness, and health if repeated
|
||||
use proves that a separate module is warranted.
|
||||
- Files stores generated bytes. DMS owns a generated artifact once it becomes a
|
||||
governed living document. Records owns later retention/archive semantics.
|
||||
|
||||
### Safe launch and generation contract
|
||||
|
||||
1. The source program opens a stable GovOPlaN route with an opaque, short-lived,
|
||||
single-purpose launch reference—not credentials, arbitrary SQL, or trusted
|
||||
personal data in the URL.
|
||||
2. GovOPlaN authenticates the actor, authorizes the requested report/template
|
||||
and source object, resolves the launch context server-side, and shows source,
|
||||
freshness, purpose, and any blockers.
|
||||
3. A curated connector/read-model capability returns a versioned input snapshot
|
||||
that satisfies the template or report schema.
|
||||
4. Generation records template/report definition version, parameters, input
|
||||
snapshot or reproducible source references, transformation version, output
|
||||
checksum, actor, and policy.
|
||||
5. The result is stored or handed back through an explicit callback/reference
|
||||
contract. Retries are idempotent; expired or replayed launch references fail
|
||||
safely.
|
||||
|
||||
### Implementation slices
|
||||
|
||||
1. Implement the first Templates manifest, version/schema DTOs, safe preview,
|
||||
deterministic render, package fragments, and Files-backed output.
|
||||
2. Implement the first Reporting manifest, parameter/source DTOs, one
|
||||
module-owned read model, execution evidence, and downloadable export.
|
||||
3. Define the shared data-source/profile and launch-context contracts with one
|
||||
read-only target connector and a mock HIS-style launch producer.
|
||||
4. Deliver one end-to-end reference document and one analytical report from the
|
||||
same governed source contract.
|
||||
5. Add role-specific UI/docs, source freshness and validation states, deep-link
|
||||
integration examples, and target-system acceptance tests.
|
||||
|
||||
### Gate
|
||||
|
||||
A user can follow a signed or server-side launch reference from a target system
|
||||
to a prefilled GovOPlaN task, verify the source and freshness, render an output,
|
||||
and reproduce why that exact artifact was produced. The browser cannot inject
|
||||
arbitrary queries or transport secrets, and authorization is re-evaluated in
|
||||
GovOPlaN.
|
||||
|
||||
## Stage 4: Governed BI and reporting
|
||||
|
||||
### Product promise
|
||||
|
||||
> As an institutional analyst, I can combine approved operational sources into
|
||||
> versioned, quality-checked analytical data products, define transparent
|
||||
> measures and reports, drill from aggregates where policy permits, and explain
|
||||
> the source, transformation, effective organizational hierarchy, and reporting
|
||||
> date behind every result.
|
||||
|
||||
### Lessons taken from SuperX
|
||||
|
||||
SuperX is useful inspiration because it combines many university sources in a
|
||||
modular data warehouse, loads and transforms them on a schedule, keeps
|
||||
historical or reporting-date views, supplies prepared subject modules, and
|
||||
serves different aggregation levels through a common reporting surface. Its
|
||||
official overview also emphasizes a lower operational-data layer, validation
|
||||
logs, configurable load routines, organizational hierarchies, and transparent
|
||||
report calculations. See the
|
||||
[SuperX project overview](https://www.superx-projekt.de/__index.htm),
|
||||
[administration and module architecture](https://www.superx-projekt.de/doku/kern_modul/admin/__index.htm),
|
||||
and [cross-institution indicator module](https://www.superx-projekt.de/doku/kenn_modul/benutzer/__index.htm).
|
||||
|
||||
GovOPlaN should adopt the principles, not clone the implementation. Its distinct
|
||||
value is connecting analytical results to governed work, responsibility,
|
||||
evidence, policy, and correction across independently installable modules.
|
||||
|
||||
### Architecture layers
|
||||
|
||||
1. **Source catalog:** governed profiles, owners, purpose, schema/version,
|
||||
classification, credentials, health, extraction mode, and source-of-truth
|
||||
declaration.
|
||||
2. **Ingestion and staging:** immutable run evidence, source snapshots or
|
||||
watermarks, schema-drift detection, quarantine, replay, and personal-data
|
||||
minimization.
|
||||
3. **Transformation and quality:** versioned transformations, dependencies,
|
||||
tests, validation findings, correction policy, and lineage. Silent repair of
|
||||
source facts is not acceptable.
|
||||
4. **Semantic products:** documented dimensions, measures, official key
|
||||
mappings, organizational hierarchies, time/stichtag semantics, ownership,
|
||||
access policy, and version.
|
||||
5. **Consumption:** Reporting definitions, dashboards, drill-down, scheduled
|
||||
outputs, APIs, open-data handoffs, and template generation.
|
||||
6. **Operations:** scheduling, backfill, freshness objectives, observability,
|
||||
cost/resource limits, retention, backup/restore, promotion between systems,
|
||||
and reproducible release recipes.
|
||||
|
||||
### Selected first subject-area direction
|
||||
|
||||
- Start with read-only HIS and CampusOnline source profiles and produce the
|
||||
institution's internal student-statistics data product plus reports derived
|
||||
from it.
|
||||
- Model reference/effective date separately from extraction, validation, and
|
||||
freeze dates. For example, a semester state may describe `1 September`, be
|
||||
accepted and frozen on `12 December`, and remain the reproducible source for
|
||||
that semester's official statistics. Later corrections create a superseding
|
||||
version; they never rewrite the frozen state silently.
|
||||
- Make a graphical, typed data-flow editor the primary analyst surface. Nodes
|
||||
represent governed sources/snapshots, validation, mapping, transformation,
|
||||
aggregation, a list report/data product, template rendering, and publication.
|
||||
The graph is versioned, testable, previewable, acyclic, and shows schema,
|
||||
lineage, quality findings, policy, and pinned upstream versions.
|
||||
- A list report may become a governed source for another flow. This enables
|
||||
`source + transformations/aggregation -> list report/data product -> template
|
||||
-> publishable report` without copying the calculation or losing lineage.
|
||||
|
||||
### Implementation slices
|
||||
|
||||
1. Bound the first HIS/CampusOnline student-statistics dataset and internal
|
||||
report; define its legal/policy basis, source owners, official keys,
|
||||
reference/freeze semantics, privacy level, and acceptance calculation.
|
||||
2. Generalize the Stage 3 source profile into catalog, ingestion-run, staged
|
||||
dataset, validation, transformation, lineage, and data-product contracts.
|
||||
3. Implement one scheduled load and explicit frozen-state lifecycle with
|
||||
quarantine/replay and a fully transparent transformation into the internal
|
||||
student-statistics product.
|
||||
4. Implement the first graphical typed flow editor over those proven nodes,
|
||||
including version/diff, validation, preview, cycle prevention, and pinned
|
||||
upstream product versions.
|
||||
5. Serve the product through Reporting with policy-aware aggregate and
|
||||
drill-down behavior; export reproducible evidence and calculation metadata.
|
||||
6. Chain one list report as a source into a template-backed publishable report.
|
||||
7. Package mappings, transformations, validations, reports, documentation, and
|
||||
tests so they can be promoted from development to test to production.
|
||||
|
||||
### Gate
|
||||
|
||||
One internal student-statistics product can be rebuilt from declared HIS and/or
|
||||
CampusOnline snapshots, preserves its reference and freeze dates, passes
|
||||
explicit quality tests, explains every measure and mapping, enforces disclosure
|
||||
policy, survives schema/freshness failures visibly, and produces the same
|
||||
accepted list and template-backed report across promoted environments.
|
||||
|
||||
## Stage 5: Collaborative document editing
|
||||
|
||||
### Product promise
|
||||
|
||||
> As an authorized group, we can turn an uploaded or generated artifact into a
|
||||
> shared document, edit it concurrently or through controlled check-out,
|
||||
> comment, review, approve, compare, and recover versions, then freeze the
|
||||
> accepted rendition as evidence or a record without losing who changed what.
|
||||
|
||||
### Ownership and composition
|
||||
|
||||
- Files owns bytes, checksums, storage providers, upload/download, and low-level
|
||||
file permissions.
|
||||
- DMS owns document identity, versions, renditions, editing sessions, locks,
|
||||
comments, reviews, approvals, signatures, external DMS references, and
|
||||
document-level evidence.
|
||||
- A collaboration connector owns provider-specific Collabora, OnlyOffice,
|
||||
Nextcloud/OpenDesk, or another office-suite protocol. DMS owns the session
|
||||
lifecycle and authorization even when editing occurs externally.
|
||||
- Templates may create the first version. Cases, Campaign, Postbox, Reporting,
|
||||
and Workflow may reference documents. Records owns classification, legal
|
||||
hold, archive handoff, and disposal after the document enters that lifecycle.
|
||||
|
||||
### Implementation slices
|
||||
|
||||
1. Implement DMS document/version/reference DTOs and one Files-backed version
|
||||
path, including optimistic concurrency, checksums, locks, and audit.
|
||||
2. Add comments, review requests, approval state, immutable accepted
|
||||
renditions, comparison, and recovery of prior versions.
|
||||
3. Define a provider-neutral editing-session capability with short-lived
|
||||
grants, callback authentication, save idempotency, health, and reconciliation.
|
||||
4. Integrate one external collaborative editor, including loss of provider,
|
||||
concurrent save, stale callback, permission revocation, and restore tests.
|
||||
5. Connect generated reports/templates, Postbox/Campaign sharing, focused
|
||||
document views, configured docs, and Records handoff.
|
||||
|
||||
### Gate
|
||||
|
||||
Multiple authorized actors can edit a document without silent lost updates;
|
||||
every accepted version has stable content and provenance; provider callbacks
|
||||
cannot bypass current authorization; degraded or ambiguous saves are visible
|
||||
and reconcilable; the approved rendition can enter records without making Files
|
||||
or the external editor the document-lifecycle owner.
|
||||
|
||||
## Program-wide acceptance and pause rules
|
||||
|
||||
- Do not start a broad generic platform abstraction until two concrete stages
|
||||
demonstrate the repeated contract.
|
||||
- Do not make Workflow a dependency of these stages. Manual transitions,
|
||||
explicit actions, and focused views should become stable providers that a
|
||||
later transition engine can coordinate.
|
||||
- Do not treat a remote system as trusted merely because it supplied a deep
|
||||
link, callback, webhook, file, identity, or data row.
|
||||
- Do not claim a stage complete from local unit tests. Use pinned composition,
|
||||
target integration, failure drills, adaptive docs, and operator evidence.
|
||||
- Do not claim a module complete while its relevant information-governance
|
||||
dimensions remain `contract_only` or while the reference journey lacks an
|
||||
assisted-channel and records outcome where those are applicable.
|
||||
- A later stage may prototype contracts while the preceding gate is being
|
||||
proven, but it may not redefine an owning module's boundary by convenience.
|
||||
|
||||
## Decisions intentionally deferred
|
||||
|
||||
The sequence itself is selected. These bounded choices remain for the stage
|
||||
that first needs them:
|
||||
|
||||
- first target SMTP/IMAP, file/directory, identity, and deployment profile;
|
||||
- first external IDM source and identity conflict/disable policy;
|
||||
- first trusted Postbox assurance/recovery/history-access profile and
|
||||
external-mail bridge;
|
||||
- first HIS or other launch producer and callback/reference contract;
|
||||
- exact HIS/CampusOnline source endpoints, student-statistics keys and accepted
|
||||
calculation, freeze/correction policy, privacy profile, and permitted
|
||||
drill-down level;
|
||||
- datasource provider selection and quality/promotion policy; the architecture
|
||||
now separates `govoplan-datasources` lifecycle from `govoplan-connectors`
|
||||
acquisition and `govoplan-dataflow` transformation;
|
||||
- first collaborative editor/provider and whether the first UX is concurrent
|
||||
editing, controlled check-out, or both; and
|
||||
- first Records/archive target and approval/signature assurance level.
|
||||
@@ -0,0 +1,100 @@
|
||||
# GovOPlaN Roadmap
|
||||
|
||||
## Purpose
|
||||
|
||||
GovOPlaN should become the connective, governance-aware operating layer of an
|
||||
institution: people complete services and work without learning the module
|
||||
graph, while the institution can explain authority, policy, source data,
|
||||
effects, evidence, and recovery.
|
||||
|
||||
This is the concise product roadmap. It states durable outcomes and sequence,
|
||||
not release dates or issue state. Use [Strategy Status](STRATEGY_STATUS.md) for
|
||||
the current reconciliation and Gitea issues for active work. The
|
||||
[detailed connected-platform vision](reference/CONNECTED_GOVERNANCE_PLATFORM_ROADMAP.md)
|
||||
retains stakeholder perspectives, configuration archetypes, and the complete
|
||||
outcome-story catalogue.
|
||||
|
||||
## Product Promise
|
||||
|
||||
GovOPlaN will:
|
||||
|
||||
1. model institutional context, responsibility, authority, and time;
|
||||
2. turn incoming information into owned, reviewable human and machine work;
|
||||
3. connect native and external systems without obscuring the source of truth;
|
||||
4. preserve decisions, effects, records, corrections, and recovery evidence;
|
||||
5. support digital, assisted, paper, message, calendar, and system channels as
|
||||
paths through the same governed work; and
|
||||
6. package successful configurations so institutions can adopt them without
|
||||
code forks or loss of local autonomy.
|
||||
|
||||
It will not replace every specialist system, copy all data into one master
|
||||
database, infer authority from membership, or claim production maturity from
|
||||
repository breadth.
|
||||
|
||||
## Outcome Horizons
|
||||
|
||||
| Horizon | Outcome | Completion evidence |
|
||||
| --- | --- | --- |
|
||||
| Trustworthy baseline | A pinned composition can be installed, upgraded, operated, explained, and recovered. | Signed artifacts, clean install/upgrade, provider failure tests, restore drill, coherent UI, and target evidence |
|
||||
| Connected work | Intake becomes accountable work with context, assignment, review, communication, and evidence. | One digital and assisted service reaches a decision and eAkte without losing responsibility or state |
|
||||
| Reusable products | Complete service, communication, and data outcomes ship as governed configuration packages. | Two materially different deployments adapt packages without code forks |
|
||||
| Institutional assurance | Records, transparency, privacy, risk, regulated review, and reporting connect to real operations. | A consequential decision can be reconstructed, corrected, retained, and disclosed under policy |
|
||||
| Federated ecosystem | Autonomous installations exchange signed data and configuration across explicit trust boundaries. | Paired-instance exchange, reconciliation, supported deployment profiles, and independent evidence |
|
||||
|
||||
## Current Sequence
|
||||
|
||||
The sequence is outcome-led. Shared foundation work enters when one of these
|
||||
proofs needs it.
|
||||
|
||||
1. **Enforce the platform quality contract.** German is the reference locale;
|
||||
help, accessibility, temporal browsing, purpose-aware access, retention,
|
||||
institutional context, optional-module combinations, and recovery behavior
|
||||
become measurable release gates.
|
||||
2. **Complete governed communication.** Prove recipient selection, Campaign,
|
||||
Files, Mail, function-bound Postbox delivery, acknowledgement, uncertain
|
||||
outcomes, correction, filing, and recovery against a named target.
|
||||
3. **Complete the monthly-data and sanctions journey.** Acquire immutable
|
||||
source snapshots, validate and reconcile data interactively, preserve
|
||||
lineage and review, publish reports and files, and deliver accepted results.
|
||||
4. **Complete inclusive service to decision.** Accept digital or assisted
|
||||
input, establish actor and purpose, persist human handoffs, decide, notify,
|
||||
and reconstruct the exact eAkte under current authorization.
|
||||
5. **Complete discovery and external coexistence.** Finish native PostgreSQL
|
||||
search coverage, prove reauthorization and reindexing, then prove one
|
||||
external product connector and one paired GovOPlaN federation exchange.
|
||||
6. **Prove production operation.** Complete multi-host, provider, restore,
|
||||
accessibility, volume, key-custody, and independently signed target
|
||||
evidence before raising maturity claims.
|
||||
|
||||
## Continuous Foundation
|
||||
|
||||
Every journey applies the same boundaries:
|
||||
|
||||
- modules cooperate through versioned Core contracts and typed references;
|
||||
- permissions, policy, institutional context, purpose, and current authority
|
||||
are evaluated before presenting or acting on data;
|
||||
- requested actions, durable intent, observed effects, unknown outcomes,
|
||||
retries, reconciliation, and correction remain distinct;
|
||||
- Workflow Engine coordinates stable module-owned actions and human handoffs;
|
||||
it does not become a second owner of domain state;
|
||||
- Files owns managed bytes, Records owns institutional filing and retention,
|
||||
and source systems retain explicitly declared authority;
|
||||
- focused views and product areas reduce interface complexity without granting
|
||||
access or hiding material consequences;
|
||||
- configuration packages include terminology, forms, policies, workflows,
|
||||
views, reports, providers, documentation, migration, and evidence; and
|
||||
- maturity advances from scaffold to vertical slice, reference-ready,
|
||||
supported, and LTS only with evidence appropriate to each claim.
|
||||
|
||||
## Decision Rule
|
||||
|
||||
A roadmap item should answer all of the following before implementation:
|
||||
|
||||
1. Which real journey and actor outcome does it improve?
|
||||
2. Which module or external system owns each object and source of truth?
|
||||
3. Which institutional, temporal, purpose, and policy context applies?
|
||||
4. Which effects, evidence, retention, failure, and recovery states result?
|
||||
5. Which package and target evidence will prove the outcome?
|
||||
|
||||
If those answers are missing, retain the idea in the Product Input Register or
|
||||
Gitea discovery work rather than opening an unbounded implementation program.
|
||||
@@ -0,0 +1,132 @@
|
||||
# GovOPlaN Strategy Status
|
||||
|
||||
## Status Record
|
||||
|
||||
| Field | Value |
|
||||
| --- | --- |
|
||||
| Reconciled on | 2026-08-06 |
|
||||
| Source scope | Local workspace manifests, source inventory, focused journey checks, signed release evidence, and live Gitea issue state |
|
||||
| Stable direction | [Platform Core Ideas](PLATFORM_CORE_IDEAS.md) and [Roadmap](ROADMAP.md) |
|
||||
| Collected product input | [Product Input Register](PRODUCT_INPUT_REGISTER.md) |
|
||||
| Delivery source | Gitea issues |
|
||||
|
||||
This is the only prose source for current cross-product status. It is a
|
||||
reconciliation, not a release certification. Module manifests and target
|
||||
evidence remain authoritative for specific maturity claims.
|
||||
|
||||
## Portfolio Snapshot
|
||||
|
||||
- 66 source module manifests were loadable and architecture-declared.
|
||||
- 48 modules declared `vertical_slice`; 18 declared `scaffold`.
|
||||
- No module declared `reference_ready`, `supported`, or `lts`.
|
||||
- The live portfolio had 133 open issues, including 37 priority-P1 items.
|
||||
- 118 open issues had no milestone, so issue labels do not yet express a
|
||||
reliable completion sequence on their own.
|
||||
- Three product package manifests existed: governed communication, governed
|
||||
data and assurance, and service to decision. None had crossed the complete
|
||||
target-evidence gate.
|
||||
|
||||
These counts are dated. Refresh them rather than copying them into another
|
||||
document.
|
||||
|
||||
## Interface And Contract Evidence
|
||||
|
||||
The 2026-08-06 source inventory found:
|
||||
|
||||
- 1,307 UI fields and 1,291 UI actions;
|
||||
- 8,157 stable interface declarations with no duplicate IDs;
|
||||
- 43 frontend routes and 920 backend endpoints;
|
||||
- no public WebUI surfaces missing runtime declarations;
|
||||
- no stale runtime route declarations;
|
||||
- no unclassified endpoint without a static UI reference;
|
||||
- all 1,307 fields with a resolvable F1 context; 1,143 remain candidates for
|
||||
richer field-specific content beyond page/module fallback;
|
||||
- German (`de`) as the complete reference locale and no used key missing from
|
||||
the required German or English catalogs;
|
||||
- 3 module information-governance dimensions classified as `enforced`, 1 as
|
||||
`partial`, and 260 as `contract_only`.
|
||||
This is an honest platform-wide baseline, not a claim that temporal,
|
||||
purpose, retention, and institutional-context adoption is complete.
|
||||
|
||||
## Credible Current Outcomes
|
||||
|
||||
### Platform foundation
|
||||
|
||||
Module discovery, optional dependency validation, migrations, shared WebUI,
|
||||
tenant and access foundations, signed catalogs/packages, event delivery,
|
||||
recovery contracts, contextual help, views, temporal titlebar context, and
|
||||
stateless-runtime patterns are implemented and tested at varying depths.
|
||||
|
||||
### Governed communication
|
||||
|
||||
Campaign authoring, recipient data, attachments, templates, mail profiles,
|
||||
mock/real delivery paths, audit evidence, reporting, distribution-list
|
||||
composition, and optional Postbox delivery form the deepest product cluster.
|
||||
Target provider, accessibility, recovery, and high-volume evidence still
|
||||
prevent a reference-ready claim.
|
||||
|
||||
### Institutional service and decision
|
||||
|
||||
Services, Forms, Forms Runtime, Cases, Parties, Mandates, Approvals, Committee,
|
||||
Voting, Decisions, Portal, Postbox, and Audit have an executable service-to-
|
||||
decision fixture. Public and invitation intake can retain Files-backed
|
||||
evidence; Forms submissions, Cases, and formal Decisions can be explicitly
|
||||
filed as exact eAkte source revisions and reconstructed through permission-
|
||||
rechecked native Search projections. A durable Workflow Engine handoff now
|
||||
survives session restart and appears through the Tasks work inbox until the
|
||||
authoritative transition completes. Browser-complete assisted intake, broader
|
||||
work projections and escalation, production identity and delivery, a named
|
||||
archive profile, and target evidence remain.
|
||||
|
||||
### Governed data and assurance
|
||||
|
||||
Connectors, Datasources, Dataflow, Reporting, Search, Policy, Risk Compliance,
|
||||
and Workflow provide source governance, immutable snapshots, transformation,
|
||||
quality, semantic reporting, and provenance foundations. The monthly-data and
|
||||
sanctions compositions now prove immutable connector snapshots, pinned
|
||||
Dataflow publication, Risk Compliance review, and rescreening in process. The
|
||||
journeys still need target connector profiles, complete interactive
|
||||
reconciliation, governed export/delivery, and browser-level handoff evidence.
|
||||
|
||||
## Material Gaps
|
||||
|
||||
| Gap | Consequence | Next proof |
|
||||
| --- | --- | --- |
|
||||
| No reference-ready product package | The platform cannot yet make a bounded supported-product claim | Complete one named target composition and evidence bundle |
|
||||
| Human-work spine is only an MVP | Tasks aggregates explicit work plus Workflow, Approval, and unread Postbox projections, but broad domain coverage, deadline escalation, assignment lifecycle, and focused product UX remain | Extend source providers through the three reference journeys and prove overdue/reassignment behavior in browser tests |
|
||||
| Records/eAkte target integration incomplete | Native lifecycle, retention, holds, approval, recovery, and transfer simulation are implemented, but real custody is not proved | Target-test one archive/xdomea profile and complete the assisted reference journey |
|
||||
| Cross-cutting governance adoption uneven | Historical and purpose-sensitive behavior varies by module | Enforced adoption declarations and route/query/effect migration |
|
||||
| Explicit help/accessibility depth incomplete | German/reference and F1 association gates now pass, but generic fallback remains too common | High-risk German help content and browser/a11y matrix |
|
||||
| Real federation absent | Cross-institution exchange remains connector-specific | Paired-instance signed exchange and reconciliation proof |
|
||||
| External production evidence incomplete | Scale, restore, interoperability and custody claims remain conditional | Real target drills and independent signed evidence |
|
||||
|
||||
## Active Strategic Order
|
||||
|
||||
1. Establish German, help, temporal, purpose, retention, and institutional
|
||||
context as enforceable platform quality contracts.
|
||||
2. Complete governed communication and Postbox against a named target.
|
||||
3. Complete the monthly-data flow and use it as the data foundation for
|
||||
sanctions screening.
|
||||
4. Complete the browser and resumable-work proof for the digital and assisted
|
||||
service-to-decision journey with its existing exact eAkte filing contracts.
|
||||
5. Complete native PostgreSQL search coverage for remaining journey-owned
|
||||
objects and prove reauthorization and reindex operations at target volume;
|
||||
keep OpenSearch optional. Communication, Records, service-to-decision,
|
||||
Dataflow, Reporting, Risk Compliance, and Datasource catalogue sources now
|
||||
exist.
|
||||
6. Prove one external product connector and one GovOPlaN federation exchange.
|
||||
7. Finish multi-host, restore, provider, accessibility, and independent signed
|
||||
target evidence before increasing maturity claims.
|
||||
|
||||
## Refresh Procedure
|
||||
|
||||
Refresh this page only from evidence:
|
||||
|
||||
1. run `tools/checks/check-manifest-shapes.py`;
|
||||
2. run `tools/inventory/platform-interface-inventory.py --strict
|
||||
--strict-declarations --strict-endpoints`;
|
||||
3. run the selected reference-journey checks;
|
||||
4. inspect signed release and target evidence;
|
||||
5. query live Gitea issue/milestone state;
|
||||
6. update the dated values and material gaps here;
|
||||
7. retain prior assessments as dated evidence rather than rewriting them.
|
||||
@@ -0,0 +1,212 @@
|
||||
# System Administrator Lifecycle User Story
|
||||
|
||||
## Story
|
||||
|
||||
> As a system administrator, I can execute one shell command that downloads a
|
||||
> verified GovOPlaN distribution and starts a completely configured Core control
|
||||
> plane with the official package directory available but only the protected
|
||||
> baseline active. In the WebUI I can browse compatible signed
|
||||
> module releases, select the modules for this installation, and follow every
|
||||
> download, validation, migration, installation, activation, and health-check
|
||||
> step. When an update is available, I can review its impact and confirm it.
|
||||
>
|
||||
> I can add API or worker replicas on containers or other servers without
|
||||
> copying mutable local state. I can operate development, test, and production
|
||||
> systems, transfer a versioned configuration through the WebUI, undo an applied
|
||||
> configuration version, test an update in one environment, and then apply the
|
||||
> same immutable update recipe to another environment.
|
||||
|
||||
This is a product-level story owned by the GovOPlaN platform rather than by an
|
||||
individual domain module. It joins installation, module lifecycle, operations,
|
||||
configuration packages, and release provenance into one administrator journey.
|
||||
The canonical backlog item is
|
||||
[GovOPlaN #13](https://git.add-ideas.de/GovOPlaN/govoplan/issues/13).
|
||||
|
||||
## Terms
|
||||
|
||||
- **Core control plane:** the smallest bootable distribution: Core API, Core
|
||||
WebUI, PostgreSQL, Redis, installer worker, migration runner, and durable
|
||||
storage configuration. An immutable image may carry the full verified package
|
||||
profile, but optional modules are not active or tenant-entitled by implication.
|
||||
- **Bootstrap administrator:** a single-use, time-limited installation identity
|
||||
that may access only first-run and module-lifecycle functions. It is retired
|
||||
when the selected identity/access configuration becomes healthy.
|
||||
- **Module release:** an immutable, signed package plus manifest, compatibility
|
||||
contract, migrations, WebUI contribution, checksums, and SBOM references.
|
||||
- **Configuration revision:** an immutable, schema-versioned export of
|
||||
non-secret system/module settings, policies, compositions, and secret
|
||||
references. Secret values are never exported.
|
||||
- **Update recipe:** the reviewed, immutable plan containing exact Core/module
|
||||
versions, configuration revision, migration order, preflight results,
|
||||
maintenance/drain requirements, health checks, and permitted rollback or
|
||||
forward-recovery actions.
|
||||
|
||||
## Acceptance journeys
|
||||
|
||||
### One-command first installation
|
||||
|
||||
1. The administrator runs one documented command on a supported host.
|
||||
2. The bootstrapper verifies a signed distribution manifest before executing or
|
||||
starting downloaded artifacts.
|
||||
3. It checks container/runtime, ports, storage, entropy, memory, architecture,
|
||||
and connectivity requirements; generates deployment-local secrets with
|
||||
restrictive permissions; and never prints them.
|
||||
4. It starts PostgreSQL, Redis, Core API/WebUI, one installer worker, and the
|
||||
migration runner. Readiness does not pass until migrations and durable
|
||||
dependencies are healthy.
|
||||
5. It prints the local URL and one-time bootstrap credential. Re-running the
|
||||
command is idempotent and shows or repairs the existing installation rather
|
||||
than creating another identity or database.
|
||||
6. Only the protected baseline is enabled. Installed package availability does
|
||||
not grant permissions, tenant entitlement, View visibility, or capability
|
||||
opt-in.
|
||||
|
||||
### Module selection, installation, and update
|
||||
|
||||
1. Core reads an approved signed catalog and trusted keyring through the shared
|
||||
outbound-network policy.
|
||||
2. The WebUI shows available, installed, compatible, blocked, withdrawn, and
|
||||
update-available releases with their channel, provenance, contracts,
|
||||
migrations, permissions, configuration requirements, and release notes.
|
||||
3. Selecting modules produces a dependency/compatibility plan before any
|
||||
mutation. The administrator can amend the selection or confirm the plan.
|
||||
4. Installation executes durably in a worker. The UI receives persisted step
|
||||
state and can reconnect without losing progress.
|
||||
5. Package signature/checksum, version alignment, contract closure, migration
|
||||
graph, configuration schema, and health checks are mandatory gates.
|
||||
6. Remote artifacts are acquired by a deployment-owned downloader that permits
|
||||
approved origins, pins the validated connection peer, enforces size and time
|
||||
limits, and verifies signature/checksum before making a local immutable
|
||||
artifact available. `pip`, `npm`, archive tools, and any compatibility Git
|
||||
importer then run without unrestricted network access. A restricted-network
|
||||
profile can satisfy the same contract through operator-prefetched artifacts.
|
||||
7. A failed or interrupted operation reaches a visible retry, forward-recovery,
|
||||
rollback, or manual-intervention state. It never reports success merely
|
||||
because the initiating request returned.
|
||||
8. An available update follows the same preview and confirmation path. Exact
|
||||
repeated requests are idempotent.
|
||||
|
||||
### Horizontal scaling
|
||||
|
||||
1. API, WebUI, installer, scheduler, and ordinary worker roles are stateless
|
||||
with respect to local container disks. Durable state uses PostgreSQL, Redis,
|
||||
and configured shared file/object storage.
|
||||
2. A documented command can add API or queue-specific worker replicas. The
|
||||
default Compose profile supports local scale-out; an orchestrator profile
|
||||
supplies equivalent health/readiness probes and rolling replacement.
|
||||
3. Only one migration or module-lifecycle mutation may own the deployment lock,
|
||||
while any healthy replica can serve read and normal domain traffic.
|
||||
4. Workers announce identity, queues, software composition, heartbeat, and
|
||||
drain state. Operators can see skew and safely retire a replica.
|
||||
5. Sessions, throttling, idempotency, jobs, installer progress, and scheduled
|
||||
work remain correct when requests move between replicas.
|
||||
|
||||
### Development, test, and production promotion
|
||||
|
||||
1. The administrator exports a configuration revision from development through
|
||||
the WebUI. The package is versioned, checksummed, attributable, and contains
|
||||
secret references or required-secret declarations, never secret values.
|
||||
2. Test imports the package into a preview area. Core reports environment-bound
|
||||
values, missing capabilities/secrets, compatibility changes, and the exact
|
||||
apply plan.
|
||||
3. Applying creates a new revision; the previous effective revision remains
|
||||
addressable. Undo is a new audited revision that restores the earlier
|
||||
configuration where contracts permit it.
|
||||
4. After tests and health checks pass, Core emits an update recipe with exact
|
||||
immutable release and configuration identifiers.
|
||||
5. Production validates the recipe against its own environment, requires a new
|
||||
confirmation, and executes the same ordered plan. Environment-specific
|
||||
secret bindings and endpoints remain local.
|
||||
6. Promotion never copies tenant/business data implicitly. Data migration,
|
||||
anonymized fixtures, and backup/restore are separate explicit operations.
|
||||
|
||||
## Safety and governance requirements
|
||||
|
||||
- Catalogs, artifacts, recipes, and configuration revisions have signatures,
|
||||
checksums, provenance, expiry/revocation semantics, and audit evidence.
|
||||
- Catalog and artifact retrieval is not delegated to an unrestricted package
|
||||
manager. Approved-origin and peer-pinned download, response bounds,
|
||||
signature/checksum verification, extraction safety, offline installation, and
|
||||
deployment egress policy form separate defenses.
|
||||
- The installer has a dedicated narrow authority; normal domain permissions do
|
||||
not imply host/package-management access.
|
||||
- The UI distinguishes reversible configuration rollback from database or
|
||||
package migrations that require forward recovery.
|
||||
- Cluster-wide mutations use fencing/leases so an expired worker cannot later
|
||||
commit a stale result.
|
||||
- Update plans declare availability impact, worker draining, backup/restore
|
||||
prerequisites, database compatibility windows, and post-change probes.
|
||||
- Deployment profiles set secure headers, trusted proxies/hosts, body limits,
|
||||
outbound-network policy, storage, TLS/cookie posture, and observability.
|
||||
- Release publication requires aligned backend/frontend/manifest versions and
|
||||
machine-readable dependency/SBOM provenance.
|
||||
|
||||
## Implementation slices
|
||||
|
||||
Implementation status as of the current source tree:
|
||||
|
||||
- Slice 1 has a published production-artifact baseline. Immutable
|
||||
[`v0.1.14`](https://git.add-ideas.de/GovOPlaN/govoplan/releases/tag/v0.1.14)
|
||||
binds source commit `1f039dd39c1ce2672f4978c8abc6dff862ef1445`, a signed
|
||||
one-file deployer, exact API/Web and managed-dependency image digests,
|
||||
composition, SBOMs, and provenance. Runtime Distribution
|
||||
[run #459](https://git.add-ideas.de/GovOPlaN/govoplan/actions/runs/459)
|
||||
passed migrations, schema checks, non-root API/Web readiness, and worker
|
||||
delivery/shutdown on both amd64 and arm64. Each future release must renew the
|
||||
evidence, and a real installation must still produce topology-specific
|
||||
ingress, failover, backup, and recovery receipts.
|
||||
- Slice 6 has a working application-tier foundation: state profiles, shared
|
||||
object storage, runtime node registration/heartbeats/drain, fenced scheduler,
|
||||
migration serialization, exact-head startup waiting, Ops visibility, and a
|
||||
Kubernetes export. Production acceptance still requires topology-specific
|
||||
failover and restore drills.
|
||||
- The recovery foundation for slices 4 and 5 is implemented as a Core recovery
|
||||
ledger and deployment operation journal. Automatic database backup and broad
|
||||
adoption by module-owned external effects remain open work.
|
||||
|
||||
1. **Reproducible Core-baseline distribution.** Publish pinned multi-architecture
|
||||
full-package images, signed distribution manifest, Core-baseline Compose profile, bootstrap
|
||||
preflight, generated secrets, readiness, and idempotent rerun/repair.
|
||||
2. **First-run control plane.** Add the restricted bootstrap administrator,
|
||||
one-time enrollment, initial catalog/keyring configuration, and retirement
|
||||
after durable administrator access is established.
|
||||
3. **Read-only online module directory (implemented foundation).** Admin falls
|
||||
back to the signed public stable directory, presents installed/update state,
|
||||
searchable availability/blocker filters, immutable source/artifact
|
||||
provenance, configuration requirements, release notes, and technical
|
||||
compatibility. Withdrawn releases remain visible but cannot be planned.
|
||||
Operator-configured catalogs remain an explicit override.
|
||||
4. **Durable module plan and install (implemented local boundary).** Catalog
|
||||
selection creates a reviewed plan; the installer queue, lock, preflight,
|
||||
maintenance gate, digest-verified artifact cache, rollback drill, and run
|
||||
evidence remain separate from the API process. Shared deployments convert
|
||||
the same intent into a new immutable release composition instead of mutating
|
||||
one replica.
|
||||
5. **Safe module update.** Add drain/maintenance coordination, backup gate,
|
||||
migration compatibility window, reconnectable progress, health verification,
|
||||
retry/recovery, and update notification.
|
||||
6. **Stateless replica profile.** Continue module adoption and operational
|
||||
proof for the implemented role commands, shared-state validation, runtime
|
||||
registration/drain, fenced scheduler, and Kubernetes application-tier
|
||||
export. Prove multiple API and worker replicas against the target shared
|
||||
dependencies.
|
||||
7. **Configuration revision model.** Define provider export/import schemas,
|
||||
canonical serialization, secret references, validation/diff, immutable
|
||||
revision storage, audit, apply, and undo-as-new-revision.
|
||||
8. **Environment promotion and recipes.** Add source/target fingerprints,
|
||||
preview, environment bindings, acceptance evidence, exact recipe generation,
|
||||
signed transfer, and independently confirmed application.
|
||||
9. **Operational proof.** Exercise interrupted installs, stale locks, unavailable
|
||||
catalogs, revoked keys, failed migrations, replica loss, configuration undo,
|
||||
and development-to-test-to-production promotion in release CI and target
|
||||
drills.
|
||||
|
||||
## Explicit non-goals for the first distribution slice
|
||||
|
||||
- Activating, tenant-entitling, or exposing optional modules merely because the
|
||||
immutable image carries their verified packages.
|
||||
- Exporting secrets or production business data with configuration.
|
||||
- Pretending every schema migration can be reversed automatically.
|
||||
- Building a proprietary orchestrator instead of supporting Compose and a
|
||||
standard cluster scheduler through the same role/readiness contracts.
|
||||
- Allowing the browser process to execute arbitrary shell commands.
|
||||
File diff suppressed because it is too large
Load Diff
Reference in New Issue
Block a user