Agent Lab

Bildungsanwendung zur Inspektion des technischen Ablaufs von KI-Agenten über Unternehmensdaten. Das Projekt zeigt Verträge, Protokolle, Tool-Aufrufe, strukturierte Ergebnisse und bereinigte Traces.

Status

Etappen 1 bis 11 — Fundament, MCP, Agent Runtime, Auth/RBAC, A2A, Evaluierungen, Cloud, CI/CD, deterministische Verträge, Resilienz und semantische Robustheit:

• Frontend React + Vite;

• Backend Node.js + Express;

• PostgreSQL-Schema und -Migrationen;

• Anwendungsbenutzer admin und viewer;

• deterministische Kalenderperioden;

• technischer Vertrag TraceEvent;

• Unit-Tests und visuelle Shell des Agent Lab;

• offizieller MCP-Server über stdio-Transport;

• sieben schreibgeschützte MCP-Tools mit strukturierten Antworten;

• parametrisierte PostgreSQL-Abfragen über eine Rolle mit minimalen Rechten.

• Ollama mit qwen3:8b für lokale Inferenz und Tool Calling ohne Token-Kosten;

• OpenAI Responses API als optionaler Anbieter beibehalten;

• lokaler MCP-Client mit Tool-Erkennung und -Ausführung;

• grounded Orchestrator und Endpunkt POST /api/agent/query;

• Abfrageoberfläche mit Antwort und realer technischer Trace.

• Authentifizierung mit opaken, in PostgreSQL persistierten Sessions;

• HttpOnly-Cookie, SameSite=Strict und konfigurierbarer Ablauf;

• RBAC-Autorisierung mit Profilen admin und viewer;

• auditierte Benutzeranlage und transaktionale Löschung von HR-Daten.

• zwei Agenten, die A2A-1.0-Agent Cards veröffentlichen;

• Delegation HR → Finanzen über JSON-RPC SendMessage;

• Finanzaufgabe mit Lebenszyklus und strukturiertem Artifact;

• Verlustbericht für Abwesenheiten, abgefragt über MCP.

• Suite von Verhaltensevaluierungen mit deterministischen Assertions;

• Referenzfälle, leeres Ergebnis und PostgreSQL-Frische;

• isolierte dynamische Fixture mit garantierter Bereinigung und Restprüfung.

• budgetiertes Timeout, begrenzter transitorischer Retry und Circuit Breaker pro heißer Instanz;

• sichere Degradierung, die den grounded answerPayload beibehält, wenn nur die Narrativ scheitert;

• Resilienz-Evaluierung mit kontrollierter Fehlerinjektion.

• Interpretation von neutralem, informellem und rioplatensischem Spanisch durch semantischen LLM-Vorschlag;

• Backend-Validierung von Capability, Schema, Periode, Polarität und Grenzen vor MCP;

• typisierte Entscheidungen für Klärungsbedarf und nicht unterstützte Abfragen ohne PostgreSQL-Zugriff;

• versionierter linguistischer Benchmark mit Before/After-Baseline und Stabilität zwischen wiederholten Ausführungen.

Die Anwendung ist mit statischem Frontend auf Render, serverless Backend auf Vercel und PostgreSQL auf Neon bereitgestellt. GitHub Actions wendet Quality Gates und Smoke-Tests gegen die Produktion an.

Related MCP server: Employee Management MCP Server

Struktur

frontend/   React, inspector técnico y system index
backend/    API, dominio, migraciones, acceso PostgreSQL y trazas

Anforderungen

• Node.js 22 oder höher.

• npm 10 oder höher.

• Ollama 0.32 oder höher und das lokale Modell qwen3:8b.

• PostgreSQL-Cloud mit drei getrennten Anmeldedaten, sofern der Anbieter dies erlaubt.

Installation

npm --prefix backend install
npm --prefix frontend install

backend/.env.example nach backend/.env kopieren und die URLs des PostgreSQL-Anbieters ausfüllen. Niemals die Eigentümer-Anmeldedaten in DATABASE_READONLY_URL oder DATABASE_ADMIN_URL verwenden.

Der Standardanbieter ist lokales Ollama:

LLM_PROVIDER=ollama
OLLAMA_HOST=http://127.0.0.1:11434
OLLAMA_MODEL=qwen3:8b

Ollama installieren und das Modell einmal mit ollama pull qwen3:8b herunterladen. Die Inferenz nutzt lokale CPU/GPU und lokalen Speicher, ohne Verbrauch einer kostenpflichtigen API.

