Skip to content

docs(EYT-142): Staging-Abnahme 25.08.2026 — Evidenz, Runbook-Korrekturen, Staging-Suite - #93

Merged
DYAI2025 merged 2 commits into
masterfrom
chore/eyt-142-staging-abnahme-evidenz
Aug 25, 2026
Merged

docs(EYT-142): Staging-Abnahme 25.08.2026 — Evidenz, Runbook-Korrekturen, Staging-Suite#93
DYAI2025 merged 2 commits into
masterfrom
chore/eyt-142-staging-abnahme-evidenz

Conversation

@DYAI2025

@DYAI2025 DYAI2025 commented Aug 25, 2026

Copy link
Copy Markdown
Owner

Was dieser PR enthaelt

Nur Dokumentation, Evidenz und eine manuelle Staging-Testsuite — kein Laufzeitcode, keine CI-Aenderung, keine Migration.

  • docs/evidence/2026-08-25-eyt-142-staging/: Abnahme der realen Admin-Kernreise auf dem VPS/Coolify-Staging am Head 164f1a1 — 19 reale Screenshots (1440/1920, Fokus, Negativfaelle), ids.json mit den massgeblichen Server-IDs, README mit allen fuenf Runbook-§8-Angaben (Head+CI-Runs, GHCR-Digests+OCI-Revisionen, Migrationsstand 18/18, Datengrenze, Smokes).
  • docs/runbooks/staging-deploy.md: vier Korrekturen aus der Wirklichkeit — §1 Datengrenze seit 24.08. erfuellt (VPS-lokaler Stack, Owner-Auftrag), §3 HTTPS-Pflicht (gemessen: crypto.randomUUID verlangt Secure Context, sonst scheitert jeder Schreibvorgang still), §7 Rollback ausgefuehrt statt beschrieben, §9 Coolify-Onboarding ausgefuehrt mit benannten Abweichungen. Railway (§10) bleibt ausdruecklich „nicht gemessen".
  • docs/plans/2026-08-24-vps-staging-deploy-protokoll.md: Deploy-Protokoll vom 24.08. (war bisher nur lokal) plus Nachtrag 25.08. (Coolify-Deploy, VPS-Lastvorfall mit korrektem fail-closed der API, HTTPS).
  • apps/web/e2e-staging/: die Playwright-Suite der Abnahme (14 Faelle). Bewusst kein Pflichtcheck und nicht Teil von pnpm test/auth-journey; laeuft nur manuell mit EYT_*-Umgebungsvariablen gegen ein reales Staging.

Abnahme-Kurzfassung (Details im Evidenz-README)

  • Deploy: exakte GHCR-Digests des Heads 164f1a1 via Coolify (Projekt easytree/staging), OCI-Revision aller drei Container = Head, User node, /health+/ready 200 (config+database), 0 Header-/HTML-Lecks, Logs secretfrei.
  • Kernreise 14/14 ueber https://srv1308064.hstgr.cloud: Login → aktuelle Woche ohne weekKey → Wochennavigation → Einsatz per Formular (201, Assignment-ID) → Reload=Serverstand → Publish (Planversion 42e052be…) → Kosten-Snapshot (8e05f8c3…, 17000 Minor = 170,00 EUR, 1 Position) → zweiter Browserkontext mit denselben IDs; SQL-Gegenprobe in PostgreSQL.
  • Negativ: ohne Mitgliedschaft und member ohne costs.read je UI-fail-closed und direkter API-Zugriff 403; „Satz fehlt" → 409 urn:easytree:costs:rate-not-found, kein Snapshot gespeichert, nirgends 0,00; „Satz mehrdeutig" auf Schemaebene unmoeglich (EXCLUDE-Constraint, Einspielversuch gemessen abgewiesen).
  • axe wcag2a/aa bei 1440/1920/200 % auf /planung und /kosten: 0 Violations; Tastatur erreicht Formular und Publish, Fokusring im Screenshot.
  • Rollback-Uebung: Kandidat → Vorgaenger 3b4bbdb (verifiziert, 32 s) → Kandidat (verifiziert, 42 s), Zeitstempel im README.

🤖 Generated with Claude Code

Summary by Sourcery

Document and verify the EYT-142 staging acceptance on the VPS/Coolify environment with reproducible evidence and a manual end-to-end test suite.

New Features:

  • Add a manually triggered Playwright staging acceptance suite covering the authenticated planning and cost workflows, cross-context consistency, authorization failures, missing-rate handling, accessibility, and responsive reflow.

Enhancements:

  • Update the staging runbook with verified VPS data-boundary, HTTPS, rollback, Coolify onboarding, bootstrap, and published-data reset behavior based on executed deployments.
  • Document the VPS/Coolify deployment protocol, operational deviations, runtime findings, and rollback exercise.

Deployment:

  • Record the executed VPS/Coolify staging deployment, pinned container digests, health checks, data-boundary verification, and rollback evidence.

