# Video Analysis Batch 5 — Security + DevOps + Deploy Stack
**Date:** 2026-06-02
**Analyst:** Aria
**Videos:** v18, v19, v20, v21, v22, v24
**Theme:** Security hardening, DevOps concepts, AI production deployment, Vibe-coding critique

---

## CRITICAL FLAG: v19 = v24 DUPLICATE

**v19** (`/tmp/aria-watch-087c44d99a75`) and **v24** (`/tmp/aria-watch-f903ff95221b`) are the exact same video extract:
- Identical transcript (1510 chars, word-for-word match)
- Identical duration: 96.066667s
- Identical frames (confirmed visually — same person, Vercel-branded hoodie, same scene)
- v24 title "You don't need SOC2 — you need these three checks" matches the transcript content (npm audit, auth boundaries, env vars)
- v19 title "Tech Stack Layer 8/13 — your database tables are public (RLS)" does NOT match the transcript at all — this is a metadata mismatch in the source file assignment

**Conclusion:** The RLS video (v19 original topic) did not extract correctly — its transcript is actually the SOC2 clip. Only one analysis is needed for the shared content. v19 is flagged as a broken extract with wrong metadata. v24 is the canonical clip for this content.

---

## v18 — Stop Reading Research Papers (Do This Instead)

**Source:** `/tmp/aria-watch-bcabdb7a7f58`
**Duration:** 57s
**Platform guess:** TikTok / Instagram Reels (vertical, office background, captions overlaid, Hackanomics brand channel)
**Transcript chars:** 1031
**Frames read:** frame_02 (speaker talking, subtitle "after"), frame_05 (n8n-style AI Agent node showing Chat Model + Memory + Tool inputs), frame_08 (speaker, subtitle "who build systems")

### Visual Notes
- frame_05 shows a dark-mode workflow canvas — looks like n8n or a custom agent orchestrator UI. Node labeled "AI Agent / Tools Agent" with inputs: Chat Model (required, red), Memory, Tool. This is showing an agentic research pipeline UI.
- Speaker is in a professional office, high production quality, subtitled. Channel: Hackanomics.

### 7-Punkt Praxisanalyse

**1. Kernaussage**
Statt Research Papers zu lesen und zu vergessen, baut man ein System: ein Agent scannt täglich arxiv nach relevanten Papers, ein zweiter wandelt jedes Paper in ein "LLM-Artefakt" um — eine lebendige, durchsuchbare, befragbare Wissensbasis, mit der man aktiv interagieren kann, statt passiv zu lesen.

**2. Was können wir lernen**
Das Muster "Paper → Artefakt → Orchestrator-Kontext" ist eine konkrete Umsetzung von Aria's eigener Brain-Philosophie, nur auf wissenschaftliche Literatur angewandt. Der Key-Shift: Knowledge Consumption wird zu Knowledge Activation. Die Person, die Systeme baut die lernen, schlägt die Person die Papers liest.

**3. Wie einsetzen**
- Aria hat bereits Brain-Notes und einen AKP-Ingestion-Flow. Dieselbe Logik ließe sich auf arxiv-Feeds, Hacker News oder GitHub Release Notes anwenden.
- Konkret: ein täglicher Cron-Agent (Aria) der arxiv-Abstracts zu Tags wie "agents", "memory", "compaction" filtert, die Top-3 als Brain-Notes anlegt und Kais per Telegram pingt.
- Der n8n-Workflow aus frame_05 (Agent + Memory + Tool) entspricht exakt Arias Subagent-Pattern.

**4. Konkreter Vorteil für Aria/Kadi**
Für Aria: Research-Pipeline würde AI-Radar (KAR-38) konkret machen. Statt manuell "neue Paper lesen" — automatisierter Digest mit Brain-Save.
Für Kadi-v2: kein direkter Nutzen, aber die Grundidee (Inputs → strukturiertes Artefakt → abfragbar) passt zum Governance-Brief-Use-Case.

**5. Was besser machen**
Das Video sagt nicht: wie wird das Artefakt aufgebaut? Welches Format? Wie vermeidet man Halluzinations-Artefakte? Was passiert wenn das Paper behind paywall ist? Der Ansatz ist richtig, aber die Implementierungsdetails fehlen komplett — reine Inspiration, keine Anleitung.

