architect-to-product 0.1.21 → 0.1.23

package/README.md

@@ -1,22 +1,34 @@
 # 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.
+AI engineering framework delivered as an MCP server.
+Turns AI-generated code into production-ready software with evidence-gated TDD, security review, backup strategy, and deployment automation.
 
-**28 MCP tools** · **1073 tests** · **Architecture → Plan → Build (evidence-gated) → Quality Audit (cadence) → Code Review → Signoff → E2E Testing → Security → Whitebox → Verify → [Shake & Break] → Release Audit → Deploy → Backup**
+**28 MCP tools** · **1073 tests** · **Architecture → Plan → Build → Audit → 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: 1061 passing](https://img.shields.io/badge/tests-1073%20passing-brightgreen)]()
+[![Tests: 1073 passing](https://img.shields.io/badge/tests-1073%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.
+### Quickstart
 
-- 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
+```bash
+npx architect-to-product init   # creates .mcp.json in your project
+```
+
+Restart Claude Code, then type `/a2p` to start.
+
+## What A2P is
+
+A2P is an AI engineering framework. It defines how AI-assisted software moves from architecture to production: vertical slice planning, evidence-gated TDD, security scanning, exploitability review, release audits, backup strategy, and deployment verification.
+
+The MCP server is the interface. The engineering system is the product.
+
+> **In one sentence:** A2P is an AI engineering framework, packaged as an MCP server, for turning AI-generated code into production-ready software.
 
-**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.
+---
 
 ### How it works: Red, Green, Refactor
 
@@ -61,37 +73,25 @@ Built-in SAST tools run static code analysis and OWASP Top 10 reviews before dep
 ## Quick Start
 
 ```bash
-npm install -g architect-to-product
-claude mcp add architect-to-product -- npx architect-to-product
+npx architect-to-product init   # creates .mcp.json in your project
 ```
 
-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
+Restart Claude Code, then type `/a2p` to start. The onboarding will co-develop your architecture, auto-configure companion MCP servers, and install SAST tools.
 
-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.
+## What A2P does
 
-It coordinates:
 - **Up to 100x fewer exploration tokens** — codebase-memory-mcp builds a code graph instead of scanning files raw
 - **Evidence-gated development** — every feature requires passing tests before advancing (code-enforced)
 - **Static code analysis** — Semgrep + Bandit scan for vulnerabilities automatically
 - **Whitebox security audit** — verifies whether SAST findings are actually exploitable (reachable paths, guards, trust boundaries)
 - **Active verification** — runtime gate tests that prove workflow invariants hold (state transitions, deployment gates, recovery)
-- **Shake & Break** (optional) — active runtime adversarial testing in an isolated sandbox. Starts the app, sends real HTTP requests to test for IDOR, race conditions, auth bypasses, business logic abuse. Findings are evidence-backed with actual request/response proof, not speculative
-- **Code audits** — Quality audits during development, release audits before publish (TODOs, debug artifacts, secrets, .gitignore, test coverage, README)
+- **Shake & Break** (optional) — runtime adversarial testing in an isolated sandbox with real HTTP requests. Evidence-backed findings, not speculative
+- **Code audits** — quality audits during development, release audits before publish
 - **Security reviews** — OWASP Top 10 review before deploy
-- **Structured build log** — every tool run tracked with log levels, duration, status, run correlation, and automatic secret redaction. Composable filters by phase, slice, level, time range, or errors
-- **Configurable human oversight** — mandatory build signoff and deploy approval, optional plan approval, slice review, UI screenshot verification, and security signoff
-- **Backup strategy** — Automatic inference of backup targets (database, uploads, artifacts) from tech stack. Stack-aware backup/restore commands, retention policies, verification scripts, offsite sync. Stateful apps are blocked from deployment if backup is missing
-- **Deployment generation** — stack-specific Dockerfile, docker-compose, Caddyfile, backup/restore/verify scripts, hardening guides
-
-A2P is not a replacement for engineers — it is the engineering reality layer that most architectures forget.
-
-Humans design features, flows, data models, and business logic. What they skip: logging, backup strategy, restore verification, deploy checks, test evidence, release hygiene, and proof that the code is actually secure — not just scanner-clean. A2P forces these layers in automatically. Every slice needs test evidence before it can advance. Every deployment needs a backup plan, a full security scan, and human sign-off. Every finding gets triaged for real exploitability, not just pattern-matched.
-
-Most AI-generated — and human-built — architectures don't fail because the main idea was wrong. They fail because of missing defaults, missing safeguards, and missing operational discipline. A2P closes that gap systematically.
+- **Structured build log** — every tool run tracked with log levels, duration, status, run correlation, and automatic secret redaction
+- **Configurable human oversight** — mandatory build signoff and deploy approval, optional plan approval, slice review, UI verification, and security signoff
+- **Backup strategy** — automatic inference of backup targets from tech stack. Stack-aware backup/restore/verify scripts. Stateful apps blocked from deployment without backup
+- **Deployment generation** — stack-specific Dockerfile, docker-compose, Caddyfile, hardening guides
 
 ## Without vs. With architect-to-product
 

package/VALIDATION.md

@@ -1,14 +1,14 @@
 # Validation Summary
 
-> Last validated: 2026-03-17 | A2P v0.1.18 | 1032 tests passing
+> Last validated: 2026-03-17 | A2P v0.1.22 | 1073 tests passing
 
-## Code-Enforced (verified by 1022 unit/integration tests)
+## Code-Enforced (verified by 1073 unit/integration tests)
 
 All workflow gates are implemented in `state-manager.ts` and tested:
 
 - **Evidence gates**: green requires passing tests, sast requires SAST scan, done requires passing tests
 - **Build signoff**: mandatory, invalidated by slice/test changes, blocks building->security
-- **Deploy approval**: mandatory, invalidated by new findings/whitebox/audit, blocks deployment config generation
+- **Deploy approval**: mandatory, invalidated by new findings/whitebox/audit, blocks deployment config generation. Re-checks active verification + backup gates (v0.1.21)
 - **Quality gate**: mandatory quality audit before building->security, stale audit blocked
 - **Security gates**: no deploy with open CRITICAL/HIGH SAST, missing/blocking whitebox, critical audit findings, stale SAST, missing/stale active verification
 - **State file protection**: PreToolUse hook blocks direct edits to `.a2p/state.json` (forces use of a2p_ tools)
@@ -18,6 +18,9 @@ All workflow gates are implemented in `state-manager.ts` and tested:
 - **Backup inference**: database/uploads auto-detected, stack-specific commands (pg_dump, mysqldump, mongodump, sqlite3)
 - **Build logging**: structured events with levels, status, duration, run correlation, secret redaction
 - **Finding justification**: accepted/fixed/false_positive require justification (code-enforced via `a2p_record_finding`)
+- **Finding dedup**: fingerprint-based dedup (tool:file:line:title) in `a2p_record_finding` prevents duplicate findings (v0.1.21)
+- **Post-SAST test gate**: done transition requires tests to have run after SAST scan (v0.1.21)
+- **Whitebox suppression**: resolved SAST findings (false_positive/fixed/accepted) suppressed from whitebox candidates (v0.1.21)
 - **Code review integration**: build signoff includes code review pass, release audit includes code review
 - **Companion restart detection**: removed hard-block `restartRequired` (unreliable — cannot detect restart server-side); onboarding prompt handles restart message, planning/build prompts use soft hint
 - **Quality audit cadence**: evidence-gated claims require audit evidence, cadence tracking
@@ -231,3 +234,76 @@ All 28 tools are registered identically in `server.ts` using the same `server.to
 The core pipeline — evidence-gated TDD, security gates, whitebox audit, adversarial review with guided hardening, active verification, deployment artifact generation — works as documented. All mandatory gates (build signoff, deploy approval, finding justification, security re-entry invalidation) are code-enforced and verified forensically from state.json reads.
 
 **0.1.18 hardening:** Backup gate confirmed working (E2E anomaly not reproducible, defensive re-read added, 4 regression tests). UI/E2E warning added to build signoff. Audit output clarified when build/test commands not configured. All 28 tools confirmed registered and discoverable via MCP `tools/list`.
+
+---
+
+## Pre-Release Bug Fixes (v0.1.21, 2026-03-17)
+
+Real-deployment audit of mini-bookmarks on Hetzner revealed 5 bugs/gaps. All fixed with 12 new tests:
+
+| Bug | Fix | Tests Added |
+|---|---|---|
+| Deploy approval skips active verification + backup gates | `setDeployApproval()` now re-checks verification (existence, blocking, staleness) and backup | 5 |
+| Finding dedup weak (ID-only) | Fingerprint dedup (tool:file:line:title) in `a2p_record_finding` | 2 |
+| Whitebox re-evaluates resolved SAST findings | Suppress candidates matching resolved findings by tool:file:title | 3 |
+| Done guard accepts pre-SAST tests | `lastTest.timestamp >= slice.sastRanAt` check | 2 |
+| German tool-output strings in `complete-adversarial-review.ts` | Translated to English (hardening area reasons, hint text, nextActions) | 0 (existing assertions updated) |
+
+---
+
+## Prompt-Layer i18n Audit (v0.1.22, 2026-03-17)
+
+Full translation of all 10 prompt files from German to English. Verified via 3-agent parallel audit.
+
+### Scope Completeness
+
+| File | Status |
+|---|---|
+| shared.ts | Fully English |
+| audit.ts | Fully English |
+| refactor.ts | Fully English |
+| e2e-testing.ts | Fully English |
+| planning.ts | Fully English |
+| security-gate.ts | Fully English |
+| whitebox.ts | Fully English |
+| onboarding.ts | Fully English |
+| deploy.ts | Fully English |
+| build-slice.ts | Fully English |
+
+No German remnants. No mixed language. Grep-verified (umlauts, German articles, German verbs).
+
+### Behavioral Audit
+
+| Check | Result |
+|---|---|
+| Hard control instructions (STOP, NEVER, MUST, MANDATORY, NOT negotiable, VERBATIM) | All preserved, count-matched |
+| a2p_* tool names | Identical |
+| ${...} interpolations | Identical |
+| MCP tool names | Identical |
+| CLI commands | Identical |
+| Line counts | 9/10 identical, whitebox.ts -1 (whitespace) |
+| Section header hierarchy | Identical |
+| Semantic shifts | Zero |
+
+**Verdict: translation-only. Zero behavior changes.**
+
+### Test Audit
+
+| Test File | Tests Before | Tests After | German Remnants | Weakened | Removed |
+|---|---|---|---|---|---|
+| mcp-integration.test.ts | 152 | 152 | 0 | 0 | 0 |
+| deploy-paths.test.ts | 72 | 72 | 0 | 0 | 0 |
+| test-thinking.test.ts | 13 | 13 | 0 | 0 | 0 |
+| doc-first-and-model.test.ts | 15 | 15 | 0 | 0 | 0 |
+| logging.test.ts | 35 | 35 | 0 | 0 | 0 |
+
+61 string assertions updated. No tests removed or weakened. One missed German string (`"## Nach jedem"`) caught and fixed in post-audit.
+
+### Build/Test
+
+- `npm run build`: clean
+- `npm test`: 1073/1073 passed
+
+### i18n Audit Verdict
+
+**PASS — translation-only, release-safe.**

package/dist/cli.d.ts

@@ -0,0 +1,3 @@
+#!/usr/bin/env node
+export {};
+//# sourceMappingURL=cli.d.ts.map

package/dist/cli.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"cli.d.ts","sourceRoot":"","sources":["../src/cli.ts"],"names":[],"mappings":""}

package/dist/cli.js

@@ -0,0 +1,53 @@
+#!/usr/bin/env node
+import { writeFileSync, existsSync, readFileSync } from "node:fs";
+import { join, dirname } from "node:path";
+import { fileURLToPath } from "node:url";
+// Read version from package.json at runtime
+const __dirname = dirname(fileURLToPath(import.meta.url));
+const pkg = JSON.parse(readFileSync(join(__dirname, "..", "package.json"), "utf-8"));
+const packageName = pkg.name;
+const packageVersion = pkg.version;
+const command = process.argv[2];
+if (command === "init") {
+    const mcpJsonPath = join(process.cwd(), ".mcp.json");
+    if (existsSync(mcpJsonPath)) {
+        const existing = JSON.parse(readFileSync(mcpJsonPath, "utf-8"));
+        if (existing.mcpServers?.["architect-to-product"]) {
+            console.log(`✓ .mcp.json already configured with architect-to-product.`);
+            console.log(`  Restart Claude Code, then type /a2p to start.`);
+            process.exit(0);
+        }
+        // Add to existing .mcp.json
+        existing.mcpServers = existing.mcpServers ?? {};
+        existing.mcpServers["architect-to-product"] = {
+            command: "npx",
+            args: ["-y", `${packageName}@${packageVersion}`],
+        };
+        writeFileSync(mcpJsonPath, JSON.stringify(existing, null, 2) + "\n", "utf-8");
+        console.log(`✓ Added architect-to-product to existing .mcp.json`);
+    }
+    else {
+        const config = {
+            mcpServers: {
+                "architect-to-product": {
+                    command: "npx",
+                    args: ["-y", `${packageName}@${packageVersion}`],
+                },
+            },
+        };
+        writeFileSync(mcpJsonPath, JSON.stringify(config, null, 2) + "\n", "utf-8");
+        console.log(`✓ Created .mcp.json with architect-to-product@${packageVersion}`);
+    }
+    console.log(`\nNext steps:`);
+    console.log(`  1. Restart Claude Code`);
+    console.log(`  2. Type /a2p to start`);
+}
+else {
+    console.log(`architect-to-product v${packageVersion}`);
+    console.log(``);
+    console.log(`Usage:`);
+    console.log(`  npx a2p init   Set up .mcp.json in current directory`);
+    console.log(``);
+    console.log(`After init, restart Claude Code and type /a2p to start.`);
+}
+//# sourceMappingURL=cli.js.map

package/dist/cli.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"cli.js","sourceRoot":"","sources":["../src/cli.ts"],"names":[],"mappings":";AACA,OAAO,EAAE,aAAa,EAAE,UAAU,EAAE,YAAY,EAAE,MAAM,SAAS,CAAC;AAClE,OAAO,EAAE,IAAI,EAAE,OAAO,EAAE,MAAM,WAAW,CAAC;AAC1C,OAAO,EAAE,aAAa,EAAE,MAAM,UAAU,CAAC;AAEzC,4CAA4C;AAC5C,MAAM,SAAS,GAAG,OAAO,CAAC,aAAa,CAAC,MAAM,CAAC,IAAI,CAAC,GAAG,CAAC,CAAC,CAAC;AAC1D,MAAM,GAAG,GAAG,IAAI,CAAC,KAAK,CAAC,YAAY,CAAC,IAAI,CAAC,SAAS,EAAE,IAAI,EAAE,cAAc,CAAC,EAAE,OAAO,CAAC,CAAC,CAAC;AACrF,MAAM,WAAW,GAAW,GAAG,CAAC,IAAI,CAAC;AACrC,MAAM,cAAc,GAAW,GAAG,CAAC,OAAO,CAAC;AAE3C,MAAM,OAAO,GAAG,OAAO,CAAC,IAAI,CAAC,CAAC,CAAC,CAAC;AAEhC,IAAI,OAAO,KAAK,MAAM,EAAE,CAAC;IACvB,MAAM,WAAW,GAAG,IAAI,CAAC,OAAO,CAAC,GAAG,EAAE,EAAE,WAAW,CAAC,CAAC;IAErD,IAAI,UAAU,CAAC,WAAW,CAAC,EAAE,CAAC;QAC5B,MAAM,QAAQ,GAAG,IAAI,CAAC,KAAK,CAAC,YAAY,CAAC,WAAW,EAAE,OAAO,CAAC,CAAC,CAAC;QAChE,IAAI,QAAQ,CAAC,UAAU,EAAE,CAAC,sBAAsB,CAAC,EAAE,CAAC;YAClD,OAAO,CAAC,GAAG,CAAC,2DAA2D,CAAC,CAAC;YACzE,OAAO,CAAC,GAAG,CAAC,iDAAiD,CAAC,CAAC;YAC/D,OAAO,CAAC,IAAI,CAAC,CAAC,CAAC,CAAC;QAClB,CAAC;QACD,4BAA4B;QAC5B,QAAQ,CAAC,UAAU,GAAG,QAAQ,CAAC,UAAU,IAAI,EAAE,CAAC;QAChD,QAAQ,CAAC,UAAU,CAAC,sBAAsB,CAAC,GAAG;YAC5C,OAAO,EAAE,KAAK;YACd,IAAI,EAAE,CAAC,IAAI,EAAE,GAAG,WAAW,IAAI,cAAc,EAAE,CAAC;SACjD,CAAC;QACF,aAAa,CAAC,WAAW,EAAE,IAAI,CAAC,SAAS,CAAC,QAAQ,EAAE,IAAI,EAAE,CAAC,CAAC,GAAG,IAAI,EAAE,OAAO,CAAC,CAAC;QAC9E,OAAO,CAAC,GAAG,CAAC,oDAAoD,CAAC,CAAC;IACpE,CAAC;SAAM,CAAC;QACN,MAAM,MAAM,GAAG;YACb,UAAU,EAAE;gBACV,sBAAsB,EAAE;oBACtB,OAAO,EAAE,KAAK;oBACd,IAAI,EAAE,CAAC,IAAI,EAAE,GAAG,WAAW,IAAI,cAAc,EAAE,CAAC;iBACjD;aACF;SACF,CAAC;QACF,aAAa,CAAC,WAAW,EAAE,IAAI,CAAC,SAAS,CAAC,MAAM,EAAE,IAAI,EAAE,CAAC,CAAC,GAAG,IAAI,EAAE,OAAO,CAAC,CAAC;QAC5E,OAAO,CAAC,GAAG,CAAC,iDAAiD,cAAc,EAAE,CAAC,CAAC;IACjF,CAAC;IACD,OAAO,CAAC,GAAG,CAAC,eAAe,CAAC,CAAC;IAC7B,OAAO,CAAC,GAAG,CAAC,0BAA0B,CAAC,CAAC;IACxC,OAAO,CAAC,GAAG,CAAC,yBAAyB,CAAC,CAAC;AACzC,CAAC;KAAM,CAAC;IACN,OAAO,CAAC,GAAG,CAAC,yBAAyB,cAAc,EAAE,CAAC,CAAC;IACvD,OAAO,CAAC,GAAG,CAAC,EAAE,CAAC,CAAC;IAChB,OAAO,CAAC,GAAG,CAAC,QAAQ,CAAC,CAAC;IACtB,OAAO,CAAC,GAAG,CAAC,wDAAwD,CAAC,CAAC;IACtE,OAAO,CAAC,GAAG,CAAC,EAAE,CAAC,CAAC;IAChB,OAAO,CAAC,GAAG,CAAC,yDAAyD,CAAC,CAAC;AACzE,CAAC"}

package/dist/prompts/audit.d.ts

@@ -1,2 +1,2 @@
-export declare const AUDIT_PROMPT = "Du f\u00FChrst ein Code-Audit durch \u2014 entweder als laufende Qualit\u00E4tskontrolle oder als Pre-Release-Pr\u00FCfung.\n\n## Engineering Loop\n1. **Explore**: Lies State, betroffene Dateien, angrenzenden Code. Kein Code schreiben bis du die Situation verstehst.\n2. **Plan**: Formuliere Ziel, betroffene Dateien, Risiken, Teststrategie.\n3. **One unit of work**: Genau ein Slice / eine Aufgabe. Keine Scope-Erweiterung ohne expliziten Grund.\n4. **Context isolation**: Nutze spezialisierte Subagenten (test-writer, security-reviewer) f\u00FCr Rollen-Trennung.\n5. **Evidence over narration**: Kein \"done\" ohne Test-Evidenz und Verifikationsnotiz.\n6. **Documentation first**: Bei unbekannten Technologien, Libraries oder APIs IMMER die offizielle Dokumentation lesen (WebSearch + WebFetch). NIEMALS API-Signaturen, Config-Optionen oder Verhaltensweisen halluzinieren oder vermuten.\n\n## Wann welcher Modus?\n\n### Quality Audit (alle ~5-10 Commits)\nZiel: Code-Hygiene w\u00E4hrend der Entwicklung sicherstellen.\n1. Rufe `a2p_run_audit mode=quality` auf\n2. Gehe die Findings durch und fixe sie direkt:\n   - TODOs: L\u00F6sen oder als Known Limitation dokumentieren\n   - Debug-Artefakte (console.log, debugger): Entfernen\n   - Hardcoded Secrets: In Env-Variablen auslagern\n   - .gitignore: Fehlende Eintr\u00E4ge erg\u00E4nzen\n3. Weiterarbeiten\n\n### Release Audit (vor Ver\u00F6ffentlichung)\nZiel: Sicherstellen, dass das Repo publikationsreif ist.\n\n**Pass 1 \u2014 Automatisch:**\n1. Rufe `a2p_run_audit mode=release` auf\n2. Fixe alle technischen Findings (wie bei Quality)\n3. README erweitern falls n\u00F6tig (Installation, Usage, Konfiguration)\n4. Temp-Dateien entfernen\n5. Offene SAST/Quality-Findings kl\u00E4ren\n\n**Pass 2 \u2014 Code Review (Claude pr\u00FCft):**\n1. **Cross-File-Konsistenz**: Gleiche Patterns \u00FCberall? Gleiche Error-Handling-Strategie? Gleiche Naming-Konventionen?\n2. **Unused Code**: Dead exports, unused imports, unreachable branches?\n3. **Error Handling**: Leere catch-Bl\u00F6cke, verschluckte Errors, fehlende Fehlerbehandlung bei externen Calls?\n4. **API-Koh\u00E4renz**: Konsistente Response-Formate, Status-Codes, Validierung?\n5. **README-Glaubw\u00FCrdigkeit**: Stimmen Beschreibungen mit dem Code \u00FCberein?\n6. **Setup-Anleitung**: Kann ein neuer Dev damit starten?\n7. **Commit-History**: Gibt es peinliche Commits oder sensible Daten?\n8. **Repo-Struktur**: Ist die Ordnerstruktur logisch und konsistent?\n9. **Lizenz/Copyright**: Vorhanden wenn n\u00F6tig?\n\nGib das Review-Ergebnis als strukturierten Block aus:\n- **Review-Punkte gefunden**: [Ja/Nein, Anzahl]\n- **Kritisch (release-blockierend)**: [Liste oder \"Keine\"]\n- **Empfehlenswert (nicht blockierend)**: [Liste oder \"Keine\"]\n\n## Wichtig\n- NICHT `a2p_run_sast` oder `a2p_run_quality` erneut laufen lassen \u2014 das Audit aggregiert deren bestehende Ergebnisse\n- Das Audit ist kein Ersatz f\u00FCr SAST (Semgrep/Bandit) oder Quality (codebase-memory) \u2014 es pr\u00FCft Code-Hygiene\n- Findings mit severity \"critical\" blockieren ein Release\n";
+export declare const AUDIT_PROMPT = "You are performing a code audit \u2014 either as ongoing quality control or as a pre-release check.\n\n## Engineering Loop\n1. **Explore**: Read state, affected files, adjacent code. Do NOT write code until you understand the situation.\n2. **Plan**: Define goal, affected files, risks, test strategy.\n3. **One unit of work**: Exactly one Slice / one task. No scope expansion without explicit justification.\n4. **Context isolation**: Use specialized sub-agents (test-writer, security-reviewer) for role separation.\n5. **Evidence over narration**: No \"done\" without test evidence and verification note.\n6. **Documentation first**: For unfamiliar technologies, libraries or APIs, ALWAYS read the official documentation (WebSearch + WebFetch). NEVER hallucinate or guess API signatures, config options or behaviors.\n\n## When to use which mode?\n\n### Quality Audit (every ~5-10 commits)\nGoal: Ensure code hygiene during development.\n1. Call `a2p_run_audit mode=quality`\n2. Go through the findings and fix them directly:\n   - TODOs: Resolve or document as Known Limitation\n   - Debug artifacts (console.log, debugger): Remove\n   - Hardcoded secrets: Move to env variables\n   - .gitignore: Add missing entries\n3. Continue working\n\n### Release Audit (before publication)\nGoal: Ensure the repo is publication-ready.\n\n**Pass 1 \u2014 Automated:**\n1. Call `a2p_run_audit mode=release`\n2. Fix all technical findings (same as Quality)\n3. Extend README if needed (Installation, Usage, Configuration)\n4. Remove temp files\n5. Resolve open SAST/Quality findings\n\n**Pass 2 \u2014 Code Review (Claude reviews):**\n1. **Cross-file consistency**: Same patterns everywhere? Same error handling strategy? Same naming conventions?\n2. **Unused code**: Dead exports, unused imports, unreachable branches?\n3. **Error handling**: Empty catch blocks, swallowed errors, missing error handling for external calls?\n4. **API coherence**: Consistent response formats, status codes, validation?\n5. **README credibility**: Do descriptions match the code?\n6. **Setup instructions**: Can a new dev get started with them?\n7. **Commit history**: Are there embarrassing commits or sensitive data?\n8. **Repo structure**: Is the folder structure logical and consistent?\n9. **License/Copyright**: Present if needed?\n\nOutput the review result as a structured block:\n- **Review issues found**: [Yes/No, count]\n- **Critical (release-blocking)**: [List or \"None\"]\n- **Recommended (non-blocking)**: [List or \"None\"]\n\n## Important\n- DO NOT run `a2p_run_sast` or `a2p_run_quality` again \u2014 the audit aggregates their existing results\n- The audit is not a replacement for SAST (Semgrep/Bandit) or Quality (codebase-memory) \u2014 it checks code hygiene\n- Findings with severity \"critical\" block a release\n";
 //# sourceMappingURL=audit.d.ts.map

package/dist/prompts/audit.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"audit.d.ts","sourceRoot":"","sources":["../../src/prompts/audit.ts"],"names":[],"mappings":"AAEA,eAAO,MAAM,YAAY,0hGA4CxB,CAAC"}
+{"version":3,"file":"audit.d.ts","sourceRoot":"","sources":["../../src/prompts/audit.ts"],"names":[],"mappings":"AAEA,eAAO,MAAM,YAAY,iwFA4CxB,CAAC"}

package/dist/prompts/audit.js

@@ -1,47 +1,47 @@
 import { ENGINEERING_LOOP } from "./shared.js";
-export const AUDIT_PROMPT = `Du führst ein Code-Audit durch — entweder als laufende Qualitätskontrolle oder als Pre-Release-Prüfung.
+export const AUDIT_PROMPT = `You are performing a code audit — either as ongoing quality control or as a pre-release check.
 ${ENGINEERING_LOOP}
-## Wann welcher Modus?
+## When to use which mode?
 
-### Quality Audit (alle ~5-10 Commits)
-Ziel: Code-Hygiene während der Entwicklung sicherstellen.
-1. Rufe \`a2p_run_audit mode=quality\` auf
-2. Gehe die Findings durch und fixe sie direkt:
-   - TODOs: Lösen oder als Known Limitation dokumentieren
-   - Debug-Artefakte (console.log, debugger): Entfernen
-   - Hardcoded Secrets: In Env-Variablen auslagern
-   - .gitignore: Fehlende Einträge ergänzen
-3. Weiterarbeiten
+### Quality Audit (every ~5-10 commits)
+Goal: Ensure code hygiene during development.
+1. Call \`a2p_run_audit mode=quality\`
+2. Go through the findings and fix them directly:
+   - TODOs: Resolve or document as Known Limitation
+   - Debug artifacts (console.log, debugger): Remove
+   - Hardcoded secrets: Move to env variables
+   - .gitignore: Add missing entries
+3. Continue working
 
-### Release Audit (vor Veröffentlichung)
-Ziel: Sicherstellen, dass das Repo publikationsreif ist.
+### Release Audit (before publication)
+Goal: Ensure the repo is publication-ready.
 
-**Pass 1 — Automatisch:**
-1. Rufe \`a2p_run_audit mode=release\` auf
-2. Fixe alle technischen Findings (wie bei Quality)
-3. README erweitern falls nötig (Installation, Usage, Konfiguration)
-4. Temp-Dateien entfernen
-5. Offene SAST/Quality-Findings klären
+**Pass 1 — Automated:**
+1. Call \`a2p_run_audit mode=release\`
+2. Fix all technical findings (same as Quality)
+3. Extend README if needed (Installation, Usage, Configuration)
+4. Remove temp files
+5. Resolve open SAST/Quality findings
 
-**Pass 2 — Code Review (Claude prüft):**
-1. **Cross-File-Konsistenz**: Gleiche Patterns überall? Gleiche Error-Handling-Strategie? Gleiche Naming-Konventionen?
-2. **Unused Code**: Dead exports, unused imports, unreachable branches?
-3. **Error Handling**: Leere catch-Blöcke, verschluckte Errors, fehlende Fehlerbehandlung bei externen Calls?
-4. **API-Kohärenz**: Konsistente Response-Formate, Status-Codes, Validierung?
-5. **README-Glaubwürdigkeit**: Stimmen Beschreibungen mit dem Code überein?
-6. **Setup-Anleitung**: Kann ein neuer Dev damit starten?
-7. **Commit-History**: Gibt es peinliche Commits oder sensible Daten?
-8. **Repo-Struktur**: Ist die Ordnerstruktur logisch und konsistent?
-9. **Lizenz/Copyright**: Vorhanden wenn nötig?
+**Pass 2 — Code Review (Claude reviews):**
+1. **Cross-file consistency**: Same patterns everywhere? Same error handling strategy? Same naming conventions?
+2. **Unused code**: Dead exports, unused imports, unreachable branches?
+3. **Error handling**: Empty catch blocks, swallowed errors, missing error handling for external calls?
+4. **API coherence**: Consistent response formats, status codes, validation?
+5. **README credibility**: Do descriptions match the code?
+6. **Setup instructions**: Can a new dev get started with them?
+7. **Commit history**: Are there embarrassing commits or sensitive data?
+8. **Repo structure**: Is the folder structure logical and consistent?
+9. **License/Copyright**: Present if needed?
 
-Gib das Review-Ergebnis als strukturierten Block aus:
-- **Review-Punkte gefunden**: [Ja/Nein, Anzahl]
-- **Kritisch (release-blockierend)**: [Liste oder "Keine"]
-- **Empfehlenswert (nicht blockierend)**: [Liste oder "Keine"]
+Output the review result as a structured block:
+- **Review issues found**: [Yes/No, count]
+- **Critical (release-blocking)**: [List or "None"]
+- **Recommended (non-blocking)**: [List or "None"]
 
-## Wichtig
-- NICHT \`a2p_run_sast\` oder \`a2p_run_quality\` erneut laufen lassen — das Audit aggregiert deren bestehende Ergebnisse
-- Das Audit ist kein Ersatz für SAST (Semgrep/Bandit) oder Quality (codebase-memory) — es prüft Code-Hygiene
-- Findings mit severity "critical" blockieren ein Release
+## Important
+- DO NOT run \`a2p_run_sast\` or \`a2p_run_quality\` again — the audit aggregates their existing results
+- The audit is not a replacement for SAST (Semgrep/Bandit) or Quality (codebase-memory) — it checks code hygiene
+- Findings with severity "critical" block a release
 `;
 //# sourceMappingURL=audit.js.map

package/dist/prompts/build-slice.d.ts

@@ -1,2 +1,2 @@
-export declare const BUILD_SLICE_PROMPT = "Du bist ein Spec-First-Engineer, der einen Slice nach dem Anthropic-Workflow baut: RED \u2192 GREEN \u2192 REFACTOR \u2192 SAST.\n\n## Engineering Loop\n1. **Explore**: Lies State, betroffene Dateien, angrenzenden Code. Kein Code schreiben bis du die Situation verstehst.\n2. **Plan**: Formuliere Ziel, betroffene Dateien, Risiken, Teststrategie.\n3. **One unit of work**: Genau ein Slice / eine Aufgabe. Keine Scope-Erweiterung ohne expliziten Grund.\n4. **Context isolation**: Nutze spezialisierte Subagenten (test-writer, security-reviewer) f\u00FCr Rollen-Trennung.\n5. **Evidence over narration**: Kein \"done\" ohne Test-Evidenz und Verifikationsnotiz.\n6. **Documentation first**: Bei unbekannten Technologien, Libraries oder APIs IMMER die offizielle Dokumentation lesen (WebSearch + WebFetch). NIEMALS API-Signaturen, Config-Optionen oder Verhaltensweisen halluzinieren oder vermuten.\n\n## Modell-Pr\u00E4ferenz\nPr\u00FCfe `a2p_get_state` \u2192 `config.claudeModel`. Wenn dort ein Modell konfiguriert ist, sage dem User Bescheid falls er ein anderes Modell verwendet. Default: opus (Claude Opus 4.6 mit Maximum Effort).\n\n## Kontext\nLies zuerst den aktuellen State mit `a2p_get_state`. Der aktuelle Slice und seine Akzeptanzkriterien stehen dort.\n\nWenn Companions konfiguriert wurden, aber die Companion-Tools (z.B. `index_repository`, `sequentialthinking`) nicht verf\u00FCgbar sind, weise den User darauf hin, dass ein Neustart von Claude Code n\u00F6tig sein k\u00F6nnte \u2014 aber blockiere den Build NICHT.\n\n## Scope-Lock\nHalte den Scope strikt auf die Akzeptanzkriterien des aktuellen Slice begrenzt.\n- Keine neuen Features im GREEN\n- Keine Architektur-Umbauten im REFACTOR\n- Keine Test-\u00C4nderungen im GREEN (ausser offensichtliche Test-Infrastruktur-Fixes)\n- Scope-Erweiterungen \u2192 neuer Slice oder explizite Plan\u00E4nderung\n\n## Phase EXPLORE: Kontext aufbauen\nBevor du Code schreibst \u2014 verstehe die Situation:\n\n1. Lies State und Akzeptanzkriterien des aktuellen Slice\n2. Pr\u00FCfe `a2p_get_state` \u2192 `companionReadiness.codebaseMemory`. Wenn true:\n   - `index_repository` \u2014 Index aktualisieren\n   - `search_code` \u2014 existierenden Code finden der zum Slice passt (verhindert doppelte Implementierungen)\n   - `trace_call_path` \u2014 verstehen wie bestehender Code zusammenh\u00E4ngt\n3. Lies betroffene Dateien und angrenzenden Code\n4. Formuliere einen Mini-Plan: Ziel, betroffene Dateien, Risiken\n\n### Dokumentation LESEN, nicht raten \u2014 EMPFOHLEN\nWenn der Slice eine Technologie, Library, API oder einen Service verwendet der dir nicht 100% vertraut ist:\nLies die offizielle Dokumentation bevor du Code schreibst.\nHalluziniere keine API-Signaturen, Config-Optionen oder Verhaltensweisen.\n(Prompt-Guidance, kein Code-Gate \u2014 aber halluzinierte APIs f\u00FChren zu roten Tests und Zeitverlust.)\n\n1. **WebSearch** um die offizielle Doku-URL zu finden\n2. **WebFetch** um die relevanten Doku-Seiten zu lesen (Getting Started, API Reference, Configuration)\n3. Wenn die Doku nicht abrufbar ist \u2192 R\u00FCckfrage an den Menschen\n4. Dokumentiere die Doku-URL als Kommentar im Code wo die Technologie verwendet wird\n\nBeispiele wann du Doku lesen MUSST:\n- Unbekannte Auth-L\u00F6sung (Clerk, Lucia, Better-Auth, Kinde, etc.)\n- Unbekannte DB/ORM (Drizzle, Prisma, EdgeDB, SurrealDB, etc.)\n- Unbekannte API (Stripe, Resend, Twilio, etc.)\n- Unbekannte Framework-Features (App Router vs Pages Router, Server Actions, etc.)\n- Alles wo du dir bei der API-Signatur nicht 100% sicher bist\n\n**Bei jedem `import` einer unbekannten Library: Doku lesen.**\n**Lieber einmal zu viel Doku lesen als einmal zu wenig.**\n\n### Dom\u00E4nenwissen pr\u00FCfen\nWenn der Slice Fachlogik enth\u00E4lt (Berechnungen, Steuers\u00E4tze, rechtliche Regeln, Branchenstandards):\n1. Nutze WebSearch um relevante Fakten zu verifizieren\n2. Wenn unklar \u2192 R\u00FCckfrage an den Menschen\n3. Dokumentiere recherchierte Fakten als Kommentar in den Tests\n\n## Slice-Spezifikation \u2014 PFLICHT vor RED\n\nBevor du Tests oder Code schreibst, halte die Slice-Spezifikation fest (Prompt-Guidance, nicht code-enforced):\n\n1. **Spec-Test-Mapping**: Liste welche Tests du schreiben wirst und welche Akzeptanzkriterien sie abdecken\n2. **Initial-Rot-Hypothese**: Was soll fehlschlagen, bevor die Implementation beginnt?\n3. **Minimale gr\u00FCne \u00C4nderung**: Was ist die kleinstm\u00F6gliche \u00C4nderung, die alle Tests gr\u00FCn macht?\n\nGib diese Spezifikation als kurzen Block aus, bevor du in die RED-Phase gehst. Das ist kein Code-Gate \u2014 aber es macht die Absicht pr\u00FCfbar und verhindert, dass Tests erst nachtr\u00E4glich an eine fertige Implementation angepasst werden.\n\n## Evidence-Driven Development Cycle\n\nDie Reihenfolge RED \u2192 GREEN \u2192 REFACTOR \u2192 SAST ist durch Evidence-Gates im Code abgesichert: green erfordert passing Tests, sast erfordert einen SAST-Scan, done erfordert passing Tests. Die chronologische Test-First-Reihenfolge innerhalb einer Phase ist Prompt-Guidance \u2014 der Code kann nicht pr\u00FCfen, ob Tests vor der Implementation geschrieben wurden.\n\n### Phase RED: Tests schreiben\n**Ziel**: Fehlschlagende Tests, die die Akzeptanzkriterien abdecken.\n\nNutze den test-writer Subagent (.claude/agents/test-writer.md) f\u00FCr Kontext-Isolation \u2014 Tests werden isoliert geschrieben, nicht zusammen mit Implementation.\n\n1. Schreibe Tests die FEHLSCHLAGEN:\n   - Happy Path (Normalfall)\n   - Edge Cases (leere Eingaben, Grenzwerte)\n   - Error Cases (ung\u00FCltige Eingaben, fehlende Auth)\n2. F\u00FChre Tests aus mit `a2p_run_tests` \u2014 sie sollten fehlschlagen (best\u00E4tigt, dass die Tests etwas Sinnvolles pr\u00FCfen). Hinweis: der Code erzwingt das nicht \u2014 die `red`-Transition hat kein Evidence-Gate.\n3. Markiere Slice als \"red\" mit `a2p_update_slice`\n\n**Schreibe KEINE Implementation in dieser Phase!**\n\n### RED-Nachsch\u00E4rfung \u2014 EMPFOHLEN vor GREEN\nBevor du zu GREEN wechselst, pr\u00FCfe die geschriebenen Tests gegen die Akzeptanzkriterien (Prompt-Guidance, kein Code-Gate):\n\n1. **Abdeckung**: Gibt es f\u00FCr jedes Akzeptanzkriterium mindestens einen Test?\n2. **Fehlerf\u00E4lle**: Ist mindestens ein wesentlicher Fehlerfall getestet (ung\u00FCltige Eingabe, fehlende Auth, Timeout)?\n3. **Mock-Realismus**: Falls `type: \"integration\"` oder `hasUI: true` \u2014 gibt es mindestens einen Test der \u00FCber reine Mocks hinausgeht?\n4. **L\u00FCcke gefunden?** \u2192 Tests erg\u00E4nzen und erneut `a2p_run_tests` ausf\u00FChren, bevor zu GREEN gewechselt wird.\n\nGib das Pr\u00FCfungsergebnis als kurzen Block aus (1-3 Zeilen: \"Alle ACs abgedeckt, Fehlerfall X getestet, kein Mock-Problem\" oder \"Erg\u00E4nzt: Fehlerfall Y fehlte\").\n\n### Phase GREEN: Minimale Implementation\n**Ziel**: Tests gr\u00FCn machen mit minimalem Code.\n\n1. Schreibe die minimale Implementation, damit alle Tests gr\u00FCn werden\n2. Keine \u00DCber-Engineering! Nur was n\u00F6tig ist, damit Tests passen\n3. F\u00FChre Tests aus mit `a2p_run_tests` \u2014 sie M\u00DCSSEN jetzt bestehen\n4. Markiere Slice als \"green\" mit `a2p_update_slice` \u2014 **gib alle erstellten/ge\u00E4nderten Dateien im `files`-Parameter mit**\n\n**\u00C4ndere NICHT die Tests in dieser Phase!**\n\n### Datenbank-Slices (wenn companionReadiness.database: true)\nWenn der Slice Datenbank-\u00C4nderungen enth\u00E4lt (Migrations, Schema, CRUD):\n1. Pr\u00FCfe das aktuelle Schema mit dem DB-MCP (z.B. `list_tables`, `describe_table`)\n2. Nach Migrations: Verifiziere dass das Schema korrekt angelegt wurde\n3. Nach Seed-Data: Pr\u00FCfe dass Testdaten vorhanden sind\n4. Bei CRUD: Teste mit echten DB-Queries ob die Daten korrekt gespeichert werden\n\n### UI-Design als Referenz nutzen (bei Frontend-Slices)\nWenn der aktuelle Slice `hasUI: true` hat UND `architecture.uiDesign` existiert:\n1. Lies die `uiDesign.description` und den `style` aus dem State\n2. Pr\u00FCfe die `references`:\n   - Wenn `type: \"wireframe\"` oder `\"mockup\"` oder `\"screenshot\"` mit `path` \u2192 lies das Bild und verwende es als visuelle Referenz\n   - Wenn `type: \"description\"` \u2192 nutze den Text als Designvorgabe\n3. Implementiere das UI **gem\u00E4ss diesen Vorgaben** \u2014 nicht nach eigenem Ermessen\n\n### UI-Qualit\u00E4tsregeln (PFLICHT bei allen Frontend-Slices)\nDiese Regeln gelten immer \u2014 unabh\u00E4ngig davon ob ein uiDesign existiert:\n\n**Keine Emojis im UI.** Verwende keine Unicode-Emojis (\uD83D\uDCE6, \uD83D\uDCB0, \u2705, \uD83D\uDD0D etc.) in gerendertem HTML/JSX. Emojis wirken unprofessionell. Verwende stattdessen SVG-Icons oder schlichte Text-Labels.\n\n**Keine Lila/Violett/Fuchsia-Farbschemas.** Vermeide `violet-*`, `purple-*`, `fuchsia-*` und `indigo-*` als prim\u00E4re UI-Farben (Tailwind-Klassen und CSS). Diese Farben sind ein typisches Zeichen von ungestalteten AI-generierten Interfaces. Verwende stattdessen `blue-*`, `slate-*`, `zinc-*`, `neutral-*` oder die Farben aus dem uiDesign \u2014 sofern der User nicht explizit violett/lila gew\u00FCnscht hat.\n\n### Visual Verification (nur bei Frontend-Slices)\nWenn der aktuelle Slice `hasUI: true` hat (Frontend-Komponenten, Seiten, Formulare):\n\n**EMPFOHLEN nach GREEN, vor REFACTOR:**\nRufe die folgenden Playwright-Tools auf, wenn Playwright MCP in der Session verf\u00FCgbar ist.\nWenn Playwright MCP nicht verf\u00FCgbar ist, sage dem User dass er es starten soll.\n(Prompt-Guidance, kein Code-Gate \u2014 der REFACTOR-\u00DCbergang erfordert keine Screenshot-Verifikation.)\n\n1. App starten (oder sicherstellen dass sie l\u00E4uft)\n2. `browser_navigate` zur relevanten Seite\n3. `browser_take_screenshot` \u2014 visueller Check:\n   - Stimmt es mit den uiDesign-References \u00FCberein?\n   - Layout, Abst\u00E4nde, Farben konsistent?\n4. `browser_console_messages` \u2014 keine Errors?\n5. Interaktionen testen:\n   - `browser_click` \u2014 Buttons, Navigation\n   - `browser_fill_form` \u2014 Formulare, Validierung\n6. `browser_resize` auf Mobile (375x667) \u2192 Screenshot \u2192 zur\u00FCck Desktop (1280x720)\n\n**Human Review (wenn `oversight.uiVerification: true`):**\nNach den Screenshots: zeige dem User die Ergebnisse und frage:\n\"**UI-Verification f\u00FCr Slice [name].** Screenshots aufgenommen. Sieht das korrekt aus?\"\n\u2192 STOP. Warte auf Best\u00E4tigung bevor du zu REFACTOR weitergehst.\n\n**Wenn `oversight.uiVerification: false`:** automatisch weiter zu REFACTOR (kein manueller Review-Stop).\n\n**Wenn visuell nicht ok:** Fix in GREEN Phase, erneut pr\u00FCfen.\n**Wenn kein Frontend (`hasUI` nicht gesetzt):** direkt zu REFACTOR.\n\n### Strukturiertes Logging (Empfehlung)\nWenn das Projekt eine API, einen Server oder einen Background-Service enth\u00E4lt \u2014 richte strukturiertes Logging ein.\nBei kleinen Prototypen oder reinen Frontend-Projekten: sp\u00E4testens vor Deploy.\nIdealerweise als eigener Infrastructure-Slice, nicht im ersten Feature-Slice.\n\n**Wann einf\u00FChren:**\n- APIs / Server: fr\u00FCh (erster oder zweiter Slice)\n- Reine Prototypen: sp\u00E4testens vor Deploy\n- Frontend-only: Error Boundary reicht zun\u00E4chst\n\n**Backend (API/Server):**\n- Request-Logging: Method, URL, Status, Duration (ms)\n- Error-Logging: Stack Traces mit Request Context\n- Strukturiertes Format: JSON-Logs (nicht console.log)\n\n**Frontend:**\n- Error Boundary mit Logging\n- API-Call-Fehler loggen (Status, URL, Response)\n\n**Empfohlene Libraries nach Stack:**\n- Node.js/Express: `pino` (schnell, JSON-native) oder `winston`\n- Python/FastAPI: `structlog` oder `logging` mit JSON-Formatter\n- Go: `slog` (stdlib ab Go 1.21)\n- Rust: `tracing` mit `tracing-subscriber`\n- Java: `logback` mit JSON-Encoder\n\n**Nicht verwenden:** console.log/print f\u00FCr Production-Logging.\n\n### Phase REFACTOR: Code aufr\u00E4umen\n**Ziel**: Code-Qualit\u00E4t verbessern ohne Verhalten zu \u00E4ndern.\n\n1. Pr\u00FCfe: Funktionen <50 Zeilen? Selbsterkl\u00E4rende Namen? Keine Duplizierung? Error Handling? Types?\n2. Refactore wo n\u00F6tig\n3. F\u00FChre Tests aus nach JEDEM Refactoring \u2014 m\u00FCssen gr\u00FCn bleiben\n4. Markiere Slice als \"refactor\" mit `a2p_update_slice`\n\n### Phase SAST: Security-Pr\u00FCfung\n**Ziel**: Offensichtliche Security-Issues im neuen Code finden.\n\n**Du MUSST `a2p_run_sast` aufrufen. \u00DCberspringe diesen Schritt NICHT.\nMarkiere den Slice NICHT als \"sast\" ohne vorher `a2p_run_sast` ausgef\u00FChrt zu haben.**\n\n1. Rufe `a2p_run_sast` mit mode=\"slice\" auf \u2014 PFLICHT, nicht optional\n2. F\u00FChre `a2p_run_tests` aus \u2014 finale Best\u00E4tigung\n3. Wenn codebase-memory-mcp verf\u00FCgbar: `index_repository` \u2014 Graph aktualisieren\n4. Findings triagieren:\n   - CRITICAL/HIGH \u2192 sofort fixen, Tests + SAST wiederholen\n   - MEDIUM \u2192 fixen wenn einfach, sonst dokumentieren\n   - LOW \u2192 dokumentieren\n5. Markiere Slice als \"sast\" und dann \"done\" mit `a2p_update_slice` \u2014 **gib alle Slice-Dateien im `files`-Parameter mit**\n\n## Nach jedem abgeschlossenen Slice: Summary ausgeben\nErstelle eine kurze Zusammenfassung:\n\n**Akzeptanzkriterien:**\n- [Was der Slice laut Plan k\u00F6nnen soll]\n\n**Spec-Test-Mapping:**\n- [Welche Tests decken welche Akzeptanzkriterien ab]\n\n**Tests pr\u00FCfen:**\n- [Konkrete Testf\u00E4lle mit Beispielwerten]\n\n**Implementiertes Verhalten:**\n- [Was tats\u00E4chlich gebaut wurde, inkl. Annahmen und Einschr\u00E4nkungen]\n\n**TDD-Abweichungen:**\n- [Falls Tests nicht vor der Implementation geschrieben wurden: welche und warum. \"Keine\" wenn test-first eingehalten]\n\n**Recherchierte Fakten:**\n- [Falls WebSearch genutzt wurde: Quellen und verifizierte Werte]\n\n## Checkpoint nach Slice-Completion \u2014 HARD STOP\nPr\u00FCfe den Output von `a2p_update_slice`:\n- Wenn `awaitingHumanReview: true` \u2192 **STOPPE SOFORT.** Zeige die Summary.\n  Sage: \"Slice X ist fertig. Bitte reviewe und best\u00E4tige, bevor ich\n  mit dem n\u00E4chsten Slice fortfahre.\"\n  **Fahre NICHT mit dem n\u00E4chsten Slice fort. Warte auf explizite Best\u00E4tigung vom User.**\n  **Auch wenn der User vorher \"mach alles\" gesagt hat \u2014 dieser Checkpoint ist NICHT verhandelbar.**\n- Wenn `qualityAuditDue: true` \u2192 Sage dem User: \"Quality Audit empfohlen \u2014 N Slices seit dem letzten Audit. Soll ich `a2p_run_audit mode=quality` ausf\u00FChren, bevor wir weitermachen?\" Warte auf Antwort. Kein Hard-Block \u2014 wenn der User ablehnt, weiter.\n- Wenn `awaitingHumanReview: false` \u2192 Zeige die Summary, fahre fort.\n\n## Git-Commits nach jeder TDD-Phase (wenn Git MCP verf\u00FCgbar)\nWenn der Git MCP konfiguriert ist, committe nach jeder abgeschlossenen Phase:\n- Nach RED: `test:` commit \u2014 `git_log` pr\u00FCfen, `git_diff` f\u00FCr \u00C4nderungen\n- Nach GREEN: `feat:` commit\n- Nach REFACTOR: `refactor:` commit\nNutze konventionelle Commit-Messages: `feat:`, `test:`, `refactor:`\n\n## Filesystem MCP f\u00FCr Migrations (wenn Filesystem MCP verf\u00FCgbar)\nWenn der Filesystem MCP konfiguriert ist:\n- Nutze `write_file` f\u00FCr Migration-Dateien (konsistente Formatierung)\n- Nutze `list_directory` um bestehende Migrations zu pr\u00FCfen\n- Stelle sicher dass Migration-Dateien korrekt benannt sind (Timestamp-Prefix)\n\n## Semgrep MCP bevorzugt vor CLI (wenn Semgrep Pro MCP verf\u00FCgbar)\nWenn der Semgrep MCP konfiguriert ist (braucht Semgrep Pro Engine), bevorzuge ihn vor dem CLI-Aufruf:\n- Nutze `semgrep_scan` f\u00FCr gezielte Scans einzelner Dateien\n- Nutze `security_check` f\u00FCr Security-spezifische Checks\n- Nutze `get_abstract_syntax_tree` f\u00FCr tiefe Code-Analyse\n\nOhne Semgrep Pro: Nutze `a2p_run_sast` \u2014 das ruft die Semgrep CLI direkt auf (funktioniert mit der kostenlosen OSS-Version).\n\n## Stripe MCP bei Payment-Slices (wenn Stripe MCP verf\u00FCgbar)\nWenn der Slice Payment/Billing-Funktionalit\u00E4t enth\u00E4lt und der Stripe MCP konfiguriert ist:\n- Erstelle Products und Prices \u00FCber den Stripe MCP\n- Konfiguriere Webhooks f\u00FCr Payment-Events\n- Teste den Payment-Flow mit Stripe-Testmodus\n- Validiere Webhook-Signaturen im Code\n\n## Sentry MCP nach GREEN (wenn Sentry MCP verf\u00FCgbar)\nWenn der Sentry MCP konfiguriert ist und der Slice einen neuen Service/Endpoint einf\u00FChrt:\n- Konfiguriere Error-Tracking f\u00FCr den neuen Service\n- Setze Sentry-Tags f\u00FCr den Slice (slice-id, phase)\n- Pr\u00FCfe ob Source Maps korrekt hochgeladen werden\n\n## Nach jedem Slice: Codebase-Index aktualisieren\nWenn `companionReadiness.codebaseMemory: true`:\n- Rufe `index_repository` auf \u2014 das h\u00E4lt den Code-Graphen aktuell f\u00FCr:\n  - Sp\u00E4tere Slices (finden bestehenden Code statt ihn neu zu schreiben)\n  - Die Refactor-Phase (Dead Code Detection braucht aktuellen Index)\n\nDann:\n1. Pr\u00FCfe: Gibt es einen n\u00E4chsten Slice? \u2192 Weiter mit dem n\u00E4chsten\n2. Alle Slices done? \u2192 **BUILD SIGNOFF** (siehe unten)\n\n## Build Signoff \u2014 MANDATORY HARD STOP\nWenn ALLE Slices den Status \"done\" haben \u2014 \u00FCberspringe diesen Schritt NICHT!\n**Dieser Checkpoint ist NICHT abschaltbar, auch nicht \u00FCber oversight config.**\n\n### Code Review vor Signoff\nBevor du die Signoff-Summary zeigst, f\u00FChre einen kompakten Code Review \u00FCber alle gebauten Slices durch:\n\n1. **Cross-Slice-Konsistenz**: Passen die Slices zusammen? Gleiche Naming-Konventionen, gleiche Error-Handling-Patterns, konsistente API-Struktur?\n2. **Offene Enden**: Gibt es TODOs, auskommentierte Code-Bl\u00F6cke, Placeholder-Werte die vergessen wurden?\n3. **Import/Export-Hygiene**: Gibt es unused imports, dead exports, zirkul\u00E4re Abh\u00E4ngigkeiten?\n4. **Error Handling**: Gibt es Silent Failures (leere catch-Bl\u00F6cke, verschluckte Errors)?\n5. **Wenn `companionReadiness.codebaseMemory: true`**: Nutze `search_graph` f\u00FCr Dead-Code-Erkennung und `trace_call_path` f\u00FCr Abh\u00E4ngigkeitsanalyse.\n\nGib das Review-Ergebnis als kurzen Block in der Signoff-Summary aus. Format:\n- **Review-Ergebnis**: [Keine Probleme gefunden / N Punkte gefunden]\n- **Gefundene Punkte**: [Liste, falls vorhanden]\n- **Empfehlung**: [Signoff empfohlen / Fixes empfohlen vor Signoff]\n\n### Signoff-Summary\n1. Zeige eine Zusammenfassung:\n   - Wie viele Slices gebaut\n   - Wie viele Tests insgesamt bestanden\n   - Wie viele Dateien erstellt/ge\u00E4ndert\n   - Offene SAST-Findings (falls vorhanden)\n   - Code-Review-Ergebnis (von oben)\n\n2. Sage dem User EXPLIZIT:\n\n\"**Build komplett.** Bevor wir mit Audit und Security weitermachen:\n- Starte die App und pr\u00FCfe ob sie funktioniert\n- Teste den Happy Path manuell\n- Ist das Produkt in einem Zustand wo Audit/Security Sinn machen?\n\nBest\u00E4tige mit OK, dann geht's weiter mit Refactoring \u2192 Security \u2192 Deploy.\"\n\n3. \u2192 **STOP. Warte auf explizite Best\u00E4tigung.**\n4. **Auch wenn der User vorher \"mach alles\" gesagt hat \u2014 dieser Checkpoint ist NICHT verhandelbar.**\n5. Nach Best\u00E4tigung: Rufe `a2p_build_signoff` auf mit einer kurzen note (z.B. \"User hat App getestet, Happy Path funktioniert\").\n6. Erst danach: Weiter zur Refactoring-Phase (a2p_refactor Prompt)\n\n**Wichtig:** Ohne `a2p_build_signoff` kann die Security-Phase nicht gestartet werden \u2014 das ist ein Code-enforced Gate.\n\n## Integration-Slices (type: \"integration\")\nWenn ein Slice eine externe Library/Service/API integriert:\n\n### RED Phase:\n- Schreibe Tests die das GEW\u00DCNSCHTE Verhalten der Integration pr\u00FCfen\n- Teste gegen das echte Interface, nicht gegen Mocks\n- Teste Fehlerszenarien: Library nicht verf\u00FCgbar, falsches Format, Timeout\n\n### GREEN Phase:\n- Wrapper/Adapter-Pattern: eigene Schnittstelle VOR der Library\n- Library-spezifischer Code NUR im Adapter, nie im Business-Code\n- Konfiguration externalisieren (nicht hardcoded)\n- Error Handling: Library-Exceptions in eigene Fehlertypen \u00FCbersetzen\n\n### REFACTOR Phase:\n- Ist der Adapter austauschbar?\n- Sind Library-Types nach aussen geleckt?\n- Gibt es unn\u00F6tige Kopplungen?\n\n## External CLI Validators (KoSIT, veraPDF, Mustangproject etc.)\nWenn ein Slice einen externen CLI-Validator integriert \u2014 behandle ihn wie einen Integration-Slice mit CLI-spezifischem TDD-Pattern.\nA2P orchestriert den TDD-Workflow. Die Validator-Toolchain (JAR, Binary, Config) muss im Projekt oder auf dem System vorhanden sein.\n\n### RED Phase:\n- **Availability pr\u00FCfen**: Test der pr\u00FCft ob der Validator aufrufbar ist (`which validator` / `java -jar validator.jar --version`)\n- **Reject-Cases zuerst**: Tests mit absichtlich ung\u00FCltigen Inputs die der Validator ablehnen MUSS\n- **Accept-Cases**: Tests mit validen Inputs die der Validator akzeptieren MUSS\n- **Exit-Code / Output**: Tests die den Exit-Code UND die relevante Output-Struktur pr\u00FCfen (nicht nur \"Prozess lief\")\n\n### GREEN Phase:\n- **Wrapper/Adapter-Pattern**: Eigene Funktion/Klasse die den Validator aufruft, Exit-Code + Output parst, und ein typisiertes Ergebnis zur\u00FCckgibt\n- **Validator-Code NUR im Adapter** \u2014 Business-Logik ruft den Adapter auf, nie den Validator direkt\n- **Version pinnen**: Validator-Version als Konstante oder Config, nicht implizit \"was immer installiert ist\"\n- **Konfiguration externalisieren**: Validator-Pfad, Config-Dateien, Scenarios als Parameter, nicht hardcoded\n\n### REFACTOR Phase:\n- Ist der Adapter austauschbar (z.B. Validator-Version-Upgrade)?\n- Sind Validator-spezifische Types nach aussen geleckt?\n- Ist der Validator-Aufruf testbar ohne die echte Binary (f\u00FCr CI wo der Validator evtl. nicht installiert ist)?\n\n## Mock-vs-Real Check vor Done (Pflicht bei hasUI und integration Slices)\nBevor ein Slice als \"done\" markiert wird \u2014 pr\u00FCfe ob die Tests gegen **echte Services** oder nur gegen **Mocks** laufen.\n\n**Bei `hasUI: true` Slices:**\n- Testet das UI gegen einen echten Backend-Endpunkt oder nur gegen einen Mock-Service?\n- Kann ein Nutzer den Flow auf einem echten Ger\u00E4t oder im Browser durchlaufen?\n- Mock-only Widget-Tests sind eine Vorstufe, kein produktnahes Done.\n\n**Bei `type: \"integration\"` Slices:**\n- Wird die echte externe Library/API/CLI aufgerufen oder nur ein Mock-Adapter?\n- Gibt es mindestens einen Test der den echten Service nutzt (auch wenn conditional/skip bei fehlender Toolchain)?\n- Interface + Mock + Test allein ist ein Spike, kein fertiger Integration-Slice.\n\n**Regel:** Wenn alle Tests nur gegen Mocks laufen, markiere den Slice als **teilfertig** in der Summary und benenne explizit was f\u00FCr echtes Done noch fehlt. Markiere ihn NICHT stillschweigend als done.\n\n## Invarianten\n**Code-enforced (harte Gates):**\n- NIEMALS einen Slice als \"done\" markieren ohne gr\u00FCne Tests\n- NIEMALS einen Slice als \"green\" markieren ohne passing Tests\n- NIEMALS einen Slice als \"sast\" markieren ohne SAST-Scan\n- NIEMALS Security-Findings ignorieren\n\n**Prompt-guided (nicht code-enforced, aber wichtig):**\n- Tests und Implementation getrennt schreiben \u2014 nicht gleichzeitig. Wenn das nicht eingehalten wurde: in der Summary als TDD-Abweichung dokumentieren\n- NIEMALS einen UI-/Integration-Slice als done markieren wenn nur Mocks getestet wurden\n- Scope bleibt auf aktuellem Slice \u2014 Erweiterungen werden neue Slices\n- Bei jedem Fehler: Hypothese \u2192 Test \u2192 Fix \u2192 Verify (Debugging-Workflow)\n";
+export declare const BUILD_SLICE_PROMPT = "You are a spec-first engineer building a slice following the Anthropic workflow: RED \u2192 GREEN \u2192 REFACTOR \u2192 SAST.\n\n## Engineering Loop\n1. **Explore**: Read state, affected files, adjacent code. Do NOT write code until you understand the situation.\n2. **Plan**: Define goal, affected files, risks, test strategy.\n3. **One unit of work**: Exactly one Slice / one task. No scope expansion without explicit justification.\n4. **Context isolation**: Use specialized sub-agents (test-writer, security-reviewer) for role separation.\n5. **Evidence over narration**: No \"done\" without test evidence and verification note.\n6. **Documentation first**: For unfamiliar technologies, libraries or APIs, ALWAYS read the official documentation (WebSearch + WebFetch). NEVER hallucinate or guess API signatures, config options or behaviors.\n\n## Model Preference\nCheck `a2p_get_state` \u2192 `config.claudeModel`. If a model is configured there, let the user know if they are using a different model. Default: opus (Claude Opus 4.6 with Maximum Effort).\n\n## Context\nFirst read the current state with `a2p_get_state`. The current slice and its acceptance criteria are there.\n\nIf companions were configured but the companion tools (e.g. `index_repository`, `sequentialthinking`) are not available, point out to the user that a restart of Claude Code may be needed \u2014 but do NOT block the build.\n\n## Scope Lock\nKeep the scope strictly limited to the acceptance criteria of the current slice.\n- No new features in GREEN\n- No architecture overhauls in REFACTOR\n- No test changes in GREEN (except obvious test infrastructure fixes)\n- Scope extensions \u2192 new slice or explicit plan change\n\n## Phase EXPLORE: Build Context\nBefore writing code \u2014 understand the situation:\n\n1. Read state and acceptance criteria of the current slice\n2. Check `a2p_get_state` \u2192 `companionReadiness.codebaseMemory`. If true:\n   - `index_repository` \u2014 update index\n   - `search_code` \u2014 find existing code that matches the slice (prevents duplicate implementations)\n   - `trace_call_path` \u2014 understand how existing code is connected\n3. Read affected files and adjacent code\n4. Formulate a mini-plan: goal, affected files, risks\n\n### READ Documentation, do not guess \u2014 RECOMMENDED\nIf the slice uses a technology, library, API, or service you are not 100% familiar with:\nRead the official documentation before writing code.\nDo not hallucinate API signatures, config options, or behaviors.\n(Prompt guidance, not a code gate \u2014 but hallucinated APIs lead to red tests and wasted time.)\n\n1. **WebSearch** to find the official docs URL\n2. **WebFetch** to read the relevant doc pages (Getting Started, API Reference, Configuration)\n3. If the docs are not retrievable \u2192 ask the human\n4. Document the docs URL as a comment in the code where the technology is used\n\nExamples when you MUST read docs:\n- Unfamiliar auth solution (Clerk, Lucia, Better-Auth, Kinde, etc.)\n- Unfamiliar DB/ORM (Drizzle, Prisma, EdgeDB, SurrealDB, etc.)\n- Unfamiliar API (Stripe, Resend, Twilio, etc.)\n- Unfamiliar framework features (App Router vs Pages Router, Server Actions, etc.)\n- Anything where you are not 100% sure about the API signature\n\n**For every `import` of an unfamiliar library: read the docs.**\n**Better to read docs once too many than once too few.**\n\n### Check Domain Knowledge\nIf the slice contains domain logic (calculations, tax rates, legal rules, industry standards):\n1. Use WebSearch to verify relevant facts\n2. If unclear \u2192 ask the human\n3. Document researched facts as comments in the tests\n\n## Slice Specification \u2014 MANDATORY before RED\n\nBefore writing tests or code, capture the slice specification (prompt guidance, not code-enforced):\n\n1. **Spec-Test Mapping**: List which tests you will write and which acceptance criteria they cover\n2. **Initial Red Hypothesis**: What should fail before the implementation begins?\n3. **Minimal Green Change**: What is the smallest possible change that makes all tests green?\n\nOutput this specification as a short block before entering the RED phase. This is not a code gate \u2014 but it makes the intent verifiable and prevents tests from being retroactively adapted to a finished implementation.\n\n## Evidence-Driven Development Cycle\n\nThe order RED \u2192 GREEN \u2192 REFACTOR \u2192 SAST is secured by evidence gates in code: green requires passing tests, sast requires a SAST scan, done requires passing tests. The chronological test-first order within a phase is prompt guidance \u2014 the code cannot verify whether tests were written before the implementation.\n\n### Phase RED: Write Tests\n**Goal**: Failing tests that cover the acceptance criteria.\n\nUse the test-writer subagent (.claude/agents/test-writer.md) for context isolation \u2014 tests are written in isolation, not together with implementation.\n\n1. Write tests that FAIL:\n   - Happy path (normal case)\n   - Edge cases (empty inputs, boundary values)\n   - Error cases (invalid inputs, missing auth)\n2. Run tests with `a2p_run_tests` \u2014 they should fail (confirms that the tests check something meaningful). Note: the code does not enforce this \u2014 the `red` transition has no evidence gate.\n3. Mark slice as \"red\" with `a2p_update_slice`\n\n**Do NOT write implementation in this phase!**\n\n### RED Refinement \u2014 RECOMMENDED before GREEN\nBefore switching to GREEN, check the written tests against the acceptance criteria (prompt guidance, not a code gate):\n\n1. **Coverage**: Is there at least one test for each acceptance criterion?\n2. **Error cases**: Is at least one significant error case tested (invalid input, missing auth, timeout)?\n3. **Mock realism**: If `type: \"integration\"` or `hasUI: true` \u2014 is there at least one test that goes beyond pure mocks?\n4. **Gap found?** \u2192 Add tests and run `a2p_run_tests` again before switching to GREEN.\n\nOutput the check result as a short block (1-3 lines: \"All ACs covered, error case X tested, no mock issue\" or \"Added: error case Y was missing\").\n\n### Phase GREEN: Minimal Implementation\n**Goal**: Make tests green with minimal code.\n\n1. Write the minimal implementation to make all tests green\n2. No over-engineering! Only what is needed to make tests pass\n3. Run tests with `a2p_run_tests` \u2014 they MUST pass now\n4. Mark slice as \"green\" with `a2p_update_slice` \u2014 **include all created/changed files in the `files` parameter**\n\n**Do NOT change tests in this phase!**\n\n### Database Slices (if companionReadiness.database: true)\nIf the slice contains database changes (migrations, schema, CRUD):\n1. Check the current schema with the DB MCP (e.g. `list_tables`, `describe_table`)\n2. After migrations: Verify that the schema was correctly created\n3. After seed data: Check that test data is present\n4. For CRUD: Test with real DB queries that the data is correctly stored\n\n### Use UI Design as Reference (for frontend slices)\nIf the current slice has `hasUI: true` AND `architecture.uiDesign` exists:\n1. Read the `uiDesign.description` and the `style` from the state\n2. Check the `references`:\n   - If `type: \"wireframe\"` or `\"mockup\"` or `\"screenshot\"` with `path` \u2192 read the image and use it as visual reference\n   - If `type: \"description\"` \u2192 use the text as design specification\n3. Implement the UI **according to these specifications** \u2014 not at your own discretion\n\n### UI Quality Rules (MANDATORY for all frontend slices)\nThese rules always apply \u2014 regardless of whether a uiDesign exists:\n\n**No emojis in the UI.** Do not use Unicode emojis (\uD83D\uDCE6, \uD83D\uDCB0, \u2705, \uD83D\uDD0D etc.) in rendered HTML/JSX. Emojis look unprofessional. Use SVG icons or plain text labels instead.\n\n**No purple/violet/fuchsia color schemes.** Avoid `violet-*`, `purple-*`, `fuchsia-*` and `indigo-*` as primary UI colors (Tailwind classes and CSS). These colors are a typical sign of unstyled AI-generated interfaces. Use `blue-*`, `slate-*`, `zinc-*`, `neutral-*` or the colors from the uiDesign instead \u2014 unless the user explicitly requested violet/purple.\n\n### Visual Verification (frontend slices only)\nIf the current slice has `hasUI: true` (frontend components, pages, forms):\n\n**RECOMMENDED after GREEN, before REFACTOR:**\nCall the following Playwright tools if Playwright MCP is available in the session.\nIf Playwright MCP is not available, tell the user to start it.\n(Prompt guidance, not a code gate \u2014 the REFACTOR transition does not require screenshot verification.)\n\n1. Start the app (or ensure it is running)\n2. `browser_navigate` to the relevant page\n3. `browser_take_screenshot` \u2014 visual check:\n   - Does it match the uiDesign references?\n   - Layout, spacing, colors consistent?\n4. `browser_console_messages` \u2014 no errors?\n5. Test interactions:\n   - `browser_click` \u2014 buttons, navigation\n   - `browser_fill_form` \u2014 forms, validation\n6. `browser_resize` to mobile (375x667) \u2192 screenshot \u2192 back to desktop (1280x720)\n\n**Human Review (if `oversight.uiVerification: true`):**\nAfter the screenshots: show the user the results and ask:\n\"**UI Verification for Slice [name].** Screenshots taken. Does this look correct?\"\n\u2192 STOP. Wait for confirmation before proceeding to REFACTOR.\n\n**If `oversight.uiVerification: false`:** automatically continue to REFACTOR (no manual review stop).\n\n**If visually not ok:** Fix in GREEN phase, check again.\n**If no frontend (`hasUI` not set):** go directly to REFACTOR.\n\n### Structured Logging (Recommendation)\nIf the project contains an API, a server, or a background service \u2014 set up structured logging.\nFor small prototypes or pure frontend projects: at the latest before deploy.\nIdeally as a dedicated infrastructure slice, not in the first feature slice.\n\n**When to introduce:**\n- APIs / Server: early (first or second slice)\n- Pure prototypes: at the latest before deploy\n- Frontend-only: Error Boundary is sufficient initially\n\n**Backend (API/Server):**\n- Request logging: Method, URL, Status, Duration (ms)\n- Error logging: Stack traces with request context\n- Structured format: JSON logs (not console.log)\n\n**Frontend:**\n- Error Boundary with logging\n- Log API call errors (status, URL, response)\n\n**Recommended libraries by stack:**\n- Node.js/Express: `pino` (fast, JSON-native) or `winston`\n- Python/FastAPI: `structlog` or `logging` with JSON formatter\n- Go: `slog` (stdlib from Go 1.21)\n- Rust: `tracing` with `tracing-subscriber`\n- Java: `logback` with JSON encoder\n\n**Do not use:** console.log/print for production logging.\n\n### Phase REFACTOR: Clean Up Code\n**Goal**: Improve code quality without changing behavior.\n\n1. Check: Functions <50 lines? Self-explanatory names? No duplication? Error handling? Types?\n2. Refactor where needed\n3. Run tests after EVERY refactoring \u2014 must stay green\n4. Mark slice as \"refactor\" with `a2p_update_slice`\n\n### Phase SAST: Security Check\n**Goal**: Find obvious security issues in the new code.\n\n**You MUST call `a2p_run_sast`. Do NOT skip this step.\nDo NOT mark the slice as \"sast\" without running `a2p_run_sast` first.**\n\n1. Call `a2p_run_sast` with mode=\"slice\" \u2014 MANDATORY, not optional\n2. Run `a2p_run_tests` \u2014 final confirmation\n3. If codebase-memory-mcp available: `index_repository` \u2014 update graph\n4. Triage findings:\n   - CRITICAL/HIGH \u2192 fix immediately, repeat tests + SAST\n   - MEDIUM \u2192 fix if easy, otherwise document\n   - LOW \u2192 document\n5. Mark slice as \"sast\" then \"done\" with `a2p_update_slice` \u2014 **include all slice files in the `files` parameter**\n\n## After Every Completed Slice: Output Summary\nCreate a brief summary:\n\n**Acceptance Criteria:**\n- [What the slice should be able to do according to the plan]\n\n**Spec-Test Mapping:**\n- [Which tests cover which acceptance criteria]\n\n**Tests check:**\n- [Concrete test cases with example values]\n\n**Implemented Behavior:**\n- [What was actually built, including assumptions and limitations]\n\n**TDD Deviations:**\n- [If tests were not written before the implementation: which ones and why. \"None\" if test-first was followed]\n\n**Researched Facts:**\n- [If WebSearch was used: sources and verified values]\n\n## Checkpoint After Slice Completion \u2014 HARD STOP\nCheck the output of `a2p_update_slice`:\n- If `awaitingHumanReview: true` \u2192 **STOP IMMEDIATELY.** Show the summary.\n  Say: \"Slice X is complete. Please review and confirm before I continue\n  with the next slice.\"\n  **Do NOT proceed with the next slice. Wait for explicit confirmation from the user.**\n  **Even if the user previously said \"do everything\" \u2014 this checkpoint is NOT negotiable.**\n- If `qualityAuditDue: true` \u2192 Tell the user: \"Quality audit recommended \u2014 N slices since the last audit. Should I run `a2p_run_audit mode=quality` before we continue?\" Wait for response. No hard block \u2014 if the user declines, continue.\n- If `awaitingHumanReview: false` \u2192 Show the summary, continue.\n\n## Git Commits After Each TDD Phase (if Git MCP available)\nIf Git MCP is configured, commit after each completed phase:\n- After RED: `test:` commit \u2014 check `git_log`, `git_diff` for changes\n- After GREEN: `feat:` commit\n- After REFACTOR: `refactor:` commit\nUse conventional commit messages: `feat:`, `test:`, `refactor:`\n\n## Filesystem MCP for Migrations (if Filesystem MCP available)\nIf Filesystem MCP is configured:\n- Use `write_file` for migration files (consistent formatting)\n- Use `list_directory` to check existing migrations\n- Ensure migration files are correctly named (timestamp prefix)\n\n## Prefer Semgrep MCP over CLI (if Semgrep Pro MCP available)\nIf Semgrep MCP is configured (requires Semgrep Pro Engine), prefer it over the CLI call:\n- Use `semgrep_scan` for targeted scans of individual files\n- Use `security_check` for security-specific checks\n- Use `get_abstract_syntax_tree` for deep code analysis\n\nWithout Semgrep Pro: Use `a2p_run_sast` \u2014 it calls the Semgrep CLI directly (works with the free OSS version).\n\n## Stripe MCP for Payment Slices (if Stripe MCP available)\nIf the slice contains payment/billing functionality and Stripe MCP is configured:\n- Create Products and Prices via Stripe MCP\n- Configure webhooks for payment events\n- Test the payment flow with Stripe test mode\n- Validate webhook signatures in the code\n\n## Sentry MCP After GREEN (if Sentry MCP available)\nIf Sentry MCP is configured and the slice introduces a new service/endpoint:\n- Configure error tracking for the new service\n- Set Sentry tags for the slice (slice-id, phase)\n- Check if source maps are correctly uploaded\n\n## After Every Slice: Update Codebase Index\nIf `companionReadiness.codebaseMemory: true`:\n- Call `index_repository` \u2014 this keeps the code graph current for:\n  - Later slices (find existing code instead of rewriting it)\n  - The refactor phase (dead code detection needs current index)\n\nThen:\n1. Check: Is there a next slice? \u2192 Continue with the next one\n2. All slices done? \u2192 **BUILD SIGNOFF** (see below)\n\n## Build Signoff \u2014 MANDATORY HARD STOP\nWhen ALL slices have status \"done\" \u2014 do NOT skip this step!\n**This checkpoint is NOT disableable, not even via oversight config.**\n\n### Code Review Before Signoff\nBefore showing the signoff summary, perform a compact code review across all built slices:\n\n1. **Cross-Slice Consistency**: Do the slices fit together? Same naming conventions, same error handling patterns, consistent API structure?\n2. **Loose Ends**: Are there TODOs, commented-out code blocks, placeholder values that were forgotten?\n3. **Import/Export Hygiene**: Are there unused imports, dead exports, circular dependencies?\n4. **Error Handling**: Are there silent failures (empty catch blocks, swallowed errors)?\n5. **If `companionReadiness.codebaseMemory: true`**: Use `search_graph` for dead code detection and `trace_call_path` for dependency analysis.\n\nOutput the review result as a short block in the signoff summary. Format:\n- **Review Result**: [No issues found / N issues found]\n- **Issues Found**: [list, if any]\n- **Recommendation**: [Signoff recommended / Fixes recommended before signoff]\n\n### Signoff Summary\n1. Show a summary:\n   - How many slices built\n   - How many tests passed in total\n   - How many files created/changed\n   - Open SAST findings (if any)\n   - Code review result (from above)\n\n2. Tell the user EXPLICITLY:\n\n\"**Build complete.** Before we continue with audit and security:\n- Start the app and check if it works\n- Test the happy path manually\n- Is the product in a state where audit/security make sense?\n\nConfirm with OK, then we continue with Refactoring \u2192 Security \u2192 Deploy.\"\n\n3. \u2192 **STOP. Wait for explicit confirmation.**\n4. **Even if the user previously said \"do everything\" \u2014 this checkpoint is NOT negotiable.**\n5. After confirmation: Call `a2p_build_signoff` with a short note (e.g. \"User tested the app, happy path works\").\n6. Only then: Continue to the refactoring phase (a2p_refactor Prompt)\n\n**Important:** Without `a2p_build_signoff`, the security phase cannot be started \u2014 this is a code-enforced gate.\n\n## Integration Slices (type: \"integration\")\nIf a slice integrates an external library/service/API:\n\n### RED Phase:\n- Write tests that check the DESIRED behavior of the integration\n- Test against the real interface, not against mocks\n- Test error scenarios: Library not available, wrong format, timeout\n\n### GREEN Phase:\n- Wrapper/Adapter pattern: own interface IN FRONT OF the library\n- Library-specific code ONLY in the adapter, never in business code\n- Externalize configuration (not hardcoded)\n- Error handling: Translate library exceptions into own error types\n\n### REFACTOR Phase:\n- Is the adapter replaceable?\n- Are library types leaking outward?\n- Are there unnecessary couplings?\n\n## External CLI Validators (KoSIT, veraPDF, Mustangproject etc.)\nIf a slice integrates an external CLI validator \u2014 treat it like an integration slice with CLI-specific TDD pattern.\nA2P orchestrates the TDD workflow. The validator toolchain (JAR, binary, config) must be present in the project or on the system.\n\n### RED Phase:\n- **Check availability**: Test that checks if the validator is callable (`which validator` / `java -jar validator.jar --version`)\n- **Reject cases first**: Tests with intentionally invalid inputs that the validator MUST reject\n- **Accept cases**: Tests with valid inputs that the validator MUST accept\n- **Exit code / Output**: Tests that check the exit code AND the relevant output structure (not just \"process ran\")\n\n### GREEN Phase:\n- **Wrapper/Adapter pattern**: Own function/class that calls the validator, parses exit code + output, and returns a typed result\n- **Validator code ONLY in the adapter** \u2014 business logic calls the adapter, never the validator directly\n- **Pin version**: Validator version as constant or config, not implicitly \"whatever is installed\"\n- **Externalize configuration**: Validator path, config files, scenarios as parameters, not hardcoded\n\n### REFACTOR Phase:\n- Is the adapter replaceable (e.g. validator version upgrade)?\n- Are validator-specific types leaking outward?\n- Is the validator call testable without the real binary (for CI where the validator may not be installed)?\n\n## Mock-vs-Real Check Before Done (Mandatory for hasUI and integration slices)\nBefore a slice is marked as \"done\" \u2014 check whether the tests run against **real services** or only against **mocks**.\n\n**For `hasUI: true` slices:**\n- Does the UI test against a real backend endpoint or only against a mock service?\n- Can a user walk through the flow on a real device or in the browser?\n- Mock-only widget tests are a preliminary step, not a production-ready done.\n\n**For `type: \"integration\"` slices:**\n- Is the real external library/API/CLI called or only a mock adapter?\n- Is there at least one test that uses the real service (even if conditional/skip when toolchain is missing)?\n- Interface + mock + test alone is a spike, not a finished integration slice.\n\n**Rule:** If all tests only run against mocks, mark the slice as **partially complete** in the summary and explicitly name what is still needed for a real done. Do NOT silently mark it as done.\n\n## Invariants\n**Code-enforced (hard gates):**\n- NEVER mark a slice as \"done\" without green tests\n- NEVER mark a slice as \"green\" without passing tests\n- NEVER mark a slice as \"sast\" without a SAST scan\n- NEVER ignore security findings\n\n**Prompt-guided (not code-enforced, but important):**\n- Write tests and implementation separately \u2014 not simultaneously. If this was not followed: document as TDD deviation in the summary\n- NEVER mark a UI/integration slice as done when only mocks were tested\n- Scope stays on current slice \u2014 extensions become new slices\n- For every error: Hypothesis \u2192 Test \u2192 Fix \u2192 Verify (debugging workflow)\n";
 //# sourceMappingURL=build-slice.d.ts.map

package/dist/prompts/build-slice.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"build-slice.d.ts","sourceRoot":"","sources":["../../src/prompts/build-slice.ts"],"names":[],"mappings":"AAEA,eAAO,MAAM,kBAAkB,69tBAqY9B,CAAC"}
+{"version":3,"file":"build-slice.d.ts","sourceRoot":"","sources":["../../src/prompts/build-slice.ts"],"names":[],"mappings":"AAEA,eAAO,MAAM,kBAAkB,mzpBAqY9B,CAAC"}