Documentation:

  • Add evidence for the 25 August 2026 staging acceptance, including screenshots, server-generated IDs, deployment metadata, security checks, SQL verification, negative cases, and accessibility results.

Tests:

  • Add an isolated, manually run staging Playwright configuration that does not participate in the regular test or CI suites.

…igests, Kernreise 14/14, Rollback-Uebung

Evidenzpaket docs/evidence/2026-08-25-eyt-142-staging/ (Screenshots, ids.json,
README nach Runbook §8), Runbook-Korrekturen aus der Wirklichkeit (VPS-lokale
Datengrenze in §1, HTTPS-Pflicht wegen crypto.randomUUID in §3, ausgefuehrter
Rollback in §7, Coolify-Onboarding in §9), Deploy-Protokolle 24./25.08. und die
Playwright-Staging-Suite apps/web/e2e-staging (kein Pflichtcheck, laeuft nur
manuell gegen ein reales Staging).

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

@sourcery-ai sourcery-ai Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry @DYAI2025, you've used your own review budget of 250,000 diff characters for the last 7 days.

You can request another review in 23 hours and 34 minutes by commenting @sourcery-ai review. Upgrade to get a review now.

@sourcery-ai

sourcery-ai Bot commented Aug 25, 2026

Copy link
Copy Markdown

Reviewer's Guide

Der PR enthält ausschließlich Dokumentation, Evidenz und eine bewusst manuelle Staging-Playwright-Suite: Er macht die VPS-/Coolify-Abnahme am exakten Release-Head nachvollziehbar, prüft die reale Admin-Kernreise einschließlich Fail-Closed- und Accessibility-Fällen und synchronisiert das Runbook mit den tatsächlich gemessenen Deploy-, HTTPS-, Daten- und Rollback-Bedingungen.

Sequence diagram for the staging admin journey and fail-closed checks

sequenceDiagram
    actor Admin
    participant Web as Staging Web
    participant API as API
    participant DB as PostgreSQL

    Admin->>Web: anmelden
    Web->>API: POST /api/v1/auth/login
    API-->>Web: 200 userId + session
    Admin->>Web: Einsatzformular ausfüllen und speichern
    Web->>API: POST /api/v1/planung/einsaetze
    API->>DB: persist assignment
    DB-->>API: assignmentId
    API-->>Web: 201 assignmentId
    Admin->>Web: Publish klicken
    Web->>API: Publish-Command
    API->>DB: create published plan version
    DB-->>API: publishedVersionId
    API-->>Web: publishedVersionId
    Admin->>Web: Snapshot erzeugen
    Web->>API: POST /api/v1/kosten/snapshots
    API->>DB: create cost snapshot
    DB-->>API: snapshotId + totalMinorUnits
    API-->>Web: 201 17000 Minor Units
    Admin->>Web: zweiter Browserkontext
    Web->>API: GET published version and snapshot
    API->>DB: authorize and read
    DB-->>API: same IDs
    API-->>Web: same publishedVersionId + snapshotId

    rect rgb(255,235,235)
      Admin->>Web: Zugriff ohne Mitgliedschaft oder costs.read
      Web->>API: GET /api/v1/kosten/snapshots/{snapshotId}
      API-->>Web: 403 ohne Betragsdaten
      Admin->>Web: Satz fehlt: Snapshot erzeugen
      Web->>API: POST /api/v1/kosten/snapshots
      API-->>Web: 409 urn:easytree:costs:rate-not-found
    end
Loading

Flow diagram for the manual staging acceptance suite

flowchart TD
    Start[Run staging.config.ts manually]
    Config[EYT_* environment variables and HTTPS staging URL]
    Login[anmelden]
    Planning["/planung: current week and navigation"]
    Assignment[POST /api/v1/planung/einsaetze: create assignment]
    Reload[Reload and verify server state]
    Publish[Publish plan version]
    Costs["/kosten: create snapshot"]
    Evidence[Capture screenshots, axe results, reflow checks, and ids.json]
    Negative[Verify 403 and 409 fail-closed cases]
    CrossContext[Verify IDs in a second browser context]

    Start --> Config --> Login --> Planning --> Assignment --> Reload --> Publish --> Costs
    Costs --> CrossContext --> Evidence
    Costs --> Negative --> Evidence
Loading

File-Level Changes

Change Details Files
Eine eigenständige, manuell ausgeführte Playwright-Abnahmesuite prüft die reale Admin-Kernreise und dokumentiert dabei Serverantworten, IDs, Screenshots, Barrierefreiheit und Negativfälle.
  • Führt Login, Wochennavigation, Einsatzanlage, Reload-Persistenz, Publish und Kosten-Snapshot serialisiert gegen konfigurierbares Staging aus.
  • Erfasst maßgebliche IDs aus API-Antworten und schreibt sie zusammen mit Evidenz-Screenshots in ein Ausgabeverzeichnis.
  • Prüft zweiten Browserkontext, fehlende Mitgliedschaft, fehlendes Kostenrecht, fehlende Sätze sowie 403/409-Fail-Closed-Verhalten.
  • Führt axe- und Reflow-Prüfungen bei 1440, 1920 und 200-%-Zoom sowie Tastatur-/Fokusprüfungen aus.
  • Bleibt bewusst außerhalb von Standardtests, CI und automatisch gestarteten Webservern; Ziel und Testdaten sind über EYT-Umgebungsvariablen steuerbar.
