5 Commits

Author	SHA1	Message	Date
Claude Fable 5	18239e2fa9	#221: offline update path incl. migrations, rehearsed with rollback ... Adds docs/operations/update-runbook.md (obtain, verify by digest, back up, apply, verify, roll back) with the migration behaviour stated explicitly: a failed migration rolls back its own transaction but is recorded in _prisma_migrations and blocks every further migrate deploy (P3009) — including a re-deployed old image — until migrate resolve --rolled-back; semantically irreversible migrations have exactly one way back, the pre-update backup set. No rolling updates on a compose stage. Rehearsed in the isolated environment of #220: regular update to a v2 image set, then a deliberate failed-update (P3018 division by zero, schema change proven rolled back) with image-rollback-alone shown insufficient and the documented recovery executed. Protocol: docs/vs-nfd/98-update-rollback-protokoll.md. ADR 0024 decisions 5+6 recorded as executed; operations handbook and restore runbook updated; plan checkbox P1-3 ticked. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01AUtYMxwTCMHG9mVHnwbFg8	2026-07-31 17:26:50 +02:00
Claude Fable 5	ccffcaadd6	#220: protocol of the isolated deployment run ... Full deployment exercised in a compose stack whose networks are all internal: true — setup, login, live collaboration, search, upload, all export formats, backup and restore. tcpdump full capture on both bridges: zero packets leave the isolated subnets; the only outbound attempt the application makes is SMTP, which fails contained in the outbox (5 retries, then FAILED) while the instance stays fully functional. The restore finding became #288, fixed earlier in this chain and re-verified in the same stack. Plan checkbox P1-3 and the I-28 open question ticked; operations handbook airgap section updated. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01AUtYMxwTCMHG9mVHnwbFg8	2026-07-31 17:05:08 +02:00
Claude Fable 5	a758c9d78b	#219: verified reproducible build without network access ... The ADR 0024 §4 decision, taken explicitly and both ways: customers OPERATE prebuilt digest-pinned images (no customer-side build), and ADDITIONALLY the workspace build is verified to work with networking disabled - so site-local patching stays possible without internet. Evidence (docs/vs-nfd/96-offline-build-protokoll.md): pnpm install --offline --frozen-lockfile plus pnpm build under docker run --network none (node:22.15.1-alpine + pnpm 11.9.0, the pinned toolchain), reproduced twice from clean checkouts with identical results. The offline kit is the pnpm store (~870 MB) plus the build user's ~/.cache (~460 MB - the prisma engines live there; without the cache the prisma postinstall fails offline). The one network dependency found and bounded: the drawio plugin's installable ZIP fetches its pinned vendor tarball on first build. Deploy images contain no plugin ZIPs, so the delivery-relevant build is fully offline (CI=1 skips the fetch, as in CI); an offline ZIP build pre-seeds the tarball into packages/plugins/drawio/vendor/. Also catches up the operations manual's scheduler-job table to 10 (read-trail-maintenance was added in #224 without the row here). Refs #219. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01AUtYMxwTCMHG9mVHnwbFg8	2026-07-31 14:39:35 +02:00
Claude Fable 5	2f7ba65eef	#218: mirror procedure into an internal registry ... Airgapped sites pull from their own registry (ADR 0024). The image list is GENERATED (deploy/scripts/list-images.sh resolves the compose file incl. the caddy profile) so a mirror can never silently miss a service; third-party images gain a configurable ${REGISTRY_PREFIX:-} in the compose file (digest pins unchanged - Docker verifies the same sha256 regardless of which registry serves it), own images keep IMAGE_PREFIX; no image reference is ever edited per site. Step-by-step procedure in deploy/stages.md 5b: generate list, copy digest-preservingly (docker buildx imagetools create; plain pull/tag/push as the documented fallback - the digest comparison closes the loop either way), verify the digest in the mirror against the pin, point the deployment via REGISTRY_PREFIX/IMAGE_PREFIX. Executed once end-to-end and recorded as assessor-facing evidence (docs/vs-nfd/95-mirror-protokoll.md): all four third-party images mirrored digest-identically into a local registry:2, plus dorfteich-api:v0.12.0 (sha256:576f1646... identical on both sides; the imagetools stall against the Gitea registry is recorded with its workaround). Operations manual's airgap section now lists the mirror part as available. Refs #218. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01AUtYMxwTCMHG9mVHnwbFg8	2026-07-31 14:33:04 +02:00
Claude Fable 5	040f3fbeae	#229: operations manual (install, update, backup/restore, deletion, roles) ... docs/vs-nfd/70-betriebshandbuch.md: installation as run on the real stages (airgap variant explicitly pending #218-#221 with what already exists as groundwork), update/rollback incl. the no-down-migrations caveat, backup/restore with the ADR-0026 target allowlist and the rehearsed monthly restore drill (evidence: logs on #98), the full scheduler-job table (cadences verified against code), the deletion-and- destruction chapter built on the #228 copy list (per content type: what deletion reaches, what remains, immediate-destruction path, decommissioning), and role separation incl. the deliberate limits of a Site Admin and the honest note that Site Admin read-bypass makes the content/platform split non-absolute app-side. Every procedure carries its evidence level (erprobt / nicht geprobt / offen) — nothing claimed above what was actually executed. Co-Authored-By: Claude Fable 5 (1M context) <noreply@anthropic.com>	2026-07-31 10:35:26 +02:00