Next Session: Presenton VF — Full Code Audit & Deploy

Ziel

Presenton VF läuft live unter https://slides.agenticventures.de (AWS Fargate, av-production, eu-central-1, Stack PresententVf). Drei Container im Task: presenton, litellm, cloudflared. Die App zeigt nach Login den Setup-Wizard weil CAN_CHANGE_KEYS fehlt, und wirft dabei HTTP 500 auf dem LiteLLM-Models-Check.

Ziel dieser Session: CDK-Stack vollständig auditieren, alle gefundenen Probleme in einem PR fixen, deployen, und Ende-zu-Ende verifizieren (Login → Präsentation generieren).

Kontext: Was wir wissen

Root Cause des 500-Fehlers (analysiert, noch nicht deployed)

Presenton liest LLM-Config aus einer JSON-Datei (USER_CONFIG_PATH). Fargate hat ephemeral Storage → Datei ist bei jedem Neustart leer. Da CAN_CHANGE_KEYS nicht gesetzt ist (true by default), zeigt Presenton den Setup-Wizard. Der Wizard ruft POST /api/v1/ppt/openai/models/available auf und schlägt mit HTTP 500 fehl, weil die gespeicherte Base-URL leer ist.

Fix bereits in Code geschrieben (nicht deployed):

  • CAN_CHANGE_KEYS: 'false' → bypasst Wizard, Presenton liest alles aus Env-Vars
  • LITELLM_MODEL: 'claude-sonnet-4-6' → required für Startup-Check wenn CAN_CHANGE_KEYS=false

Beide sind bereits in ~/source/apps/presenton-vf/infra/lib/presenton-vf-stack.ts im environment-Block des presenton-Containers eingetragen. Noch nicht deployed.

Auth-Bootstrap-Problem (unklar)

Beim Start erscheint in CloudWatch:

Failed to bootstrap auth from environment: Username must be at least 3 characters
ValueError: Username must be at least 3 characters

AUTH_USERNAME=vibe (4 Zeichen) — sollte < 3 nie triggern. Mögliche Ursache: deployed Image-Version hat schärfere Schwelle als aktueller GitHub-Code. Der dritte Container-Start (jüngster) lief OHNE diesen Fehler — möglicherweise weil DB von manuellem Setup persistiert. Praktischer Fix: AUTH_USERNAME im Secret auf einen längeren Wert setzen (≥ 6 Zeichen).

Bekannte IAM-Drift (potentiell kritisch)

Der CDK-Stack hat für Bedrock-Inference-Profiles:

`arn:aws:bedrock:eu-central-1:${this.account}:inference-profile/eu.anthropic.claude-sonnet-4-6*`

Cross-Region Inference Profiles in Bedrock verwenden leere Account-ID (::) im ARN, nicht die Account-ID des Callers. Korrekt wäre:

arn:aws:bedrock:eu-central-1::inference-profile/eu.anthropic.claude-sonnet-4-6*

Das ${this.account} macht die IAM-Permission möglicherweise unwirksam → Bedrock würde trotz HEALTHY-LiteLLM mit 403/AuthorizationError fehlschlagen wenn tatsächlich ein Completion-Request läuft.

Health-Check-Drift (LiteLLM)

Deployed nutzt: curl -fsS http://localhost:4000/health/liveliness CDK-Source hat: Python-Socket-Test

cdk diff erkennt das und wird es mit-fixen.

Scope dieser Session

1. Code-Audit (vor dem Deploy)

Lies ~/source/apps/presenton-vf/infra/lib/presenton-vf-stack.ts vollständig und prüfe:

  • IAM Bedrock-ARNs: Inference-Profile brauchen :: (leere Account-ID). Foundation Models auch prüfen — aktuell arn:aws:bedrock:eu-central-1::foundation-model/... (korrekt leer).
  • LITELLM_MASTER_KEY vs LITELLM_API_KEY: LiteLLM hat LITELLM_MASTER_KEY im Container-Env (hardcoded sk-vf-presenton-2026). Presenton bekommt LITELLM_API_KEY via Secret (gleicher Wert). Stimmt das Format? LiteLLM erwartet Authorization: Bearer sk-....
  • LiteLLM Config (Base64): model_name: claude-sonnet-4-6 → passt zu LITELLM_MODEL=claude-sonnet-4-6. Bedrock-Modell-ID eu.anthropic.claude-sonnet-4-6-v2:0 — ist das der korrekte Cross-Region-Inference-Profile-Name?
  • enableExecuteCommand: Aktuell false — für Production OK, aber wenn der Fix nicht klappt, brauchen wir es zum Debuggen. Vielleicht auf true setzen für jetzt.
  • AUTH_USERNAME: Im Secret prüfen ob der Wert ≥ 5 Zeichen hat. Falls vibe (4 Zeichen) weiter Probleme macht, im Secret auf vibeai oder vibe-ai anpassen.
  • Sonst was Auffälliges: Missing env vars, fehlende permissions, etc.