**6. Lohnt sich Umsetzung**
Ja, P2. Aria hat schon die Infrastruktur (Brain, Cron, Telegram). Ein arxiv-Agent wäre ein kleiner Skill (~2h). Aber: der echte Hebel ist nicht arxiv — für Kais ist Praxis-Content (YouTube, HN, GitHub) relevanter als Papers. Arxiv-Monitoring ist nice-to-have, kein kritischer Gap.

**7. Nächste Schritte**
- Aria-eigenständig: Proof-of-concept arxiv-fetch-Skill skizzieren (KAR-38 als Kontext)
- Kais-Decision: Soll arxiv in den AI-Radar-Sprint B aufgenommen werden oder nur HN/GitHub?

**Relevanz-Tag:** Aria/agents
**Save-worthy:** Ja — P2, als Inspiration für KAR-38 AI-Radar Sprint B

---

## v19 — Tech Stack Layer 8/13: your database tables are public (RLS)

**Source:** `/tmp/aria-watch-087c44d99a75`
**Duration:** 96s
**Status:** BROKEN EXTRACT — Transcript ist identisch mit v24 (SOC2-Clip). Die eigentlichen RLS-Inhalte wurden nicht korrekt transkribiert. Frames zeigen dieselbe Person im Vercel-Hoodie wie v24, nicht RLS-Demos.

**Analyse:** Nicht möglich auf Basis des vorhandenen Extracts. Das Video mit dem RLS-Topic (Supabase RLS-Konfiguration) ist für Kadi-v2 hochrelevant (P0-Bereich), sollte aber erneut extrahiert werden. Die Quelle ist ein "Tech Stack"-Video-Serie und enthält wahrscheinlich Supabase RLS-Policies, ALTER TABLE ... ENABLE ROW LEVEL SECURITY, und USING-Klauseln.

**Handlung:**
- Video-Extraktion von v19 wiederholen mit korrektem Source-File
- Wenn erfolgreich: P0-Analyse da RLS direkt Kadi-v2 Sicherheit betrifft

**Relevanz-Tag:** Security (potenziell)
**Save-worthy:** Extraktion wiederholen, dann neu entscheiden

---

## v20 — These DevOps Concepts Show Up In EVERY Interview

**Source:** `/tmp/aria-watch-f855f9bd0e8c`
**Duration:** 120s (2 Min)
**Platform guess:** TikTok / Instagram Reels (vertical, side-by-side icon cards, female presenter in red hoodie, gaming chair, home setup)
**Transcript chars:** 2139

### Visual Notes
- frame_02: Split-screen with "CI" label visible, presenter pointing upward, concept-card format
- frame_05: REST API card (http/https, browser logos) vs gRPC — good visual illustration of the distinction
- frame_08: DevOps vs MLOps infinity-loop icons in blue and purple, "WHAT'S THE DIFFERENCE?" callout

### Begriffe im Video (vollständige Liste)
Docker vs Kubernetes | Container vs Pod | CI vs CD | Horizontal vs Vertical Scaling | Load Balancer vs Reverse Proxy | REST vs gRPC | Terraform vs Ansible | Logging vs Monitoring | Stateless vs Stateful | DevOps vs MLOps

### 7-Punkt Praxisanalyse

**1. Kernaussage**
10 fundamentale DevOps-Begriffspaare in je 1-2 Sätzen erklärt — klassisches "Interview Prep"-Format, kein Tiefgang, aber akkurate Definitionen.

**2. Was können wir lernen**
Nichts Neues für einen erfahrenen Builder. Die Definitionen sind korrekt aber trivial. Das einzige potenzielle Learning ist der Hinweis auf MLOps als explizites Konzept (DevOps + Retrain-Loop) — relevant für AI-Produkte wie Aria.

**3. Wie einsetzen**
Nicht direkt einsetzbar. Die Konzepte sind bereits im Stack-Wissen integriert. Aria nutzt Docker (Containerisierung), GitHub Actions (CI/CD), und die REST/gRPC-Unterscheidung ist für API-Design-Entscheidungen bei Kadi-v2 bereits bekannt.

**4. Konkreter Vorteil für Aria/Kadi**
Kein direkter Vorteil. Als Onboarding-Content für neue Teammitglieder oder Kadi-v2-Dokumentation potenziell nützlich, aber nicht für Kais selbst.

