Update nexus wiki content
This commit is contained in:
63
wiki/sources/phase-2-foundation.md
Normal file
63
wiki/sources/phase-2-foundation.md
Normal file
@@ -0,0 +1,63 @@
|
||||
---
|
||||
title: "Phase 2 Playbook — Foundation & Scaffolding"
|
||||
type: source
|
||||
tags: []
|
||||
date: 2026-05-01
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Agent/agency-agents/strategy/playbooks/phase-2-foundation.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：NEXUS 框架 Phase 2 执行手册——技术基础设施与运营基础的并行构建阶段
|
||||
- 问题域：如何在 Phase 1 架构通过审批后，快速为所有开发 Agent 提供可工作的基础环境
|
||||
- 方法/机制：6 个 Agent 双工作流并行（Workstream A 基础设施 + Workstream B 应用框架），双门卫（DevOps Automator + Evidence Collector）联合签发质量门
|
||||
- 结论/价值：Phase 2 是整个 NEXUS 流水线的"骨架站立"阶段，产出包含 CI/CD 管道、API 脚手架、设计系统和 Git 协作流程，为 Phase 3 全面开发提供即插即用的基础设施
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- 双工作流并行策略使基础设施搭建和应用框架构建同步完成，3 天内交付可用基础
|
||||
- DevOps Automator + Evidence Collector 联合双签质量门确保只有通过真实运行验证的产出进入 Phase 3
|
||||
- 零基础设施债务——所有 Phase 2 产出必须通过截图证据（CI 管道日志/浏览器截图/主题切换对比/API 健康检查）方可过关
|
||||
- Evidence Collector 的 8 项截图证据是 Phase 2 交付的强制验证标准，覆盖从前端渲染到数据库迁移的全链路
|
||||
- Design Token（设计令牌）是前端框架和 CSS 系统之间的核心连接点，确保 Brand Guardian 的品牌规范可被 Frontend Developer 无损复用
|
||||
|
||||
## Key Quotes
|
||||
> "Phase 2 is complete when the skeleton application is running, the CI/CD pipeline is operational, and the Evidence Collector has verified all foundation elements with screenshots." — Phase 2 完成的定义性标准
|
||||
> "Dual sign-off required: DevOps Automator (infrastructure) + Evidence Collector (visual)" — 质量门双重签发机制
|
||||
> "Build the technical and operational foundation that all subsequent work depends on. Get the skeleton standing before adding muscle." — Phase 2 战略定位
|
||||
|
||||
## Key Concepts
|
||||
- [[NEXUS-Sprint]]：NEXUS 多 Agent 协作框架中的阶段化执行模型，Phase 2 属于基础设施建设阶段
|
||||
- [[Quality-Gate]]：NEXUS 流水线中的质量门控机制，Phase 2 要求 DevOps Automator + Evidence Collector 联合双签
|
||||
- [[Evidence-Based-QA]]：以截图证据为验证标准的 QA 方法论，Evidence Collector 在 Phase 2 执行 8 项截图验证
|
||||
- [[Design-Tokens]]：CSS 设计系统中颜色/字体/间距等设计决策的变量化表达，实现 Brand Guardian 到 Frontend Developer 的规范无损传递
|
||||
- [[Two-Phase-Build]]：Phase 2 特有的先构建应用骨架再分发的两阶段构建策略（第一次 build 产出脚手架，第二次 build 集成 raw 原始文件后 serve）
|
||||
- [[Infrastructure-as-Code]]：IaC 模板化环境配置（Terraform/CDK），实现多环境（dev/staging/production）一致性
|
||||
- [[Blue-Green-Deployment]]：蓝绿部署策略，CI/CD 管道中的零宕机部署机制
|
||||
|
||||
## Key Entities
|
||||
- [[DevOps-Automator]]：负责 CI/CD 管道和 IaC 模板，交付 GitHub Actions 流水线（安全扫描/自动化测试/容器化/蓝绿部署/自动回滚）和 docker-compose.yml/Dockerfile，时间线 3 天
|
||||
- [[Infrastructure-Maintainer]]：负责云资源供给和监控栈，交付 Prometheus/Grafana 监控面板 + 集中日志聚合 + SSL/TLS 安全加固，时间线 3 天
|
||||
- [[Studio-Operations]]：负责流程搭建，交付 Git 工作流文档（分支策略/PR 流程/合并策略）和协作工具配置，时间线 2 天
|
||||
- [[Frontend-Developer]]：负责项目脚手架和组件库，交付 React/Vue/Angular 框架 + TypeScript 配置 + 设计系统组件（Button/Input/Card/Layout），时间线 3 天
|
||||
- [[Backend-Architect]]：负责数据库和 API 脚手架，交付数据库 Schema 迁移 + Express/FastAPI 框架 + JWT 认证 + RBAC，时间线 4 天
|
||||
- [[UX-Architect]]：负责 CSS 系统实现，交付 CSS 自定义属性设计令牌 + 响应式网格布局 + 亮/暗/系统三主题切换，时间线 2 天
|
||||
- [[Evidence-Collector]]：Phase 2 的 Gate Keeper，执行 8 项截图验证（CI 日志/桌面端/移动端/主题切换/API 健康检查/数据库迁移/监控面板/组件库渲染），输出带截图证据的质量裁决，时间线 2 天
|
||||
- [[Project-Shepherd]]：在 Studio Operations 的输入中提及，负责项目协调和时间线管理
|
||||
- [[Brand-Guardian]]：为 Frontend Developer 和 UX Architect 提供品牌身份输入（品牌颜色/字体规范），确保 Design Token 与品牌规范对齐
|
||||
|
||||
## Connections
|
||||
- [[phase-1-strategy]] ← prerequisite_for ← [[phase-2-foundation]]（Phase 1 架构包审批通过是 Phase 2 启动的前置条件）
|
||||
- [[phase-2-foundation]] ← handoff_to ← [[phase-3-build]]（Phase 2 产出的完整脚手架交付给 Phase 3 开发 Agent）
|
||||
- [[DevOps-Automator]] ← depends_on ← [[phase-1-strategy]]（DevOps Automator 读取 Backend Architect 的系统架构作为输入）
|
||||
- [[Frontend-Developer]] ← depends_on ← [[Brand-Guardian]]（Frontend Developer 接收 Brand Guardian 的品牌身份作为 CSS 设计系统输入）
|
||||
- [[UX-Architect]] ← depends_on ← [[Brand-Guardian]]（UX Architect 接收 Brand Guardian 的品牌身份作为 CSS 设计令牌输入）
|
||||
- [[DevOps-Automator]] ← parallel_with ← [[Infrastructure-Maintainer]]（Workstream A 并行工作）
|
||||
- [[DevOps-Automator]] ← parallel_with ← [[Studio-Operations]]（Workstream A 并行工作）
|
||||
- [[Frontend-Developer]] ← parallel_with ← [[Backend-Architect]]（Workstream B 并行工作）
|
||||
- [[Frontend-Developer]] ← parallel_with ← [[UX-Architect]]（Workstream B 并行工作）
|
||||
- [[Evidence-Collector]] ← gate_keeps ← [[phase-2-foundation]]（Evidence Collector 是 Phase 2 质量门的双签人之一）
|
||||
- [[DevOps-Automator]] ← gate_keeps ← [[phase-2-foundation]]（DevOps Automator 是 Phase 2 质量门的双签人之一）
|
||||
|
||||
## Contradictions
|
||||
- 与 [[scenario-startup-mvp]] 的 Agent 数量：Phase 2 指定 6 个 Agent（DevOps Automator/Infrastructure Maintainer/Studio Operations/Frontend Developer/Backend Architect/UX Architect），而 scenario-startup-mvp 的 Week 1 提到"Sprint Prioritizer + Studio Producer + Evidence Collector"等角色。**协调方向**：Phase 2 的 6 Agent 是基础设施专项 Agent，scenario-startup-mvp 的是全周期角色，两者服务于不同阶段，同步激活是合理的（Evidence Collector 在 Phase 2 是 Gate Keeper，在 scenario-startup-mvp 中是全周期 QA）。
|
||||
Reference in New Issue
Block a user