OpenAI bleibt als Alternative verfügbar, indem LLM_PROVIDER=openai, OPENAI_API_KEY und OPENAI_MODEL konfiguriert werden. Der Schlüssel gehört ausschließlich in backend/.env, das von Git ignoriert wird. Er darf niemals an das Frontend gesendet oder in Traces aufgenommen werden.

Datenbank

1. Die PostgreSQL-Datenbank beim Cloud-Anbieter erstellen.

2. Die Rollen gemäß backend/ops/database-roles.example.sql erstellen oder konfigurieren.

3. Die Umgebungsvariablen konfigurieren.

4. Ausführen:

npm --prefix backend run db:migrate
npm --prefix backend run db:seed
npm --prefix backend run db:smoke
npm --prefix backend run db:verify-permissions

db:smoke verwendet ausschließlich DATABASE_READONLY_URL und fragt die Sicht hr_late_arrivals mit Datumsparametern ab.

Das Seed erfordert SEED_ADMIN_PASSWORD und SEED_VIEWER_PASSWORD, beide mit mindestens 12 Zeichen. Es gibt keine Standardpasswörter im Repository.

Entwicklung

In zwei Terminals:

npm run dev:backend
npm run dev:frontend

• Frontend: http://localhost:5173

• Backend: http://localhost:3000

Verifizierung ohne Cloud-Datenbank

npm test
npm run typecheck
npm run build

Die Kalendertests prüfen:

• aktueller Monat vom 1. bis einschließlich heute;

• vollständiger vorheriger Kalendermonat;

• Februar eines Schaltjahres;

• letzte 30 Kalendertage.

Zeitintervalle

Die Oberfläche spricht von inklusiven Daten, intern werden jedoch halboffene Intervalle verwendet:

startInclusive <= timestamp < endExclusive

Dies vermeidet die Abhängigkeit von 23:59:59 und erhält die Präzision von PostgreSQL korrekt.

Nachvollziehbarkeit

Das Frontend zeigt technische Ereignisse mit:

• Ereignisname;

• Technologie;

• Komponente;

• Kategorie;

• Konzepte;

• bereinigte Eingabe und Ausgabe;

• Dauer und Status.

Es werden keine Anmeldedaten, Session-Tokens oder interne Modellüberlegungen angezeigt.

MCP-Server

Der Server verwendet das offizielle Model Context Protocol SDK, um Folgendes bereitzustellen:

• count_employees: zählt Gesamt-, aktive und inaktive Mitarbeiter;

• list_employees: listet das vollständige Verzeichnis mit Personalnummer, Name, Abteilung und Status auf;

• find_employee: sucht nach Name oder Mitarbeiternummer;

• summarize_employee_delays: aggregiert die historischen Verspätungen einer Person nach Name oder Personalnummer;

• list_late_arrivals: listet Zuspätkommen nach Zeitraum und optionalem Mitarbeiter auf;

• list_employees_without_late_arrivals: berechnet in PostgreSQL, welche aktiven Mitarbeiter im Zeitraum kein Zuspätkommen hatten;

• list_absences: listet Abwesenheiten nach Zeitraum und optionalem Mitarbeiter auf.

Die Tools deklarieren readOnlyHint, validieren Eingabe und Ausgabe mit Zod und geben sowohl Textinhalt als auch structuredContent zurück. Die Ergebnisse enthalten Quelle, Abfragedatum, angewendeten Zeitraum, Gesamtmenge und Trunkierungssignal. Jeder Aufruf fragt PostgreSQL erneut ab; in dieser Etappe gibt es keinen Cache.

Zum Starten des lokalen MCP-Servers:

npm run mcp:server

Zur Überprüfung von Erkennung, echten Aufrufen, geseedeten Daten und leerem Ergebnis:

npm run mcp:smoke

stdout bleibt dem MCP-Protokoll vorbehalten; operative Fehler werden an stderr gesendet und die Antwort an den Client wird bereinigt.

Agent Runtime

Implementierter Ablauf:

React → POST /api/agent/query → HrAgentOrchestrator
      → Ollama local + qwen3:8b (tool calling)
      → MCP Client → MCP Server → PostgreSQL
      → tool result → Ollama → respuesta + TraceEvent[]