apps/web/e2e-staging/journey.spec.ts
apps/web/e2e-staging/staging.config.ts
Die reale Staging-Abnahme wird als reproduzierbares Evidenzpaket mit Deployment-, CI-, Container-, Datenbank-, Sicherheits- und Rollback-Nachweisen festgehalten.
  • Bindet die Abnahme an Head 164f1a1, erfolgreiche CI-Runs, exakte GHCR-Digests und OCI-Revisionen aller Container.
  • Dokumentiert 14/14 Journey-Fälle, 19 Screenshots, Server-IDs, SQL-Gegenproben, Secret-/Leak-Smokes und die HTTPS-Abhängigkeit.
  • Belegt die Negativreisen, den unveränderlichen Datenbestand veröffentlichter Stände und die ausgeführte Kandidat-Vorgänger-Kandidat-Rollback-Übung.
  • Erfasst bewusste Betriebsabweichungen einschließlich VPS-lokalem Supabase-Stack, Coolify-Digest-Deployment, Host-Netz-Topologie und Host-nginx-TLS.
docs/evidence/2026-08-25-eyt-142-staging/README.md
docs/evidence/2026-08-25-eyt-142-staging/ids.json
docs/plans/2026-08-24-vps-staging-deploy-protokoll.md
Das Staging-Runbook wird von einem ungemessenen, gesperrten Ablauf auf den tatsächlich ausgeführten VPS-/Coolify-Betrieb aktualisiert.
  • Hebt die VPS-lokale Datengrenze nach Owner-Freigabe hervor und erhält die Sperre für cloudseitiges Staging aufrecht.
  • Ergänzt die gemessene HTTPS-Pflicht für Browser-Schreibvorgänge und aktualisiert Bootstrap-, Rollback- und Ausführungsstatus.
  • Beschreibt die Coolify-Abweichungen beim Digest-Pull, der Host-Netz-Topologie und der fehlenden Coolify-Redeploy-Historie.
  • Kennzeichnet Railway weiterhin ausdrücklich als nicht gemessen.
docs/runbooks/staging-deploy.md

Tips and commands

Interacting with Sourcery

  • Trigger a new review: Comment @sourcery-ai review on the pull request.
  • Continue discussions: Reply directly to Sourcery's review comments.
  • Generate a GitHub issue from a review comment: Ask Sourcery to create an
    issue from a review comment by replying to it. You can also reply to a
    review comment with @sourcery-ai issue to create an issue from it.
  • Generate a pull request title: Write @sourcery-ai anywhere in the pull
    request title to generate a title at any time. You can also comment
    @sourcery-ai title on the pull request to (re-)generate the title at any time.
  • Generate a pull request summary: Write @sourcery-ai summary anywhere in
    the pull request body to generate a PR summary at any time exactly where you
    want it. You can also comment @sourcery-ai summary on the pull request to
    (re-)generate the summary at any time.
  • Generate reviewer's guide: Comment @sourcery-ai guide on the pull
    request to (re-)generate the reviewer's guide at any time.
  • Resolve all Sourcery comments: Comment @sourcery-ai resolve on the
    pull request to resolve all Sourcery comments. Useful if you've already
    addressed all the comments and don't want to see them anymore.
  • Dismiss all Sourcery reviews: Comment @sourcery-ai dismiss on the pull
    request to dismiss all existing Sourcery reviews. Especially useful if you
    want to start fresh with a new review - don't forget to comment
    @sourcery-ai review to trigger a new review!

Customizing Your Experience

Access your dashboard to:

  • Enable or disable review features such as the Sourcery-generated pull request
    summary, the reviewer's guide, and others.
  • Change the review language.
  • Add, remove or edit custom review instructions.
  • Adjust other review settings.

Getting Help

…sleser-Waechter hatte recht

Der secret-surface-Waechter meldete die process.env-Zugriffe der neuen Suite
als Laufzeitpfad: apps/web/e2e-staging/ stand nicht unter den ausgenommenen
Testpfaden. Statt die Ausnahmeliste zu weiten, zieht die Suite unter das
bereits ausgenommene apps/web/e2e/ und traegt wie auth-journey die Endung
.pwtest.ts, damit weder die Haupt-Playwright-Config noch vitest sie
aufsammeln. Dazu ids.json prettier-konform.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
@DYAI2025
DYAI2025 merged commit 02c6693 into master Aug 25, 2026
13 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants