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](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.