**5. Was besser machen**
Das Video liefert keine konkreten Entscheidungshilfen: Wann gRPC statt REST? Wann Kubernetes statt Docker Compose? Wann horizontal statt vertikal skalieren? Die Definitionen sind richtig aber ohne Entscheidungskontext wertlos für einen Praktiker.

**6. Lohnt sich Umsetzung**
Nein. Das Video ist für Einsteiger gedacht. Kais baut bereits mit diesen Konzepten. Kein Handlungsbedarf.

**7. Nächste Schritte**
Keine.

**Relevanz-Tag:** DevOps
**Save-worthy:** Nein — Anfänger-Content, keine neuen Erkenntnisse für Kais

---

## v21 — Free tools to deploy your first AI system to production

**Source:** `/tmp/aria-watch-bcfce23ba49c`
**Duration:** 65.7s
**Platform guess:** Instagram Reels / TikTok (vertical, conference/event setting, female presenter, LangGraph logo card, OpenTofu logo card)
**Transcript chars:** 877

### Visual Notes
- frame_02: Presenter holding up a LangGraph logo card — confirming LangGraph as agent orchestration layer
- frame_05: OpenTofu logo card held prominently — Terraform-fork als IaC-Tool
- frame_08: Presenter gesturing, conference atmosphere (purple event lighting)

### Stack aus dem Video (vollständige Liste)
**Backend:** FastAPI, LangGraph (agent orchestration), Groq (LLM inference), Genie AI (embeddings), PostgreSQL + pgvector (DB + vector search)
**Frontend:** Next.js on Vercel (free tier)
**Infra:** AWS Free Tier + $200 credit
**DevOps:** OpenTofu (IaC), CircleCI / GitHub Actions (CI/CD), Docker
**Quality/Monitoring:** Sentry (errors), OPIK (LLM call tracing), CloudWatch (logs/alerts), Ruff + MyPy (linting/type-checking)

### 7-Punkt Praxisanalyse

**1. Kernaussage**
Ein vollständiger Free-Tier-Stack für AI-Produktionssysteme existiert — von Backend über Agent-Orchestration bis Monitoring — alles ohne Kosten mit kostenfreien Tiers.

**2. Was können wir lernen**
- OPIK als LLM-Call-Tracer ist ein konkretes Tool, das in Arias Monitoring fehlt. OPIK (von Comet ML) trackt jeden LLM-Call mit Input/Output/Cost/Latency.
- OpenTofu als Terraform-Ersatz (open-source, keine BSL-Lizenz-Probleme) ist ein valider IaC-Weg für Aria-Infra.
- Groq für schnelle, kostenlose Inferenz — bekannt, aber der Stack-Kontext bestätigt die Wahl.
- pgvector + PostgreSQL als einheitlicher DB/Vector-Stack passt zu Kadi-v2 (Supabase nutzt genau das).

**3. Wie einsetzen**
- OPIK für Aria-Agent-Tracing: jede Tool-Call-Chain von Aria könnte via OPIK instrumentiert werden. Gibt Kais Einblick in was Aria tut + Kosten pro Task.
- OpenTofu für Durrani/Kadi-v2-Infra: wenn wir IaC einführen, OpenTofu statt HashiCorp Terraform wegen Lizenz-Risiko.
- Ruff ist bereits ein starkes Tool — falls nicht in Kadi-v2 vorhanden, sofort hinzufügen.

**4. Konkreter Vorteil für Aria/Kadi**
Aria: OPIK-Integration wäre ein konkreter Observability-Gewinn (KAR-Web-Service-Baseline spricht von OpenTelemetry — OPIK könnte dort rein).
Kadi-v2: pgvector-Bestätigung (wir nutzen Supabase = pgvector), Ruff als Linter.
Durrani: noch kein IaC — OpenTofu als zukünftige Option wenn Infra wächst.

**5. Was besser machen**
Stack ist gut gewählt aber unvollständig für Enterprise/B2B:
- Kein Auth-Layer (Clerk, Auth.js, Supabase Auth)
- Kein Rate-Limiting / API-Gateway
- Genie AI Embeddings ist wenig bekannt — Alternativen (OpenAI, Cohere) nicht diskutiert
- "Free Tier" is temporär — Skalierungskosten fehlen komplett

