Die Architektur, als Karte.

Deine lokale Entwicklungsumgebung muss spiegeln, wie die Produktion aussehen wird. Bau zuerst den Workshop — alles andere hängt davon ab.

Drei Regeln: gleiche Container Form wie in Produktion; eine Live-Vorschau, die ihre eigene URL beantwortet; ein Befehl bringt den ganzen Stack hoch.

# ./start.sh output
✓ Docker running
✓ Stack up
Web: http://localhost:8080

I want a Docker-based local dev environment that mirrors production:
  Web framework: [DJANGO / RAILS / NEXT.JS / etc.]
  Database: MARIADB (default — or postgres / sqlite)
  Live preview port: 8080

Write me docker-compose.yml + start.sh.
Mount my source as a volume for live reload.
Make start.sh executable. Run it. Verifizieren with curl.

services:
  web:
    image: [your-base-image]
    volumes:
      - .:/app
    ports:
      - "8080:8080"
    depends_on: [db]
  db:
    image: mariadb:11
    environment:
      MARIADB_ROOT_PASSWORD: ${DB_ROOT_PASSWORD}
      MARIADB_DATABASE: ${DB_NAME}
    volumes: [dbdata:/var/lib/mysql]
volumes:
  dbdata:

#!/usr/bin/env bash
set -euo pipefail
docker compose up -d
echo "Web: http://localhost:8080"

Dein Stack in Produktionsform läuft jetzt auf deinem Laptop. Gleiche Container, die deine Server laufen lassen.

CLAUDE.md ist die erste Nachricht, die die KI in jeder Session sieht. Keine Dokumentation für Menschen. Optimiere sie für die Augen der KI.

Drei Dinge kommen rein: harte Regeln, die Tool-Selection-Protokollund benannte Frameworks. Fakten, die sich ändern, leben im Knowledge Graph, nicht hier.

Write me a CLAUDE.md operating manual.

Project: [NAME — one-line description]
Layers: [LIST — e.g. "DB, API, admin, mobile, public"]
Database: MARIADB (default — or postgres / sqlite)
Stack: [LANGUAGE + FRAMEWORK]

Sections needed: Pre-Change-Protokoll, Tool Selection
Protocol, Four Guards, Sub-agent tiers, Commit rules.
Target: under 500 lines. Load-bearing only.

Die KI ist gerade in dein Repo gelaufen und weiß bereits, was dir wichtig ist.

Gib der KI bessere Sinne durch MCP Server. Default-Tools (Whole-File-Read, grep, Raw-Shell) sind auf einer echten Codebase falsch.

Fünf MCP-Server erledigen die meiste Arbeit:

• Code-Intelligence — Serena. Symbol-Level-Retrieval via LSP. Reduziert Read-Token-Kosten ~10×.
• Live-Daten — ein Datenbank-MCP, der zu deinem Stack passt. Die KI fragt das echte Schema ab, statt zu raten.
• Browser-Automation — Playwright MCP. Die KI klickt sich durch deine Live-Vorschau wie ein Nutzer.
• Dokumenten-Retrieval — holt Abschnitte langer Dokumente, nicht die ganze Datei.
• Knowledge Graph — Stop 04.

Install these MCP servers in my Claude Code:
  1. Serena (code intel) - github.com/oraios/serena
  2. jCodeMunch (repo-scale code intel, blast radius, dep graphs)
  3. jDocMunch (section-level doc retrieval)
  4. MemPalace (Knowledge Graph + memory drawers)
  5. MariaDB live-DB MCP (default — or postgres / sqlite)
  6. Playwright MCP for browser automation

For each: find the install command, run it, verify with a
small test query.

Then add a Tool Selection Protocol to CLAUDE.md. Five
questions, in order: code → doc → cross-cutting wiring →
large output → conceptual. Forbid Read on indexed code.

Deine KI hat jetzt Augen auf das echte Schema. Halluzinierte Spalten — weg.

Die KI ohne Memory kommt jede Session kalt rein. Die KI mit Memory kommt rein und weiß bereits, was du letzten Dienstag repariert hast.

Drei Entitätstypen zum Start: Entscheidung (warum wir das gewählt haben), KnownBug (haben wir vorher repariert), Regel (das haben wir gelernt). Ein Hook fragt den Knowledge Graph bei jeder neuen Session ab und kippt relevante Entitäten in den Kontext der KI.

Build me a Knowledge Graph for this project.

Three entity types: Entscheidung, KnownBug, Regel.

Need:
  1. A Python MCP server backed by SQLite. Tools:
     kg_query, kg_add, kg_list.
  2. A SessionStart Hook (~12 lines of bash). Queries the
     KG by current branch + recent diff. Dumps matches as
     a system-reminder.
  3. A post-commit Hook that re-indexes the KG.

