BernhardJackiewicz/architect-to-product

# A2P — Architect-to-Product AI 工程框架，以 MCP 服务器形式交付。将 AI 生成的代码转化为生产级软件。 ## A2P v2 — 证据约束的 AI 系统工程 v2 层将 AI 交付的代码视为工程师对待系统的方式：十三个 **系统工程关注点**（data_model、invariants、state_machine、api_contracts、auth_permissions、failure_modes、 observability、performance_under_load、migrations、 concurrency_idempotency、distributed_state、cache_invalidation、security） 必须在每个硬化工件（需求、测试、计划、完成评审）处提供证据后，片段才能达到 `ready_for_red` 或 `done`。适用性是确定性的。状态管理器在代码中强制执行这些门控——不是仅靠提示清单。 v2.0.2（当前）新增 `codebase-memory-mcp` 作为 **必需配套**：没有它，`planning → building` 转换会被阻塞，因此每个片段探索都必须基于符号图谱而非 bash grep。 ### A2P v1 — 证据约束的 AI 交付（基础） 在验证系统工程关注点之前，需要验证交付：测试存在、编写优先、通过新鲜 SAST 测试、验收标准确实满足。v1 的硬化三联（需求 → 测试 → 计划）、测试优先防护、完成评审循环、安全门控、备份策略与 SSL 验证仍然有效——v2 是严格叠加的，且状态文件在首次读取时透明地将 v1 迁移到 v2。 若希望同时获得交付纪律与系统严谨性，请使用 v2。若片段范围足够窄而不适用 13 个关注点，则使用 v1 流（默认行为）。 **37 个 MCP 工具 · 1473 个测试 · 狗食验证通过（153/158 评分卡，50/50 对抗样本）· 架构 → 计划 → 构建 → 审计 → 安全 → 部署** [](https://www.npmjs.com/package/architect-to-product) [](LICENSE) [](docs/validation/) [-blue)](#dogfood-validation) [](tsconfig.json) **最佳适用场景：** 使用 Claude Code、Cursor 或其他 MCP 客户端、希望在 AI 速度的同时具备测试、安全与部署纪律的开发人员——无论是从零构建还是硬化 vibe-coded MVP。 📖 [入门指南](#quickstart) · [工作流](docs/WORKFLOW.md) · [安全](docs/SECURITY.md) · [参考](docs/REFERENCE.md) · [部署（Hetzner / VPS）](docs/HETZNER-DEPLOYMENT.md) ## 快速开始 ``` npx architect-to-product init ``` 这会在项目中创建 `.mcp.json`。然后重启 Claude Code 并运行： ``` /a2p ``` A2P 从两条新手引导路径开始： 1. **讨论你的想法** —— 适合 vibe 编码者。A2P 提出结构化问题并与你协同设计架构。 2. **粘贴你的架构** —— 适合已有架构的工程师。粘贴架构后，A2P 进行分析并开始构建。此路径针对速度优化。 ## A2P 是什么 A2P 是一个以 MCP 服务器形式打包的 AI 工程框架。 它为 AI 辅助软件开发增加了工程纪律：架构驱动的计划、证据约束的 TDD、安全审查、备份策略与部署生成。 一句话总结：**A2P 是一个 AI 工程框架，以 MCP 服务器形式存在，用于将 AI 生成的代码转化为生产就绪软件。** ## 工作原理 A2P 通过一个有门控的生命周期驱动软件开发： **架构 → 计划 → 构建 → 审计 → 安全 → 部署** 在构建阶段，每个功能（称为“片段”）都会经历 **原生流程**——每一步都由代码强制执行，每个门控背后都有具体的工具调用： **需求硬化 → 测试硬化 → 计划硬化（1–3 轮对抗 + 最终化）→ ready_for_red → 测试优先防护 → RED → GREEN → REFACTOR → SAST → 完成评审循环 → DONE** 这意味着： - 验收准则、测试矩阵与实现计划在代码编写前就作为结构化工件捕获，并在每次变更时级联失效。 - 测试优先防护（`a2p_verify_test_first`）将工作区与基准提交或文件哈希快照进行差异分类，要求至少触碰 1 个测试文件、0 个生产文件，并且测试运行失败——否则片段无法达到 RED。 - 完成评审循环（`a2p_completion_review`）在 SAST 后运行，自动扫描差异中的 stub 信号，将实现与 `finalPlan.expectedFiles` 和 `interfacesToChange` 进行差异校验，并强制执行结果一致性：任何未“满足”的 AC、未“深度”的覆盖率、未“ok”的计划合规性或未经解释的 stub 信号都会导致 NOT_COMPLETE，并将片段回退到 `completion_fix` 并刷新基准。 - **状态转换在代码中强制执行，而非仅由提示描述。** AI 代理无法跳过门控。如果尝试在未满足条件时推进，状态机会抛出错误并指向缺失的工具调用。唯一的例外是每个项目一次性的 **引导片段**（标记为 `bootstrap: true`），它运行旧版流程，仅用于 A2P 自身的自我重建。 ### 生命周期概览 ``` onboarding → planning → building → security → deployment → complete ↑ ↓ ↑ ↓ └── refactoring ←───┘ (re-entry: full ↓ security cycle e2e_testing required again) ``` → 完整生命周期、门控与重新进入规则：[docs/WORKFLOW.md](docs/WORKFLOW.md) ## 为何 A2P 存在 AI 编码代理很快，但容易跳过纪律： - 它们在测试之前编写代码 - 在证据不足的情况下标记工作为“完成” - 抑制错误而非修复根本原因 - 对安全、备份与部署硬化投入不足 A2P 在代理周围补充了缺失的工程系统。 ## 核心能力 - **证据约束的开发** — 片段推进通过测试与工作流证据强制执行；没有通过的测试就无法继续。 - **架构驱动的计划** — 工作被分解为有序的垂直片段，而非即兴任务生成。 - **内建安全审查** — 包含 SAST（Semgrep + Bandit）、针对可利用性的白盒审查，以及可选的对抗运行时测试（Shake & Break）。 - **关键门控的人工监督** — 构建签名与部署批准为强制步骤；其余检查点可配置。 - **感知备份的部署** — 有状态系统在满足备份要求前禁止部署。 - **SSL/HTTPS 强制** — 部署在完成前必须验证已签发的 SSL 证书与自动续期；Caddy 自动处理 Let's Encrypt；PaaS 平台自动处理 SSL。 - **密钥管理** — 4 级密钥管理（env 文件、Docker Swarm、Infisical、外部）在部署配置生成前由代码强制执行。 - **前端美学强制** — 所有 UI 片段遵循 Anthropic 的前端美学指南：独特的排版、协调的配色方案、动效与氛围化背景。明确禁止通用 AI 美学（Inter 字体、紫色渐变、Cookie-cutter 布局）。 - **部署生成** — 生成特定栈的 Dockerfile、docker-compose、Caddyfile 以及备份/恢复/验证脚本与加固指南。 - **代码智能** — `codebase-memory-mcp` 构建代码图谱而非原始扫描文件，最多减少 100 倍探索令牌。 - **结构化构建历史** — 工具运行、状态、耗时与发现被记录在可查询的构建日志中，并进行密钥脱敏。 ## 常见使用场景 ### 1. 从第一天起使用防护栏启动新项目 从第一天起使用 A2P 定义架构、规划片段、构建时采用 TDD 并生成部署工件。 ``` /a2p → /a2p_planning → /a2p_build_slice (repeat per slice) → /a2p_audit → /a2p_security_gate → /a2p_whitebox → /a2p_audit (release) → /a2p_deploy ``` ### 2. 硬化 vibe-coded MVP 直接进入安全、审计、重构与部署准备阶段——无需片段。 ``` /a2p → set architecture → transition to security /a2p_security_gate → /a2p_whitebox → /a2p_refactor → /a2p_deploy ``` ### 3. 重新扫描以准备发布 从部署或完成阶段切换回安全阶段；之前的批准会自动失效，必须重新满足完整安全周期。 ``` security re-entry → /a2p_security_gate → /a2p_whitebox → /a2p_deploy ``` ## 与不使用 A2P 的对比 | 无 A2P | 使用 A2P | |---|---| | 临时性的 AI 编码 | 架构驱动的垂直片段 | | 测试可选 | 证据约束的 TDD（代码中强制执行） | | 安全为手动或后期 | SAST + 白盒 + 可选的对运行时测试 | | 部署即兴编排 | 特定栈配置、备份/恢复脚本与加固指南 | | 备份为事后想法 | 从栈推断备份策略并强制执行门控 | | SSL “以后再加” | 部署完成前验证 SSL/HTTPS，自动续期确认 | | 密钥保存在 .env，可能被提交 | 4 级密钥管理在部署前强制执行 | | “完成”为主观判断 | 门控在代码中强制执行，而非仅靠提示 | | 无构建历史 | 结构化构建日志，含层级、耗时与运行关联 | ## 验证 A2P 在整个流水线中包含主动声明的验证。 - **阶段 A/B**：工作流、状态管理与门控强制执行（96 个 QuickBill 场景） - **阶段 C**：通过 Playwright 对运行中的 Next.js 应用进行真实 UI 测试（8 个浏览器测试） - **阶段 D/E**：部署目标现实检查与配套工具数量验证 - README 声明被主动追踪、修正并与实际行为对比 → 完整验证结果：[docs/validation/](docs/validation/) ### 狗食验证 A2P 的原生流程已在受控沙箱中对其自身进行端到端验证，使用隐藏的 adversarial 测试套件与独立观察者评分。 | 指标 | 运行 1 | 运行 2（修复后） | |---|---|---| | 隐藏对抗样本 | 50/50（100%） | 43/44（98%） | | 评分卡总分（严格） | 146/158（92.4%） | 153/158（97%） | | 门控合规性（每片段 10 项检查） | 每片段 10/10 | 每片段 10/10 | | Schublade-2 陷阱类捕获 | 6/6 | 5/6 清洁 + 1 部分 | | 代理击败参考实现 | 3/6 场景 | — | **6 个场景测试**：纯函数（除法）、HTTP 集成（Webhook）、日期解析（10 个边界情况）、带中止的重试（计划深度批判）、中位数（语义正确性陷阱）、平凡常量（过度工程陷阱）。 **关键发现**：硬化三联（需求 → 测试 → 计划）是承重结构，而非礼仪。代理持续预见了参考实现中缺失的边缘情况，包括 IEEE-754 符号零语义、中止延迟竞争、年 0 的 `Date.UTC` 怪癖，以及偶数长度中位数陷阱。A2P 对 [docs/QUALITY-IMPACT.md](docs/QUALITY-IMPACT.md) 中 40–60% Schublade-2 改进预估的支持度接近观察值 60–70%。 **真实世界试验**：一个片段（德语电话号码标准化器）通过完整原生流程在 Handwerk CRM 代码库（121 个现有片段）上构建。计划硬化第 1–2 轮在编写任何代码前发现了两个真实算法错误：加号剥离的运算顺序错误和奥地利区号 0043 的误分类。 → 完整的狗食工件：`a2p-dogfood/OBSERVATIONS-SUMMARY.md`，每个场景的评分卡在 `a2p-dogfood/observations/` ## 已知限制 A2P 的门控是强制的强制函数，而非绝对证明。本节诚实地列出了 A2P **无法**做到、**做得不完美**以及**有意保持保守**的事项。在将其用于高 stakes 生产工作前请仔细阅读。 ### 工作流与强制执行 - **A2P 无法阻止手动修改 `.a2p/state.json`**。任何客户端状态存储都可以在带外被编辑。只要通过 A2P 工具调用的门控在 [`docs/WORKFLOW.md`](docs/WORKFLOW.md) 中被强制执行——而非直接写入状态时才生效。将状态文件视为来自自身流程的可信输入。 - **A2P 无法验证计划硬化轮次是否真正具有对抗性**。3 轮上限与结构性要求是强制执行严谨性的极限。填写字段的橡皮图章式评审可通过门控；执行工作的模型需对实际对抗性负责；A2P 仅强制工件存在。 - **A2P 无法验证 `"met"` 的 AC 覆盖率声明是否诚实**。完成评审强制模型明确做出该声明，并与新的测试和 SAST 运行交叉引用——但“测试已运行、通过、AC 满足”最终仍是自我报告。 ### 基于差异的防护 - **`.gitignore` 解析器是简单子集**。支持字面文件、目录模式（`build/`）和简单通配符（`*.log`）。**不支持**否定（`!pattern`）、嵌套 `.gitignore` 文件或完整 glob 语义。若依赖复杂忽略规则，请在 git 仓库内使用 A2P；基于 git 的差异路径直接使用 `git diff` 并尊重完整忽略规范。 - **文件哈希基线上限为 50,000 个文件**。超过该大小的项目在非 git 回退模式下会有部分基线；差异可能遗漏超出上限的文件。建议对任何非 trivial 大小的项目在 git 仓库内使用 A2P。 - **符号链接在文件哈希回退中被忽略**。基线快照从不跟随符号链接——既不哈希也不遍历。这是故意为之：符号链接可能引入循环风险、泄露项目树外的内容，且目标不稳定。如需符号感知差异，请使用基于 git 的路径（git 将符号链接作为目标文本引用处理）。在非 git 项目中，符号链接对 A2P 的基线/差异逻辑实际上不可见。 - **Python 仅单行 `def` 签名的 stub 检测器**。仅匹配单行 `def` 签名（例如 `def foo(): pass`）；多行签名（如 `def foo(\n a,\n b\n):\n pass`）不会被标记。`async def`、类方法等会被捕获。 - **计划合规性接口变更扫描仅限 TypeScript/JavaScript**。它通过正则表达式提取变更 `.ts`/`.tsx`/`.js`/`.jsx`/`.mjs`/`.cjs` 文件中的导出符号（`export function|const|class|interface|type|enum`）。非 TS/JS 文件按文件粒度检查（`unplannedFiles`），但不进行符号级检查。足够巧妙的跨非 TS 文件重构可能在 `unplannedInterfaceChanges` 中未被标记。 - **stub 扫描基于模式——巧妙的 stub 可能逃逸**。返回与 happy-path 测试匹配的字面值（如 TODO/FIXME/NotImplementedError/仅 pass）的函数不会被任何模式捕获。完成评审中的 `shortcutsOrStubs` 通过结构性强制（非语义性）作为补充通道：任何非空即导致 NOT_COMPLETE，但不会进行语义验证。 ### 测试基础设施逃生舱 - **`StateManager.forceLegacyFlowForTests` 是生产代码中的静态类字段**。设为 `true` 时会禁用硬化三联与测试优先防护，适用于旧版测试套件在不生成完整硬化工件的情况下遍历片段。默认为 `false`，生产代码路径永不设置，仅测试辅助工具（`useLegacySliceFlow()` in `tests/helpers/setup.ts`）可见。恶意或意外的写入将静默禁用门控——请视其为已知的仅用于测试的逃生舱，不应在未来的审计硬化版本中存在。 ### 自我重建验证 - **A2P 已通过端到端狗食验证**，涵盖 2 次完整运行（每次 6 个场景）以及在 121 个片段的生产代码库上的真实世界试验。端到端闭环——代理遵循提示 → 提示路由至工具 → 工具更新状态 → 从状态读取下一步——已通过独立观察者对隐藏对抗测试套件进行评分。结果：运行 1 的 50/50 隐藏测试、运行 2 的 153/158 评分卡（97%）、每片段 10/10 门控合规。6 个门控机械错误被发现并修复；该方法本身（硬化三联 + 测试优先 + 完成评审）被验证为承重结构。参见 [狗食验证](#dogfood-validation) 获取完整结果。 ### 平台说明 - **Windows 未包含在 CI 矩阵中**。代码库目标为 macOS 与 Linux；基于 `fs.symlinkSync` 的测试在 Windows 上行为可能不同（需要管理员权限或开发者模式）。 ## 客户端设置 A2P 兼容 Claude Code、Claude Desktop、Cursor、VS Code 以及任何兼容 MCP 的 AI 编码助手。 **Claude Code（CLI）** ``` claude mcp add architect-to-product -- npx architect-to-product ``` **Claude Desktop** — 添加到 `~/Library/Application Support/Claude/claude_desktop_config.json`（macOS）或 `%APPDATA%\Claude\claude_desktop_config.json`（Windows）： ``` { "mcpServers": { "architect-to-product": { "command": "npx", "args": ["architect-to-product"] } } } ``` **Cursor** — 添加到 `.cursor/mcp.json`： ``` { "mcpServers": { "architect-to-product": { "command": "npx", "args": ["architect-to-product"] } } } ``` **VS Code** — 添加到 `.vscode/mcp.json`： ``` { "servers": { "architect-to-product": { "command": "npx", "args": ["architect-to-product"] } } } ``` ## 提示词 MCP 提示词通过 `/` 在 Claude Code 中调用： | 命令 | 功能 | |---|---| | `/a2p` | 启动新手引导——定义架构、UI 设计、技术栈、监控配置与配套 | | `/a2p_planning` | 将架构分解为有序的垂直片段 | | `/a2p_build_slice` | 通过原生流程构建当前片段（硬化 → 测试优先防护 → RED → GREEN → REFACTOR → SAST → 完成评审 → 完成） + 强制构建签名 | | `/a2p_refactor` | 代码质量工具——分析代码库的死代码、冗余、耦合 | | `/a2p_e2e_testing` | AI 测试工具——使用 Playwright 运行视觉 E2E 测试 | | `/a2p_security_gate` | 完整 SAST 扫描 + OWASP Top 10 审查 | | `/a2p_whitebox` | 白盒安全审计 + 主动验证 | | `/a2p_audit` | 质量审计或发布审计。关键发布问题会阻止部署 | | `/a2p_deploy` | 生成部署配置与启动清单 | ## 文档 - [工作流与生命周期](docs/WORKFLOW.md) — 状态机、门控、监控、重新进入、多阶段 - [质量影响](docs/QUALITY-IMPACT.md) — 真实收益的非技术性说明 - [安全模型](docs/SECURITY.md) — SAST、白盒、Shake & Break、安全覆盖率、发现 - [参考](docs/REFERENCE.md) — 工具、提示词、栈、配套、模型偏好 - [部署（Hetzner / VPS）](docs/HETZNER-DEPLOYMENT.md) — Docker VPS、Hetzner Cloud、三层备份 - [验证](docs/validation/) — 声明验证、测试证据、现实检查