**6. Lohnt sich Umsetzung**
Teilweise. OPIK ist konkret umsetzbar (P2). OpenTofu als IaC-Referenz für später merken (P3). Der Rest des Stacks ist bekannt oder bereits in Verwendung.

**7. Nächste Schritte**
- Aria-eigenständig: OPIK in Integration-Wishlist aufnehmen (`02-Wissen/integration-wishlist.md`)
- Aria-eigenständig: Prüfen ob Ruff in Kadi-v2 Linter-Setup existiert
- Kais-Decision: Soll OPIK als LLM-Tracing-Layer für Aria evaluiert werden?

**Relevanz-Tag:** Aria/agents, DevOps
**Save-worthy:** Ja — P2, wegen OPIK-Fund und Stack-Bestätigung

---

## v22 — Vibe coders: the modern stack (Vercel + Supabase)

**Source:** `/tmp/aria-watch-0076f695a661`
**Duration:** 36.3s
**Platform guess:** TikTok / X (sehr kurz, reaction-format, embedded screenshot von anderem Post, "Vibe coders This is wrong!" overlay)
**Transcript chars:** 603

### Visual Notes
- frame_02: Screenshot eines Posts wird gezeigt mit der vollständigen Vibe-Coder-Stack-Liste (Claude für Coding, Supabase, Vercel, Namecheap, Stripe, GitHub, Resend, Clerk, Cloudflare, PostHog, Sentry, Upstash Redis, Pinecone) — plus Reaktion "Vibe coders This is wrong!"
- frame_05: Gleiche Ansicht, Presenter sagt: "I would stick with one cloud provider, then take a snapshot of this and tell your AI, I need all these things in Azure"
- frame_08: Presenter face, "And now you're thinking like a real software engineer"

### Vollständiger Vibe-Coder-Stack (aus dem Post im frame):
Claude, Supabase, Vercel, Namecheap, Stripe, GitHub, Resend, Clerk, Cloudflare, PostHog, Sentry, Upstash Redis, Pinecone

### 7-Punkt Praxisanalyse

**1. Kernaussage**
Ein Software-Engineer kritisiert den typischen "Vibe-Coder-Stack" (12+ unabhängige SaaS-Services) als Dependency-Chaos und empfiehlt stattdessen: einen einzigen Cloud-Provider wählen, Infrastructure as Code schreiben, und den AI-Assistenten damit beauftragen — statt 12 verschiedene SaaS-Dashboards zu managen.

**2. Was können wir lernen**
Die Kritik ist inhaltlich berechtigt für Enterprise/skalierbare Systeme, aber für Startup-MVP-Phasen (wie Kadi-v2 aktuell) ist der Vibe-Coder-Stack pragmatisch und schnell. Der Presenter übersieht, dass die SaaS-Fragmentation bewusst ist: jeder Dienst best-in-class für seinen Zweck, mit klaren Free Tiers. Die "Infrastructure as Code auf Azure"-Empfehlung erhöht massiv die Komplexität für Solo-Founder.

**3. Wie einsetzen**
Nicht direkt. Das Video bestätigt aber: Kais' aktueller Stack (Supabase + Vercel + Clerk + Cloudflare) ist marktüblich für vibe-coders. Der IaC-Punkt (für spätere Skalierung) ist valide als langfristiger Plan.

**4. Konkreter Vorteil für Aria/Kadi**
Kein direkter neuer Vorteil. Das Video validiert unseren Stack indirekt (der Post im frame zeigt genau was wir nutzen). Die IaC-Idee (OpenTofu/Terraform) ist für Kadi-v2 bei Skalierung relevant aber nicht jetzt.

**5. Was besser machen**
Der Presenter hat recht, dass Vendor-Fragmentation Risiken hat (jeden Dienst einzeln sichern, rotieren, managen). Aber er ignoriert: Azure-Mono-Cloud schafft einen Single-Point-of-Failure und versteckt Kosten durch komplexe Pricing-Modelle. Weder "alle SaaS" noch "alle Azure" ist universell richtig.

**6. Lohnt sich Umsetzung**
Nein. Das Video liefert keine actionable Information. Die Kritik ist bekannt, der Gegenvorschlag (Azure IaC) ist für unsere Phase falsch. Als Gesprächsstarter für "wann wechseln wir zu IaC" nützlich, aber kein KAR-würdiger Input.