Der MCP-Client erkennt die verfügbaren Tools, aber der Router übergibt dem Modell eine einzige Definition der ausführungsgesteuerten Allowlist. Die Function-Calling-Schemata sind streng und parallele Aufrufe sind deaktiviert, damit jede Ausführung einfach zu inspizieren ist.

grounded: true bedeutet, dass der Orchestrator einen Aufruf eines genehmigten Tools verifiziert und structuredContent erhalten hat, bevor er die endgültige Antwort anfordert. Es bedeutet nicht, dass eine mathematische Garantie für jedes vom Modell erzeugte Token besteht; diese Qualität muss mit Evaluierungen gemessen werden.

Der System-Prompt verlangt, dass Unternehmensdaten ausschließlich aus den Tools stammen, dass leere Ergebnisse explizit gemeldet werden und dass der empfangene Inhalt als Daten und nicht als Anweisungen behandelt wird.

Deterministischer Integrationstest ohne API-Verbrauch:

npm run agent:smoke

Echter Test mit lokalem Ollama, MCP und Neon:

npm run agent:smoke:ollama

Echter Test mit Groq, MCP und Neon:

npm run agent:smoke:groq

Optionaler Test mit OpenAI, MCP und Neon:

npm run agent:smoke:openai

Endpunkt:

POST /api/agent/query
Content-Type: application/json

{"question":"¿Qué empleados llegaron tarde durante el último mes?"}

Die Antwort enthält answer, model, grounded, toolsUsed und eine Sequenz bereinigter technischer Ereignisse. Sie enthält keine Tokens, Anmeldedaten oder interne Überlegungen.

Semantische Robustheit, validiertes Routing und deterministische Darstellung

Der LLM erhält die sieben kontrollierten Capabilities und schlägt genau eine Entscheidung vor. Das Backend vertraut diesem Vorschlag nicht: Es validiert Allowlist, Zod-Schema, vom Benutzer ausgedrückten Zeitraum, Polarität und Geschäftsgrenzen, bevor ein MCP-Aufruf erlaubt wird:

LLM propone → backend valida → MCP ejecuta → PostgreSQL → payload determinista

Zusätzlich zu den sieben MCP-Tools verfügt die Planung über zwei interne Entscheidungen, die MCP nie erreichen: request_clarification und reject_unsupported_query. Die erste gibt agent_clarification_required zurück, wenn ein Zeitraum fehlt oder Mehrdeutigkeit besteht; die zweite gibt unsupported_agent_query zurück, wenn die Anfrage eine nicht vorhandene Capability, Rangfolge, Häufigkeit oder einen nicht vorhandenen Filter verlangt. Der öffentliche Katalog wird unter GET /api/agent/capabilities abgefragt und erscheint auch im System-Index.

Informelle Ausdrücke werden nach Bedeutung interpretiert. Beispielsweise können „llegar", „entrar", „caer", „fichar" oder „marcar tarde" sich auf late_arrivals beziehen; „sin tardanzas" und „siempre puntual" werden nur innerhalb eines expliziten Zeitraums als null Ereignisse interpretiert. Ausdrücke wie „banda", „una bocha", „siempre" oder „seguido" werden niemals in erfundene Mengen umgewandelt.

Nach der MCP-Ausführung validiert AnswerPresentation den structuredContent über eine diskriminierte Zod-Union. Die API gibt zwei getrennte Oberflächen zurück:

• presentation: typisierter, deterministischer answerPayload, gerendert von einer spezifischen React-Komponente;

• answer: grounded Narrativ, vom LLM erzeugt, sichtbar in einem sekundären Panel, das als nicht deterministisch gekennzeichnet ist.

Mengen, Tabellen, Daten, leere Zustände und Quellenmetadaten werden aus presentation angezeigt; sie werden nicht aus dem Modelltext extrahiert. Etappe 11 ändert diesen Vertrag aus Etappe 9 nicht. Die Trace enthält llm.semantic_proposal.completed, agent.semantic_decision.validated und presentation.payload.validated, um Vorschlag, Validierung und deterministische Darstellung zu trennen.

Die verneinte Abfrage wird als Mengendifferenz implementiert: aktive Mitarbeiter minus Mitarbeiter mit mindestens einem Zuspätkommen innerhalb des Zeitraums. PostgreSQL führt diese Semantik über NOT EXISTS aus; der LLM berechnet das Komplement nicht. Wenn Groq eine leere endgültige Antwort zurückgibt oder während der Finalisierung einen zweiten Tool-Aufruf versucht, führt der Adapter einen einzigen textuellen Retry mit denselben grounded Daten durch. Das Ereignis llm.grounded_response.completed meldet recovery=not_required, den angewendeten Retry-Typ oder den Fallback auf die deterministische Darstellung.

