coulomb/railiance-apps
5
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Refresh S5 scope and publish attended recovery discovery evidence
All checks were successful
CI Smoke / host-smoke (push) Successful in 0s
Details
CI Smoke / container-smoke (push) Successful in 1s
Details

Browse source 
Assistant: codex
Assistant-Model: gpt-6.1-sol
Assistant-Session: 01a1abf1-7e95-7141-87c9-ee78332bf790
This commit is contained in:
tegwick 2026-11-06 20:25:52 +01:00
parent 1f97c91d6b
commit 61d122b2e1
4 changed files with 331 additions and 305 deletions
Download patch file Download diff file Expand all files Collapse all files

407
SCOPE.md
View file

@ -1,305 +1,142 @@
# SCOPE
This file defines what `railiance-apps` owns, when to use it, and where its
boundaries stop.
Last reviewed: 2026-11-06.
Last reviewed: 2026-06-05
`railiance-apps` owns the S5 application release and operations surface:
Helm values/charts, workload manifests, immutable release bindings, operator
checks and app-specific recovery procedures on the existing Railiance platform.
[INTENT.md](INTENT.md) describes the stable direction; this file describes the
current implementation and its boundaries.
---
## Ownership and current surfaces
## One-liner
- **Vergabe participation:** `charts/vergabe-teilnahme/`, production values and
ingress, plus the exact demo-company release binding. The release has separate
persistent media and SQLite issue-facade state, alongside its PostgreSQL
database on the platform-owned `apps-pg` cluster.
- **Coulomb personal workspace:** persistent content release configuration,
single-writer/Recreate guards and paired database/content recovery handoffs.
Application source, content semantics and product acceptance remain with
`coulomb-social`.
- **Forgejo deployment:** this checkout currently contains the active Helm
values, runner manifests, deployment targets and operator runbook. Its
[release-unit declaration](registry/release-units/forgejo.yaml) records Apps
as rollout owner and `railiance-forge` as owner of forge operating contracts.
RAPPS-WP-0016 owns the Apps side of NetKingdom login integration. The June
[forge ownership decision](docs/forge-source-of-truth-decision.md) is historical;
its statement that this checkout has no deploy wrappers no longer describes
the current source. This review records existing ownership, without moving
runtime authority between repositories.
- **Other S5 releases and shared recipes:** application charts/values, ingress,
probe and migration checks, SOPS/reference guards, manifest server dry-run,
deployment smoke checks and onboarding/runbook patterns. Current workload
source is discoverable through the Makefile, `charts/`, `helm/`, `manifests/`
and the owner capability index.
- **Reviewed build tooling:** `tools/forgejo-release-build.py` and its pinned
source/patch/build inputs support the Forgejo security-extension candidate.
Local build verification establishes source/artifact properties; runtime
image, package, type and authentication admission remain separate.
S5 Workloads & Experience Endpoints for Railiance: application Helm releases,
Kubernetes workload manifests, app deployment guardrails, and operator runbooks
for user-facing services such as `vergabe-teilnahme`.
## Completed release milestones
---
**RAPPS-WP-0014 is finished, four tasks done.** The two-account demo-company
pilot has a fixed release/storage binding, founder functional and restart
acceptance, populated three-store recovery proof and an accepted attended
operating arrangement. The fresh run `20261106T100825Z-acc2a468a535` completes
provider publication, independent readback/decryption, current session cleanup
and isolated restore, with staging removed and no retention execution pending.
The [closeout](docs/evidence/2026-11-06-vergabe-pilot-closeout.md) distinguishes
supplied detailed baseline proof from fresh checks inferred from the reviewed
worker's exit-zero contract. Fresh detailed worker timing was not supplied.
## Core Idea
Bernd Worsch is the attended backup executor and first incident/support contact.
The accepted cadence is after every active pilot day and before changes, with
seven daily/two weekly verified provider points and protected baseline/newest.
Targets are at most one active pilot day's data loss and attended recovery
within one working day. The [operating packet](docs/proposals/2026-11-06-vergabe-attended-backups/README.md)
provides capture, retry, restore and bounded retention commands. This is an
attended arrangement; no scheduled backup or failure-notification service was
installed. Storage and credential custody use existing platform owner paths.
Railiance is organized as layered repositories for the Open Application Stack.
This repository owns the S5 application deployment surface. It does not build
the lower platform; it takes already-converged infrastructure, cluster,
platform services, and enablement paths, then ships user-facing workloads on
top of them.
**RAPPS-WP-0015 is finished, nine tasks done.** The personal Coulomb workspace
release has user acceptance, persistent single-writer content and paired
PostgreSQL/content recovery evidence. The final reconciled release is Helm 22,
source `61c154f`, image `85378d10…bc83`. The
[workplan](workplans/RAPPS-WP-0015-coulomb-personal-content-release.md) links the
exact postflight, recovery and product acceptance receipts; ongoing service,
corpus transfer and access-control work retains its existing CSOC owners.
The practical contract is:
## Remaining work and limits
1. lower layers provide runtime primitives and platform services,
2. this repo owns application release configuration and app-level manifests,
3. operator docs and checks here make those releases repeatable,
4. source application repos own their app code, package metadata, and image
build pipelines.
**RAPPS-WP-0016 is active, two of nine tasks done.** Break-glass and source
build tooling are complete. NetKingdom answered the Apps C1–C3 review on
October 23; Apps adopts revised C3's independent configuration transaction and
fresh attended inverse placement as an implementation requirement. The
[owner continuation](docs/evidence/2026-11-06-forgejo-owner-continuation.md)
records the real missing journal, current authorization/session, release-wide
writer-exclusion, observer and receipt-store backends. T07/T08/T09 candidate
source does not establish deployed acceptance. Client registration still waits
for KEY-WP-0038-T02 / the first admitted KnownSecurityCase. Native source
installation, account linking and positive/negative group probes remain open.
No forge visibility or local-password policy change follows from these records.
---
Vergabe recovery proves the captured application stores and clone workflow,
including a same-image/schema configuration inverse. It does not establish
restored interactive SSO/MFA/ingress, an older image/schema downgrade, Helm
rollback, node rebuild, HA or autonomous factory delivery. Broader invited
recipient/company-contact acceptance, document UX, refresh/session refinements
and factory delivery retain their existing VERGABE/Custodian work records.
See the closeout for exact handoff IDs and the shared recipient decision that
remains open. This file is an orientation surface, not a second task backlog.
## Intent Comparison
## Lower-layer and application boundaries
`INTENT.md` now defines the stable purpose of this repo as the S5 application
workload layer: turning platform capabilities into reliable, user-facing
Railiance services with repeatable release operations. Compared with that
intent, the current implementation is aligned around:
- `railiance-infra` owns host/OS provisioning; `railiance-cluster` owns the
Kubernetes runtime, networking and ingress-controller primitives.
- `railiance-platform` owns shared CNPG/storage/backup primitives, ESO/OpenBao
custody and its operator login/browser helper. Apps references these owner
paths and coordinates app-consistent recovery; it does not own their secrets.
- `net-kingdom`, `key-cape` and authorization owners provide identity, client
registration, assurance and policy contracts. Apps owns its consumer wiring
and evidence, not new issuer, factor, grant or credential authority.
- `railiance-enablement` and `railiance-forge` own their declared developer,
source/registry and forge operating contracts; this checkout owns the release
configuration and targets actually maintained here.
- Application repositories own behavior, package metadata/locks, ordinary image
pipelines and product acceptance. Publishing `issue-core` or rebuilding a
Vergabe package lock stays with those source owners. The explicitly reviewed
Forgejo build candidate is a bounded release-tooling exception, not a transfer
of upstream application ownership.
- keep S5 application deployments portable across operators, CI, and remote
builders;
- keep application release concerns in S5 while respecting S1-S4 ownership;
- provide enough runbook and guardrail coverage that the next app does not
rediscover the same deployment traps;
- consume forge-owned source and registry capabilities through the
`railiance-forge` boundary instead of owning forge runtime state in S5.
Production changes continue to use the existing reviewed operator lanes and
founder authorization. A discovery entry, source test or completed workplan
provides no additional deployment or credential permission.
The remaining gap is not the absence of intent; it is turning the first-app
lessons into reusable S5 app release patterns.
## Reuse and orientation
---
The owner-authored [capability index](registry/indexes/capabilities.yaml) is
federated by reuse-surface. It describes broad release tooling separately from
the bounded attended Vergabe recovery path. Maturity records describe the
cited consumption scope; they do not certify unrelated workloads or native
Forgejo security-extension admission.
## In Scope
Useful entry points:
- Consumption of forge-owned source and registry capabilities from S5 app
release docs and values, without owning forge runtime configuration.
- `vergabe-teilnahme` as the first concrete S5 application release:
- chart in `charts/vergabe-teilnahme/`;
- values in `helm/vergabe-teilnahme-values.yaml`;
- ingress in `manifests/vergabe-teilnahme-ingress.yaml`;
- Makefile targets for deploy, status, migrations, seed, logs, and DB URL
secret rebuilds.
- Application deployment operator guardrails:
- `make check-tools`;
- `make check-sops`;
- `make k8s-server-dry-run`;
- `.gitea/workflows/manifest-server-dry-run.yaml`;
- scripts under `tools/`.
- S5 app runbooks and recipes in `docs/`, especially:
- `docs/vergabe-teilnahme.md`;
- `docs/s5-app-onboarding-checklist.md`;
- `docs/app-data-backup-restore-handoff.md`;
- `docs/manifest-server-dry-run.md`;
- `docs/django-on-railiance.md`;
- `docs/operator-setup.md`;
- `docs/operator-recipes.md`.
- Repo-local workplan files under `workplans/`.
- [Deployment binding](docs/vergabe-demo-company-binding.md),
[walkthrough](docs/vergabe-demo-company-acceptance.md),
[accepted operating arrangement](docs/vergabe-demo-company-operating-acceptance.proposed.md).
- [Forgejo operator runbook](docs/forgejo-on-railiance01.md) and
[current workplan](workplans/RAPPS-WP-0016-forgejo-netkingdom-login.md).
- [S5 onboarding](docs/s5-app-onboarding-checklist.md),
[data recovery handoff](docs/app-data-backup-restore-handoff.md),
[Django deployment](docs/django-on-railiance.md),
[manifest dry-run](docs/manifest-server-dry-run.md).
---
## Out of Scope
- OS or host provisioning: `railiance-infra`.
- Kubernetes runtime, ingress controller primitives, and cluster-level routing:
`railiance-cluster`.
- Platform databases, shared backup primitives, object storage, caches, and
durable platform services: `railiance-platform`.
- CI/CD systems, source templates, and developer portal enablement outside the
S5 app release surface: `railiance-enablement`.
- Application source code and package build metadata for deployed apps:
source application repos such as `vergabe-teilnahme`.
- Publishing `issue-core` itself or regenerating `vergabe-teilnahme` package
locks: `issue-core` and `vergabe-teilnahme` own those release artifacts.
- Secret value custody. This repo may reference SOPS files and Kubernetes
Secret names, but it must not commit decrypted values or secret material.
---
## Relevant When
- Consuming already-published registry artifacts from S5 app releases.
- Deploying or upgrading `vergabe-teilnahme` on Railiance.
- Adding another user-facing S5 application release.
- Debugging app-level Helm values, app ingress, app probes, app secrets, or
app-specific runbook behavior.
- Turning lessons from an app deployment into reusable operator recipes.
---
## Not Relevant When
- S1-S4 are not converged enough for S5 workloads to deploy.
- The work requires platform database provisioning, backup controller setup, or
shared storage changes.
- The work is application source-code behavior rather than release wiring.
- The work is forge runtime, registry retention, runner substrate, or Forgejo
production migration design rather than S5 app release operation.
- The work requires secret custody, credential generation, or token storage
outside approved operator paths.
---
## Current State
- Forgejo is deployed and operational as the current forge, having replaced
Gitea. Its deploy-capable Helm/SOPS/manifests live in `railiance-forge`; this
repo no longer keeps forge deploy/status wrappers or registry pointer docs.
- The container and Python package registry paths are verified. Canonical
registry operating docs live in `railiance-forge`; S5 runbooks link to those
docs directly when app releases consume forge artifacts.
- The final source-of-truth decision for forge ownership is recorded in
`docs/forge-source-of-truth-decision.md`.
- The `issue-core` migration blocker is closed: `issue-core==0.2.0` is
published to the forge PyPI registry, and the `vergabe-teilnahme` lock in its
source repo resolves it from the registry rather than a sibling checkout.
- `vergabe-teilnahme` is represented as a local Helm chart plus values,
ingress, Makefile targets, and an operator runbook.
- Reusable S5 app onboarding, app data restore handoff, and manifest
server-dry-run prerequisite docs now capture the repeatable parts of the
first app release.
- Several deployment lessons are now repo-local guardrails: URL-encoded
database URL secret creation, Django probe Host headers, operator tool checks,
SOPS age-key checks, server-side manifest dry-run, and persistent-pod smoke
testing.
- Workplan files are now the source artifacts for planned work. State Hub
indexes those files as workplans and task blocks after
`make fix-consistency REPO=railiance-apps`.
---
## Known Gaps And Opportunities
- The reusable S5 app onboarding checklist exists, but still needs to be
exercised by the next real app release.
- The manifest dry-run prerequisite contract exists. Enforcing it in CI still
depends on forge-owned runner labels, placement, and credential evidence
defined in
`/home/worsch/railiance-forge/docs/ci-runner-actions-gitops-ownership.md`;
plus representative cluster access from lower layers.
- App-level backup and restore handoffs are documented, but production-trust use
of `vergabe_db` still depends on platform-owned `apps-pg` backup and restore
evidence. Forge artifact restore and secret-custody evidence is defined in
`/home/worsch/railiance-forge/docs/backup-restore-secret-handoff.md`.
- Forge release-readiness evidence that S5 app runbooks may cite is defined in
`/home/worsch/railiance-forge/docs/observability-operating-evidence.md`.
---
## Workplan And State Hub Model
Work items originate as files in this repository under `workplans/`. State Hub
does not own the canonical file; it indexes workplan files as hub workplans
and indexes each fenced task block as a hub task.
After editing workplan files, run from `~/state-hub`:
```bash
make fix-consistency REPO=railiance-apps
```
Use "workplan" for the repo file and "workplan" for the State Hub row created
from that file.
---
## How It Fits
- Upstream dependencies:
`railiance-infra` (S1) -> `railiance-cluster` (S2) ->
`railiance-platform` (S3) -> `railiance-enablement` (S4) ->
`railiance-apps` (S5).
- Downstream consumers:
operators deploying S5 workloads, users accessing deployed apps, and source
repos that need a governed deployment target.
- Frequent collaborators:
`railiance-platform` for databases and backup contracts, `net-kingdom` for
identity integrations, `issue-core` for task/package coordination, and source
app repos such as `vergabe-teilnahme`.
---
## Terminology
- Preferred terms:
S5 app release, application workload, app runbook, release values, deployment
guardrail, smoke evidence.
- Forge terms:
source forge, registry, package registry, runner substrate, and artifact
evidence belong to `railiance-forge`; this repo consumes those capabilities.
- Potentially confusing terms:
"deployment" here means app release deployment. Forge runtime deployment and
registry operation belong to `railiance-forge`.
---
## Related / Overlapping
- `railiance-platform`: shared CNPG clusters, backup primitives, object storage,
and other platform services consumed by S5 apps.
- `railiance-forge`: current Gitea operation, future Forgejo migration,
registries, runners, artifact retention, and forge evidence.
- `railiance-enablement`: CI/CD templates and developer paved paths used by S5
releases.
- `railiance-cluster`: Kubernetes runtime, ingress controllers, cert-manager,
and cluster networking.
- `vergabe-teilnahme`: source Django app, package lock, Dockerfile, and app code.
- `issue-core`: package release required by `vergabe-teilnahme` and future apps.
---
## Provided Capabilities
```capability
type: infrastructure
title: S5 application workload deployment
description: Deploy and operate user-facing Railiance applications as Helm releases and Kubernetes manifests, including app release guardrails and the first Django S5 app release.
keywords: [railiance, s5, registry-consumer, helm, django, vergabe-teilnahme, workload, deployment]
```
```capability
type: operations
title: S5 deployment guardrails and runbooks
description: Provide operator checks, SOPS verification, server-side manifest dry-runs, smoke-test patterns, and app-specific deployment runbooks for Railiance S5 workloads.
keywords: [operator, runbook, sops, cnpg, dry-run, smoke-test, deployment]
```
---
## Getting Oriented
1. Read `AGENTS.md` for session protocol and State Hub conventions.
2. Read `INTENT.md` for the stable purpose of the S5 layer.
3. Read this file for scope and boundaries.
4. Read the active files in `workplans/`.
5. For forge registry work, use the forge-owned docs directly (filenames still
carry the legacy `gitea-` prefix):
`/home/worsch/railiance-forge/docs/gitea-container-registry.md` and
`/home/worsch/railiance-forge/docs/gitea-package-registry.md`.
6. For a new S5 app release, start with
`docs/s5-app-onboarding-checklist.md`.
7. For `vergabe-teilnahme`, start with `docs/vergabe-teilnahme.md`, then inspect
`charts/vergabe-teilnahme/`, `helm/vergabe-teilnahme-values.yaml`, and
`manifests/vergabe-teilnahme-ingress.yaml`.
8. For data durability and server-side dry-run readiness, read
`docs/app-data-backup-restore-handoff.md` and
`docs/manifest-server-dry-run.md`.
9. Run `make check-tools` before deploy work. Run
`SOPS_SENTINEL=<encrypted-file> make check-sops` when app release work
touches encrypted SOPS files.
## Generated work-record index
This repository opts into staged-source WORK-RECORDS.md generation through
`.generated-work-records.json` and the isolated `.generated-work-records.mk`
recipe. `make generated-work-records` reuses the State Hub renderer through
the Custodian adapter; `make generated-work-records-check` verifies byte-exact
agreement with staged Markdown. The pre-commit hook uses the isolated recipe,
preserves unstaged index edits by refusing them, and retains the generated-only
commit guard and existing security checks. It does not contact the hub, alter
workplan statuses or grant deployment authority. This consumes shared tooling;
it does not make this repository the provider of the generator capability.
## Local orientation brief policy — 2026-10-19
`.custodian-brief.md` is a local, ignored State Hub orientation snapshot. Its
existing bytes remain available for offline session startup; refreshing it does
not require a Git commit. Authored workplans and the generated WORK-RECORDS index
retain their existing source and staged-generation contracts. No runtime or
credential change follows from this repository hygiene policy.
## Synthetic pilot sizing follow-up
Application-owner local evidence and configurable workloads live in
`vergabe-teilnahme/docs/evidence/2026-10-19-synthetic-sizing/` and that repository's
`config/synthetic-pilot*.json`. RAPPS-WP-0014-T04 owns fresh exact release/hardware
metadata and a co-timed isolated replay/shared-contention assessment feeding
CUST-WP-0071-T02 and RESOURCE-WP-0008-T02. Routine read-only capture/preparation is
authorized; no benchmark writes to customer datasets or unreviewed deployment
changes follow from the local synthetic result. The existing T03 human/recovery
gate remains separate and unchanged.
Authored workplans under `workplans/` are the source of truth. State Hub indexes
them; run `statehub fix-consistency --repo railiance-apps` after task/status
edits. `WORK-RECORDS.md` is generated from staged Markdown through
`.generated-work-records.json` and `.generated-work-records.mk`; its pre-commit
check preserves the existing source/staging contract and grants no runtime
authority. `.custodian-brief.md` is an ignored local orientation snapshot;
refreshing it needs no Git commit. Follow [AGENTS.md](AGENTS.md) for session and
credential-routing rules.

