full-stack-orchestration-full-stack-feature

适用场景

• 执行全栈编排的全栈功能任务或工作流时
• 需要全栈编排全栈功能的指导、最佳实践或检查清单时

不适用场景

• 任务与全栈编排全栈功能无关时
• 需要使用此范围之外的其他领域或工具时

说明

• 明确目标、约束和所需输入。
• 应用相关最佳实践并验证结果。
• 提供可执行的步骤和验证方法。

采用现代 API 优先的方法，协调后端、前端和基础设施层的全栈功能开发：

[扩展思考：此工作流协调多个专业 Agent，从架构设计到部署，共同交付完整的全栈功能。它遵循 API 优先的开发原则，以契约驱动开发，确保 API 规范同时驱动后端实现和前端调用。每个阶段都基于前序阶段的产出，构建出职责分离明确、测试全面且可用于生产的完整系统。此工作流强调组件驱动的 UI 开发、功能标记、可观测性和渐进式发布策略等现代实践。]

阶段 1：架构与设计基础

1. 数据库架构设计

• 使用 Task 工具，设置 subagent_type="database-design::database-architect"
• 提示词："为以下内容设计数据库架构和数据模型：$ARGUMENTS。考虑可扩展性、查询模式、索引策略和数据一致性要求。如果要修改现有架构，请包含迁移策略。提供逻辑数据模型和物理数据模型。"
• 预期产出：实体关系图、表结构、索引策略、迁移脚本、数据访问模式
• 上下文：初始需求和业务领域模型

2. 后端服务架构

• 使用 Task 工具，设置 subagent_type="backend-development::backend-architect"
• 提示词："为以下内容设计后端服务架构：$ARGUMENTS。根据前一步的数据库设计，划分服务边界、定义 API 契约（OpenAPI/GraphQL）、设计身份验证/授权策略，并指定服务间通信模式。包含弹性模式（断路器、重试）和缓存策略。"
• 预期产出：服务架构图、OpenAPI 规范、身份验证流程、缓存架构、消息队列设计（如适用）
• 上下文：步骤 1 中的数据库架构、非功能性需求

3. 前端组件架构

• 使用 Task 工具，设置 subagent_type="frontend-mobile-development::frontend-developer"
• 提示词："为以下内容设计前端架构和组件结构：$ARGUMENTS。根据前一步的 API 契约，设计组件层级、状态管理方案（Redux/Zustand/Context）、路由结构和数据获取模式。包含无障碍要求和响应式设计策略，并规划 Storybook 组件文档。"
• 预期产出：组件树图、状态管理设计、路由配置、设计系统集成方案、无障碍检查清单
• 上下文：步骤 2 中的 API 规范、UI/UX 要求

阶段 2：并行实施

4. 后端服务实现

• 使用 Task 工具，subagent_type="python-development::python-pro"（或根据技术栈选择 "golang-pro"/"nodejs-expert"）
• 提示词："为以下内容实现后端服务：$ARGUMENTS。使用第 1 阶段的架构和 API 规范，构建具有适当验证、错误处理和日志记录的 RESTful/GraphQL 端点。实现业务逻辑、数据访问层、身份验证中间件以及与外部服务的集成。包含可观测性（结构化日志、指标、链路追踪）。"
• 预期输出：后端服务代码、API 端点、中间件、后台任务、单元测试、集成测试
• 上下文：第 1 阶段的架构设计、数据库 schema

5. 前端实现

• 使用 Task 工具，subagent_type="frontend-mobile-development::frontend-developer"
• 提示词："为以下内容实现前端应用：$ARGUMENTS。使用第 1 阶段的组件架构构建 React/Next.js 组件。实现状态管理、具有适当错误处理和加载状态的 API 集成、表单验证以及响应式布局。为组件创建 Storybook stories。确保可访问性（符合 WCAG 2.1 AA）。"
• 预期输出：React 组件、状态管理实现、API 客户端代码、Storybook stories、响应式样式、可访问性实现
• 上下文：第 3 步的组件架构、API 契约

6. 数据库实现与优化

• 使用 Task 工具，subagent_type="database-design::sql-pro"
• 提示词："为以下内容实现并优化数据库层：$ARGUMENTS。创建迁移脚本、存储过程（如需要），优化后端实现中识别出的查询，设置适当的索引，并实现数据验证约束。包含数据库级别的安全措施和备份策略。"
• 预期输出：迁移脚本、优化后的查询、存储过程、索引定义、数据库安全配置
• 上下文：第 1 步的数据库设计、后端实现中的查询模式

第 3 阶段：集成与测试