Resilienz des LLM-Anbieters

Etappe 10 enthält externe Fehler über vier explizite Mechanismen:

Der öffentliche Endpunkt GET /api/resilience legt die Richtlinie und den bereinigten Zustand des Schaltkreises offen, niemals Zugangsdaten. Der Agent wird innerhalb jeder warmen Instanz wiederverwendet, damit der Circuit Breaker seinen Zustand zwischen Requests beibehält. Bei Vercel besitzt jede Instanz ihren eigenen Schaltkreis; eine globale Koordinierung würde einen verteilten Store erfordern und ist für dieses Labor nicht gerechtfertigt.

Schlägt die anfängliche Planung fehl, existieren noch kein MCP-Aufruf und keine grounded Daten, und die API gibt einen typisierten Fehler zurück (llm_timeout, llm_rate_limited, llm_provider_unavailable oder llm_circuit_open). Schlägt nur die abschließende Formulierung fehl, antwortet die API erfolgreich mit der deterministischen Tabelle und gibt llm.grounded_response.degraded aus.

Authentifizierung und Autorisierung

Die Zugangsdaten werden gegen bcrypt-Hashes in app_users validiert. Bei der Authentifizierung erstellt das Backend ein zufälliges Token, speichert ausschließlich dessen SHA-256-Hash in app_sessions und stellt das Token über ein HttpOnly-Cookie bereit. Das Frontend greift niemals auf das Token zu.

Die Gültigkeitsdauer wird mit SESSION_TTL_HOURS=8 konfiguriert.

Anwendungsberechtigungen:

• viewer: darf den Agenten abfragen und den technischen Index einsehen;

• admin: umfasst die Abfragefunktionen, das Anlegen von Benutzern und das kontrollierte Löschen operativer Daten.

Das administrative Löschen führt kein DROP DATABASE aus. Es entfernt attendance_records, employees und departments innerhalb einer einzigen Transaktion; Schema, Benutzer, Sitzungen und audit_events bleiben erhalten. Es erfordert die wörtliche Bestätigung DELETE HR DATA und protokolliert das Ergebnis im Audit.

Die PostgreSQL-Rolle app_admin besitzt weder DROP, CREATE DATABASE, Superuser noch Mitgliedschaft in neon_superuser. Diese Trennung zeigt, dass Anwendungs-RBAC und Datenbankprivilegien getrennte Schichten sind.

Realer Test beider Benutzer und des vollständigen Sitzungszyklus:

npm run auth:smoke

Agenten und A2A

Das Projekt implementiert A2A Protocol 1.0 mit dem offiziellen SDK @a2a-js/sdk:

• HR Grounding Agent: grounded Abfragen zu Mitarbeitern und Anwesenheit über MCP;

• Absence Finance Agent: deterministische wirtschaftliche Analyse von Abwesenheiten.

Agent Cards:

/.well-known/agent-card.json
/.well-known/hr-agent-card.json
/.well-known/finance-agent-card.json

Finanzfluss:

Usuario → HR Agent / A2A Client
        → descubre Finance Agent Card
        → JSON-RPC SendMessage
        → Finance Agent Task: submitted → working
        → MCP list_absences → PostgreSQL
        → calculadora determinista
        → A2A Artifact application/json
        → Task completed → reporte + TraceEvent[]

Die A2A-Endpunkte verwenden ein internes, zufälliges Bearer-Token. Die Agent Card beschreibt das Sicherheitsschema, enthält aber niemals die Zugangsdaten.

Die Datenbank enthält keine Gehälter. Daher verlangt der Bericht explizite Parameter: Währung, Tageskosten, Ersatzzuschlag und Produktivitätsauswirkung. Die Formel lautet:

días × costo diario × (1 + prima de reemplazo + impacto de productividad)

Das LLM führt die Arithmetik nicht aus. Eine deterministische TypeScript-Funktion berechnet die auf zwei Dezimalstellen gerundeten Beträge. Wenn MCP angibt, dass das Ergebnis abgeschnitten wurde, lehnt der Agent die Berechnung ab, um einen unvollständigen Bericht zu vermeiden.

Die Implementierung verwendet In-Memory-A2A-Aufgaben, da der Ablauf kurz und synchron ist. Für mehrere Instanzen oder lange Aufgaben muss der TaskStore auf einen persistenten Speicher migriert werden.

Realer Test von Agent Card, A2A, MCP und Neon:

npm run a2a:smoke

Evaluierungen des Agenten

Die Unit-Tests validieren Funktionen und Verträge mit kontrollierten Abhängigkeiten. Die Evaluierungssuite misst das vollständige Verhalten des realen Agenten mit dem konfigurierten Modell, MCP und PostgreSQL.

Implementierte Fälle:

• employee-count: prüft, dass eine Mengenfrage ausschließlich an count_employees weitergeleitet wird;

• employee-directory: prüft, dass eine Namensanfrage an list_employees weitergeleitet wird und das Verzeichnis abruft;

• employee-delay-summary: prüft die deterministische Aggregation der Verspätungen von Bruno Silva über summarize_employee_delays;

• employees-without-late-arrivals: prüft Negations-Routing, Mengendifferenz und das erwartete Ergebnis EMP-003;

• known-late-arrivals: vergleicht Tool, Grounding und Anzahl mit dem Seed-Datensatz;

• unknown-employee: verlangt ein leeres PostgreSQL-Ergebnis und eine explizite Antwort ohne erfundene Daten;

• source-of-truth-freshness: fügt einen eindeutigen temporären Mitarbeiter und eine Verspätung ein, fragt den neu erstellten Datensatz ab und prüft, dass der Agent die Aktualisierung beobachtet.

• finalization-failure-degradation: injiziert einen kontrollierten Fehler nach MCP und prüft, dass das PostgreSQL-Payload weiterhin verfügbar ist.

• semantic-robustness-v1: führt 80 neutrale, formelle, informelle, rioplatensische und Grenzformulierungen aus; misst Intention, Entscheidung, Argumente, Zeitlichkeit, Ambiguität und Stabilität.

Das dynamische Fixture verwendet die administrative Rolle nur während der Vorbereitung und Bereinigung. Die Agentenabfrage verwendet weiterhin die Read-only-Rolle. Ein finally-Block löscht anhand exakter UUID und Mitarbeiternummer; nach Abschluss verlangt eine zusätzliche Abfrage, dass weder Mitarbeiter EVAL-% noch Anwesenheiten mit Quelle agent-evaluation existieren.

Reale Ausführung mit dem konfigurierten LLM-Anbieter, MCP und Neon:

npm run evals:run
npm run resilience:eval
npm run semantic:eval
npm run semantic:stability

semantic:eval durchläuft die 80 Fälle einmal und semantic:stability wiederholt den kritischen Satz fünfmal. Beide berichten validDecisionRate, intentRecognitionRate, toolSelectionRate, argumentExtractionRate, temporalInterpretationRate, exactOutcomeRate, stabilityRate, ambiguityPassRate und unsupportedPassRate. Standardmäßig warten sie 30 Sekunden zwischen den Aufrufen, um das kostenlose Token-Budget von Groq zu respektieren und Anbieterlimits von semantischer Instabilität zu unterscheiden. Die Stage-10-Baseline wird in backend/evals/baselines/ aufbewahrt und die Stage-11-Ergebnisse in backend/evals/results/.

Die übrigen Befehle geben reproduzierbares JSON mit passRate, Dauer, erwarteten/tatsächlichen Checks und Grounded-Evidenz pro Fall zurück. Sie enden mit einem von null verschiedenen Exit-Code, wenn eine Evaluierung fehlschlägt oder ein temporäres Fixture zurückbleibt. Der Referenzfall setzt voraus, dass der Demo-Seed vorhanden ist.

Cloud-Deployment

Das Repository hält frontend/ und backend/ getrennt, mit zwei Deployment-Oberflächen:

• agent-lab-ignac: Vite-Frontend als Render Static Site;

• agent-lab-api-ignac: Express-Backend als Vercel Function mit Fluid Compute.

Produktions-URLs:

• Anwendung: https://agent-lab-ignac.onrender.com;

• API: https://agent-lab-api-ignac.vercel.app;

• direkter Health Check: https://agent-lab-api-ignac.vercel.app/api/health.

