v1.6.0 – Eigene Domain demo.vompa.dev, App schläft nicht mehr

Neu

• Die Demo läuft jetzt unter einer eigenen Adresse: https://demo.vompa.dev (Landingpage, /demo, /swagger). Das TLS-Zertifikat stellt Azure kostenlos aus und erneuert es selbst. Die alte Azure-Adresse funktioniert weiter.
• Eigene Domain als optionale Einstellung im Deployment: Bicep-Parameter customDomain und customDomainCertificate, im Workflow über die Repository-Variablen CUSTOM_DOMAIN und CUSTOM_DOMAIN_CERTIFICATE. Ohne Werte läuft die App wie bisher nur unter der Azure-Adresse, die Domain bleibt aber bei jedem Deployment erhalten. Die Einrichtung (DNS-Einträge, az containerapp hostname bind) steht in infra/README.md.
• Die App schläft nicht mehr ein: Der Bicep-Parameter minReplicas ist standardmäßig 1. Es gibt keinen Kaltstart mehr, Kontingent und Daten bleiben bis zum nächsten Deployment erhalten. Mit minReplicas = 0 ist Scale-to-zero wieder möglich und kostet im Leerlauf praktisch nichts.

Geändert

• Demo-Seite in der Handy-Ansicht: Das kleine Handy im gelben Banner „Zugang zur Demo“ wird unter 900 px Breite nicht mehr angezeigt, weil es dort nicht sauber dargestellt wurde. Am Desktop bleibt es sichtbar.
• Die README verlinkt Live-Demo und API-Doku auf die neue Adresse.
• 209 Tests, alle grün.

Grenzen

• Die dauerhaft laufende Instanz kostet grob 3 bis 6 USD pro Monat. Das ist eine Schätzung, den genauen Preis zeigt die Azure-Preisübersicht.
• Das Deployment mit eigener Domain ist einmal von Hand durchgespielt (Domain, Zertifikat, zwei Läufe), ein Test dafür im CI fehlt.
• Unverändert: flüchtige Daten in Azure, das Kontingent liegt im Speicher, API-Keys statt Entra ID.

v1.5.0 – Neues Design der Demo-Seiten

Neu

• Neues Design für die Demo-Seiten (Landingpage und Demo mit Chat) nach einer Designvorlage: helle Rahmenkarte auf grauem Grund, Gelb und Fast-Schwarz als Akzent, große weiche Karten, ein Telefon-Mockup, das die echte Tool-Spur zeigt, blaue und grüne Funktionskarten, Kacheln mit Pastellkreisen, die Tabelle „Zahlen & Grenzen“, ein Diagramm „So hängt es zusammen“, ein gelbes Banner als Anmeldung, Projektkarten und ein mehrspaltiger Fuß. Nur Systemschriften, alle Grafiken als eigene SVG-Formen, keine Marke, Texte oder Fotos der Vorlage.
• Demo-Seite (/demo) mit gleicher Hülle: Kontingent als Pillen mit Farbpunkt, runder Chat, pastellfarbene Beispielfragen, gelber Senden-Button, Tool-Spur als Spalte weicher Karten mit Status in Farbe und Text.
• Link zur Live-Demo und zur API-Doku ganz oben im README.

Geändert

• Impressum und Datenschutzseite sind entfernt (Seiten, Routen, Fußzeilen, Tests und Doku). Das ist bewusst: Die Daten sind nur Länderdaten, der Zugang ist reiner Lesezugriff für wenige Eingeladene. Die Landingpage sagt offen, dass Fragen an die Anthropic-API gehen und die Server-Logs IP-Adressen enthalten. Wer die Demo weiter öffnet, sollte das neu bewerten.
• Stackdump-Dateien werden nicht mehr eingebettet und nicht in den Docker-Kontext kopiert.
• 209 Tests (zuvor 212, wegen der entfernten Seiten), CodeTour mit 43 Schritten.

Wie das Design entstanden ist

Ein Generator-Agent hat die Seiten gebaut, ein Evaluator-Agent hat sie im Browser gegen die Vorlage bewertet: Runde 1 mit 7,5 von 10, danach wurden zwölf belegte Mängel behoben (Diagramm, Schriftgrößen, Tabelle auf schmaler Breite, Kontrast im Banner, Höhe des Chats und der Tool-Spur). Eine zweite Bewertung durch den Evaluator gab es nicht.

Grenzen

• Das Telefon-Mockup hat keine Hand und keine Tiefe wie die Vorlage.
• Die neue Optik habe ich nur schmal selbst gesehen, die breite Ansicht, Hell und Dunkel stammen aus den Berichten des Evaluators und Generators. Ein vollständiger Tab-Durchlauf fehlt.
• Unverändert: flüchtige Daten in Azure, das Kontingent liegt im Speicher und wird bei einem Neustart zurückgesetzt, API-Keys statt Entra ID, das echte Modell ist nur von Hand getestet.

