add-ideas/govoplan-core
1
0
Fork 0
Code Issues 45 Pull Requests Actions Packages Projects Releases Wiki Activity

Sync wiki from project files

Albrecht Degering
2026-07-07 21:17:31 +02:00
parent 8697c9b68b
commit fab115d2a7
3 changed files with 241 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files

9
Repo-docs-CONFIGURATION-PACKAGES.md

@@ -1,4 +1,4 @@
<!-- codex-wiki-sync:a150855bffefd51fdf4ca73c -->
<!-- codex-wiki-sync:5279514d500c139b03703050 -->
> Mirrored from `/mnt/DATA/git/govoplan-core/docs/CONFIGURATION_PACKAGES.md`.
> Origin: `repository`.
@@ -16,6 +16,13 @@ Example: an application-handling package could configure a public portal form,
a case workflow, task creation, a mail template, payment processing, access
roles, audit evidence, and the interface bindings between those modules.
The guiding reference scenario is the government-operations permit journey in
`docs/GOVERNMENT_OPERATIONS_VISION.md`: a person applies through the portal,
uploads files, receives workflow-driven messages and appointment proposals, has
a case opened, gets a permit generated from a template, and completes payment.
Configuration packages are the mechanism that should make such processes
reusable and safely importable.
This document is durable architecture context and should be mirrored to the
Gitea wiki. Active implementation should be tracked in Gitea issues.

224
Repo-docs-GOVERNMENT-OPERATIONS-VISION.md Normal file

