[User Story] One-command Core bootstrap, module lifecycle, scale-out, and environment promotion #13

New Issue

2026-07-21T11:07:16+02:00

zemion commented

2026-07-21 11:07:16 +02:00

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 without optional modules. 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.

Terms

Core control plane: the smallest bootable distribution: Core API, Core
WebUI, PostgreSQL, Redis, installer worker, migration runner, and durable
storage configuration. No optional GovOPlaN module package is installed.
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

The administrator runs one documented command on a supported host.
The bootstrapper verifies a signed distribution manifest before executing or
starting downloaded artifacts.
It checks container/runtime, ports, storage, entropy, memory, architecture,
and connectivity requirements; generates deployment-local secrets with
restrictive permissions; and never prints them.
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.
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.
No optional module is installed or enabled at this point.

Module selection, installation, and update

Core reads an approved signed catalog and trusted keyring through the shared
outbound-network policy.
The WebUI shows available, installed, compatible, blocked, withdrawn, and
update-available releases with their channel, provenance, contracts,
migrations, permissions, configuration requirements, and release notes.
Selecting modules produces a dependency/compatibility plan before any
mutation. The administrator can amend the selection or confirm the plan.
Installation executes durably in a worker. The UI receives persisted step
state and can reconnect without losing progress.
Package signature/checksum, version alignment, contract closure, migration
graph, configuration schema, and health checks are mandatory gates.
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.
An available update follows the same preview and confirmation path. Exact
repeated requests are idempotent.

Horizontal scaling

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.
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.
Only one migration or module-lifecycle mutation may own the deployment lock,
while any healthy replica can serve read and normal domain traffic.
Workers announce identity, queues, software composition, heartbeat, and
drain state. Operators can see skew and safely retire a replica.
Sessions, throttling, idempotency, jobs, installer progress, and scheduled
work remain correct when requests move between replicas.

Development, test, and production promotion

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.
Test imports the package into a preview area. Core reports environment-bound
values, missing capabilities/secrets, compatibility changes, and the exact
apply plan.
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.
After tests and health checks pass, Core emits an update recipe with exact
immutable release and configuration identifiers.
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.
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.
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

Reproducible Core-only distribution. Publish pinned multi-architecture
images, signed distribution manifest, Core-only Compose profile, bootstrap
preflight, generated secrets, readiness, and idempotent rerun/repair.
First-run control plane. Add the restricted bootstrap administrator,
one-time enrollment, initial catalog/keyring configuration, and retirement
after durable administrator access is established.
Read-only online module directory. Move the existing catalog and module
directory contracts into the installed Core WebUI with compatibility,
provenance, release-note, and update-state presentation.
Durable module plan and install. Reuse the existing installer queue,
locks, signed-package validator, rollback drill, and run evidence behind a
plan/confirm/progress UI. Add initial catalog-entry synthesis and artifact
acquisition where the current release console still assumes local sources.
Safe module update. Add drain/maintenance coordination, backup gate,
migration compatibility window, reconnectable progress, health verification,
retry/recovery, and update notification.
Stateless replica profile. Remove remaining local-runtime assumptions,
expose role-specific commands/images, implement worker registration/drain,
and prove multiple API and worker replicas against shared dependencies.
Configuration revision model. Define provider export/import schemas,
canonical serialization, secret references, validation/diff, immutable
revision storage, audit, apply, and undo-as-new-revision.
Environment promotion and recipes. Add source/target fingerprints,
preview, environment bindings, acceptance evidence, exact recipe generation,
signed transfer, and independently confirmed application.
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

Shipping optional modules in the Core image.
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.