v1.4.0 – Öffentliche Demo mit Claude

Neu

• Öffentliche Demo mit Claude (optional, standardmäßig aus): Landingpage, Zugang mit gemeinsamem Zugangscode und eine Demo-Seite, auf der ein echtes Claude-Modell die MCP-Tools dieser App aufruft. Die Seite zeigt Antwort und die Tool-Aufrufe live, auch Fehler und Korrekturen (get_country("Island") → Fehler → IS → ISL).
• Nur deine Tools, nur lesend: Claude sieht ausschließlich search_countries, get_country und list_regions, ohne eingebaute Claude-Werkzeuge. Die Demo ruft /mcp mit einem Reader-Key auf, Änderungen werden mit 403 abgewiesen. Der Browser liefert nur den Prompt-Text; Modell, Tools, Ziel und Grenzen sind fest.
• Limits: 100 Abfragen pro Stunde für alle, 15 pro Sitzung, 400 pro Tag (gleitendes Fenster), 300 Zeichen pro Frage, 6 Tool-Runden, begrenzte Antwortlänge.
• Zugang: Zugangscode nur als Hash, Vergleich in konstanter Zeit, Bremse gegen Raten, signiertes Sitzungs-Cookie (HttpOnly, SameSite=Strict), CSRF-Header für alle POSTs. Keine Konten, keine Personendaten.
• Strenge Content-Security-Policy ohne Inline-Code, ohne fremde Server und Tracker.
• Deployment: Die Demo wird im Azure-Workflow nur eingeschaltet, wenn die vier Demo-Secrets gesetzt sind. Ohne sie ändert sich nichts.
• Kosten gemessen: rund 0,03 Cent pro Frage (Haiku 5.5, zwei Stichproben), Token-Nutzung steht bei jeder Frage im Log.
• Außerdem: 209 Tests (zuvor 123) mit Mutationsproben für sieben Absicherungen, CodeTour auf 43 Schritte erweitert, Link zur Live-Demo und zur API-Doku ganz oben im README.

Grenzen

• Kein Impressum und keine Datenschutzseite: bewusst weggelassen, weil die Daten nur Länderdaten sind und der Zugang reiner Lesezugriff für wenige Eingeladene ist. Die Prompts gehen zur Beantwortung an die Anthropic-API, die Server-Logs enthalten IP-Adressen. Wer die Demo weiter öffnet, sollte das neu bewerten.
• Das Kontingent liegt im Speicher: Ein Neustart (auch Scale-to-zero) setzt es zurück. Die harte Kostengrenze ist das Ausgabenlimit in der Anthropic-Konsole.
• Ob eine Frage zum Thema passt, entscheidet am Ende das Modell. Der Systemtext begrenzt es auf die Länderdaten, ein harter Schutz ist das nicht.
• Der echte Modellaufruf ist nicht automatisiert getestet, nur von Hand gegen die Azure-Instanz. Die Oberfläche mit echten Chat-Ereignissen wurde über die Schnittstelle, aber nicht im Browser auf Azure durchgespielt.
• Unverändert: flüchtige Daten in Azure, API-Keys statt Entra ID, öffentliche Erreichbarkeit.

v1.3.0 – Swagger-Oberfläche für die OData-API

Neu

• Swagger-Oberfläche unter /swagger und ein OpenAPI-Dokument unter /openapi/odata.json, zur Laufzeit aus dem EDM-Modell erzeugt (Microsoft.OpenApi.OData). Über Authorize wird der Header X-Api-Key gesetzt, danach lassen sich die Aufrufe direkt ausprobieren.
• Das Dokument beschreibt nur, was die API wirklich bietet: lesen auf allen drei Mengen, POST, PATCH und DELETE nur auf Countries. Der Generator hatte zuerst mehr Operationen beschrieben (z. B. POST auf WorldRegions, die in Wirklichkeit 405 liefern); ein Test hält das jetzt fest.
• Standardmäßig aus (OpenApi:Enabled). Eingeschaltet im Development-Profil und im Azure-Deployment (Bicep).
• Oberfläche und Dokument sind ohne Key lesbar und enthalten keine Daten. Datenendpunkte und /mcp verlangen weiterhin den API-Key (401 ohne).
• Das Dokument nutzt eine relative Server-URL (/odata/v1) und hängt nicht vom Host-Header ab.
• Abhängigkeiten: Microsoft.OpenApi auf 3.5.4 angehoben (die transitiv gezogene 3.5.1 hat eine bekannte Schwachstelle beim Einlesen zirkulärer Schemata), Microsoft.OData.Core auf 8.4.3 abgeglichen. Keine bekannten Schwachstellen mehr.
• 123 Tests (zuvor 114): Swagger aus bzw. an, Dokument, unterstützte Operationen, Host-Header, Schutz der Daten.

Grenzen

• Swagger deckt nur OData ab. Der MCP-Endpunkt /mcp ist kein REST und steht nicht im Dokument.
• Unverändert: flüchtige Daten in Azure, API-Keys statt Entra ID, öffentliche Erreichbarkeit mit Key und Rate Limit.