@@ -0,0 +1,224 @@
<!-- codex-wiki-sync:4ca91654d9f8b3b351393bd8 -->
> Mirrored from `/mnt/DATA/git/govoplan-core/docs/GOVERNMENT_OPERATIONS_VISION.md`.
> Origin: `repository`.
> Active tasks and changing state belong in Gitea issues; this wiki page is durable project context.
---
# GovOPlaN Government Operations Vision
This document is the durable product north star for GovOPlaN as a modular
platform for administrative operations. It should be mirrored to the Gitea wiki.
Active implementation belongs in Gitea issues and module-specific follow-ups.
The goal is not to replace every existing system. GovOPlaN should connect
existing systems, provide better workflows where the current landscape is weak,
and make administrative processes configurable, auditable, and reusable.
## Guiding Reference Journey
A useful reference process is a permit application that crosses public portal,
back-office workflow, documents, appointments, templates, notifications, and
payments:
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.
8. The permit, payment evidence, communication history, and audit trail remain
available according to policy and retention rules.
This journey should be possible to model as a configuration package once the
participating modules exist. The package should wire module-owned fragments
together without core knowing module internals.
## Design Principles
- Modules must stay independently installable, enableable, and disableable.
- Cross-module behavior should use core-mediated capabilities, commands, events,
DTOs, and UI contribution points rather than direct imports.
- Configuration packages should turn installed modules into concrete, reusable
administrative processes.
- Operators should be able to configure the platform through the UI.
- Every powerful configuration path needs preflight, preview, audit, rollback,
RBAC, and policy checks.
- Integration should be a first-class product path: connect to existing systems,
consume their data, and publish governed outputs back to them.
- GovOPlaN should scale from a small local installation to a larger deployment
with separately scalable web, API, worker, storage, and database components.
## Capability Map
| Capability | Likely owner |
| --- | --- |
| Public application entry point | `govoplan-portal` |
| Structured forms and validation | `govoplan-forms` |
| Uploaded files and managed storage | `govoplan-files` |
| Case record and lifecycle | `govoplan-cases` |
| Workflow transitions and automation | `govoplan-workflow` |
| Internal work queues and tasks | `govoplan-tasks` |
| Appointment proposals and booking | `govoplan-appointments`, `govoplan-calendar` |
| Postbox, email, and notifications | `govoplan-mail`, `govoplan-notifications` |
| Permit/document generation | `govoplan-templates`, `govoplan-dms` |
| Payment capture and accounting handoff | `govoplan-payments`, `govoplan-ledger` |
| Roles, permissions, tenants, policy, audit | `govoplan-access`, `govoplan-tenancy`, `govoplan-policy`, `govoplan-audit` |
| External software integration | `govoplan-connectors` |
| Recurring extraction and transformation | proposed `govoplan-datasources`, proposed `govoplan-dataflow` |
| Reports, BI, and management visibility | `govoplan-reporting` |
## Integration Landscape
The integration strategy should start with research and connector catalogues.
The product needs a structured view of common public-sector systems and
recurring integration patterns before deciding where native modules are worth
building.
Research should cover:
- citizen portals and service portals
- DMS/e-file systems and archive systems
- case-management and workflow platforms
- ERP, finance, accounting, payment, and cash-register systems
- identity providers, LDAP/Active Directory, SAML, OIDC, OpenDesk, and IAM tools
- groupware, mail, calendar, postbox, and notification systems
- document collaboration, chat, video conferencing, and project-management tools
- FIT-Connect, XTA/OSCI, XRechnung, XOE/V, ePayment, and other public-sector
protocol families
- file shares, Nextcloud, Seafile, WebDAV, SMB/NFS, and object storage
- reporting, BI, open-data, RSS/API publication, and data-exchange endpoints
The output should be a ranked connector backlog with owners, protocols,
authentication models, data shapes, operational risks, and minimum viable
integration tests.
## Recurring Data Extraction And Transformation
A concrete recurring use case is monthly extraction and transformation of data
received from one or more sources, preparing files for several downstream
systems by applying transformation rules.
This should become a datasource-plus-workflow-plus-dataflow capability:
- register datasources for uploads, file locations, APIs, databases, and
external systems
- discover or declare schemas
- define transformation rules, mapping versions, validation rules, and output
formats
- schedule monthly runs and allow manual reruns
- produce previewable diffs and validation diagnostics before publication
- write output files to configured destinations
- keep provenance, lineage, input hashes, generated outputs, operator actions,
and audit evidence
- let workflows react to success, warning, failure, or manual approval
`govoplan-datasources` and `govoplan-dataflow` are proposed module boundaries
for this area if the scope grows beyond connectors and reporting.
## Full UI Configuration
The long-term target is that operators configure the platform through the UI
instead of editing files for normal operation.
UI-managed configuration should include:
- module installation, enablement, lifecycle state, and health
- tenants, users, groups, roles, policies, and permissions
- connectors, credentials, secret references, and external service tests
- workflows, forms, templates, task queues, schedules, and notifications
- configuration package import/export and environment-specific data collection
- retention, audit, privacy, maintenance mode, and safety controls
- deployment-visible settings such as public URLs, mail senders, storage
profiles, queues, and worker capabilities
Safety controls should include dry-run plans, field-level validation, policy
explanations, two-person approval for destructive changes, versioned
configuration history, rollback paths, audit events, and maintenance-mode
guards.
## Scalability
GovOPlaN should be manually scalable first and automatically scalable where the
deployment platform supports it.
The architecture should support:
- stateless web/API processes behind a reverse proxy or load balancer
- separate background workers for mail, workflow jobs, imports, exports,
transformations, notifications, and scheduled tasks
- PostgreSQL as the production database path
- object/file storage that can grow independently from the API process
- queue-backed job dispatch with retry, deduplication, and observability
- cache and lock services only where they are optional or operationally
documented
- health checks, readiness checks, metrics, and clear degraded-mode behavior
The product needs realistic sizing profiles instead of guessed requirements.
Sizing should account for tenants, concurrent users, cases, files, storage
volume, upload/download rates, campaign volume, workflow jobs, transformation
runs, reporting load, and retention/audit growth.
## Hardware Requirements
Hardware guidance should be empirical and deployment-shaped. The first sizing
matrix should distinguish:
- local development
- single-office pilot
- small production tenant
- medium municipal deployment
- larger shared deployment with separate workers and PostgreSQL
Each profile should document CPU, memory, disk, database, storage, queue/cache,
backup, and monitoring requirements, plus the assumptions behind the numbers.
A later calculator can turn operator inputs into recommended profiles.
## Collaboration
Collaboration should be integration-first. GovOPlaN should connect with strong
existing tools and provide native behavior only where the administrative process
needs tighter governance than an external tool can provide.
Target areas:
- collaborative document editing and versioning through DMS integrations
- comments, internal notes, and task discussions attached to cases and workflow
items
- chat and messaging connectors
- video conferencing connectors with appointment/workflow handoff
- project-management connectors, with OpenProject as the first likely target
- presence, notifications, and activity streams where they improve operational
handoff
Native modules are justified when GovOPlaN must own the domain semantics,
permissions, audit trail, retention behavior, or configuration package fragments.
## Relationship To Configuration Packages
The permit-to-payment journey should become a reference configuration package.
The package imports module-owned fragments, binds interfaces between modules,
asks the operator for deployment-specific data, and validates everything before
applying it.
See `docs/CONFIGURATION_PACKAGES.md` for the concrete package model.
## Tracking Issues
The cross-cutting backlog starts with these core tracking issues. Split
module-specific child issues from them when implementation begins.
| Topic | Tracking |
| --- | --- |
| Government operations backbone reference model | `add-ideas/govoplan-core#213` |
| Permit-to-payment configuration package | `add-ideas/govoplan-core#214` |
| Public-sector integration landscape catalogue | `add-ideas/govoplan-core#215` |
| Recurring datasource and data-transformation workflows | `add-ideas/govoplan-core#216` |
| Scalability profiles and autoscaling readiness | `add-ideas/govoplan-core#217` |
| Fully UI-managed configuration with safety controls | `add-ideas/govoplan-core#218` |
| Hardware sizing matrix and requirements calculator | `add-ideas/govoplan-core#219` |
| Collaboration suite integration strategy | `add-ideas/govoplan-core#220` |