MCP 工具参考（37 个工具）

| 工具 | 阶段 | 描述 | |---|---|---| | `a2p_init_project` | 0 | 使用 CLAUDE.md、钩子、代理与状态初始化项目 | | `a2p_set_architecture` | 0 | 解析架构、检测数据库/前端、提取阶段、配置监控、捕获 UI 设计 | | `a2p_setup_companions` | 0 | 注册配套 MCP 服务器 | | `a2p_create_build_plan` | 1 | 架构 → 有序垂直片段（支持多阶段追加） | | `a2p_add_slice` | 1,2 | 在项目中插入单个片段 | | `a2p_set_phase` | * | 切换到新工作流阶段（强制执行所有门控） | | `a2p_complete_phase` | 7 | 完成当前产品阶段，推进到下一阶段 | | `a2p_get_state` | * | 读取当前项目状态 | | `a2p_update_slice` | 2 | 通过原生流程更新片段状态（pending / ready_for_red / red / green / refactor / sast / completion_fix / done），包含硬化、测试优先与完成评审门控 | | `a2p_harden_requirements` | 2 | 固化需求并覆盖片段 AC；级联失效下游硬化 | | `a2p_harden_tests` | 2 | 固化测试矩阵；拒绝无真实服务的集成/UI 片段 | | `a2p_harden_plan` | 2 | 记录对抗性计划硬化轮次（1–3）与结构化 `finalPlan` | | `a2p_verify_test_first` | 2 | 对工作区与片段基线进行差异分类，运行测试命令，强制执行测试优先纪律 | | `a2p_completion_review` | 2 | 记录完成评审，包含 stub 扫描、计划合规性校验与结果一致性强制执行 | | `a2p_get_slice_hardening_status` | * | 片段的只读硬化、防护与评审状态 | | `a2p_run_tests` | 2 | 执行测试命令，解析结果（pytest/vitest/jest/go/flutter/dart/xctest/gradle） | | `a2p_run_quality` | 2.5 | 代码质量分析——死代码、冗余、耦合 | | `a2p_run_e2e` | 2.6 | 记录 Playwright E2E 测试结果 | | `a2p_run_sast` | 2,3 | 静态代码分析（Semgrep + Bandit），结果去重 | | `a2p_record_finding` | 3 | 手动记录安全发现 | | `a2p_run_audit` | 2,6 | 质量审计或发布审计。关键发布问题会阻止部署 | | `a2p_run_whitebox_audit` | 4 | 白盒安全审计——对 SAST 发现进行可利用性分析 | | `a2p_run_active_verification` | 5 | 主动验证——运行门控测试以证明工作流不变量成立 | | `a2p_build_signoff` | 2 | 确认构建可用（安全阶段前必须） | | `a2p_deploy_approval` | 7 | 批准部署（部署生成前必须） | | `a2p_set_secret_management` | 7 | 设置密钥管理层级（部署配置生成前必须） | | `a2p_plan_infrastructure` | 7 | 为 Hetzner Cloud 规划服务器基础设施 | | `a2p_record_server` | 7 | 在项目中记录已配置服务器详情 | | `a2p_deploy_to_server` | 7 | 生成 rsync/ssh/docker 部署命令 | | `a2p_verify_ssl` | 7 | 记录 SSL/HTTPS 验证（部署完成前必须） | | `a2p_generate_deployment` | 7 | 特定栈的部署指导 | | `a2p_shake_break_setup` | 5 | 设置隔离沙箱以进行对抗运行时测试 | | `a2p_shake_break_teardown` | 5 | 拆除沙箱，记录结果 | | `a2p_get_build_log` | * | 查询结构化构建日志 | | `a2p_get_checklist` | * | 部署前后检查清单 |