**7. Nächste Schritte**
Keine unmittelbaren. Notiz: bei Kadi-v2-Skalierung (>1000 Kunden) IaC evaluieren.

**Relevanz-Tag:** Startup/Strategy, DevOps
**Save-worthy:** Nein — Opinion-Content, kein neues Wissen, 36s zu kurz für substantiellen Inhalt

---

## v24 — You don't need SOC2 — you need these three checks (30 min)

**Source:** `/tmp/aria-watch-f903ff95221b`
**Duration:** 96s
**Platform guess:** TikTok / Instagram Reels (vertical, person in Vercel-branded black hoodie, logo visible on chest, dark background, minimal set)
**Transcript chars:** 1510
**Note:** Identischer Inhalt wie v19 — dies ist das kanonische Video für diesen Transcript

### Visual Notes
- frame_02: Torso in schwarzem Vercel-Hoodie, Overlay-Text "yourself." — Kontext-Bruch, gehört zu einer anderen Sequenz im Clip
- frame_05: "Change the" Overlay auf dem Hoodie — animated text-overlay Style
- frame_08: Dunkle Schlusskarte ohne Text

### Security Audit Checkliste aus dem Transcript (3 Schritte):

**Step 1 — npm audit**
```bash
npm audit
```
- Zeigt alle bekannten CVEs in installierten Packages
- Lock-File prüfen: Wie viele Dependencies? Wie viele outdated? Wie viele Critical CVEs?
- Aktion: Rote fixen, Gelbe updaten, Nicht-zutreffende ignorieren

**Step 2 — Auth Boundaries testen**
- Als User A einloggen
- User B's ID in der URL ändern → sehe ich B's Daten?
- User B's ID im API-Call ändern → sehe ich B's Daten?
- Wenn ja: "You don't have auth, you have a login page."

**Step 3 — Environment Variables Review**
- Sind Secrets im Codebase?
- Ist `.env` in Git committed?
- Sind Secrets im Frontend-Code?
- Regel: Jedes Secret nur in server-seitigen ENV VARs. Nie im Code, nie in Git, nie im Browser.

### 7-Punkt Praxisanalyse

**1. Kernaussage**
Bevor du SOC2 brauchst, führe diese drei 30-Minuten-Checks selbst durch: npm audit, Auth-Boundary-Test (IDOR), und ENV-Var-Review. Diese drei decken die häufigsten kritischen Sicherheitslücken in Web-Apps ab.

**2. Was können wir lernen**
- Der IDOR-Test (Insecure Direct Object Reference) ist konkret und leicht durchzuführen — und wird bei vibe-coding-Projekten systematisch vergessen.
- Der ENV-Var-Check ist ein Pflicht-Gate vor jedem Production-Deploy — besonders relevant für Kadi-v2 wo Supabase-Keys, Linear-Keys, und Vercel-Tokens verwaltet werden.
- npm audit sollte in der CI-Pipeline laufen — nicht nur manuell.

**3. Wie einsetzen**
Kadi-v2:
- `npm audit --audit-level=critical` in GitHub Actions CI-Step einbauen
- IDOR-Test als manuellen Pre-Release-Checklist-Punkt in KAR-Issue erfassen
- ENV-Var-Audit: `.env.example` vollständig halten, `.env` in `.gitignore` verifizieren, `git log --all --full-history -- .env` laufen lassen

Durrani:
- Payload CMS: API-Key-Scoping prüfen (welche Operationen sind ohne Auth möglich?)
- `.env` nicht in lokalem Git-History

Aria (als System):
- Aria-Secrets-Audit: `/root/.aria-secrets/` — welche Dateien haben welche Permissions? SSH-Keys, Google-Credentials, Telegram-Token alle korrekt chmod 600?

**4. Konkreter Vorteil für Aria/Kadi**
Kadi-v2: Konkrete Sofort-Maßnahmen für Production-Hardening. IDOR ist in multi-user-Apps (BMW-Tenant-Modell) ein reales Risiko wenn RLS nicht vollständig aktiviert ist.
Durrani: Kleineres Risikoprofil, aber ENV-Check immer relevant.
Aria: Secrets-File-Audit ist sinnvoll.

