# SCOPE Last reviewed: 2026-11-06. `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 - **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. ## 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. 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. **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. ## Remaining work and limits **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. ## Lower-layer and application boundaries - `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. 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. ## 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. Useful entry points: - [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). 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.