145
registry/capabilities/capability.railiance.vergabe-attended-recovery.md Normal file
View file

@ -0,0 +1,145 @@
---
id: capability.railiance.vergabe-attended-recovery
name: Attended Vergabe three-store backup and isolated recovery
summary: Capture PostgreSQL, media and SQLite coherently, verify encrypted provider
readback/decryption, and restore the bound demo-company pilot in isolation.
owner: railiance-apps
status: reviewed
domain: financials
tags:
- railiance
- vergabe
- backup
- restore
- postgresql
- sqlite
- media
- attended
- recovery
maturity:
discovery:
current: D3
target: D4
confidence: high
rationale: Native inventory, capture/transfer/provider/restore sequence, owner
handoffs and known scope limits are documented; no systematic general recovery-product
research is claimed.
availability:
current: A2
target: A3
confidence: high
rationale: Executable source tools and reviewed operator packets are in the repository;
this is not a separately packaged/installable CLI.
external_evidence:
completeness:
level: C3
confidence: high
basis: scope_vs_intent_and_consumer_expectations
satisfied_expectations:
- Coherent populated three-store capture and verified production app resume
- Encrypted off-host provider retrieval, packet checks and current session revocation
- Isolated data/workflow and same-image/schema configuration-inverse verification
- Accepted attended ownership, cadence, retention and recovery objectives
broken_expectations: []
out_of_scope_expectations:
- Scheduled service/automated failure reporting
- Restored interactive SSO/MFA/ingress and older-code/schema/Helm rollback
- Node rebuild, HA and generic multi-tenant recovery
reliability:
level: R2
confidence: medium
basis: consumer_quality_signals
known_reliability_risks:
- First repeatable operating run and a detailed baseline, not broad operational
history.
- WSLg/Chrome input stalled during attended login; the native Windows opener works
around it and actual owner login succeeds.
- Fresh detailed worker JSON/timing was not supplied; full fresh worker checks
are inferred from reviewed success-exit semantics.
- Earlier failed login receipts retain unconfirmed revocation outcomes.
- Attended operator, existing healthy cluster/cached image and platform custody
lane remain dependencies.
discovery:
intent: Repeatable attended app-consistent recovery for the exact admitted Vergabe
demo-company release.
includes:
- Coherent PostgreSQL/media/SQLite capture, encrypted transfer and provider readback
- Bounded isolated restore/configuration inverse and cleanup
- Verified-point retention preview and conditional owner deletion
excludes:
- General backup service or identity/custody authority
- Broader invited-recipient/product acceptance or factory delivery
assumptions:
- Named attended operator and existing admitted platform storage/custody paths
- Exact source/image/cluster/storage bindings must be reviewed before reuse
use_cases:
- Recover the bound populated pilot after an active day or before changes
- Adapt the reviewed three-store pattern for another owner-reviewed application
research_memos: []
availability:
current_level: A2
target_level: A3
current_artifacts:
- tools/vergabe_pilot_backup.py
- tools/vergabe_pilot_restore.py
- tools/vergabe_pilot_point.py
- docs/proposals/2026-11-06-vergabe-attended-backups/README.md
target_artifacts: []
consumption_modes:
- CLI
- source
relations:
depends_on: []
supports: []
related_to:
- capability.railiance.workload-deployment-tooling
evidence:
documentation:
- docs/evidence/2026-11-06-vergabe-pilot-closeout.md
- docs/vergabe-demo-company-operating-acceptance.proposed.md
- docs/evidence/2026-11-06-vergabe-native-restore-return.json
- docs/evidence/2026-11-06-vergabe-attended-provider-success-return.json
- docs/evidence/2026-11-06-vergabe-attended-restore-transport-return.json
tests:
- docs/proposals/2026-11-06-vergabe-attended-backups/validation.json
- docs/evidence/2026-11-06-vergabe-attended-backup-complete-return.json
consumer_feedback:
- docs/evidence/2026-11-06-vergabe-post-restart-user-return.json
- docs/evidence/2026-11-06-vergabe-operating-choice.json
- docs/evidence/2026-11-06-vergabe-attended-provider-success-return.json
bug_reports:
- docs/evidence/2026-11-06-vergabe-browser-window-repair.json
incidents: []
consumer_guidance:
recommended_for:
- Attended backup/recovery of the exact demo-company pilot with the reviewed source
and owner lanes
- Source-pattern reuse after reviewing each new app/tenant/store binding
not_recommended_for:
- Unattended or general disaster-recovery guarantees
- Unreviewed production overwrite, schema downgrade or identity acceptance
known_limitations:
- Run after each active pilot day and before changes; named operator responsibility.
- Seven daily/two weekly verified points, at most one active-day data loss and one
working-day attended recovery are accepted targets, not SLA measurements.
- No live data overwrite in the rehearsal; isolated fresh claims and owned staging
are cleaned.
- Provider no-op retention is valid when no excess verified point is eligible; unknown
provider objects are excluded.
promotion_history: []
---
# Attended Vergabe three-store backup and isolated recovery
The [closeout](../../docs/evidence/2026-11-06-vergabe-pilot-closeout.md) binds
the detailed baseline and fresh operating point to the exact release/stores,
founder acceptance and named operating arrangement.
Initial owner assessment: D3/A2/C3/R2, 2026-11-06. The declared core works
end-to-end; limited operating history and the documented browser workaround
justify cautious reliability. This initial record does not promote the broad
release-tooling capability or admit another tenant, image or identity flow.
Use the [operator packet](../../docs/proposals/2026-11-06-vergabe-attended-backups/README.md).
The capture/private recovery kit stays outside Git. No source index or receipt
confers permission to execute a live recovery or retention deletion.