# 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 without optional modules. 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. ## Terms - **Core control plane:** the smallest bootable distribution: Core API, Core WebUI, PostgreSQL, Redis, installer worker, migration runner, and durable storage configuration. No optional GovOPlaN module package is installed. - **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. No optional module is installed or enabled at this point. ### 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. 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. 7. 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. - 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 1. **Reproducible Core-only distribution.** Publish pinned multi-architecture images, signed distribution manifest, Core-only 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.** Move the existing catalog and module directory contracts into the installed Core WebUI with compatibility, provenance, release-note, and update-state presentation. 4. **Durable module plan and install.** Reuse the existing installer queue, locks, signed-package validator, rollback drill, and run evidence behind a plan/confirm/progress UI. Add initial catalog-entry synthesis and artifact acquisition where the current release console still assumes local sources. 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.** Remove remaining local-runtime assumptions, expose role-specific commands/images, implement worker registration/drain, and prove multiple API and worker replicas against 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 - Shipping optional modules in the Core image. - 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.

zemion commented

2026-07-21 16:34:41 +02:00

Codex State: note

Summary

Separated tenant connector egress from the deployment-owned installer artifact trust path.
Specified approved origins, connection-time peer pinning, size/time bounds, checksum/signature verification, safe extraction, offline package installation, and operator-prefetched restricted-network operation.

Changed Files

docs/SYSTEM_ADMINISTRATOR_LIFECYCLE_USER_STORY.md
docs/REFERENCE_JOURNEY_PROGRAM.md

Verification

PYTHONPATH=. .venv/bin/python -m pytest -q -> 57 passed

Next / Blocked

Implementation remains in the staged administrator lifecycle slices; this update closes the artifact trust-model ambiguity only.

## Codex State: note ### Summary - Separated tenant connector egress from the deployment-owned installer artifact trust path. - Specified approved origins, connection-time peer pinning, size/time bounds, checksum/signature verification, safe extraction, offline package installation, and operator-prefetched restricted-network operation. ### Changed Files - `docs/SYSTEM_ADMINISTRATOR_LIFECYCLE_USER_STORY.md` - `docs/REFERENCE_JOURNEY_PROGRAM.md` ### Verification - `PYTHONPATH=. .venv/bin/python -m pytest -q -> 57 passed` ### Next / Blocked - Implementation remains in the staged administrator lifecycle slices; this update closes the artifact trust-model ambiguity only.

zemion referenced this issue

2026-07-22 03:46:14 +02:00

[Feature] Make the Release Console guided, resumable, and repository-aware #15

zemion added the area/devex area/governance area/module-system codex/ready module/admin module/core module/ops

labels 2026-07-29 14:15:02 +02:00

zemion referenced this issue

2026-07-30 15:08:21 +02:00

[Task] Publish signed multi-architecture GovOPlaN runtime images and distribution manifest #21

zemion referenced this issue

2026-07-30 15:08:25 +02:00

[Task] Publish and verify the one-file GovOPlaN deployment bootstrap #22

zemion referenced this issue

2026-07-30 15:08:31 +02:00

[Task] Provision installer-selected infrastructure capabilities through configuration packages #23

zemion added

status

in-progress

area/release area/security and removed

status

ready

labels 2026-07-30 15:08:55 +02:00

zemion commented

2026-07-30 15:08:55 +02:00

Executable deployment-compiler slice

Implemented and pushed in GovOPlaN/govoplan@82e836b:

versioned installation specification and JSON Schema;
interactive/non-interactive managed or external PostgreSQL/Redis choices;
mail and storage profiles;
private generated secrets, service-specific environment allowlists, and secret-preserving reconfiguration;
deterministic Compose rendering plus host and external-endpoint preflights;
plan, doctor, status, apply, migration ordering, readiness, locking, and keyed receipts;
one-file standard-library zipapp build with correct blocked/error exit propagation;
focused CI and 19 tests, including Core startup configuration validation, apply ordering, endpoint reachability, and zipapp behavior.

Production remains deliberately blocked until image/signature/enrollment/ingress gates are complete.

Child work

GovOPlaN #21: signed multi-architecture runtime images and distribution manifest.
GovOPlaN #22: verified/published one-file bootstrap.
GovOPlaN #23: configuration-provider seeding for selected infrastructure.
GovOPlaN #24: supported ingress, TLS, and public-route profiles.
govoplan-core #278: controlled first-administrator enrollment.
govoplan-core #34: typed update request and deployment-agent safety contract.
govoplan-ops #2: status, plan, progress, and safe update UI.