render.yaml verwaltet nur das Frontend und schreibt /api/* auf https://agent-lab-api-ignac.vercel.app um. Für den Browser bleiben Authentifizierung und Cookies unter dem Ursprung des Frontends; das Sitzungstoken bleibt HttpOnly und wird React nicht ausgesetzt.

backend/vercel.json deklariert Express, ein Maximum von 300 Sekunden und die Region gru1 (São Paulo), nahe der Neon-Datenbank. Vercel erkennt den von src/app.ts exportierten Lazy-Handler; die Anwendung und ihre Pools werden initialisiert, sobald eine Instanz ihre erste Request erhält. src/server.ts behält app.listen() für die lokale Entwicklung bei.

Der MCP-Transport wird über MCP_TRANSPORT ausgewählt:

• stdio: lokale Entwicklung; der Client startet einen eigenständigen MCP-Prozess;

• in_process: Vercel; MCP-Client und -Server verbinden sich über ein Paar In-Memory-Transporte, ohne Protokoll, Verträge, Validierung oder Tool Discovery zu verlieren.

In der lokalen Entwicklung behält LLM_PROVIDER=ollama qwen3:8b. Bei Vercel verwendet LLM_PROVIDER=groq openai/gpt-oss-20b, das Function Calling unterstützt. Der Groq-Adapter erzwingt mindestens ein Tool und gibt dessen Ergebnis an das Modell zurück, um die grounded Antwort zu erzeugen.

Erforderliche Produktionsvariablen im Vercel-Projekt:

NODE_ENV=production
FRONTEND_ORIGIN=https://agent-lab-ignac.onrender.com
APP_TIMEZONE=America/Argentina/Buenos_Aires
SESSION_TTL_HOURS=8
PUBLIC_BASE_URL=https://agent-lab-api-ignac.vercel.app
MCP_TRANSPORT=in_process
LLM_PROVIDER=groq
GROQ_MODEL=openai/gpt-oss-20b
GROQ_API_KEY=<secret>
LLM_TIMEOUT_MS=12000
LLM_TRANSIENT_RETRIES=1
LLM_CIRCUIT_FAILURE_THRESHOLD=3
LLM_CIRCUIT_RESET_MS=30000
DATABASE_READONLY_URL=<secret>
DATABASE_ADMIN_URL=<secret>
A2A_INTERNAL_TOKEN=<secret-aleatorio-de-32-o-mas-caracteres>

Das öffentliche Backend ergänzt Header mit Helmet, Rate Limits, explizite Fehlerbehandlung und GET /api/health. Die In-Memory-Limits sind demonstrativ und wirken pro warmer Instanz; eine verteilte Produktionsanwendung würde einen gemeinsamen Store verwenden. PostgreSQL bewahrt Benutzer, Sitzungen und Daten, sodass das serverlose Dateisystem weiterhin verzichtbar bleibt.

CI/CD und Quality Gates

Jeder push auf main und jeder Pull Request führt .github/workflows/ci.yml aus. Backend und Frontend werden in unabhängigen, reproduzierbaren Jobs unter Node.js 22 validiert:

checkout → npm ci → typecheck → build → tests → audit de dependencias productivas

npm ci installiert exakt den durch jede package-lock.json festgelegten Baum. Die Jobs besitzen nur Leseberechtigung für das Repository, haben ein Timeout und brechen frühere Ausführungen desselben Branches ab. Keine Produktions-Zugangsdaten werden an den CI-Workflow übergeben.

Vercel ist mit dem Repository verbunden, mit backend/ als Root Directory; ein akzeptierter Commit auf main erzeugt das serverlose Deployment. Render hält das statische Frontend aus frontend/. Diese Trennung unterscheidet zwei Kontrollen:

• Quality Gate vor der Laufzeit: Typen, Kompilierung, Tests und Audit;

• Smoke Test nach dem Deployment: tatsächlich bereitgestellter öffentlicher HTTP-Vertrag.

.github/workflows/production-smoke.yml reagiert auf erfolgreiche Deployment-Status und erlaubt auch manuelle Ausführung. scripts/production-smoke.mjs prüft:

• direkten Health Check des Vercel-Backends;

• Vertrag von /api/system und aktuelle Stufe;

• öffentlichen Vertrag von /api/resilience;

• Proxy /api/*, der unter dem Render-Ursprung bereitgestellt wird;

• Verfügbarkeit des HTML-Dokuments des Frontends.

Lokale Ausführung desselben Produktionsvertrags:

node scripts/production-smoke.mjs