10
Repo-docs-GOVOPLAN-MODULE-ROADMAP.md

@@ -1,4 +1,4 @@
<!-- codex-wiki-sync:8eda5a7c450bc8421ffacb5a -->
<!-- codex-wiki-sync:d50d3a857949d55597475417 -->
> Mirrored from `/mnt/DATA/git/govoplan-core/docs/GOVOPLAN_MODULE_ROADMAP.md`.
> Origin: `repository`.
@@ -13,15 +13,20 @@ This page maps current module and integration ideas to existing GovOPlaN reposit
| Idea | Owner | Tracking |
| --- | --- | --- |
| Government operations backbone reference model | `govoplan-core` | `add-ideas/govoplan-core#213` |
| Permit-to-payment configuration package | `govoplan-core` plus participating modules | `add-ideas/govoplan-core#214` |
| Fully UI-managed configuration with safety controls | `govoplan-admin`, `govoplan-core`, `govoplan-policy`, `govoplan-access`, `govoplan-audit` | `add-ideas/govoplan-core#218` |
| Access as a module | `govoplan-access` | `add-ideas/govoplan-access#7` |
| OpenProject API / project management connector | `govoplan-connectors` | `add-ideas/govoplan-connectors#1` |
| Native project-management module decision | `govoplan-core` | `add-ideas/govoplan-core#196` |
| Datasources for databases, CSV, files, APIs | proposed `govoplan-datasources` | `add-ideas/govoplan-core#197` |
| Dataflow for pipelines, BI, publication | proposed `govoplan-dataflow` | `add-ideas/govoplan-core#198` |
| Monthly datasource and transformation workflows | proposed `govoplan-datasources`, proposed `govoplan-dataflow`, `govoplan-workflow`, `govoplan-reporting` | `add-ideas/govoplan-core#216` |
| Templates for letters, emails, forms, reports | `govoplan-templates` | `add-ideas/govoplan-templates#1` |
| Reporting and BI | `govoplan-reporting` | `add-ideas/govoplan-reporting#1` |
| File connectors: Nextcloud, Seafile, SMB, NFS | `govoplan-files` | `add-ideas/govoplan-files#15` |
| Public-sector software integration catalogue | `govoplan-connectors` | `add-ideas/govoplan-connectors#2` |
| Public-sector integration landscape catalogue | `govoplan-connectors` with core tracking | `add-ideas/govoplan-core#215` |
| Adrema-style address and distribution-list management | `govoplan-addresses` | `add-ideas/govoplan-addresses#1` |
| Consume sources and become a governed source | `govoplan-connectors` plus proposed `govoplan-dataflow` | `add-ideas/govoplan-connectors#3`, `add-ideas/govoplan-core#198` |
| Terminfindung and meeting scheduling polls | `govoplan-scheduling` | local scaffold; remote creation tracked by `add-ideas/govoplan-core#199` |
@@ -34,6 +39,9 @@ This page maps current module and integration ideas to existing GovOPlaN reposit
| OpenDesk stack integration map | `govoplan-connectors` | `add-ideas/govoplan-connectors#5` |
| Open-Xchange mail/groupware | `govoplan-mail` | `add-ideas/govoplan-mail#5` |
| Open-Xchange calendar | `govoplan-calendar` | `add-ideas/govoplan-calendar#2` |
| Scalability profiles and autoscaling readiness | `govoplan-ops`, `govoplan-core` | `add-ideas/govoplan-core#217` |
| Hardware sizing matrix and requirements calculator | `govoplan-ops`, `govoplan-core` | `add-ideas/govoplan-core#219` |
| Collaboration suite integration strategy | `govoplan-connectors`, `govoplan-dms`, `govoplan-workflow`, `govoplan-tasks`, `govoplan-appointments`, `govoplan-calendar` | `add-ideas/govoplan-core#220` |
## Proposed Missing Modules