## Executable deployment-compiler slice Implemented and pushed in `GovOPlaN/govoplan@82e836b`: - versioned installation specification and JSON Schema; - interactive/non-interactive managed or external PostgreSQL/Redis choices; - mail and storage profiles; - private generated secrets, service-specific environment allowlists, and secret-preserving reconfiguration; - deterministic Compose rendering plus host and external-endpoint preflights; - plan, doctor, status, apply, migration ordering, readiness, locking, and keyed receipts; - one-file standard-library zipapp build with correct blocked/error exit propagation; - focused CI and 19 tests, including Core startup configuration validation, apply ordering, endpoint reachability, and zipapp behavior. Production remains deliberately blocked until image/signature/enrollment/ingress gates are complete. ### Child work - GovOPlaN #21: signed multi-architecture runtime images and distribution manifest. - GovOPlaN #22: verified/published one-file bootstrap. - GovOPlaN #23: configuration-provider seeding for selected infrastructure. - GovOPlaN #24: supported ingress, TLS, and public-route profiles. - govoplan-core #278: controlled first-administrator enrollment. - govoplan-core #34: typed update request and deployment-agent safety contract. - govoplan-ops #2: status, plan, progress, and safe update UI.

zemion referenced this issue

2026-07-30 15:27:31 +02:00

[Task] Implement supported ingress, TLS, and public-route deployment profiles #24

zemion referenced this issue

2026-07-30 18:56:08 +02:00

[Task] Add multi-host orchestrator profile, fencing, and worker lifecycle #27

zemion commented

2026-07-30 18:56:33 +02:00

Local implementation progress (pending push):

Added managed Garage S3 as an installer storage mode with generated stable application credentials, bucket bootstrap, separate persistent metadata/data volumes, health checks, and an explicit single-node/no-redundancy warning.
Added managed HAProxy as the only published HTTP endpoint. It discovers bounded WebUI/API replica slots through Docker DNS without mounting the Docker socket.
Added declarative API, WebUI, and Celery worker replica counts to installation desired state, plans, Compose, and receipts. Migrations and Celery beat remain singleton roles.
Added first-upgrade handoff from the legacy directly published WebUI port.
Added docs/SCALING_AND_MULTI_HOST_DEPLOYMENT.md with the supported same-host boundary and multi-host topology.
Added a narrow Files/Core trust contract for only the exact installer-owned http://garage:3900 endpoint; arbitrary SDK S3 endpoints remain fail-closed.

Verification: 25 installer tests, 15 Core configuration/policy tests, 6 Files storage tests, Ruff, git diff --check, a live Garage 2.3 bootstrap, and real Files S3 put/get/stat/delete all pass. The consolidated focused suite also passes, including 31 WebUI module permutations and the full-product build.

This completes a useful portion of the horizontal-scaling and managed-storage journey, but not multi-host HA. Remaining cluster work is now tracked explicitly in #27.

Local implementation progress (pending push): - Added managed Garage S3 as an installer storage mode with generated stable application credentials, bucket bootstrap, separate persistent metadata/data volumes, health checks, and an explicit single-node/no-redundancy warning. - Added managed HAProxy as the only published HTTP endpoint. It discovers bounded WebUI/API replica slots through Docker DNS without mounting the Docker socket. - Added declarative API, WebUI, and Celery worker replica counts to installation desired state, plans, Compose, and receipts. Migrations and Celery beat remain singleton roles. - Added first-upgrade handoff from the legacy directly published WebUI port. - Added docs/SCALING_AND_MULTI_HOST_DEPLOYMENT.md with the supported same-host boundary and multi-host topology. - Added a narrow Files/Core trust contract for only the exact installer-owned http://garage:3900 endpoint; arbitrary SDK S3 endpoints remain fail-closed. Verification: 25 installer tests, 15 Core configuration/policy tests, 6 Files storage tests, Ruff, git diff --check, a live Garage 2.3 bootstrap, and real Files S3 put/get/stat/delete all pass. The consolidated focused suite also passes, including 31 WebUI module permutations and the full-product build. This completes a useful portion of the horizontal-scaling and managed-storage journey, but not multi-host HA. Remaining cluster work is now tracked explicitly in #27.