**5. Was besser machen**
Das Video bleibt sehr oberflächlich:
- Kein Wort über HTTPS-Enforcement, CSP-Headers, CORS-Konfiguration
- Kein Wort über Rate-Limiting / Brute-Force-Schutz
- npm audit findet nur bekannte CVEs in direkten Deps — transitive Dependencies und private Packages bleiben unsichtbar
- "30 Minuten" ist unrealistisch für eine ehrliche Auth-Boundary-Test-Session in einer komplexen App
- RLS in Supabase (das eigentliche Thema von v19) wird nicht mal erwähnt — der Titel des übergeordneten Videos (Tech Stack Layer 8/13) deutet auf eine mehrteilige Serie hin, von der nur ein Clip gespeichert wurde

**6. Lohnt sich Umsetzung**
Ja, P1. Die drei Checks sind einfach, kostenlos, und direkt auf Kadi-v2 anwendbar. npm audit in CI ist ein 15-Minuten-Task. Der IDOR-Test sollte vor dem BMW-Go-Live durchgeführt werden. ENV-Var-Audit ist bereits in der Kadi-v2-Checklist implizit vorhanden, sollte aber explizit gemacht werden.

**7. Nächste Schritte**
- Aria-eigenständig: `npm audit --audit-level=critical` in Kadi-v2 GitHub Actions einbauen (KAR anlegen)
- Aria-eigenständig: IDOR-Testprotokoll als Brain-Note oder Checklist-Template anlegen
- Kais-Decision: Vor BMW-Go-Live manuellen IDOR-Test durchführen (Kais selbst als User A + User B)
- Aria-eigenständig: `/root/.aria-secrets/` Permission-Audit durchführen, Ergebnis reporten

**Relevanz-Tag:** Security
**Save-worthy:** Ja — P1, direkt actionable für Kadi-v2 Pre-Production-Hardening

---

## Zusammenfassung Brain-Saves

| Video | Save | Priorität | Brain-Note |
|-------|------|-----------|------------|
| v18 | Ja | P2 | Anlegen: arxiv-agent-paper-artefakt pattern |
| v19 | Nein (broken extract) | — | Extraktion wiederholen |
| v20 | Nein | — | Anfänger-Content |
| v21 | Ja | P2 | Anlegen: OPIK LLM-Tracing + free-AI-prod-stack |
| v22 | Nein | — | Opinion-Clip, kein Substanz |
| v24 | Ja | P1 | Anlegen: security-audit-3-checks (npm audit + IDOR + ENV) |

---

## Duplikate / Überschneidungen

- **v19 = v24**: Technisch identisches Extract (gleiche Quelle, gleiche Frames). v19-Originaltitel (RLS) wurde nicht korrekt extrahiert. v24 ist kanonisch für den SOC2/Security-Audit-Content.
- **v20 (DevOps-Begriffe) vs frühere Screenshot-Batches**: DevOps-Grundbegriffe (Docker/K8s, CI/CD) waren bereits Thema in Screenshot-Analysen (Batch-1/2 Kontext). Kein neues Wissen.
- **v21 (Free AI Stack) vs v22 (Vibe-Coder-Stack)**: Überschneiden sich thematisch (beide diskutieren Deployment-Stacks für AI-Apps). v21 ist pro-SaaS, v22 ist anti-SaaS. Keine inhaltliche Redundanz, aber thematisch verwandt.

---

## Actionable Security Checklist (aus v24, direkt verwendbar)

```bash
# 1. Dependency Audit
npm audit --audit-level=critical

# 2. Prüfe Lock-File Größe
cat package-lock.json | python3 -c "import json,sys; d=json.load(sys.stdin); print(f'{len(d[\"packages\"])} packages')"

# 3. Env-Var in Git-History suchen
git log --all --full-history -- .env
git log --all --full-history -- **/.env

# 4. Frontend-Env-Leak suchen (Next.js NEXT_PUBLIC_ Keys)
grep -r "NEXT_PUBLIC_" src/ --include="*.ts" --include="*.tsx"

# 5. Secrets-File-Permissions prüfen
find /root/.aria-secrets -type f -exec stat -c "%a %n" {} \;

# 6. IDOR-Test (manuell, vor jedem Go-Live)
# - 2 Testaccounts anlegen
# - Als User A einloggen
# - User B's Record-ID in URL / API-Request ersetzen
# - Erwartung: 403 oder 404, niemals 200 mit B's Daten
```