7. API 契约测试

• 使用 Task 工具，subagent_type="test-automator"
• 提示词："为以下内容创建契约测试：$ARGUMENTS。实现 Pact/Dredd 测试以验证后端与前端之间的 API 契约。为所有 API 端点创建集成测试，测试身份验证流程，验证错误响应，并确保正确的 CORS 配置。包含负载测试场景。"
• 预期输出：契约测试套件、集成测试、负载测试场景、API 文档验证
• 上下文：第 2 阶段的 API 实现

8. 端到端测试

• 使用 Task 工具，subagent_type="test-automator"
• 提示词："为以下内容实现 E2E 测试：$ARGUMENTS。创建 Playwright/Cypress 测试，覆盖关键用户旅程、跨浏览器兼容性、移动端响应性和错误场景。测试功能标志集成、分析跟踪和性能指标。包含视觉回归测试。"
• 预期输出：E2E 测试套件、视觉回归基线、性能基准、测试报告
• 上下文：第 2 阶段的前端和后端实现

9. 安全审计与加固

• 使用 Task 工具，subagent_type="security-auditor"
• 提示词："为以下内容执行安全审计：$ARGUMENTS。审查 API 安全性（身份验证、授权、速率限制），检查 OWASP Top 10 漏洞，审计前端的 XSS/CSRF 风险，验证输入清理，并审查密钥管理。提供渗透测试结果和修复步骤。"
• 预期输出：安全审计报告、漏洞评估、修复建议、安全响应头配置
• 上下文：第 2 阶段的所有实现

第 4 阶段：部署与运维

10. 基础设施与 CI/CD 设置

• 使用 Task 工具，subagent_type="deployment-engineer"
• 提示词："为以下内容设置部署基础设施：$ARGUMENTS。创建 Docker 容器、Kubernetes 清单（或特定云平台的配置）、实现包含自动化测试门禁的 CI/CD 流水线、设置功能开关（LaunchDarkly/Unleash），并配置监控/告警。包含蓝绿部署策略和回滚流程。"
• 预期输出：Dockerfiles、K8s 清单、CI/CD 流水线配置、功能开关设置、IaC 模板（Terraform/CloudFormation）
• 上下文：前几个阶段的所有实现和测试

11. 可观测性与监控

• 使用 Task 工具，subagent_type="deployment-engineer"
• 提示词："为以下内容实现可观测性堆栈：$ARGUMENTS。设置分布式追踪（OpenTelemetry）、配置应用指标（Prometheus/DataDog）、实现集中式日志记录（ELK/Splunk）、为关键指标创建仪表板，并定义 SLI/SLO。包含告警规则和轮值流程。"
• 预期输出：可观测性配置、仪表板定义、告警规则、运行手册、SLI/SLO 定义
• 上下文：第 10 步的基础设施设置

12. 性能优化

• 使用 Task 工具，subagent_type="performance-engineer"
• 提示词："为以下内容优化整个技术栈的性能：$ARGUMENTS。分析并优化数据库查询、实现缓存策略（Redis/CDN）、优化前端包大小和加载性能、设置延迟加载和代码拆分，并调整后端服务性能。包含优化前后的指标。"
• 预期输出：性能改进、缓存配置、CDN 设置、优化后的包、性能指标报告
• 上下文：第 11 步的监控数据、负载测试结果

配置选项

• stack：指定技术栈（例如："React/FastAPI/PostgreSQL"、"Next.js/Django/MongoDB"）
• deployment_target：云平台（AWS/GCP/Azure）或本地部署
• feature_flags：启用/禁用功能开关集成
• api_style：REST 或 GraphQL
• testing_depth：全面或基本
• compliance：特定合规要求（GDPR、HIPAA、SOC2）

成功标准

• 所有 API 契约均通过契约测试验证
• 前端和后端集成测试通过
• E2E 测试覆盖关键用户流程
• 安全审计通过，且无严重漏洞
• 性能指标达到定义的 SLO
• 可观测性堆栈能够采集所有关键指标
• 已配置功能开关以支持逐步发布
• 所有组件的文档齐全
• CI/CD 流水线包含自动化质量门禁
• 已验证具备零停机部署能力

协调说明

• 每个阶段都基于前一阶段的输出构建
• 第 2 阶段的并行任务可以同时运行，但必须在第 3 阶段前汇合
• 保持需求与实现之间的可追溯性
• 在所有服务中使用关联 ID 进行分布式追踪
• 在 ADR 中记录所有架构决策
• 确保各服务的错误处理和 API 响应保持一致

要实现的功能：$ARGUMENTS