zemion commented

2026-08-01 01:48:21 +02:00

Codex State: progress

Summary

Implemented a major local slice of the horizontal-scaling and recovery journeys: stateless application roles over shared state, Kubernetes export, runtime coordination, ordered/fenced migrations, durable deployment journals, and explicit pre-/post-migration recovery behavior.
The deployer now records checksum-verified applied state and a hash-chained operation journal before mutation; pre-migration bundle restore is bounded, while any started migration forces forward recovery unless a separately verified database backup is restored.

Changed Files

docs/INSTALLATION_AND_DEPLOYMENT_ARCHITECTURE.md
docs/RECOVERY_AND_ROLLBACK_GUARANTEES.md
docs/SYSTEM_ADMINISTRATOR_LIFECYCLE_USER_STORY.md

Verification

30 deployment-installer tests and the full workspace focused gate passed

Next / Blocked

The story remains open for signed published images/bootstrap, first-administrator enrollment, automatic backup evidence, broad module recovery-ledger adoption, configuration promotion, and real topology drills.

Suggested status label: status/in-progress

## Codex State: progress ### Summary - Implemented a major local slice of the horizontal-scaling and recovery journeys: stateless application roles over shared state, Kubernetes export, runtime coordination, ordered/fenced migrations, durable deployment journals, and explicit pre-/post-migration recovery behavior. - The deployer now records checksum-verified applied state and a hash-chained operation journal before mutation; pre-migration bundle restore is bounded, while any started migration forces forward recovery unless a separately verified database backup is restored. ### Changed Files - `docs/INSTALLATION_AND_DEPLOYMENT_ARCHITECTURE.md` - `docs/RECOVERY_AND_ROLLBACK_GUARANTEES.md` - `docs/SYSTEM_ADMINISTRATOR_LIFECYCLE_USER_STORY.md` ### Verification - `30 deployment-installer tests and the full workspace focused gate passed` ### Next / Blocked - The story remains open for signed published images/bootstrap, first-administrator enrollment, automatic backup evidence, broad module recovery-ledger adoption, configuration promotion, and real topology drills. Suggested status label: `status/in-progress`

zemion referenced this issue

2026-08-01 01:49:31 +02:00

[Task] Integrate coordinated backup evidence and restore drills into deployment flow #35

zemion referenced this issue

2026-08-01 01:49:31 +02:00

[Task] Adopt Core recovery ledger for module-owned external and multi-resource effects #36

zemion commented

2026-08-01 01:49:40 +02:00

Codex State: note

Summary

Created focused follow-ups so the residual recovery work is not hidden in this broad story: #35 for coordinated PostgreSQL/object/key backup evidence and restore drills, #36 for cross-module recovery-ledger adoption, and GovOPlaN/govoplan-campaign#91 for hard-crash orphan artifact reconciliation.

## Codex State: note ### Summary - Created focused follow-ups so the residual recovery work is not hidden in this broad story: #35 for coordinated PostgreSQL/object/key backup evidence and restore drills, #36 for cross-module recovery-ledger adoption, and GovOPlaN/govoplan-campaign#91 for hard-crash orphan artifact reconciliation.

zemion commented

2026-08-04 04:30:27 +02:00

Package distribution slice completed in f7590a7: protected per-module wheel/npm workflows, exact registry artifact locking, signed runtime package-lock binding, and the optional govoplan developer meta-package are implemented and pushed across all packageable repositories. Initial registry population is tracked separately in #38 because it requires a dedicated least-privilege package token.

Package distribution slice completed in `f7590a7`: protected per-module wheel/npm workflows, exact registry artifact locking, signed runtime package-lock binding, and the optional `govoplan` developer meta-package are implemented and pushed across all packageable repositories. Initial registry population is tracked separately in #38 because it requires a dedicated least-privilege package token.

zemion commented

2026-08-05 22:03:04 +02:00

Codex State: Kubernetes rehearsal completed