安全覆盖概览

A2P 通过确定性模式匹配到 LLM 引导代码审查再到主动运行时测试的多层机制提供安全覆盖。 **覆盖数字**：32 个确定性探测 · 25 个对抗评审域 · 8 类运行时测试 · 2 类主动验证 · 部署工件验证 · 依赖扫描 · 部署前后检查清单 **机制**： - **探测** — 确定性的正则/AST 模式匹配 - **SAST** — Semgrep + Bandit 静态分析 - **对抗** — LLM 引导的代码审查，带置信度跟踪与文件:行证据 - **Shake & Break** — 在隔离沙箱中运行真实 HTTP 请求的运行时对抗测试 - **主动验证** — 运行门控测试以证明工作流不变量成立 **覆盖域**：SQL/命令/NoSQL 注入、XSS、路径遍历、SSRF、不安全反序列化、认证中间件、IDOR、权限提升、越权赋值、硬编码密钥、JWT、会话固定、CSRF、CORS、竞争条件、业务逻辑绕过、文件上传、Webhook 安全等。 → 完整安全覆盖矩阵：[docs/SECURITY.md](docs/SECURITY.md)

配套 MCP 服务器

A2P 会根据你的技术栈自动配置配套 MCP 服务器。 **核心（始终安装）** | 配套 | 提供的能力 | |---|---| | `codebase-memory-mcp` | 代码图谱智能——最多减少 100 倍探索令牌 | | `mcp-server-git` | Git 历史、、差异 | | `@modelcontextprotocol/server-filesystem` | 文件操作 | | `@modelcontextprotocol/server-sequential-thinking` | 逐步推理 | **条件安装（基于栈）** | 配套 | 启用条件 | |---|---| | Playwright MCP | 前端项目 | | GitHub MCP | GitHub 仓库 | | Supabase MCP | Supabase 项目 | | `@stripe/mcp` | 计费/支付 | | `@cloudflare/mcp-server-cloudflare` | Cloudflare 托管 | | `@sentry/mcp-server` | 错误追踪 | | `@upstash/mcp-server` | Serverless Redis/队列 | | Semgrep MCP | Semgrep Pro 用户 | | 数据库 MCP | PostgreSQL、MongoDB、MySQL | **前端美学强制** A2P 对所有 `hasUI` 片段强制执行 [Anthropic 前端美学指南](https://docs.anthropic.com/en/docs/build-with-claude/prompt-engineering/frontend-design)。构建提示要求独特的排版、协调的配色方案、动效与氛围化背景。明确禁止通用 AI 美学（Inter 字体、紫色渐变、Cookie-cutter 布局）。

支持栈与部署目标

**语言**：Python、TypeScript/Node.js、Go、Rust、Java/Kotlin、Ruby、PHP、C#/.NET、Dart/Flutter、Swift **数据库**：SQLite、PostgreSQL、MySQL/MariaDB、MongoDB、Redis **托管**：Hetzner、DigitalOcean、AWS、Fly.io、Railway、Vercel、Cloudflare、Render、任意 VPS **部署目标**： | 目标 | A2P 生成内容 | |---|---| | Docker VPS（Hetzner/DigitalOcean 等任意 Ubuntu VPS） | Dockerfile、docker-compose、Caddyfile、备份/恢复/验证脚本、BACKUP.md、DEPLOYMENT.md、加固清单。Hetzner：自动化配置、云初始化、防火墙、三层备份 | | Vercel | 建议 + 检查清单 | | Cloudflare Pages/Workers | 建议 + 检查清单 | | Railway | 建议 + 检查清单 | | Fly.io | 建议 + 检查清单 | | Render | 建议 + 检查清单 | | 移动端（Flutter、React Native） | 仅建议与检查清单——移动端工具链由项目提供 |

## 更新日志 | 版本 | 重点 | |---|---| | **2.0.2** | **codebase-memory-mcp 现为必需配套**。新增 `planning → building` 门控（`requireCodebaseMemoryRegistered`），无配套则阻塞转换；可通过 `architecture.bypassCodebaseMemory: true` + ≥20 字符理由绕过。新工具 `a2p_verify_codebase_memory_index`。对 `ready_for_red` 软新鲜度警告。所有 A2P 提示词已改为强制 codebase-memory 语言。1473 个测试（新增 25 个：强制执行门控、提示回归、初始化项目 CLAUDE.md 断言）。 | | **2.0.1** | **MCP 表面修复以适配 v2 流**。`src/server.ts` 现暴露 `systemsConcerns`、`systemsConcernTests`、`systemsConcernReviews`、`systemsClassification` 与 `architecture.systems`。此前 v2.0.0 前 MCP SDK 默认 `strip` 会静默丢弃客户端发送的 v2 字段，导致基于证据的门控流程无法通过任意 MCP 客户端使用。现已添加形状一致性回归测试。1448 个测试。 | | **2.0.0** | **A2P v2 — 证据约束的 AI 系统工程**。13 个规范系统工程关注点，每个关注点在每个硬化工件（需求、测试、计划、完成评审）处均需提供证据。确定性适用规则。状态管理器在代码中强制执行门控（`pending → ready_for_red` 与 `sast → done`）。状态版本自 1 升级至 2，并向后兼容迁移。1425 个测试。 | | **1.1.0** | **原生片段硬化（v1 流基础）**。新增 6 个 MCP 工具（`a2p_harden_requirements`、`a2p_harden_tests`、`a2p_harden_plan`、`a2p_verify_test_first`、`a2p_completion_review`、`a2p_get_slice_hardening_status`）。新增状态 `ready_for_red` 与 `completion_fix`。基于差异的测试优先防护（含 git 与文件哈希回退）。完成评审循环（含计划合规性扫描、stub 自动扫描与结果一致性强制执行）。引导片段（`bootstrap: true`）用于单项目一次性的旧版流程豁免。计划硬化归档（`previousPlanHardenings`）保留审计追踪。排除 `.claude/`、`CLAUDE.md`、`.mcp.json`、`.gitignore` 等 A2P 元文件。`completion_fix` 在测试已通过时自动通过 `verify_test_first`（防止外部漂移恢复导致的无限循环）。接口变更扫描仅提取裸标识符；类型仅导出容忍。狗食验证：50/50 对抗样本、153/158 评分卡（97%）、6/6 Schublade-2 陷阱捕获。1351 个测试（由 1097 增至）。 | | **1.0.10** | 配套 `config` 以 `env` 块写入 `.mcp.json`（修复 Supabase MCP 崩溃）。Supabase 云与本地 onboarding。`a2p_get_state` 中的配套健康警告。 | | **1.0.5–1.0.9** | 门控强化：SSL、密钥管理、安全决策为强制停止。Anthropic 前端美学强制执行。端到端全流程测试。安全门控覆盖仪表盘。文档统一为英文。 | | **1.0.4** | SSL/HTTPS 验证门控（`a2p_verify_ssl`）。无 SSL 证明则阻止部署与阶段完成。 | | **1.0.3** | SAST 排除构建产物。发现去重。密钥管理工具（`a2p_set_secret_management`）。对抗评审需确认码。 | | **1.0.2** | 重构 README。工具计数修正为 27。升级说明补充。 | | **1.0.1** | 修复重复的审计/SAST/白盒事件。`pendingSecurityDecision` 作为部署门控强制执行。 | ## 开发 ``` git clone https://github.com/BernhardJackiewicz/architect-to-product.git cd architect-to-product npm install npm run typecheck # Type checking npm test # 1473 tests npm run build # Build npm run dev # Dev mode ``` **在本地构建上运行 Claude Code** — 已提交的 `.mcp.json` 固定指向发布的 npm 版本，因此贡献者与外部用户始终获得稳定服务器。如需让 Claude Code 加载本地 `dist/`，请将 `.mcp.local.json.example` 复制为不跟踪的覆盖（`~/.claude/settings.local.json` 或私有 `.mcp.local.json`），并编辑绝对路径。本地覆盖优先于提交的 `.mcp.json`。在运行 `npm run build` 后重启 Claude Code 以加载最新的 `dist/`。 ## 许可证 MIT

标签：AI工程框架, MCP服务器, MITM代理, TDD, VPS部署, 代码即生产, 代码库记忆, 减少令牌消耗, 安全扫描, 安全配置, 开发者效率, 开源框架, 持续交付, 持续集成, 探索令牌优化, 时序注入, 架构到产品, 特权提升, 状态管理, 生产就绪, 确定性适用性, 系统工程, 自动化攻击, 自动化部署, 证据门控, 请求拦截, 质量审计, 软件交付, 软件分析, 静态应用安全测试