Close S5 app readiness workplan

SCOPE.md

@@ -71,6 +71,9 @@ lessons into reusable S5 app release patterns.
   - 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`.
@@ -135,6 +138,9 @@ lessons into reusable S5 app release patterns.
   `vergabe-teilnahme` lock in its source repo.
 - `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
@@ -147,16 +153,16 @@ lessons into reusable S5 app release patterns.
 
 ## Known Gaps And Opportunities
 
-- The first-app lessons from `vergabe-teilnahme` are documented, but there is
-  no reusable "new S5 app release checklist" yet.
-- The manifest dry-run workflow assumes access to a representative cluster and
-  CRDs. Forge-owned runner labels, placement, and credential prerequisites are
+- 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`;
-  the app-side workflow behavior still needs explicit S5 readiness docs.
-- App-level backup and restore responsibilities need clearer handoff contracts
-  with `railiance-platform`, especially for shared CNPG databases consumed by
-  S5 apps. Forge artifact restore and secret-custody evidence is defined in
+  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`.
@@ -252,9 +258,14 @@ keywords: [operator, runbook, sops, cnpg, dry-run, smoke-test, deployment]
 5. For Gitea registry work, use the forge-owned docs directly:
    `/home/worsch/railiance-forge/docs/gitea-container-registry.md` and
    `/home/worsch/railiance-forge/docs/gitea-package-registry.md`.
-6. For `vergabe-teilnahme`, start with `docs/vergabe-teilnahme.md`, then inspect
+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`.
-7. Run `make check-tools` before deploy work. Run
+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.