chore: consolidate platform split checks
This commit is contained in:
@@ -9,6 +9,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/GOVOPLAN_MASTER_ROADMAP.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.
|
||||
|
||||
@@ -97,6 +104,33 @@ export(selection, context) -> fragment, data_placeholders, warnings
|
||||
health(import_result, context) -> diagnostics
|
||||
```
|
||||
|
||||
The initial core contract lives in
|
||||
`govoplan_core.core.configuration_packages`. Modules register providers through
|
||||
module-specific capability keys and implement the `ConfigurationProvider`
|
||||
protocol. The generic `configuration.provider` key names the contract and can be
|
||||
used in package requirements; concrete providers such as `access.configuration`
|
||||
are resolved by the admin package wizard. The first DTO surface includes package
|
||||
manifests, module/capability requirements, module-owned fragments, diagnostics,
|
||||
required operator data, dry-run plan items, apply results, export selections,
|
||||
and export results.
|
||||
|
||||
The initial implementation includes provider-neutral orchestration helpers:
|
||||
|
||||
- `dry_run_configuration_package(...)`
|
||||
- `apply_configuration_package(...)`
|
||||
- `export_configuration_package(...)`
|
||||
|
||||
The first concrete provider is `govoplan_access.backend.configuration_provider`.
|
||||
It supports access-owned `roles`, `groups`, and `group_role_assignments`
|
||||
fragments and applies them idempotently.
|
||||
|
||||
The admin wizard backend starts with these routes:
|
||||
|
||||
- `GET /api/v1/admin/configuration-packages/catalog`
|
||||
- `POST /api/v1/admin/configuration-packages/dry-run`
|
||||
- `POST /api/v1/admin/configuration-packages/apply`
|
||||
- `POST /api/v1/admin/configuration-packages/export`
|
||||
|
||||
## Import Flow
|
||||
|
||||
1. Select a package from a trusted catalog or upload a package file.
|
||||
@@ -168,6 +202,20 @@ Configuration catalogs should follow the existing module package catalog model:
|
||||
a file-backed or remotely fetched JSON catalog with Ed25519 signatures, channel
|
||||
gating, trusted key ids, and operator-controlled trust policy.
|
||||
|
||||
The initial catalog validator mirrors the module catalog environment model with
|
||||
configuration-specific names:
|
||||
|
||||
```bash
|
||||
GOVOPLAN_CONFIGURATION_PACKAGE_CATALOG=/srv/govoplan/configuration-catalogs/stable.json
|
||||
GOVOPLAN_CONFIGURATION_PACKAGE_CATALOG_URL=https://govoplan.example/configuration-catalogs/stable.json
|
||||
GOVOPLAN_CONFIGURATION_PACKAGE_CATALOG_CACHE=/srv/govoplan/runtime/configuration-catalog-cache/stable.json
|
||||
GOVOPLAN_CONFIGURATION_PACKAGE_CATALOG_REQUIRE_SIGNATURE=true
|
||||
GOVOPLAN_CONFIGURATION_PACKAGE_CATALOG_APPROVED_CHANNELS=stable,lts
|
||||
GOVOPLAN_CONFIGURATION_PACKAGE_CATALOG_TRUSTED_KEYS_FILE=/srv/govoplan/trust/configuration-catalog-keyring.json
|
||||
GOVOPLAN_CONFIGURATION_PACKAGE_CATALOG_SEQUENCE_STATE=/srv/govoplan/runtime/configuration-catalog-sequences.json
|
||||
GOVOPLAN_CONFIGURATION_PACKAGE_CATALOG_ENFORCE_SEQUENCE=true
|
||||
```
|
||||
|
||||
Catalog entries should include:
|
||||
|
||||
- package id, version, name, description, publisher, tags, and channel
|
||||
|
||||
Reference in New Issue
Block a user