The scale-out slice now has a clean immutable subject and passing live rehearsal:

signed GovOPlaN v0.1.18 runtime, including the tracked WebUI entrypoint;
API, WebUI and worker roles distributed across two K3s worker VMs;
serial node updates, external PostgreSQL/Redis/S3, fenced scheduler and release-specific migration job;
all runtime composition, queue, deployment and connection-budget checks passed;
API pod deletion/replacement passed with zero public readiness failures after adding the verified pre-stop drain (389df7c).

Receipt SHA-256: 259f8e33b7b7a7161e1278f3ae94d52d99d88fcc2659fd1f1f8a2808cfb08abc.

This completes the source-controlled and same-host rehearsal work for the Kubernetes part of this story. GovOPlaN #27 remains open for repetition on independent physical failure domains; #37 remains the wider controlled production maturity/recovery evidence gate. The other module-lifecycle and environment-promotion acceptance journeys remain independently tracked.

## Codex State: Kubernetes rehearsal completed The scale-out slice now has a clean immutable subject and passing live rehearsal: - signed GovOPlaN `v0.1.18` runtime, including the tracked WebUI entrypoint; - API, WebUI and worker roles distributed across two K3s worker VMs; - serial node updates, external PostgreSQL/Redis/S3, fenced scheduler and release-specific migration job; - all runtime composition, queue, deployment and connection-budget checks passed; - API pod deletion/replacement passed with zero public readiness failures after adding the verified pre-stop drain (`389df7c`). Receipt SHA-256: `259f8e33b7b7a7161e1278f3ae94d52d99d88fcc2659fd1f1f8a2808cfb08abc`. This completes the source-controlled and same-host rehearsal work for the Kubernetes part of this story. GovOPlaN #27 remains open for repetition on independent physical failure domains; #37 remains the wider controlled production maturity/recovery evidence gate. The other module-lifecycle and environment-promotion acceptance journeys remain independently tracked.

zemion commented

2026-08-05 22:48:14 +02:00

Codex State: progress

Summary

Documented five canonical operating profiles: local source development, split source integration, immutable single-host rehearsal, single-host production, and multi-host Kubernetes production.
Separated profile topology from managed/BYO component bindings and from rehearsal versus acceptance evidence.
Recorded the current proof boundary: horizontal deployability and bounded pod replacement are proven; representative capacity, independent failure domains, HA state services, failover, restore/RTO/RPO, observability, and soak evidence remain required for an institution-scale production claim.

Changed Files

docs/DEPLOYMENT_PROFILES.md
docs/INSTALLATION_AND_DEPLOYMENT_ARCHITECTURE.md
dev/production-like/README.md

Verification

tools/checks/check-focused.sh (passed)

Next / Blocked

Published in commit 7b0ab31 on main.
A future Ops surface may govern application replica and worker-pool desired state; physical nodes and PostgreSQL/Redis/S3 replication remain orchestrator or provider responsibilities.

Suggested status label: status/in-progress

## Codex State: progress ### Summary - Documented five canonical operating profiles: local source development, split source integration, immutable single-host rehearsal, single-host production, and multi-host Kubernetes production. - Separated profile topology from managed/BYO component bindings and from rehearsal versus acceptance evidence. - Recorded the current proof boundary: horizontal deployability and bounded pod replacement are proven; representative capacity, independent failure domains, HA state services, failover, restore/RTO/RPO, observability, and soak evidence remain required for an institution-scale production claim. ### Changed Files - `docs/DEPLOYMENT_PROFILES.md` - `docs/INSTALLATION_AND_DEPLOYMENT_ARCHITECTURE.md` - `dev/production-like/README.md` ### Verification - `tools/checks/check-focused.sh (passed)` ### Next / Blocked - Published in commit 7b0ab31 on main. - A future Ops surface may govern application replica and worker-pool desired state; physical nodes and PostgreSQL/Redis/S3 replication remain orchestrator or provider responsibilities. Suggested status label: `status/in-progress`

zemion commented

2026-08-06 14:12:19 +02:00