v1.2.1 – https-Links hinter dem Azure-Proxy

Behoben

• OData-Links zeigten hinter dem TLS-Proxy http:// statt https://. Die App wertet jetzt X-Forwarded-Proto und X-Forwarded-For aus, wenn ForwardedHeaders:Enabled gesetzt ist. In Azure ist das über das Bicep eingestellt.
• Das Rate Limit für anonyme Anfragen sieht dadurch die echte Client-IP statt der IP des Proxys.

Sicherheit

Die Auswertung ist standardmäßig aus. Wer die App direkt erreicht, könnte die Header sonst fälschen und das IP-basierte Rate Limit umgehen. Sie gehört nur dort angeschaltet, wo der Proxy der einzige Zugangsweg ist.

Tests

114 Tests (zuvor 112): Mit der Einstellung übernehmen OData-Links das Schema des Proxys, ohne sie werden die Header ignoriert. Ohne die Middleware wird der erste Test nachweislich rot.

Grenzen

Unverändert: flüchtige Daten (SQLite im Container), API-Keys statt Entra ID, öffentliche Erreichbarkeit mit Key und Rate Limit.

v1.2.0 – Deployment auf Azure

Neu

• Deployment auf Azure Container Apps per GitHub Actions (manuell auslösbar): Anmeldung über OIDC ohne gespeicherte Passwörter, Infrastruktur als Bicep, Image in der Container Registry, Smoke-Test nach dem Ausrollen.
• Dockerfile (Multi-Stage, läuft nicht als root) und .dockerignore.
• infra/main.bicep: Log Analytics mit Tageslimit, Container Registry ohne Admin-Zugang, Managed Identity mit AcrPull, Container App mit Scale-to-zero, Health-Probes und API-Keys als Secrets.
• Einrichtung, Kosten, Aufräumen und Grenzen in infra/README.md.
• Neues Demo-GIF: ein echter Agent (Claude Code) arbeitet gegen den MCP-Endpunkt in Azure, inklusive Fehlerkorrektur und abgewiesenem Schreibversuch mit Reader-Key.
• Tests: 112 (zuvor 95), darunter Region-Endpunkte, 404/400-Fehlerpfade und MCP-Fehlertexte.

Grenzen

• Die Daten in Azure sind flüchtig: SQLite im Container, eine Replik, Neuaufbau bei jedem Start.
• Die Anmeldung läuft weiter mit API-Keys. Der Weg über Authority (Entra ID) ist nicht gegen einen echten Identity Provider getestet.
• Die Instanz ist öffentlich erreichbar und durch API-Key und Rate Limit geschützt.
• @odata.context enthält hinter dem TLS-Proxy http:// statt https:// (funktional ohne Folgen).

v1.1.0 – OAuth2/JWT

Neu

• OAuth2/JWT als zweite Anmeldeart neben den API-Keys (optional, über Authentication:Jwt). Ein Policy-Schema wählt pro Anfrage den passenden Handler.
• Scopes (scp/scope) und App-Rollen (roles) werden auf die vorhandenen Rollen reader und writer abgebildet, OData-Policy und MCP-Tool bleiben unverändert.
• Strenge Token-Prüfung: Aussteller, Zielgruppe und Ablauf, nur signierte Tokens, beim lokalen Schlüssel nur HS256, Toleranz 30 s.
• Konfiguration wird beim Start validiert: eine halbe JWT-Konfiguration verhindert den Start.
• Hilfsbefehl issue-token für lokale Demo-Tokens (nur Development).
• 95 Tests (zuvor 42), darunter acht Arten kaputter Tokens, Scope- und Rollen-Fälle und MCP mit Token.
• CodeTour um fünf Schritte erweitert.

Grenzen

Die Validierung ist mit lokal signierten Tokens getestet. Der Weg über Authority (OIDC-Discovery, z. B. Entra ID) ist nicht gegen einen echten Identity Provider geprüft.

v1.0.0 – Erste Version

Erste veröffentlichte Version.

Der OData-v4-Service des ODataSample (EF Core, SQLite, 264 Länder), umgebaut für KI-Agenten: MCP-Endpunkt /mcp mit den Tools search_countries, get_country, list_regions und update_country. Der OData-Service bleibt daneben erhalten.

Sicherheit: API-Key mit den Rollen reader und writer, alles standardmäßig geschützt, Rate Limit, Seiten- und Abfragelimits, Audit-Log je Tool-Aufruf.

Datenfunde: NameGER enthält in den Quelldaten den englischen Langnamen, und die Ja/Nein-Kodierung ist uneinheitlich. Beides ist im Agenten-Vertrag behandelt und im README erklärt.

Qualität: 42 Tests, CI mit Warnungen als Fehler, keine bekannten Schwachstellen. Dazu eine CodeTour durch den Umbau.