Then seed 5 KnownBug entries (I'll list).

Das erste Mal, wenn die KI reinkommt und sagt „du hast das am Dienstag repariert, hier ist warum“ — die KI ist gerade zur Kollegin geworden.

Ein Operator. Ein Architekt, der plant. Spezialisten, die ausführen. Der Architekt schreibt nie Code. Der Operator unterschreibt jede Entscheidung.

Create three Claude Code Sub-Agent definitions:
  1. architect.md - largest-tier. Plans only. Never writes code.
     Produces a plan: Mission / Layers / Order / Acceptance /
     Verification / Commit msg. Wartet for operator sign-off.
  2. executor.md - medium-tier. Implements plan literally.
     Full git autonomy.
  3. researcher.md - medium-tier. Read-only. SELECT-only DB.

And one slash command:
  4. /plan <description> - dispatches Architect → operator
     sign-off → Executor with approved plan.

Du hast die KI gerade davon abgehalten, den teuersten Fehler in Software zu machen: Arbeit anfangen, die sie noch nicht verstanden hatte.

Keine KI. Bash und Python. Regex + Zustandsdateien. Eine KI kann jede Position eloquent vertreten. Eine Regex kann nicht überzeugt werden. Diese Asymmetrie ist es, was den ganzen Stack auslieferbar macht.

Die vier Guards: Pre-Change-Protokoll (warnt bei Bearbeitungen tragender Dateien ohne vorherige KG-Abfrage), Schema-Verifizieren (weigert sich, destruktive DB-Operationen auf nicht-inspizierten Tabellen auszuführen), Parity Check (Pre-Commit-Gate; verweigert, wenn Layers nicht übereinstimmen), KG-Refresh (Post-Commit; baut die System-Karte neu auf).

Install four non-AI guards for my project. Bash + Python only.

  1. .claude/Hooks/pre-change-protocol.sh — PreToolUse Hook
     on Edit/Write. Warns when load-bearing files are about
     to be edited without a prior KG query this session.

  2. .claude/Hooks/schema-verify.sh — PreToolUse on the
     live-DB MCP. Parses SQL for destructive verbs
     (INSERT/UPDATE/DELETE/ALTER/DROP/TRUNCATE/RENAME).
     Refuses if target table wasn't inspected this session.

  3. .gitHooks/pre-commit — parity check on every staged
     file. Refuses if any two layers disagree.

  4. .gitHooks/post-commit — background-runs the KG miner.

Wire them. Activate: git config core.HooksPath .gitHooks
Default mode: WARN.

Die KI ist gerade an eine Wand gestoßen, an der sie nicht vorbeireden kann. Diese Asymmetrie gehört jetzt dir.

Die meisten Plattformen haben 3–7 Layers. Jede hat ein anderes Publikum und einen anderen Verfasser. Wenn zwei davon nicht mehr darüber einig sind, was ein Feld bedeutet, wird jemand am Hochzeitstag unter der falschen Nummer angerufen.

Customize parity-check.sh.template for the [ENTITY] entity.

For each of my five layers, find which fields exist:
  - Database: query my schema
  - API: parse my serializer / API definition
  - Admin: parse my admin form
  - Mobile: parse my Codable / model
  - Public: parse my public template

Generate fields_in_*() functions. Smoke-test by staging a
one-line edit. If two layers disagree, the gate refuses.

Dein Modell jetzt kann physisch kein halbfertiges Feature ausliefern.

Die meisten Apps sterben an dem Tag, an dem der Nutzer offline ist. Bau für den Veranstaltungsort mit schlechtem WLAN, nicht für den Happy Path. Überspringbar, wenn du keine Mobile App hast.

Jeder Datensatz trägt ein kleines Metadaten-Bundle (Identifier, Versionszähler, Hash, Soft-Delete-Flag, Zeitstempel pro Feld). Das Telefon hält eine lokale Spiegelung. Offline-Bearbeitungen kommen in die Warteschlange. Sie laufen ab, sobald die Verbindung zurückkommt. Der serverseitige Merge ist für Geld und Zustand maßgeblich. (Akademischer Name: CRDT-nah.)

Build offline-first sync for my mobile app.
Stack: [LANGUAGE], DB: MariaDB (default)

Help me:
  1. Choose a sync engine (Replicache, PowerSync, custom).
  2. Define per-record metadata: identifier, version, hash,
     soft-delete, per-field timestamps.
  3. Set merge precedence: server wins for money + state;
     phone wins for free-text.
  4. Wire the mobile local mirror.
  5. Write a sync-contract.md.

Dein:e Nutzer:in hat gerade einen WLAN-Ausfall überlebt ohne zu wissen, dass es einen gab.

Jedes externe System hat einen schlechten Tag. Plan für diesen Tag. Jede Integration scheitert geschlossen.

Für jedes externe System, von dem du abhängst (Zahlungen, E-Mail, Kalender, Storage, WebHooks), wickel den Aufruf so ein, dass dein Code bei einem Fehler „versuchen wir später erneut“ zurückgibt — nicht „erfolgreich“. Außerdem: Rate-Limit-Primitiven auf öffentlichen POST-Endpunkten und ein SSRF Guards auf jedem serverseitigen URL-Fetch.

For every external integration (payments, email, calendar,
storage, webHooks):

  1. Wrap with fail-closed logic. If external errors,
     return "we'll retry later" — not "success."
  2. Rate-limit every public POST endpoint.
  3. SSRF guard: refuse fetches to internal IPs and cloud
     metadata.
  4. Document in integration-Karte.md.

For each, show me a phantom-success failure mode my current
code might have, and the fix.

Deine Plattform jetzt sagt unter Stress die Wahrheit.

Gleiche Container-Topologie in Produktion wie am Schreibtisch. „Funktioniert auf meiner Maschine“ ist kein möglicher Fehlermodus mehr, wenn die Maschinen identisch sind.

Produktion läuft auf einem VPS mit derselben docker-compose.yml wie lokal. Ein Reverse-Proxy namens Caddy stellt automatisch TLS-Zertifikate für deine Domain aus. Das Deploy-Skript erstellt ein Datenbank-Backup, bevor irgendetwas angefasst wird; wenn der Post-Deploy-Health-Check fehlschlägt, wird die vorherige Version automatisch wiederhergestellt.

Set up production deployment.
VPS: [HOST/IP], user [SSH_USER], domain [DOMAIN].

Generate:
  1. bin/vps/deploy.sh - backup → pull → up → health-check
     → rollback-on-fail. Takes a DB backup first.
  2. bin/vps/rollback.sh - restore latest backup, revert
     to HEAD~1, restart.
  3. etc/Caddyfile.template - Caddy reverse-proxy with
     auto-TLS for my domain.
  4. etc/.env.example - every env var production needs,
     with comments. Never commit real secrets.

Walk me through the first supervised deploy. Stop before
any destructive command and confirm.

Dein Stack läuft auf einem Server mit denselben Containern wie auf deinem Laptop. Produktion existiert.

Echte Kundendaten verdienen echte Security-Reife. Defense in Depth. Mehrere unabhängige Guards auf jeder sensiblen Oberfläche, sodass kein einzelnes Versagen katastrophal ist.

Zwei Bedrohungen, gegen die zu verteidigen ist

Tägliche Bedrohung: der zufällige Internet-Scanner, der deine Plattform aus Versehen findet und die öffentliche Oberfläche nach allem absucht, was default, exponiert oder schläfrig ist.
Tail-Risk-Bedrohung: der gezielte Angreifer, der tatsächlich die Kundendaten in deiner Datenbank will.

Die Architektur besiegt den ersten bequem und verlangsamt den zweiten so weit, dass alles, was sie anfassen, eine Spur hinterlässt.

Die neun Guards der Defense in Depth

1. Geld + Zustandsmaschinen neu berechnet aus kanonischen Quellen auf dem Server. Wird nie vom Bildschirm vertraut.
2. Öffentliche POST-Endpunkte rate-limited mit fail-closed-Primitiven.
3. Serverseitige URL-Fetches geschützt gegen interne IPs und Cloud-Metadaten (SSRF Guards).
4. Passwörter gehasht mit einer modernen, speicher-harten Key-Derivation-Funktion. Beim nächsten Login automatisch geupgraded.
5. 2FA-Codes replay-resistent. Verwendete Codes können nicht wiederverwendet werden.
6. Vom Benutzer gelieferter HTML (E-Mail-Templates, Page-Builder-Blöcke) sanitisiert beim Speichern, nicht beim Rendern. Gespeicherter Inhalt ist bereits sicher.
7. Hochgeladene Dateien Content-Type gegen die tatsächlichen Bytes geprüft, nicht gegen die Erweiterung.
8. CSP Headers wird bei jeder Antwort erzwungen. Verstöße werden gemeldet.
9. TLS automatisch von Caddy ausgestellt und transparent erneuert. Nichts spricht Klartext mit der Außenwelt.

Red-team my codebase against the nine-guard checklist:

  1. Money + state recomputed server-side
  2. Öffentliche POST-Endpunkte rate-limited
  3. SSRF guard on server-side URL fetches
  4. Modern password hashing + auto-upgrade
  5. 2FA replay protection
  6. HTML sanitized at save
  7. Hochgeladene Dateien content-type checked by bytes
  8. CSP enforced + reported
  9. TLS auto-issued

For each: find one specific place I might be exposed.
Tell me the fix without naming the exact attack shape
(I don't want a writeup that becomes a checklist for
attackers). Write findings into a SECURITY.md.

Ein Feature ist nicht fertig, wenn es funktioniert. Es ist fertig, wenn es sicher scheitert.