The normalized source ideas and user-story orientation are now preserved in govoplan/docs/PRODUCT_INPUT_REGISTER.md. This issue remains the canonical live work item for the corresponding outcome.

The normalized source ideas and user-story orientation are now preserved in `govoplan/docs/PRODUCT_INPUT_REGISTER.md`. This issue remains the canonical live work item for the corresponding outcome.

zemion commented

2026-08-06 21:15:01 +02:00

Codex State: progress

Summary

Implemented an entitlement-free official public catalog fallback with a pinned Core trust anchor; explicit operator catalogs still take precedence and fail closed.
Implemented signed-catalog artifact acquisition from Gitea PyPI/npm, exact size/hash verification, private content-addressed caching, and install only from verified local archives.
The Admin package catalog now discovers the official directory and distinguishes install, installed, and update states; lifecycle remains instance package composition/runtime activation, while tenant and user availability remain Policy/Views concerns.
Release tooling now synthesizes the complete full profile from tagged module manifests and exact registry artifacts, including source and package provenance.

Verification

Core module-system suite: 125 tests passed
Focused cross-repository suite: 56 WebUI permutations and module checks passed
Manifest registry: 67/67 modules passed

Next / Blocked

Publish and verify the newly generated 67-module signed stable catalog.
Carry Core/Admin runtime behavior in the next protected package and OCI release; shared/Kubernetes deployments continue to use immutable rollout instead of node-local mutation.

Suggested status label: status/in-progress

## Codex State: progress ### Summary - Implemented an entitlement-free official public catalog fallback with a pinned Core trust anchor; explicit operator catalogs still take precedence and fail closed. - Implemented signed-catalog artifact acquisition from Gitea PyPI/npm, exact size/hash verification, private content-addressed caching, and install only from verified local archives. - The Admin package catalog now discovers the official directory and distinguishes install, installed, and update states; lifecycle remains instance package composition/runtime activation, while tenant and user availability remain Policy/Views concerns. - Release tooling now synthesizes the complete full profile from tagged module manifests and exact registry artifacts, including source and package provenance. ### Verification - `Core module-system suite: 125 tests passed` - `Focused cross-repository suite: 56 WebUI permutations and module checks passed` - `Manifest registry: 67/67 modules passed` ### Next / Blocked - Publish and verify the newly generated 67-module signed stable catalog. - Carry Core/Admin runtime behavior in the next protected package and OCI release; shared/Kubernetes deployments continue to use immutable rollout instead of node-local mutation. Suggested status label: `status/in-progress`

zemion commented

2026-08-06 21:26:48 +02:00

Codex State: progress

Summary

Published the complete signed stable catalog to addideas-govoplan-website commit 58601ac and annotated tag catalog-v0.1.18.
The generated payload contains 67 module entries, 68 verified Python artifacts including Core, 41 verified WebUI artifacts including Core, and no official license feature requirements.

Verification

Local catalog validation: signed=true, trusted=true, sequence=202608061915, warnings=[]
Website production build passed

Next / Blocked

Redeploy the addideas-govoplan-website Docker service from commit 58601ac; the live URL currently still serves sequence 202607222013 with 17 entries.
After deployment, verify https://govoplan.add-ideas.de/catalogs/v1/channels/stable.json reports sequence 202608061915 and 67 modules.

Suggested status label: status/in-progress

## Codex State: progress ### Summary - Published the complete signed stable catalog to addideas-govoplan-website commit 58601ac and annotated tag catalog-v0.1.18. - The generated payload contains 67 module entries, 68 verified Python artifacts including Core, 41 verified WebUI artifacts including Core, and no official license feature requirements. ### Verification - `Local catalog validation: signed=true, trusted=true, sequence=202608061915, warnings=[]` - `Website production build passed` ### Next / Blocked - Redeploy the addideas-govoplan-website Docker service from commit 58601ac; the live URL currently still serves sequence 202607222013 with 17 entries. - After deployment, verify https://govoplan.add-ideas.de/catalogs/v1/channels/stable.json reports sequence 202608061915 and 67 modules. Suggested status label: `status/in-progress`