57
registry/capabilities/capability.railiance.workload-deployment-tooling.md
View file

@ -1,7 +1,8 @@
---
id: capability.railiance.workload-deployment-tooling
name: Workload release configuration and guards
summary: Helm/manifests, exact image pins, application runbooks and rollout/rollback.
summary: Application Helm/manifests, exact image bindings, operator guards and bounded
recovery runbooks; Forgejo identity extension remains in progress.
owner: railiance-apps
status: draft
domain: financials
@ -47,11 +48,17 @@ external_evidence:
known_reliability_risks:
- no top-level packaging; tooling is a collection of shell scripts under tools/
discovery:
intent: Helm/manifests, exact image pins, application runbooks and rollout/rollback
intent: Application Helm/manifests, exact image bindings, operator guards and bounded
recovery runbooks; Forgejo identity extension remains in progress.
includes:
- Helm/manifests, exact image pins, application runbooks and rollout/rollback
- S5 application release configuration, exact image/storage bindings and operator
guardrails
- Current Forgejo deployment surface and reviewed source build tooling
- App-consistent attended backup and isolated recovery for the bound Vergabe pilot
excludes:
- Release settings depend on underlying platform and workload owners
- Shared platform/credential authority and application product behavior
- Unadmitted Forgejo identity-extension runtime and general image/schema downgrade
guarantees
assumptions: []
use_cases:
- 'U12: Developer builds and publishes through controlled source, dependency and
@ -62,8 +69,12 @@ discovery:
availability:
current_level: A2
target_level: A3
current_artifacts:
current_artifacts: &id001
- SCOPE.md
- Makefile
- docs/vergabe-demo-company-binding.md
- docs/evidence/2026-11-06-vergabe-pilot-closeout.md
- docs/evidence/2026-11-06-forgejo-owner-continuation.md
target_artifacts: []
consumption_modes:
- CLI
@ -73,13 +84,15 @@ relations:
supports: []
related_to:
- capability.security.iam-tooling-suite
- capability.railiance.vergabe-attended-recovery
evidence:
documentation:
- SCOPE.md
documentation: *id001
tests:
- tools/forgejo-smoke.sh
- tools/k8s-server-dry-run.sh
consumer_feedback: []
consumer_feedback:
- docs/evidence/2026-11-06-vergabe-post-restart-user-return.json
- docs/evidence/2026-11-06-vergabe-attended-backup-complete-return.json
bug_reports: []
incidents: []
consumer_guidance:
@ -94,24 +107,32 @@ consumer_guidance:
- Release settings depend on underlying platform and workload owners
- 2026-10-14 architecture review estimates operational maturity separately; a registry
entry does not authorize execution or establish deployment.
- WP-0014 and WP-0015 release milestones are finished; WP-0016 is active 2/9 and
awaits real owner backends, first-case registration and native acceptance.
- Generic release-tooling maturity is retained; a scoped recovery result does not
promote all workloads.
promotion_history: []
---
# Workload release configuration and guards
Helm/manifests, exact image pins, application runbooks and rollout/rollback.
Application Helm/manifests, exact image bindings, operator guards and bounded recovery runbooks; Forgejo identity extension remains in progress.
## Reuse boundary
Release settings depend on underlying platform and workload owners.
Read [SCOPE.md](../../SCOPE.md) for current ownership and explicit limits.
The June forge split is historical; the current Apps release declaration and
Makefile carry deployment configuration, while forge operating contracts retain
their declared owner. This entry grants no deployment or credential authority.
## Supported use cases
## Current evidence — 2026-11-06
- U12: Developer builds and publishes through controlled source, dependency and runner paths
- U13: Platform owner deploys and rolls back a workload with explicit substrate and custody bindings
WP-0014 is finished (4/4), including two-user/restart acceptance and the first
repeatable attended three-store provider/recovery run. WP-0015 is finished (9/9)
with personal workspace and paired recovery acceptance. WP-0016 remains active
(2/9): source candidates and break-glass do not prove native OIDC admission.
The [owner continuation](../../docs/evidence/2026-11-06-forgejo-owner-continuation.md)
corrects the stale review blocker and names the real remaining backends.
## Evidence and integration
- [SCOPE.md](../../SCOPE.md)
Assessment: CUST-WP-0081, 2026-10-14. Relations identify interfaces to compose; they do not certify native integration. Existing external evidence levels are retained where present. New entries use conservative C1/R0 until consumer assessment exists.
The broad D3/A2/C1/R1 assessment is retained; the narrower recovery entry carries
its own bounded evidence and maturity. No unrelated release is promoted.

27
registry/indexes/capabilities.yaml
View file

@ -1,10 +1,11 @@
version: 1
updated: '2026-10-14'
updated: '2026-11-06'
domain: helix_forge
capabilities:
- id: capability.railiance.workload-deployment-tooling
name: Workload release configuration and guards
summary: Helm/manifests, exact image pins, application runbooks and rollout/rollback.
summary: Application Helm/manifests, exact image bindings, operator guards and bounded
recovery runbooks; Forgejo identity extension remains in progress.
domain: financials
status: draft
owner: railiance-apps
@ -21,3 +22,25 @@ capabilities:
consumption_modes:
- CLI
- source
- id: capability.railiance.vergabe-attended-recovery
name: Attended Vergabe three-store backup and isolated recovery
summary: Capture PostgreSQL, media and SQLite coherently, verify encrypted provider
readback/decryption, and restore the bound demo-company pilot in isolation.
domain: financials
status: reviewed
owner: railiance-apps
tags:
- railiance
- vergabe
- backup
- restore
- postgresql
- sqlite
- media
- attended
- recovery
vector: D3 / A2 / C3 / R2
path: registry/capabilities/capability.railiance.vergabe-attended-recovery.md
consumption_modes:
- CLI
- source