architect-to-product 0.1.0

package/.mcp.json

@@ -0,0 +1,9 @@
+{
+  "mcpServers": {
+    "codebase-memory": {
+      "command": "codebase-memory-mcp",
+      "args": [],
+      "env": {}
+    }
+  }
+}

package/LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2025 Bernhard Jackiewicz
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

package/README.md

@@ -0,0 +1,306 @@
+# A2P — Architect-to-Product
+
+MCP server that turns AI-generated code into production-ready software with TDD, security scanning, and deployment automation. Up to 100 times fewer exploration tokens for claude code.
+
+**15 MCP tools** · **527 tests** · **Architecture → Plan → Build → Security → Deploy**
+
+[![npm version](https://img.shields.io/npm/v/architect-to-product)](https://www.npmjs.com/package/architect-to-product)
+[![License: MIT](https://img.shields.io/badge/License-MIT-blue.svg)](LICENSE)
+[![Tests: 527 passing](https://img.shields.io/badge/tests-527%20passing-brightgreen)]()
+[![TypeScript](https://img.shields.io/badge/TypeScript-5.9-blue)]()
+
+---
+
+Vibe coding with Claude Code, Cursor, or any AI coding assistant generates code fast — but ships it without tests, with security holes, and with no deployment story. You spend more time fixing what the AI wrote than you saved.
+
+- AI-generated code frequently introduces security vulnerabilities — and coding agents will delete validation, disable auth, or relax database policies just to make errors go away
+- "It works on my machine" turns into a 3am production incident
+
+**Architect-to-Product** is an MCP server that turns AI-generated code into production-ready software. It adds TDD, static code analysis, and deployment automation to AI coding workflows.
+
+AI-driven test driven development (AI TDD) ensures every feature works. Built-in SAST tools (Semgrep for all languages, Bandit for Python) run static code analysis and OWASP Top 10 reviews before deploy. Stack-specific deployment configs mean you ship on day one, not day thirty.
+
+## Quick Start
+
+```bash
+npm install -g architect-to-product
+claude mcp add architect-to-product -- npx architect-to-product
+```
+
+Then restart Claude Code and type: **`/a2p`**
+
+The onboarding will co-develop your architecture, auto-configure companion MCP servers, and install SAST tools. One restart, then you're building.
+
+## What A2P Actually Does
+
+A2P is an MCP server that orchestrates an AI engineering workflow. Instead of vibe coding features, A2P builds software in vertical slices with TDD and security gates.
+
+It coordinates:
+- **Up to 100x fewer exploration tokens** — codebase-memory-mcp builds a code graph instead of scanning files raw
+- **Test-driven development** — every feature has tests before implementation
+- **Static code analysis** — Semgrep + Bandit scan for vulnerabilities automatically
+- **Security reviews** — OWASP Top 10 review before deploy
+- **Deployment generation** — stack-specific Dockerfile, docker-compose, Caddyfile, backup scripts
+
+A2P is not a replacement for engineers. It is an engineering safety net for AI-generated code.
+
+## Without vs. With architect-to-product
+
+| Without a2p | With a2p |
+|---|---|
+| Vibe code a feature | Architecture-driven vertical slices |
+| Manually write some tests (maybe) | TDD per slice: RED → GREEN → REFACTOR |
+| Miss security vulnerabilities | Automated SAST + OWASP Top 10 review |
+| Copy-paste a Dockerfile from StackOverflow | Generated Dockerfile + docker-compose + Caddyfile + backup scripts |
+| Hope for the best | Ship to production with confidence |
+
+## Key Benefits
+
+- **100x fewer tokens** — Code graph intelligence via codebase-memory-mcp replaces raw file scanning — saves context window and money
+- **Develop faster** — Vertical slices with TDD, no yak shaving
+- **Fewer bugs** — AI-driven test driven development (TDD): every feature has tests before implementation (RED → GREEN → REFACTOR)
+- **Ship secure** — Static code analysis (Semgrep + Bandit) + OWASP Top 10 review built into the AI coding workflow
+- **Deploy on day one** — Stack-specific Dockerfile, docker-compose, Caddyfile, backup scripts
+- **Code quality** — Built-in code quality tool: dead code detection, redundancy analysis, coupling metrics
+- **Any stack** — Python, TypeScript, Go, Rust, Java, Ruby, PHP, C#, PostgreSQL, MySQL, MongoDB, Redis
+
+## How it works
+
+The full AI workflow automation pipeline:
+
+```
+AI Assistant
+     │
+     ▼
+Architecture
+     │
+     ▼
+Planning (vertical slices)
+     │
+     ▼
+Build (TDD loop per slice)
+     │
+     ▼
+Security Gate (SAST + OWASP)
+     │
+     ▼
+Deployment
+```
+
+For multi-phase projects (e.g. Phase 0: Spikes, Phase 1: MVP, Phase 2: Scale), this loop repeats per phase automatically.
+
+```
+Phase 0: Plan → Build → Security → Deploy → complete_phase
+Phase 1: Plan → Build → Security → Deploy → complete_phase
+...
+```
+
+1. **Onboarding**: Capture or co-develop the AI software architecture. Detect database and frontend tech. Describe UI via text, upload wireframes/mockups/screenshots, or let AI generate a design concept. Set up companion MCP servers via the MCP protocol. If the architecture defines phases, they get extracted automatically.
+2. **Planning**: Break the architecture into ordered vertical slices, each a deployable feature unit with acceptance criteria. Three slice types: `feature` (default), `integration` (library/API adapters with TDD), `infrastructure` (CI, auth, monitoring).
+3. **Build Loop**: TDD per slice: RED (write failing tests) → GREEN (minimal implementation) → REFACTOR (clean up) → SAST (lightweight AI security testing). Frontend slices with `hasUI: true` get visual verification via Playwright between GREEN and REFACTOR. Configurable review checkpoints (`reviewMode`: `off`, `all`, `ui-only`) pause after slices for human approval. Domain logic triggers a WebSearch step before tests to verify facts (tax rates, regulations, standards).
+4. **Security Gate**: Full SAST scan (static code analysis via Semgrep + Bandit), OWASP Top 10 manual review, dependency audit. Acts as an AI code review tool and AI code scanner for your entire codebase. Fix all critical/high findings.
+5. **Deployment**: Generate Dockerfile, docker-compose, Caddyfile, backup scripts, hardening guides. Stack-specific launch checklist.
+
+## Client Configuration
+
+Works with Claude Code, Cursor AI, and any MCP-compatible AI coding assistant:
+
+### Claude Code (CLI)
+
+```bash
+claude mcp add architect-to-product -- npx architect-to-product
+```
+
+### Claude Desktop
+
+Add to `~/Library/Application Support/Claude/claude_desktop_config.json` (macOS) or `%APPDATA%\Claude\claude_desktop_config.json` (Windows):
+
+```json
+{
+  "mcpServers": {
+    "architect-to-product": {
+      "command": "npx",
+      "args": ["architect-to-product"]
+    }
+  }
+}
+```
+
+### Cursor AI
+
+Add to `.cursor/mcp.json` in your project root:
+
+```json
+{
+  "mcpServers": {
+    "architect-to-product": {
+      "command": "npx",
+      "args": ["architect-to-product"]
+    }
+  }
+}
+```
+
+### VS Code
+
+Add to `.vscode/mcp.json`:
+
+```json
+{
+  "servers": {
+    "architect-to-product": {
+      "command": "npx",
+      "args": ["architect-to-product"]
+    }
+  }
+}
+```
+
+## MCP Tools (15)
+
+| Tool | Phase | Description |
+|------|-------|-------------|
+| `a2p_init_project` | 0 | Scaffold project with CLAUDE.md, hooks, agents, state |
+| `a2p_set_architecture` | 0 | Parse architecture, detect DB/frontend, extract phases, set review mode, capture UI design |
+| `a2p_setup_companions` | 0 | Register companion MCP servers |
+| `a2p_create_build_plan` | 1 | Architecture → ordered vertical slices (supports `append` for multi-phase) |
+| `a2p_add_slice` | 1,2 | Insert a single slice mid-project (e.g. integration discovered during build) |
+| `a2p_complete_phase` | 4 | Complete current product phase, advance to next |
+| `a2p_get_state` | * | Read current project state (includes phase info) |
+| `a2p_update_slice` | 2 | Update slice status with review checkpoints and slice summaries |
+| `a2p_run_tests` | 2 | Execute test command, parse results (pytest/vitest/jest/go) |
+| `a2p_run_quality` | 2.5 | Code quality analysis — dead code, redundancy, coupling metrics |
+| `a2p_run_e2e` | 2.6 | Record Playwright E2E test results |
+| `a2p_run_sast` | 2,3 | Static code analysis with Semgrep/Bandit, deduplicated findings |
+| `a2p_record_finding` | 3 | Manually record a security finding |
+| `a2p_generate_deployment` | 4 | Stack-specific deployment guidance |
+| `a2p_get_checklist` | 4 | Pre/post-deployment verification checklist |
+
+## Prompts (7)
+
+MCP prompts are invoked with `/` in Claude Code:
+
+| Command | What it does |
+|---------|-------------|
+| `/a2p` | Start onboarding — define architecture, UI design, tech stack, companions |
+| `/a2p_planning` | Break architecture into ordered vertical slices |
+| `/a2p_build_slice` | Build the current slice with TDD (RED → GREEN → REFACTOR → SAST) |
+| `/a2p_refactor` | Code quality tool — analyze codebase for dead code, redundancy, coupling |
+| `/a2p_e2e_testing` | AI testing tool — run visual E2E tests with Playwright |
+| `/a2p_security_gate` | Full SAST scan + OWASP Top 10 review |
+| `/a2p_deploy` | Generate deployment configs and launch checklist |
+
+### When to use which prompt
+
+You don't have to run the full pipeline. Each prompt works standalone — pick what you need:
+
+**Full project from scratch:**
+`/a2p` → `/a2p_planning` → `/a2p_build_slice` (repeat per slice) → `/a2p_security_gate` → `/a2p_deploy`
+
+**MVP built with vibe coding, now make it production-ready:**
+- `/a2p_security_gate` — find the vulnerabilities that vibe coding missed
+- `/a2p_refactor` — clean up the spaghetti, remove dead code
+- `/a2p_deploy` — generate Dockerfile, docker-compose, Caddyfile instead of guessing
+
+**Added features without tests, need confidence before shipping:**
+- `/a2p_refactor` — identify dead code and coupling from the feature sprawl
+- `/a2p_e2e_testing` — visually verify nothing is broken
+- `/a2p_security_gate` — catch injection, auth holes, hardcoded secrets
+
+**Existing project, just need deployment:**
+- `/a2p_deploy` — stack-specific configs, backup scripts, hardening guide
+
+**Built the MVP with slices, now entering Phase 2:**
+- `/a2p_planning` — create new slices for the next phase
+- `/a2p_build_slice` — TDD per slice as usual
+
+## Supported Stacks
+
+| Category | Technologies |
+|----------|-------------|
+| **Languages** | Python, TypeScript/Node.js, Go, Rust, Java/Kotlin, Ruby, PHP, C#/.NET |
+| **Databases** | SQLite, PostgreSQL, MySQL/MariaDB, MongoDB, Redis |
+| **Hosting** | Hetzner, DigitalOcean, AWS, Fly.io, Railway, Vercel, Cloudflare, Render, any VPS |
+
+## Supported Deploy Targets
+
+| Target | Method | What gets generated |
+|--------|--------|-------------------|
+| **Docker VPS** (Hetzner, DigitalOcean, any VPS) | Dockerfile + docker-compose + Caddy | Dockerfile, docker-compose.prod.yml, Caddyfile, backup.sh, DEPLOYMENT.md |
+| **Vercel** | Vercel CLI | vercel.json, Edge Middleware, env var setup |
+| **Cloudflare** (Pages/Workers) | Wrangler CLI / MCP | wrangler.toml, Page Rules, DNS config |
+| **Railway** | Railway CLI | railway.toml / Procfile, service config |
+| **Fly.io** | Fly CLI | fly.toml, secrets, volumes |
+| **Render** | Blueprint | render.yaml, health checks, auto-deploy |
+
+Each deploy path includes: env var handling, basic hardening, smoke checks, and domain checklist.
+
+## Companion MCP Servers
+
+a2p auto-configures companion MCP servers based on your tech stack. Each companion is integration-tested against its real server to verify tool availability. These MCP tools extend your AI development tool with specialized capabilities.
+
+### Core (always installed)
+
+| Companion | What it adds | Verified Tools |
+|-----------|-------------|----------------|
+| [codebase-memory-mcp](https://github.com/DeusData/codebase-memory-mcp) | Code graph intelligence — up to 100x fewer exploration tokens vs. raw file scanning | 11 tools: `index_repository`, `search_graph`, `search_code`, `trace_call_path`, ... |
+| [mcp-server-git](https://github.com/modelcontextprotocol/servers) | Git history, commits, diffs | 12 tools: `git_log`, `git_diff`, `git_commit`, `git_status`, ... |
+| [@modelcontextprotocol/server-filesystem](https://github.com/modelcontextprotocol/servers) | File operations | 14 tools: `write_file`, `list_directory`, `read_file`, `search_files`, ... |
+| [@modelcontextprotocol/server-sequential-thinking](https://github.com/modelcontextprotocol/servers) | Step-by-step reasoning for complex decisions | 1 tool: `sequentialthinking` |
+
+### Conditional (installed based on stack)
+
+| Companion | When | Verified Tools |
+|-----------|------|----------------|
+| [Playwright MCP](https://github.com/microsoft/playwright-mcp) | Frontend projects | 22 tools: `browser_navigate`, `browser_click`, `browser_fill_form`, `browser_take_screenshot`, `browser_resize`, ... |
+| [GitHub MCP](https://github.com/github/github-mcp-server) | GitHub repos | 41 tools: `list_issues`, `create_pull_request`, `search_code`, `get_file_contents`, ... |
+| [Supabase MCP](https://github.com/supabase-community/supabase-mcp) | Supabase projects | 29 tools: `execute_sql`, `list_tables`, `apply_migration`, `deploy_edge_function`, ... |
+| [@stripe/mcp](https://github.com/stripe/agent-toolkit) | Payment/billing | 28 tools: `create_product`, `create_price`, `create_payment_link`, `create_customer`, ... |
+| [@cloudflare/mcp-server-cloudflare](https://github.com/cloudflare/mcp-server-cloudflare) | Cloudflare hosting | 85 tools: `worker_deploy`, `kv_put`, `d1_query`, `r2_put_object`, `zones_list`, `secret_put`, ... |
+| [@sentry/mcp-server](https://github.com/getsentry/sentry-mcp-server) | Error tracking | 22 tools: `list_issues`, `get_issue_details`, `find_projects`, `analyze_issue_with_seer`, ... |
+| [@upstash/mcp-server](https://github.com/upstash/mcp-server) | Serverless Redis/Queue | 26 tools: `redis_database_run_redis_commands`, `qstash_publish_message`, `workflow_logs_list`, ... |
+| [Semgrep MCP](https://semgrep.dev/) | Semgrep Pro users | `semgrep_scan`, `security_check`, `get_abstract_syntax_tree` (OSS uses CLI fallback) |
+| [Atlassian MCP](https://developer.atlassian.com/) | Jira/Confluence | Remote MCP via OAuth |
+
+### Database MCPs
+
+| Companion | When |
+|-----------|------|
+| [@modelcontextprotocol/server-postgres](https://github.com/modelcontextprotocol/servers) | PostgreSQL |
+| [@mongodb-js/mongodb-mcp-server](https://github.com/mongodb-js/mongodb-mcp-server) | MongoDB |
+| [mcp-server-mysql](https://github.com/benborla/mcp-server-mysql) | MySQL/MariaDB |
+
+### CLI-only (no MCP server, uses CLI commands)
+
+| Tool | When |
+|------|------|
+| Vercel CLI (`vercel`) | Vercel / Next.js hosting |
+| Clerk | Auth integration |
+| Resend | Email integration |
+
+> **Security note:** Companion MCPs are third-party software with access to your project files and databases. Before enabling a companion: check the source repo (author, stars, open issues), review the `.mcp.json` that gets generated, and confirm you trust the server. Official packages (`@modelcontextprotocol/*`, `@playwright/mcp`, `mcp.supabase.com`) are maintained by their respective organizations. Community packages are not audited by us — use at your own discretion.
+
+## How is this different?
+
+- **vs. AI coding assistants alone (Claude Code, Cursor AI, Copilot)** — They generate code. a2p adds the TDD, security scanning, and deployment that AI coding assistants skip.
+- **vs. create-\*-app scaffolders** — Static templates vs. dynamic architecture-driven AI app builder with TDD and security gates.
+- **vs. manual deployment setup** — Weeks of DevOps vs. generated configs on day one.
+- **vs. vibe coding without a2p** — You ship fast but accumulate security debt, untested features, and manual deployment. a2p is the safety net that makes vibe coding production-viable.
+
+Works alongside autonomous AI agents — a2p adds the engineering rigor (TDD, SAST, deployment) that autonomous AI coding needs.
+
+## Development
+
+```bash
+git clone https://github.com/BernhardJackiewicz/architect-to-product.git
+cd architect-to-product
+npm install
+npm run typecheck   # Type checking
+npm test            # 527 tests
+npm run build       # Build
+npm run dev         # Dev mode
+```
+
+## License
+
+MIT

package/package.json

@@ -0,0 +1,36 @@
+{
+  "name": "architect-to-product",
+  "version": "0.1.0",
+  "type": "module",
+  "main": "dist/index.js",
+  "bin": {
+    "architect-to-product": "dist/index.js"
+  },
+  "scripts": {
+    "build": "tsc",
+    "dev": "tsx src/index.ts",
+    "test": "vitest run",
+    "test:watch": "vitest",
+    "typecheck": "tsc --noEmit"
+  },
+  "keywords": [
+    "mcp",
+    "architecture",
+    "tdd",
+    "code-quality"
+  ],
+  "author": "",
+  "license": "MIT",
+  "description": "MCP server that turns software architectures into tested, secure products",
+  "dependencies": {
+    "@modelcontextprotocol/sdk": "^1.27.1",
+    "zod": "^4.3.6"
+  },
+  "devDependencies": {
+    "@playwright/mcp": "^0.0.68",
+    "@types/node": "^25.5.0",
+    "tsx": "^4.21.0",
+    "typescript": "^5.9.3",
+    "vitest": "^4.1.0"
+  }
+}

package/setup.sh

@@ -0,0 +1,66 @@
+#!/bin/bash
+set -e
+
+echo "=== architect-to-product Setup ==="
+echo ""
+
+# 1. Build the MCP server
+echo "1/4 Building MCP server..."
+npm install
+npm run build
+echo "    ✓ Built successfully"
+
+# 2. Register architect-to-product in Claude Code
+echo ""
+echo "2/4 Registering architect-to-product MCP server..."
+claude mcp add architect-to-product -- node "$(pwd)/dist/index.js"
+echo "    ✓ Registered"
+
+# 3. Install codebase-memory-mcp
+echo ""
+echo "3/4 Installing codebase-memory-mcp..."
+ARCH=$(uname -m)
+OS=$(uname -s | tr '[:upper:]' '[:lower:]')
+
+if [ "$OS" = "darwin" ] && [ "$ARCH" = "arm64" ]; then
+    BINARY="codebase-memory-mcp-darwin-arm64"
+elif [ "$OS" = "darwin" ] && [ "$ARCH" = "x86_64" ]; then
+    BINARY="codebase-memory-mcp-darwin-amd64"
+elif [ "$OS" = "linux" ] && [ "$ARCH" = "x86_64" ]; then
+    BINARY="codebase-memory-mcp-linux-amd64"
+else
+    echo "    ⚠ Unsupported platform: $OS/$ARCH"
+    echo "    Download manually from https://github.com/DeusData/codebase-memory-mcp/releases"
+    BINARY=""
+fi
+
+if [ -n "$BINARY" ]; then
+    if command -v codebase-memory-mcp &>/dev/null; then
+        echo "    ✓ Already installed"
+    else
+        curl -sL "https://github.com/DeusData/codebase-memory-mcp/releases/latest/download/$BINARY" -o /usr/local/bin/codebase-memory-mcp
+        chmod +x /usr/local/bin/codebase-memory-mcp
+        echo "    ✓ Installed to /usr/local/bin/codebase-memory-mcp"
+    fi
+    claude mcp add codebase-memory -- codebase-memory-mcp
+    echo "    ✓ Registered in Claude Code"
+fi
+
+# 4. Check for Playwright MCP (optional)
+echo ""
+echo "4/4 Checking Playwright MCP (optional, for frontend E2E testing)..."
+if npm list -g @playwright/mcp &>/dev/null 2>&1; then
+    echo "    ✓ Already installed"
+else
+    echo "    ℹ Not installed. Install later with: npm install -g @playwright/mcp"
+    echo "    ℹ Then register: claude mcp add playwright -- npx @playwright/mcp"
+fi
+
+echo ""
+echo "=== Setup complete! ==="
+echo ""
+echo "Start a new project:"
+echo "  1. Open Claude Code"
+echo "  2. Use the a2p prompt"
+echo "  3. Or call a2p_init_project directly"
+echo ""

package/src/index.ts

@@ -0,0 +1,14 @@
+#!/usr/bin/env node
+import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
+import { createServer } from "./server.js";
+
+async function main() {
+  const server = createServer();
+  const transport = new StdioServerTransport();
+  await server.connect(transport);
+}
+
+main().catch((err) => {
+  console.error("Fatal:", err);
+  process.exit(1);
+});

package/src/prompts/build-slice.ts

@@ -0,0 +1,203 @@
+import { ENGINEERING_LOOP } from "./shared.js";
+
+export const BUILD_SLICE_PROMPT = `Du bist ein TDD-Engineer, der einen Slice nach dem Anthropic-Workflow baut: RED → GREEN → REFACTOR → SAST.
+${ENGINEERING_LOOP}
+## Kontext
+Lies zuerst den aktuellen State mit \`a2p_get_state\`. Der aktuelle Slice und seine Akzeptanzkriterien stehen dort.
+
+## Scope-Lock
+Halte den Scope strikt auf die Akzeptanzkriterien des aktuellen Slice begrenzt.
+- Keine neuen Features im GREEN
+- Keine Architektur-Umbauten im REFACTOR
+- Keine Test-Änderungen im GREEN (ausser offensichtliche Test-Infrastruktur-Fixes)
+- Scope-Erweiterungen → neuer Slice oder explizite Planänderung
+
+## Phase EXPLORE: Kontext aufbauen
+Bevor du Code schreibst — verstehe die Situation:
+
+1. Lies State und Akzeptanzkriterien des aktuellen Slice
+2. Wenn codebase-memory-mcp verfügbar:
+   - \`index_repository\` — Index aktualisieren
+   - \`search_code\` — existierenden Code finden der zum Slice passt (verhindert doppelte Implementierungen)
+   - \`trace_call_path\` — verstehen wie bestehender Code zusammenhängt
+3. Lies betroffene Dateien und angrenzenden Code
+4. Formuliere einen Mini-Plan: Ziel, betroffene Dateien, Risiken
+
+### Domänenwissen prüfen
+Wenn der Slice Fachlogik enthält (Berechnungen, Steuersätze, rechtliche Regeln, Branchenstandards):
+1. Nutze WebSearch um relevante Fakten zu verifizieren
+2. Wenn unklar → Rückfrage an den Menschen
+3. Dokumentiere recherchierte Fakten als Kommentar in den Tests
+
+## TDD-Zyklus (STRIKT einhalten!)
+
+### Phase RED: Tests schreiben
+**Ziel**: Fehlschlagende Tests, die die Akzeptanzkriterien abdecken.
+
+Nutze den test-writer Subagent (.claude/agents/test-writer.md) für Kontext-Isolation — Tests werden isoliert geschrieben, nicht zusammen mit Implementation.
+
+1. Schreibe Tests die FEHLSCHLAGEN:
+   - Happy Path (Normalfall)
+   - Edge Cases (leere Eingaben, Grenzwerte)
+   - Error Cases (ungültige Eingaben, fehlende Auth)
+2. Führe Tests aus mit \`a2p_run_tests\` — sie MÜSSEN fehlschlagen
+3. Markiere Slice als "red" mit \`a2p_update_slice\`
+
+**Schreibe KEINE Implementation in dieser Phase!**
+
+### Phase GREEN: Minimale Implementation
+**Ziel**: Tests grün machen mit minimalem Code.
+
+1. Schreibe die minimale Implementation, damit alle Tests grün werden
+2. Keine Über-Engineering! Nur was nötig ist, damit Tests passen
+3. Führe Tests aus mit \`a2p_run_tests\` — sie MÜSSEN jetzt bestehen
+4. Markiere Slice als "green" mit \`a2p_update_slice\`
+
+**Ändere NICHT die Tests in dieser Phase!**
+
+### Datenbank-Slices (wenn DB-MCP verfügbar)
+Wenn der Slice Datenbank-Änderungen enthält (Migrations, Schema, CRUD):
+1. Prüfe das aktuelle Schema mit dem DB-MCP (z.B. \`list_tables\`, \`describe_table\`)
+2. Nach Migrations: Verifiziere dass das Schema korrekt angelegt wurde
+3. Nach Seed-Data: Prüfe dass Testdaten vorhanden sind
+4. Bei CRUD: Teste mit echten DB-Queries ob die Daten korrekt gespeichert werden
+
+### UI-Design als Referenz nutzen (bei Frontend-Slices)
+Wenn der aktuelle Slice \`hasUI: true\` hat UND \`architecture.uiDesign\` existiert:
+1. Lies die \`uiDesign.description\` und den \`style\` aus dem State
+2. Prüfe die \`references\`:
+   - Wenn \`type: "wireframe"\` oder \`"mockup"\` oder \`"screenshot"\` mit \`path\` → lies das Bild und verwende es als visuelle Referenz
+   - Wenn \`type: "description"\` → nutze den Text als Designvorgabe
+3. Implementiere das UI **gemäss diesen Vorgaben** — nicht nach eigenem Ermessen
+
+### Visual Verification (nur bei Frontend-Slices)
+Wenn der aktuelle Slice \`hasUI: true\` hat (Frontend-Komponenten, Seiten, Formulare):
+
+**PFLICHT nach GREEN, vor REFACTOR:**
+1. App starten (oder sicherstellen dass sie läuft)
+2. \`browser_navigate\` zur relevanten Seite
+3. \`browser_take_screenshot\` — visueller Check:
+   - Stimmt es mit den uiDesign-References überein?
+   - Layout, Abstände, Farben konsistent?
+4. \`browser_console_messages\` — keine Errors?
+5. Interaktionen testen:
+   - \`browser_click\` — Buttons, Navigation
+   - \`browser_fill_form\` — Formulare, Validierung
+6. \`browser_resize\` auf Mobile (375x667) → Screenshot → zurück Desktop (1280x720)
+
+**Wenn visuell nicht ok:** Fix in GREEN Phase, erneut prüfen.
+**Wenn kein Frontend (\`hasUI\` nicht gesetzt):** direkt zu REFACTOR.
+
+### Phase REFACTOR: Code aufräumen
+**Ziel**: Code-Qualität verbessern ohne Verhalten zu ändern.
+
+1. Prüfe: Funktionen <50 Zeilen? Selbsterklärende Namen? Keine Duplizierung? Error Handling? Types?
+2. Refactore wo nötig
+3. Führe Tests aus nach JEDEM Refactoring — müssen grün bleiben
+4. Markiere Slice als "refactor" mit \`a2p_update_slice\`
+
+### Phase SAST: Security-Prüfung
+**Ziel**: Offensichtliche Security-Issues im neuen Code finden.
+
+1. Rufe \`a2p_run_sast\` mit mode="slice" auf
+2. Führe \`a2p_run_tests\` aus — finale Bestätigung
+3. Wenn codebase-memory-mcp verfügbar: \`index_repository\` — Graph aktualisieren
+4. Findings triagieren:
+   - CRITICAL/HIGH → sofort fixen, Tests + SAST wiederholen
+   - MEDIUM → fixen wenn einfach, sonst dokumentieren
+   - LOW → dokumentieren
+5. Markiere Slice als "sast" und dann "done" mit \`a2p_update_slice\`
+
+## Nach jedem abgeschlossenen Slice: Summary ausgeben
+Erstelle eine kurze Zusammenfassung:
+
+**Akzeptanzkriterien:**
+- [Was der Slice laut Plan können soll]
+
+**Tests prüfen:**
+- [Konkrete Testfälle mit Beispielwerten]
+
+**Implementiertes Verhalten:**
+- [Was tatsächlich gebaut wurde, inkl. Annahmen und Einschränkungen]
+
+**Recherchierte Fakten:**
+- [Falls WebSearch genutzt wurde: Quellen und verifizierte Werte]
+
+## Checkpoint nach Slice-Completion
+Prüfe den Output von \`a2p_update_slice\`:
+- Wenn \`awaitingHumanReview: true\` → STOPPE. Zeige die Summary.
+  Sage: "Slice X ist fertig. Bitte reviewe und bestätige, bevor ich
+  mit dem nächsten Slice fortfahre."
+  Warte auf explizite Bestätigung.
+- Wenn \`awaitingHumanReview: false\` → Zeige die Summary, fahre fort.
+
+## Git-Commits nach jeder TDD-Phase (wenn Git MCP verfügbar)
+Wenn der Git MCP konfiguriert ist, committe nach jeder abgeschlossenen Phase:
+- Nach RED: \`test:\` commit — \`git_log\` prüfen, \`git_diff\` für Änderungen
+- Nach GREEN: \`feat:\` commit
+- Nach REFACTOR: \`refactor:\` commit
+Nutze konventionelle Commit-Messages: \`feat:\`, \`test:\`, \`refactor:\`
+
+## Filesystem MCP für Migrations (wenn Filesystem MCP verfügbar)
+Wenn der Filesystem MCP konfiguriert ist:
+- Nutze \`write_file\` für Migration-Dateien (konsistente Formatierung)
+- Nutze \`list_directory\` um bestehende Migrations zu prüfen
+- Stelle sicher dass Migration-Dateien korrekt benannt sind (Timestamp-Prefix)
+
+## Semgrep MCP bevorzugt vor CLI (wenn Semgrep Pro MCP verfügbar)
+Wenn der Semgrep MCP konfiguriert ist (braucht Semgrep Pro Engine), bevorzuge ihn vor dem CLI-Aufruf:
+- Nutze \`semgrep_scan\` für gezielte Scans einzelner Dateien
+- Nutze \`security_check\` für Security-spezifische Checks
+- Nutze \`get_abstract_syntax_tree\` für tiefe Code-Analyse
+
+Ohne Semgrep Pro: Nutze \`a2p_run_sast\` — das ruft die Semgrep CLI direkt auf (funktioniert mit der kostenlosen OSS-Version).
+
+## Stripe MCP bei Payment-Slices (wenn Stripe MCP verfügbar)
+Wenn der Slice Payment/Billing-Funktionalität enthält und der Stripe MCP konfiguriert ist:
+- Erstelle Products und Prices über den Stripe MCP
+- Konfiguriere Webhooks für Payment-Events
+- Teste den Payment-Flow mit Stripe-Testmodus
+- Validiere Webhook-Signaturen im Code
+
+## Sentry MCP nach GREEN (wenn Sentry MCP verfügbar)
+Wenn der Sentry MCP konfiguriert ist und der Slice einen neuen Service/Endpoint einführt:
+- Konfiguriere Error-Tracking für den neuen Service
+- Setze Sentry-Tags für den Slice (slice-id, phase)
+- Prüfe ob Source Maps korrekt hochgeladen werden
+
+## Nach jedem Slice: Codebase-Index aktualisieren
+Wenn codebase-memory-mcp verfügbar:
+- Rufe \`index_repository\` auf — das hält den Code-Graphen aktuell für:
+  - Spätere Slices (finden bestehenden Code statt ihn neu zu schreiben)
+  - Die Refactor-Phase (Dead Code Detection braucht aktuellen Index)
+
+Dann:
+1. Prüfe: Gibt es einen nächsten Slice? → Weiter mit dem nächsten
+2. Alle Slices done? → Weiter zur Refactoring-Phase (a2p_refactor Prompt)
+
+## Integration-Slices (type: "integration")
+Wenn ein Slice eine externe Library/Service/API integriert:
+
+### RED Phase:
+- Schreibe Tests die das GEWÜNSCHTE Verhalten der Integration prüfen
+- Teste gegen das echte Interface, nicht gegen Mocks
+- Teste Fehlerszenarien: Library nicht verfügbar, falsches Format, Timeout
+
+### GREEN Phase:
+- Wrapper/Adapter-Pattern: eigene Schnittstelle VOR der Library
+- Library-spezifischer Code NUR im Adapter, nie im Business-Code
+- Konfiguration externalisieren (nicht hardcoded)
+- Error Handling: Library-Exceptions in eigene Fehlertypen übersetzen
+
+### REFACTOR Phase:
+- Ist der Adapter austauschbar?
+- Sind Library-Types nach aussen geleckt?
+- Gibt es unnötige Kopplungen?
+
+## Invarianten
+- NIEMALS Tests und Implementation gleichzeitig schreiben
+- NIEMALS einen Slice als "done" markieren ohne grüne Tests
+- NIEMALS Security-Findings ignorieren
+- Scope bleibt auf aktuellem Slice — Erweiterungen werden neue Slices
+- Bei jedem Fehler: Hypothese → Test → Fix → Verify (Debugging-Workflow)
+`;