zemion commented

2026-08-06 22:47:36 +02:00

Codex State: progress

Summary

Published a complete 67-module browsable directory derived from signed stable catalog sequence 202608061915; stale partial JSON is now pruned and website validation enforces the projection.
Core now validates release availability, source provenance, release-note URLs, and configuration requirements; withdrawn entries require a reason.
Admin now exposes searchable and filtered available/installed/update/blocked states, immutable source and artifact evidence, and technical compatibility blockers without conflating tenant/user visibility with package lifecycle.

Changed Files

govoplan@78811f7
govoplan-core@44196f5
govoplan-admin@9d522ef
addideas-govoplan-website@dc9c48f

Verification

39 targeted release/publication tests passed
Core module-system regression suite passed
Admin test suite and Core TypeScript build passed
67/67 manifest shape gate and consolidated focused check passed
Website catalog validator (including Core signature validation) and production build passed

Next / Blocked

Deploy website commit dc9c48f if deployment is not automatic, then verify the public modules/index.json reports 67 entries.
A protected package/runtime release is still required before immutable installations receive the new Core/Admin behavior; broader safe-update lifecycle acceptance remains open.

Suggested status label: status/in-progress

## Codex State: progress ### Summary - Published a complete 67-module browsable directory derived from signed stable catalog sequence 202608061915; stale partial JSON is now pruned and website validation enforces the projection. - Core now validates release availability, source provenance, release-note URLs, and configuration requirements; withdrawn entries require a reason. - Admin now exposes searchable and filtered available/installed/update/blocked states, immutable source and artifact evidence, and technical compatibility blockers without conflating tenant/user visibility with package lifecycle. ### Changed Files - `govoplan@78811f7` - `govoplan-core@44196f5` - `govoplan-admin@9d522ef` - `addideas-govoplan-website@dc9c48f` ### Verification - `39 targeted release/publication tests passed` - `Core module-system regression suite passed` - `Admin test suite and Core TypeScript build passed` - `67/67 manifest shape gate and consolidated focused check passed` - `Website catalog validator (including Core signature validation) and production build passed` ### Next / Blocked - Deploy website commit dc9c48f if deployment is not automatic, then verify the public modules/index.json reports 67 entries. - A protected package/runtime release is still required before immutable installations receive the new Core/Admin behavior; broader safe-update lifecycle acceptance remains open. Suggested status label: `status/in-progress`

zemion commented

2026-08-07 02:03:50 +02:00

Implemented the next public-catalog governance slice.

Delivered:

tagged module manifests now publish their declared permission definitions into catalog entries;
Core validates bounded permission metadata, levels, and duplicate scopes before accepting a signed catalog;
Admin shows permission counts, categories, levels, scopes, labels, descriptions, and deprecation state before install/update;
the UI states explicitly that package installation does not grant permissions;
release synthesis, Core catalog, Admin projection, integrated WebUI, and 56 optional-module permutations pass.

Commits: GovOPlaN/govoplan@dce7256, GovOPlaN/govoplan-core@40cc012, GovOPlaN/govoplan-admin@bc589a3.

This closes the permission-disclosure slice, not the broader bootstrap/user-story issue.

Implemented the next public-catalog governance slice. Delivered: - tagged module manifests now publish their declared permission definitions into catalog entries; - Core validates bounded permission metadata, levels, and duplicate scopes before accepting a signed catalog; - Admin shows permission counts, categories, levels, scopes, labels, descriptions, and deprecation state before install/update; - the UI states explicitly that package installation does not grant permissions; - release synthesis, Core catalog, Admin projection, integrated WebUI, and 56 optional-module permutations pass. Commits: GovOPlaN/govoplan@dce7256, GovOPlaN/govoplan-core@40cc012, GovOPlaN/govoplan-admin@bc589a3. This closes the permission-disclosure slice, not the broader bootstrap/user-story issue.

zemion referenced this issue

2026-08-21 02:02:09 +02:00

[Privacy] Complete DSAR provider coverage across data-owning modules #47

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: GovOPlaN/govoplan#13