2. Fixes implementieren

Fang direkt mit dem Editieren von ~/source/apps/presenton-vf/infra/lib/presenton-vf-stack.ts an:

  1. IAM-ARN korrigieren (falls Audit bestätigt das Problem):
    // VORHER:
    `arn:aws:bedrock:eu-central-1:${this.account}:inference-profile/eu.anthropic...`
    // NACHHER:
    `arn:aws:bedrock:eu-central-1::inference-profile/eu.anthropic...`
  2. enableExecuteCommand auf true (für Debugging-Fähigkeit):
    enableExecuteCommand: true,
  3. Die beiden Fixes aus vorheriger Session sind bereits drin (CAN_CHANGE_KEYS, LITELLM_MODEL) — nicht nochmal einfügen, nur verifizieren dass sie noch drin sind.

Optional: Falls AUTH_USERNAME im Secret nur 4 Zeichen hat und das Bootstrap-Problem relevant ist: Secret-Wert via AWS CLI updaten auf einen längeren Username. Das ist ein AWS-CLI-Call, kein CDK-Change.

3. Deploy

cd ~/source/apps/presenton-vf/infra
AWS_PROFILE=av-production npx cdk diff
# diff prüfen, dann:
AWS_PROFILE=av-production npx cdk deploy PresententVf --require-approval never

Nach dem Deploy: Warten bis Service-Update durch ist (ECS Rolling Update, ~2-3 Minuten). Status prüfen:

aws ecs describe-services \
  --cluster default --services presenton-vf \
  --profile av-production --region eu-central-1 \
  --query 'services[0].{status:status,running:runningCount,desired:desiredCount,events:events[:3]}'

4. Verifizierung

  1. Logs prüfen — kein “Username must be at least 3 characters”, kein “LITELLM_BASE_URL not set”, startup ohne Exception:

    aws logs filter-log-events \
      --log-group-name /aws/ecs/default/presenton-vf \
      --log-stream-name-prefix presenton \
      --start-time $(date -v-5M +%s000) \
      --profile av-production --region eu-central-1 \
      --query 'events[].message' --output text
  2. Browser-Test: https://slides.agenticventures.de öffnen. Erwartet:

    • Login-Screen (kein Setup-Wizard)
    • Login mit vibe / Passwort aus Secret funktioniert
    • Direkt auf /upload weitergeleitet (kein LLM-Config-Wizard)
  3. Präsentation generieren: Ein simples Test-Thema eingeben und Präsentation generieren. Das ist der End-to-End-Test: Presenton → LiteLLM → Bedrock EU → zurück.

  4. LiteLLM-Logs nach Completion-Request:

    aws logs filter-log-events \
      --log-group-name /aws/ecs/default/presenton-vf \
      --log-stream-name-prefix litellm \
      --start-time $(date -v-10M +%s000) \
      --profile av-production --region eu-central-1 \
      --query 'events[].message' --output text

    Erwartet: Request-Logs für /chat/completions erscheinen.

Relevante Dateien

Wenn Bedrock nach dem Deploy noch fehlschlägt

Falls die Präsentations-Generierung mit Bedrock-Fehler scheitert (403, AuthorizationError):

# IAM Policy des Task-Roles prüfen
aws iam list-role-policies \
  --role-name $(aws cloudformation describe-stack-resources \
    --stack-name PresententVf --profile av-production --region eu-central-1 \
    --query 'StackResources[?ResourceType==`AWS::IAM::Role` && LogicalResourceId==`TaskRole`].PhysicalResourceId' \
    --output text) \
  --profile av-production --region eu-central-1

Dann Bedrock-Modell-Verfügbarkeit in eu-central-1 prüfen:

aws bedrock list-inference-profiles \
  --profile av-production --region eu-central-1 \
  --query 'inferenceProfileSummaries[?contains(inferenceProfileId, `claude-sonnet-4-6`)].{id:inferenceProfileId,arn:inferenceProfileArn}'

Der korrekte ARN für die IAM-Policy ergibt sich direkt aus dem Output.