railiance-apps/SCOPE.md

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 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 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 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 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 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 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 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 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, walkthrough, accepted operating arrangement.
• Forgejo operator runbook and current workplan.
• S5 onboarding, data recovery handoff, Django deployment, manifest dry-run.

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 for session and credential-routing rules.