feat(skills): complete multi-agent collaboration framework
## Skills Ecosystem (60+ Skills) - Engineering: 7 skills (ai-engineer, backend-architect, etc.) - Testing: 8 skills (reality-checker, evidence-collector, etc.) - Support: 6 skills (support-responder, analytics-reporter, etc.) - Design: 7 skills (ux-architect, brand-guardian, etc.) - Product: 3 skills (sprint-prioritizer, trend-researcher, etc.) - Marketing: 4+ skills (growth-hacker, content-creator, etc.) - PM: 5 skills (studio-producer, project-shepherd, etc.) - Spatial: 6 skills (visionos-spatial-engineer, etc.) - Specialized: 6 skills (agents-orchestrator, etc.) ## Collaboration Framework - Coordination protocols (handoff-templates, agent-activation) - 7-phase playbooks (Discovery → Operate) - Standardized skill template for consistency ## Quality Improvements - Each skill now includes: Identity, Mission, Workflow, Deliverable Format - Collaboration triggers define when to invoke other agents - Success metrics provide measurable quality standards Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
This commit is contained in:
iven
113
skills/.playbooks/README.md
Normal file
113
skills/.playbooks/README.md
Normal file
@@ -0,0 +1,113 @@
|
||||
# ZClaw Agent Playbooks
|
||||
|
||||
> 分阶段工作手册 - 指导多 Agent 协作的标准化流程
|
||||
|
||||
---
|
||||
|
||||
## 概述
|
||||
|
||||
Playbooks 定义了项目从发现到运营的完整生命周期，每个阶段有明确的目标、活动和交付物。
|
||||
|
||||
## 阶段总览
|
||||
|
||||
```
|
||||
┌─────────────────────────────────────────────────────────────────────────┐
|
||||
│ ZClaw 项目生命周期 │
|
||||
├─────────────────────────────────────────────────────────────────────────┤
|
||||
│ │
|
||||
│ Phase 0 Phase 1 Phase 2 Phase 3 │
|
||||
│ ┌────────┐ ┌────────┐ ┌────────┐ ┌────────┐ │
|
||||
│ │Discovery│ ──→ │Strategy │ ──→ │Foundation│ ──→ │ Build │ │
|
||||
│ │ │ │ │ │ │ │ │ │
|
||||
│ │ 2-3 天 │ │ 3-5 天 │ │ 3-5 天 │ │ 2-4 周 │ │
|
||||
│ └────────┘ └────────┘ └─────────┘ └────────┘ │
|
||||
│ │
|
||||
│ ↑ │ │
|
||||
│ │ ↓ │
|
||||
│ │ Phase 6 Phase 5 Phase 4 │
|
||||
│ │ ┌────────┐ ┌────────┐ ┌────────┐ │
|
||||
│ └─────── │Operate │ ←─── │ Launch │ ←─── │Harden │ │
|
||||
│ 持续改进 │ │ │ │ │ │ │
|
||||
│ │持续运营 │ │ 1-2 天 │ │ 1 周 │ │
|
||||
│ └────────┘ └────────┘ └────────┘ │
|
||||
│ │
|
||||
└─────────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
## Playbook 列表
|
||||
|
||||
| Phase | 名称 | 文件 | 主要目标 |
|
||||
|-------|------|------|----------|
|
||||
| 0 | Discovery | [phase-0-discovery.md](./phase-0-discovery.md) | 理解需求、定义范围 |
|
||||
| 1 | Strategy | [phase-1-strategy.md](./phase-1-strategy.md) | 架构设计、任务规划 |
|
||||
| 2 | Foundation | [phase-2-foundation.md](./phase-2-foundation.md) | 项目搭建、基础实现 |
|
||||
| 3 | Build | [phase-3-build.md](./phase-3-build.md) | 功能开发、Dev↔QA 循环 |
|
||||
| 4 | Hardening | [phase-4-hardening.md](./phase-4-hardening.md) | 性能优化、安全加固 |
|
||||
| 5 | Launch | [phase-5-launch.md](./phase-5-launch.md) | 部署发布、上线验证 |
|
||||
| 6 | Operate | [phase-6-operate.md](./phase-6-operate.md) | 持续运营、监控维护 |
|
||||
|
||||
## 核心原则
|
||||
|
||||
### 1. 阶段门禁 (Phase Gates)
|
||||
|
||||
每个阶段结束前必须通过质量门禁，确保：
|
||||
- 所有必需的交付物完成
|
||||
- 质量指标达标
|
||||
- 文档更新完整
|
||||
|
||||
### 2. Dev↔QA 循环
|
||||
|
||||
```
|
||||
Developer 实现 → Reality Checker 验证 → PASS/FAIL 决策
|
||||
↑ │
|
||||
└────── FAIL (< 3次) ────┘
|
||||
│
|
||||
FAIL (= 3次) → ESCALATE
|
||||
```
|
||||
|
||||
### 3. 证据驱动
|
||||
|
||||
所有质量评估需要可验证的证据：
|
||||
- 截图证据
|
||||
- 测试报告
|
||||
- 性能指标
|
||||
- 安全扫描结果
|
||||
|
||||
### 4. 持续文档
|
||||
|
||||
每个阶段结束时更新：
|
||||
- 项目文档
|
||||
- API 文档
|
||||
- 运维手册
|
||||
- 知识库
|
||||
|
||||
## 快速开始
|
||||
|
||||
### 启动新项目
|
||||
|
||||
1. 阅读 [Phase 0: Discovery](./phase-0-discovery.md)
|
||||
2. 激活相关 Agents
|
||||
3. 按阶段执行
|
||||
|
||||
### 加入进行中的项目
|
||||
|
||||
1. 确定当前阶段
|
||||
2. 阅读对应 Playbook
|
||||
3. 检查阶段门禁状态
|
||||
4. 继续执行
|
||||
|
||||
### 处理事件
|
||||
|
||||
1. 参考 [Phase 6: Operate](./phase-6-operate.md) 的事件响应流程
|
||||
2. 按严重程度分级处理
|
||||
3. 完成事后复盘
|
||||
|
||||
## 相关文档
|
||||
|
||||
- [协作协议](../.coordination/handoff-templates.md) - Agent 间交接格式
|
||||
- [激活提示](../.coordination/agent-activation.md) - Agent 激活模板
|
||||
- [Skill 模板](../.templates/skill-template.md) - Skill 定义格式
|
||||
|
||||
---
|
||||
|
||||
*ZClaw Multi-Agent Collaboration Framework*
|
||||
123
skills/.playbooks/phase-0-discovery.md
Normal file
123
skills/.playbooks/phase-0-discovery.md
Normal file
@@ -0,0 +1,123 @@
|
||||
# Phase 0: Discovery Playbook
|
||||
|
||||
> 项目发现阶段 - 理解需求、定义范围、建立基础
|
||||
|
||||
---
|
||||
|
||||
## 阶段目标
|
||||
|
||||
深入理解用户需求，定义项目范围，建立技术和业务基础。
|
||||
|
||||
## 激活 Agents
|
||||
|
||||
| Agent | 角色 | 优先级 |
|
||||
|-------|------|--------|
|
||||
| **UX Researcher** | 用户研究、需求收集 | 立即 |
|
||||
| **Trend Researcher** | 市场趋势、竞争分析 | 立即 |
|
||||
| **UX Architect** | 信息架构、技术基础 | Day 2 |
|
||||
| **Brand Guardian** | 品牌识别定义 | Day 2 |
|
||||
|
||||
## 关键活动
|
||||
|
||||
### 1. 需求收集 (Day 1-2)
|
||||
|
||||
**UX Researcher 执行**:
|
||||
- 用户访谈和调研
|
||||
- 痛点识别
|
||||
- 用户旅程映射
|
||||
- 成功指标定义
|
||||
|
||||
**交付物**:
|
||||
```markdown
|
||||
## User Research Report
|
||||
|
||||
### Target Users
|
||||
- [用户画像 1]
|
||||
- [用户画像 2]
|
||||
|
||||
### Pain Points
|
||||
1. [痛点 1] - 严重程度: [High/Med/Low]
|
||||
2. [痛点 2] - 严重程度: [High/Med/Low]
|
||||
|
||||
### User Journey
|
||||
[用户旅程图]
|
||||
|
||||
### Success Metrics
|
||||
- [指标 1]: [目标值]
|
||||
- [指标 2]: [目标值]
|
||||
```
|
||||
|
||||
### 2. 市场分析 (Day 1-2)
|
||||
|
||||
**Trend Researcher 执行**:
|
||||
- 竞品分析
|
||||
- 市场趋势研究
|
||||
- 差异化机会识别
|
||||
- 技术可行性评估
|
||||
|
||||
**交付物**:
|
||||
```markdown
|
||||
## Market Analysis Report
|
||||
|
||||
### Competitive Landscape
|
||||
| 竞品 | 优势 | 劣势 | 我们的差异化 |
|
||||
|------|------|------|-------------|
|
||||
|
||||
### Market Trends
|
||||
- [趋势 1]: [影响分析]
|
||||
- [趋势 2]: [影响分析]
|
||||
|
||||
### Opportunity Assessment
|
||||
- 高价值机会: [描述]
|
||||
- 技术可行性: [评估]
|
||||
```
|
||||
|
||||
### 3. 信息架构 (Day 2-3)
|
||||
|
||||
**UX Architect 执行**:
|
||||
- 内容层级定义
|
||||
- 导航结构设计
|
||||
- 响应式策略规划
|
||||
- 无障碍基础建立
|
||||
|
||||
### 4. 品牌定义 (Day 2-3)
|
||||
|
||||
**Brand Guardian 执行**:
|
||||
- 品牌基础（愿景、使命、价值观）
|
||||
- 视觉识别系统
|
||||
- 品牌声音指南
|
||||
- 颜色和排版系统
|
||||
|
||||
## 阶段门禁
|
||||
|
||||
进入 Phase 1 前必须满足：
|
||||
|
||||
| # | 标准 | 阈值 | 验证方法 |
|
||||
|---|------|------|----------|
|
||||
| 1 | 用户研究完成 | 100% | 交付物审查 |
|
||||
| 2 | 市场分析完成 | 100% | 交付物审查 |
|
||||
| 3 | 信息架构定义 | 100% | 交付物审查 |
|
||||
| 4 | 品牌基础定义 | 100% | 交付物审查 |
|
||||
| 5 | 成功指标量化 | ≥ 3 个指标 | 数值验证 |
|
||||
|
||||
## 交接文档
|
||||
|
||||
阶段结束时交接给 Phase 1：
|
||||
1. User Research Report
|
||||
2. Market Analysis Report
|
||||
3. Information Architecture Spec
|
||||
4. Brand Guidelines
|
||||
5. Success Metrics Definition
|
||||
|
||||
## 常见风险
|
||||
|
||||
| 风险 | 缓解措施 |
|
||||
|------|----------|
|
||||
| 需求不清晰 | 多轮用户验证 |
|
||||
| 范围蔓延 | 严格的 MoSCoW 优先级 |
|
||||
| 品牌不一致 | 早期建立设计系统 |
|
||||
|
||||
---
|
||||
|
||||
**预计时间**: 2-3 天
|
||||
**下一阶段**: Phase 1 - Strategy
|
||||
141
skills/.playbooks/phase-1-strategy.md
Normal file
141
skills/.playbooks/phase-1-strategy.md
Normal file
@@ -0,0 +1,141 @@
|
||||
# Phase 1: Strategy Playbook
|
||||
|
||||
> 策略阶段 - 定义解决方案架构和实施计划
|
||||
|
||||
---
|
||||
|
||||
## 阶段目标
|
||||
|
||||
基于 Discovery 阶段的发现，制定技术策略、架构设计和实施计划。
|
||||
|
||||
## 输入文档
|
||||
|
||||
从 Phase 0 接收：
|
||||
1. User Research Report
|
||||
2. Market Analysis Report
|
||||
3. Information Architecture Spec
|
||||
4. Brand Guidelines
|
||||
5. Success Metrics Definition
|
||||
|
||||
## 激活 Agents
|
||||
|
||||
| Agent | 角色 | 优先级 |
|
||||
|-------|------|--------|
|
||||
| **Backend Architect** | 系统架构设计 | 立即 |
|
||||
| **Sprint Prioritizer** | 任务分解和优先级 | 立即 |
|
||||
| **UX Architect** | 设计系统完善 | Day 2 |
|
||||
| **Security Engineer** | 安全架构审查 | Day 2 |
|
||||
|
||||
## 关键活动
|
||||
|
||||
### 1. 系统架构设计 (Day 1-3)
|
||||
|
||||
**Backend Architect 执行**:
|
||||
- 技术栈选型
|
||||
- 数据库 schema 设计
|
||||
- API 端点规划
|
||||
- 微服务/单体架构决策
|
||||
- 扩展性考虑
|
||||
|
||||
**交付物**:
|
||||
```markdown
|
||||
## System Architecture Document
|
||||
|
||||
### Technology Stack
|
||||
- Frontend: [技术]
|
||||
- Backend: [技术]
|
||||
- Database: [技术]
|
||||
- Infrastructure: [技术]
|
||||
|
||||
### Database Schema
|
||||
[ER 图或 schema 定义]
|
||||
|
||||
### API Endpoints
|
||||
| 端点 | 方法 | 描述 | 认证 |
|
||||
|------|------|------|------|
|
||||
|
||||
### Architecture Diagram
|
||||
[系统架构图]
|
||||
|
||||
### Scalability Considerations
|
||||
- 水平扩展: [策略]
|
||||
- 缓存策略: [描述]
|
||||
- CDN 配置: [描述]
|
||||
```
|
||||
|
||||
### 2. 任务分解 (Day 2-4)
|
||||
|
||||
**Sprint Prioritizer 执行**:
|
||||
- 将功能分解为用户故事
|
||||
- RICE 评分和优先级排序
|
||||
- Sprint 规划
|
||||
- 依赖关系映射
|
||||
|
||||
**交付物**:
|
||||
```markdown
|
||||
## Sprint Plan
|
||||
|
||||
### Backlog (RICE Scored)
|
||||
| # | 任务 | R | I | C | E | Score | Sprint |
|
||||
|---|------|---|---|---|---|-------|--------|
|
||||
|
||||
### Sprint Allocation
|
||||
- Sprint 1: [任务列表]
|
||||
- Sprint 2: [任务列表]
|
||||
- Sprint 3: [任务列表]
|
||||
|
||||
### Dependencies
|
||||
[依赖关系图]
|
||||
|
||||
### Risk Register
|
||||
| 风险 | 概率 | 影响 | 缓解措施 |
|
||||
```
|
||||
|
||||
### 3. 设计系统 (Day 2-4)
|
||||
|
||||
**UX Architect + Brand Guardian 协作**:
|
||||
- CSS 变量和 tokens
|
||||
- 组件库规划
|
||||
- 响应式断点
|
||||
- 主题系统（亮/暗）
|
||||
|
||||
### 4. 安全审查 (Day 3-4)
|
||||
|
||||
**Security Engineer 执行**:
|
||||
- 威胁建模
|
||||
- 认证/授权方案
|
||||
- 数据保护策略
|
||||
- 合规要求检查
|
||||
|
||||
## 阶段门禁
|
||||
|
||||
进入 Phase 2 前必须满足：
|
||||
|
||||
| # | 标准 | 阈值 | 验证方法 |
|
||||
|---|------|------|----------|
|
||||
| 1 | 架构文档完成 | 100% | 技术审查 |
|
||||
| 2 | Sprint 计划完成 | ≥ 2 Sprints | PM 审查 |
|
||||
| 3 | 设计系统定义 | 核心组件 100% | 设计审查 |
|
||||
| 4 | 安全审查通过 | 无 Critical 问题 | 安全审查 |
|
||||
| 5 | 依赖关系明确 | 100% 映射 | 依赖图验证 |
|
||||
|
||||
## 交接文档
|
||||
|
||||
阶段结束时交接给 Phase 2：
|
||||
1. System Architecture Document
|
||||
2. Sprint Plan
|
||||
3. Design System Spec
|
||||
4. Security Review Report
|
||||
5. Risk Register
|
||||
|
||||
## 质量标准
|
||||
|
||||
- 架构决策有文档化的 ADR (Architecture Decision Records)
|
||||
- 所有 API 端点有 OpenAPI 规格定义
|
||||
- 设计系统有可工作的 Storybook
|
||||
- 安全审查无 P0/P1 问题
|
||||
|
||||
---
|
||||
|
||||
**预计时间**: 3-5 天
|
||||
**下一阶段**: Phase 2 - Foundation
|
||||
158
skills/.playbooks/phase-2-foundation.md
Normal file
158
skills/.playbooks/phase-2-foundation.md
Normal file
@@ -0,0 +1,158 @@
|
||||
# Phase 2: Foundation Playbook
|
||||
|
||||
> 基础阶段 - 搭建项目骨架和核心基础设施
|
||||
|
||||
---
|
||||
|
||||
## 阶段目标
|
||||
|
||||
建立项目的核心技术基础，包括开发环境、CI/CD、数据库和核心 API。
|
||||
|
||||
## 输入文档
|
||||
|
||||
从 Phase 1 接收：
|
||||
1. System Architecture Document
|
||||
2. Sprint Plan
|
||||
3. Design System Spec
|
||||
4. Security Review Report
|
||||
5. Risk Register
|
||||
|
||||
## 激活 Agents
|
||||
|
||||
| Agent | 角色 | 优先级 |
|
||||
|-------|------|--------|
|
||||
| **DevOps Automator** | CI/CD 和基础设施 | 立即 |
|
||||
| **Backend Architect** | 核心 API 实现 | 立即 |
|
||||
| **Senior Developer** | 项目骨架搭建 | 立即 |
|
||||
| **Frontend Developer** | UI 框架搭建 | Day 2 |
|
||||
|
||||
## 关键活动
|
||||
|
||||
### 1. 项目初始化 (Day 1)
|
||||
|
||||
**Senior Developer 执行**:
|
||||
```bash
|
||||
# 创建项目结构
|
||||
mkdir -p {src,tests,docs,config}
|
||||
# 初始化版本控制
|
||||
git init
|
||||
# 设置代码规范
|
||||
# 配置 TypeScript/ESLint/Prettier
|
||||
```
|
||||
|
||||
**交付物**:
|
||||
- 完整的项目骨架
|
||||
- 配置文件（ESLint, Prettier, TypeScript）
|
||||
- README 和 CONTRIBUTING 文档
|
||||
|
||||
### 2. CI/CD 设置 (Day 1-2)
|
||||
|
||||
**DevOps Automator 执行**:
|
||||
- GitHub Actions / GitLab CI 配置
|
||||
- 测试自动化
|
||||
- 部署流程
|
||||
- 环境变量管理
|
||||
|
||||
**交付物**:
|
||||
```yaml
|
||||
# .github/workflows/ci.yml
|
||||
name: CI
|
||||
on: [push, pull_request]
|
||||
jobs:
|
||||
test:
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
- uses: actions/checkout@v3
|
||||
- name: Run tests
|
||||
run: |
|
||||
npm ci
|
||||
npm test
|
||||
|
||||
lint:
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
- uses: actions/checkout@v3
|
||||
- name: Lint
|
||||
run: npm run lint
|
||||
```
|
||||
|
||||
### 3. 数据库和 API (Day 2-4)
|
||||
|
||||
**Backend Architect 执行**:
|
||||
- 数据库迁移系统
|
||||
- 核心 API 端点
|
||||
- 认证中间件
|
||||
- 错误处理框架
|
||||
|
||||
**交付物**:
|
||||
- 数据库 schema 迁移
|
||||
- API 路由结构
|
||||
- 认证系统
|
||||
- API 文档 (OpenAPI)
|
||||
|
||||
### 4. UI 框架 (Day 2-4)
|
||||
|
||||
**Frontend Developer 执行**:
|
||||
- 组件库集成
|
||||
- 路由设置
|
||||
- 状态管理配置
|
||||
- 设计系统实现
|
||||
|
||||
**交付物**:
|
||||
- 基础组件库
|
||||
- 路由配置
|
||||
- 状态管理 store
|
||||
- 主题系统
|
||||
|
||||
## 阶段门禁
|
||||
|
||||
进入 Phase 3 前必须满足：
|
||||
|
||||
| # | 标准 | 阈值 | 验证方法 |
|
||||
|---|------|------|----------|
|
||||
| 1 | CI/CD 运行 | 绿色 | Pipeline 检查 |
|
||||
| 2 | 测试框架就绪 | 100% | 框架验证 |
|
||||
| 3 | 核心 API 可用 | ≥ 80% 端点 | API 测试 |
|
||||
| 4 | UI 框架就绪 | 核心组件 100% | 组件审查 |
|
||||
| 5 | 认证系统工作 | 100% | 登录测试 |
|
||||
| 6 | 文档完整 | README + API docs | 内容审查 |
|
||||
|
||||
## 验收标准
|
||||
|
||||
### CI/CD
|
||||
- [ ] Push 到 main 触发 CI
|
||||
- [ ] 所有测试自动运行
|
||||
- [ ] Lint 检查通过
|
||||
- [ ] 可部署到 staging
|
||||
|
||||
### 数据库
|
||||
- [ ] 迁移系统工作
|
||||
- [ ] Schema 符合设计
|
||||
- [ ] 索引已创建
|
||||
- [ ] 备份策略定义
|
||||
|
||||
### API
|
||||
- [ ] 健康检查端点工作
|
||||
- [ ] 认证端点工作
|
||||
- [ ] CORS 配置正确
|
||||
- [ ] 错误处理一致
|
||||
|
||||
### UI
|
||||
- [ ] 应用可启动
|
||||
- [ ] 路由工作
|
||||
- [ ] 主题切换工作
|
||||
- [ ] 响应式基础
|
||||
|
||||
## 交接文档
|
||||
|
||||
阶段结束时交接给 Phase 3：
|
||||
1. 项目代码仓库
|
||||
2. CI/CD 配置
|
||||
3. API 文档
|
||||
4. 组件库文档
|
||||
5. 部署指南
|
||||
|
||||
---
|
||||
|
||||
**预计时间**: 3-5 天
|
||||
**下一阶段**: Phase 3 - Build
|
||||
159
skills/.playbooks/phase-3-build.md
Normal file
159
skills/.playbooks/phase-3-build.md
Normal file
@@ -0,0 +1,159 @@
|
||||
# Phase 3: Build Playbook
|
||||
|
||||
> 构建阶段 - 功能开发、代码实现、迭代开发
|
||||
|
||||
---
|
||||
|
||||
## 阶段目标
|
||||
|
||||
实现所有计划功能，通过 Dev↔QA 循环确保质量，完成代码集成。
|
||||
|
||||
## 输入文档
|
||||
|
||||
从 Phase 2 接收：
|
||||
1. System Architecture Document
|
||||
2. Sprint Plan
|
||||
3. Design System Spec
|
||||
4. Security Review Report
|
||||
5. Risk Register
|
||||
|
||||
## 激活 Agents
|
||||
|
||||
| Agent | 角色 | 优先级 |
|
||||
|-------|------|--------|
|
||||
| **Senior Developer** | 核心功能实现 | 立即 |
|
||||
| **Frontend Developer** | UI 组件开发 | 立即 |
|
||||
| **Backend Architect** | API 实现 | 立即 |
|
||||
| **AI Engineer** | AI 功能集成 | 按需 |
|
||||
| **Reality Checker** | QA 验证 | 每任务完成时 |
|
||||
| **Evidence Collector** | 测试证据收集 | QA 时 |
|
||||
|
||||
## Dev↔QA 循环协议
|
||||
|
||||
```
|
||||
┌─────────────────────────────────────────────────────────────┐
|
||||
│ Dev↔QA 循环 │
|
||||
├─────────────────────────────────────────────────────────────┤
|
||||
│ │
|
||||
│ ┌─────────────┐ │
|
||||
│ │ Task Start │ │
|
||||
│ └──────┬──────┘ │
|
||||
│ │ │
|
||||
│ ▼ │
|
||||
│ ┌─────────────┐ │
|
||||
│ │ Developer │ ──── 实现功能 ────┐ │
|
||||
│ │ Implements │ │ │
|
||||
│ └─────────────┘ │ │
|
||||
│ ▲ ▼ │
|
||||
│ │ ┌─────────────┐ │
|
||||
│ │ │ Reality │ │
|
||||
│ │ │ Checker │ │
|
||||
│ │ │ QA Review │ │
|
||||
│ │ └──────┬──────┘ │
|
||||
│ │ │ │
|
||||
│ │ ┌──────────┴──────────┐ │
|
||||
│ │ │ │ │
|
||||
│ │ PASS │ │ FAIL │
|
||||
│ │ ▼ ▼ │
|
||||
│ │ ┌─────────────┐ ┌─────────────┐ │
|
||||
│ │ │ Task Done │ │ Retry < 3? │ │
|
||||
│ │ │ Next Task │ └──────┬──────┘ │
|
||||
│ │ └─────────────┘ │ │
|
||||
│ │ YES ─────┘ │
|
||||
│ │ │ │
|
||||
│ └──────────────────────────┘ │
|
||||
│ │ │
|
||||
│ ▼ NO │
|
||||
│ ┌─────────────┐ │
|
||||
│ │ ESCALATE │ → 重新分配/拆分/推迟 │
|
||||
│ └─────────────┘ │
|
||||
│ │
|
||||
└─────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
## 关键活动
|
||||
|
||||
### 1. Sprint 执行 (每个 Sprint)
|
||||
|
||||
**每日流程**:
|
||||
1. **Morning**: 检查 overnight 测试结果
|
||||
2. **Development**: 实现 Sprint backlog 中的任务
|
||||
3. **QA**: 完成的任务提交 Reality Checker
|
||||
4. **Evening**: 更新进度，处理阻塞
|
||||
|
||||
**任务状态追踪**:
|
||||
```markdown
|
||||
## Sprint N Progress
|
||||
|
||||
### In Progress
|
||||
| Task | Developer | Started | Status |
|
||||
|------|-----------|---------|--------|
|
||||
| [ID] | [Agent] | [Date] | [状态] |
|
||||
|
||||
### QA Pending
|
||||
| Task | Developer | QA Agent | Attempt |
|
||||
|------|-----------|----------|---------|
|
||||
| [ID] | [Agent] | [Agent] | [N]/3 |
|
||||
|
||||
### Completed This Sprint
|
||||
| Task | Developer | QA Agent | Attempts | Date |
|
||||
|------|-----------|----------|----------|------|
|
||||
|
||||
### Blocked
|
||||
| Task | Blocker | Impact | Resolution |
|
||||
|------|---------|--------|------------|
|
||||
```
|
||||
|
||||
### 2. 代码审查标准
|
||||
|
||||
**Reality Checker 检查清单**:
|
||||
- [ ] 功能与验收标准完全匹配
|
||||
- [ ] 代码遵循项目风格指南
|
||||
- [ ] 测试覆盖率 ≥ 80%
|
||||
- [ ] 无安全漏洞
|
||||
- [ ] 性能符合标准
|
||||
- [ ] 无障碍要求满足
|
||||
- [ ] 文档完整
|
||||
|
||||
### 3. 集成协议
|
||||
|
||||
**每次代码合并**:
|
||||
1. 运行完整测试套件
|
||||
2. 通过 Reality Checker 验证
|
||||
3. 更新 CHANGELOG
|
||||
4. 通知相关 Agents
|
||||
|
||||
## 质量门禁
|
||||
|
||||
每个 Sprint 结束时检查：
|
||||
|
||||
| # | 标准 | 阈值 | 验证方法 |
|
||||
|---|------|------|----------|
|
||||
| 1 | Sprint 目标完成 | 100% | 任务追踪 |
|
||||
| 2 | 首次通过率 | ≥ 70% | QA 统计 |
|
||||
| 3 | 测试覆盖率 | ≥ 80% | 覆盖率报告 |
|
||||
| 4 | 无 P0/P1 问题 | 0 | Issue 追踪 |
|
||||
| 5 | 文档更新 | 100% | 文档审查 |
|
||||
|
||||
## 交接文档
|
||||
|
||||
阶段结束时交接给 Phase 4：
|
||||
1. 完整的代码库
|
||||
2. 测试报告和覆盖率
|
||||
3. 已知问题列表
|
||||
4. 技术债务记录
|
||||
5. 部署检查清单
|
||||
|
||||
## 常见问题处理
|
||||
|
||||
| 问题 | 处理方式 |
|
||||
|------|----------|
|
||||
| 任务超时 | 评估复杂度，考虑拆分 |
|
||||
| QA 连续失败 | 升级，考虑重新分配 |
|
||||
| 依赖阻塞 | 标记阻塞，通知依赖方 |
|
||||
| 技术债务 | 记录，安排后续 Sprint |
|
||||
|
||||
---
|
||||
|
||||
**预计时间**: 2-4 周 (根据项目规模)
|
||||
**下一阶段**: Phase 4 - Hardening
|
||||
180
skills/.playbooks/phase-4-hardening.md
Normal file
180
skills/.playbooks/phase-4-hardening.md
Normal file
@@ -0,0 +1,180 @@
|
||||
# Phase 4: Hardening Playbook
|
||||
|
||||
> 强化阶段 - 性能优化、安全加固、生产准备
|
||||
|
||||
---
|
||||
|
||||
## 阶段目标
|
||||
|
||||
将系统从功能完整提升到生产就绪，包括性能优化、安全加固、监控配置。
|
||||
|
||||
## 输入文档
|
||||
|
||||
从 Phase 3 接收：
|
||||
1. 完整代码库
|
||||
2. 测试报告
|
||||
3. 已知问题列表
|
||||
4. 技术债务记录
|
||||
5. 部署检查清单
|
||||
|
||||
## 激活 Agents
|
||||
|
||||
| Agent | 角色 | 优先级 |
|
||||
|-------|------|--------|
|
||||
| **Performance Benchmarker** | 性能测试和优化 | 立即 |
|
||||
| **Security Engineer** | 安全审查和加固 | 立即 |
|
||||
| **DevOps Automator** | 监控和告警配置 | 立即 |
|
||||
| **Accessibility Auditor** | 无障碍最终检查 | Day 2 |
|
||||
| **Reality Checker** | 生产就绪验证 | 最后 |
|
||||
|
||||
## 关键活动
|
||||
|
||||
### 1. 性能优化 (Day 1-3)
|
||||
|
||||
**Performance Benchmarker 执行**:
|
||||
|
||||
```bash
|
||||
# Core Web Vitals 测试
|
||||
npx lighthouse http://localhost:3000 --output=json --output-path=./reports/lighthouse.json
|
||||
|
||||
# API 响应时间测试
|
||||
ab -n 1000 -c 100 http://localhost:3000/api/endpoint
|
||||
|
||||
# 数据库查询分析
|
||||
EXPLAIN ANALYZE SELECT * FROM users WHERE ...
|
||||
|
||||
# 内存泄漏检测
|
||||
node --inspect server.js
|
||||
# 打开 Chrome DevTools > Memory > Heap Snapshot
|
||||
```
|
||||
|
||||
**优化目标**:
|
||||
| 指标 | 目标值 |
|
||||
|------|--------|
|
||||
| LCP (Largest Contentful Paint) | < 2.5s |
|
||||
| FID (First Input Delay) | < 100ms |
|
||||
| CLS (Cumulative Layout Shift) | < 0.1 |
|
||||
| API P95 响应时间 | < 200ms |
|
||||
| 数据库查询 P95 | < 50ms |
|
||||
|
||||
### 2. 安全加固 (Day 1-3)
|
||||
|
||||
**Security Engineer 执行**:
|
||||
|
||||
```bash
|
||||
# 依赖漏洞扫描
|
||||
npm audit
|
||||
pip-audit
|
||||
|
||||
# SAST 扫描
|
||||
sonarqube-scanner
|
||||
|
||||
# OWASP ZAP 扫描
|
||||
zap-baseline.py -t http://localhost:3000
|
||||
|
||||
# 密钥泄露检查
|
||||
git secrets --scan-history
|
||||
```
|
||||
|
||||
**安全检查清单**:
|
||||
- [ ] 所有 API 端点有认证
|
||||
- [ ] 输入验证完整
|
||||
- [ ] SQL 注入防护
|
||||
- [ ] XSS 防护
|
||||
- [ ] CSRF Token 实现
|
||||
- [ ] Rate Limiting 配置
|
||||
- [ ] 敏感数据加密
|
||||
- [ ] 安全头配置 (CSP, HSTS, etc.)
|
||||
|
||||
### 3. 监控配置 (Day 2-4)
|
||||
|
||||
**DevOps Automator 执行**:
|
||||
|
||||
**指标收集**:
|
||||
- 应用指标 (请求率、错误率、延迟)
|
||||
- 基础设施指标 (CPU、内存、磁盘)
|
||||
- 业务指标 (用户活跃、转化率)
|
||||
|
||||
**告警配置**:
|
||||
| 告警 | 条件 | 严重程度 |
|
||||
|------|------|----------|
|
||||
| 服务不可用 | 健康检查失败 | Critical |
|
||||
| 高错误率 | 错误 > 1% | High |
|
||||
| 高延迟 | P95 > 500ms | High |
|
||||
| 内存使用 | > 85% | Medium |
|
||||
|
||||
### 4. 无障碍最终检查 (Day 3-4)
|
||||
|
||||
**Accessibility Auditor 执行**:
|
||||
|
||||
```bash
|
||||
# 自动化测试
|
||||
npx axe http://localhost:3000
|
||||
|
||||
# 手动测试清单
|
||||
- [ ] 键盘导航完整
|
||||
- [ ] 屏幕阅读器兼容
|
||||
- [ ] 颜色对比度 ≥ 4.5:1
|
||||
- [ ] 焦点指示清晰
|
||||
- [ ] 表单标签完整
|
||||
- [ ] Alt 文本存在
|
||||
```
|
||||
|
||||
### 5. 生产就绪验证 (Day 4-5)
|
||||
|
||||
**Reality Checker 最终验证**:
|
||||
|
||||
```markdown
|
||||
## Production Readiness Checklist
|
||||
|
||||
### 功能完整性
|
||||
- [ ] 所有 P0 功能实现
|
||||
- [ ] 所有 P1 功能实现
|
||||
- [ ] P2 功能已评估
|
||||
|
||||
### 性能
|
||||
- [ ] Core Web Vitals 达标
|
||||
- [ ] API 响应时间达标
|
||||
- [ ] 负载测试通过
|
||||
|
||||
### 安全
|
||||
- [ ] 无 Critical 漏洞
|
||||
- [ ] 无 High 漏洞
|
||||
- [ ] 安全审查通过
|
||||
|
||||
### 可靠性
|
||||
- [ ] 监控配置完成
|
||||
- [ ] 告警配置完成
|
||||
- [ ] 回滚流程测试
|
||||
|
||||
### 文档
|
||||
- [ ] API 文档完整
|
||||
- [ ] 部署文档完整
|
||||
- [ ] 运维手册完整
|
||||
```
|
||||
|
||||
## 阶段门禁
|
||||
|
||||
进入 Phase 5 前必须满足：
|
||||
|
||||
| # | 标准 | 阈值 | 验证方法 |
|
||||
|---|------|------|----------|
|
||||
| 1 | 性能基准达标 | 100% | Lighthouse + Load Test |
|
||||
| 2 | 安全漏洞 | 0 Critical/High | 扫描报告 |
|
||||
| 3 | 监控覆盖 | 100% | 配置审查 |
|
||||
| 4 | 无障碍合规 | WCAG 2.1 AA | 审计报告 |
|
||||
| 5 | Reality Checker 签署 | READY | 最终报告 |
|
||||
|
||||
## 交接文档
|
||||
|
||||
阶段结束时交接给 Phase 5：
|
||||
1. 性能基准报告
|
||||
2. 安全审计报告
|
||||
3. 监控配置文档
|
||||
4. 无障碍合规报告
|
||||
5. 生产就绪清单
|
||||
|
||||
---
|
||||
|
||||
**预计时间**: 1 周
|
||||
**下一阶段**: Phase 5 - Launch
|
||||
227
skills/.playbooks/phase-5-launch.md
Normal file
227
skills/.playbooks/phase-5-launch.md
Normal file
@@ -0,0 +1,227 @@
|
||||
# Phase 5: Launch Playbook
|
||||
|
||||
> 发布阶段 - 部署、验证、发布后监控
|
||||
|
||||
---
|
||||
|
||||
## 阶段目标
|
||||
|
||||
安全部署系统到生产环境，执行发布计划，确保平稳上线。
|
||||
|
||||
## 输入文档
|
||||
|
||||
从 Phase 4 接收：
|
||||
1. 性能基准报告
|
||||
2. 安全审计报告
|
||||
3. 监控配置文档
|
||||
4. 无障碍合规报告
|
||||
5. 生产就绪清单
|
||||
|
||||
## 激活 Agents
|
||||
|
||||
| Agent | 角色 | 优先级 |
|
||||
|-------|------|--------|
|
||||
| **DevOps Automator** | 部署执行 | 立即 |
|
||||
| **Reality Checker** | 发布验证 | 部署后 |
|
||||
| **Infrastructure Maintainer** | 基础设施监控 | 部署后 |
|
||||
| **Support Responder** | 用户支持准备 | 发布前 |
|
||||
| **Content Creator** | 发布公告 | 发布时 |
|
||||
|
||||
## 发布前检查清单
|
||||
|
||||
### T-24h: 最终准备
|
||||
|
||||
```markdown
|
||||
## Pre-Launch Checklist
|
||||
|
||||
### 代码冻结
|
||||
- [ ] 所有 PR 合并
|
||||
- [ ] Release 分支创建
|
||||
- [ ] 版本号更新
|
||||
- [ ] CHANGELOG 更新
|
||||
|
||||
### 基础设施
|
||||
- [ ] 生产环境配置验证
|
||||
- [ ] SSL 证书检查
|
||||
- [ ] DNS 配置确认
|
||||
- [ ] CDN 缓存预热
|
||||
|
||||
### 数据库
|
||||
- [ ] 迁移脚本测试
|
||||
- [ ] 备份完成
|
||||
- [ ] 回滚脚本准备
|
||||
|
||||
### 第三方服务
|
||||
- [ ] API 密钥验证
|
||||
- [ ] Webhook 配置
|
||||
- [ ] 限流配置
|
||||
|
||||
### 团队准备
|
||||
- [ ] On-call 排班确认
|
||||
- [ ] 通知渠道测试
|
||||
- [ ] 回滚流程演练
|
||||
```
|
||||
|
||||
## 部署流程
|
||||
|
||||
### Step 1: 部署到 Staging (T-4h)
|
||||
|
||||
```bash
|
||||
# 1. 部署到 Staging
|
||||
./deploy.sh staging v1.0.0
|
||||
|
||||
# 2. 运行烟雾测试
|
||||
./smoke-test.sh staging
|
||||
|
||||
# 3. Reality Checker 验证
|
||||
# 触发 Reality Checker 进行最终验证
|
||||
|
||||
# 4. 如果失败，修复并重试
|
||||
# 如果成功，继续生产部署
|
||||
```
|
||||
|
||||
### Step 2: 生产部署 (T-0)
|
||||
|
||||
```bash
|
||||
# 1. 备份当前版本
|
||||
./backup.sh production
|
||||
|
||||
# 2. 执行部署
|
||||
./deploy.sh production v1.0.0
|
||||
|
||||
# 3. 健康检查
|
||||
curl https://api.example.com/health
|
||||
|
||||
# 4. 烟雾测试
|
||||
./smoke-test.sh production
|
||||
|
||||
# 5. 如果失败，执行回滚
|
||||
./rollback.sh production
|
||||
```
|
||||
|
||||
### Step 3: 发布后验证 (T+15min)
|
||||
|
||||
**Reality Checker 执行**:
|
||||
|
||||
```markdown
|
||||
## Post-Launch Verification
|
||||
|
||||
### 功能验证
|
||||
- [ ] 用户注册流程
|
||||
- [ ] 用户登录流程
|
||||
- [ ] 核心业务流程
|
||||
- [ ] 支付流程 (如有)
|
||||
|
||||
### 性能验证
|
||||
- [ ] 页面加载时间
|
||||
- [ ] API 响应时间
|
||||
- [ ] 错误率检查
|
||||
|
||||
### 监控验证
|
||||
- [ ] 指标正常收集
|
||||
- [ ] 告警正常触发
|
||||
- [ ] 日志正常记录
|
||||
|
||||
### 用户验证
|
||||
- [ ] 无用户投诉
|
||||
- [ ] 支持工单正常
|
||||
```
|
||||
|
||||
## 发布后监控 (T+0 to T+24h)
|
||||
|
||||
### 实时监控 (第一小时)
|
||||
|
||||
| 指标 | 警告阈值 | 严重阈值 | 检查频率 |
|
||||
|------|----------|----------|----------|
|
||||
| 错误率 | > 0.5% | > 1% | 1 分钟 |
|
||||
| 响应时间 | > 300ms | > 500ms | 1 分钟 |
|
||||
| CPU 使用 | > 70% | > 85% | 1 分钟 |
|
||||
| 内存使用 | > 75% | > 90% | 1 分钟 |
|
||||
|
||||
### 短期监控 (24 小时)
|
||||
|
||||
- 每小时检查关键指标
|
||||
- 监控用户反馈渠道
|
||||
- 准备快速响应团队
|
||||
|
||||
## 回滚计划
|
||||
|
||||
### 触发条件
|
||||
|
||||
立即回滚如果：
|
||||
- 错误率 > 2%
|
||||
- 关键功能不可用
|
||||
- 数据丢失风险
|
||||
- 安全漏洞暴露
|
||||
|
||||
### 回滚步骤
|
||||
|
||||
```bash
|
||||
# 1. 宣布回滚
|
||||
./notify.sh "ROLLBACK INITIATED"
|
||||
|
||||
# 2. 执行回滚
|
||||
./rollback.sh production v0.9.0
|
||||
|
||||
# 3. 验证回滚
|
||||
./smoke-test.sh production
|
||||
|
||||
# 4. 通知团队
|
||||
./notify.sh "ROLLBACK COMPLETE"
|
||||
```
|
||||
|
||||
## 发布公告
|
||||
|
||||
### 内部通知
|
||||
|
||||
```markdown
|
||||
## 🚀 Release v1.0.0
|
||||
|
||||
### 发布时间
|
||||
[时间戳]
|
||||
|
||||
### 新功能
|
||||
- [功能 1]
|
||||
- [功能 2]
|
||||
|
||||
### 修复
|
||||
- [修复 1]
|
||||
- [修复 2]
|
||||
|
||||
### 已知问题
|
||||
- [问题 1] - 计划修复: [时间]
|
||||
|
||||
### 关键指标
|
||||
- 部署时间: [时间]
|
||||
- 烟雾测试: PASS
|
||||
- 错误率: [当前值]
|
||||
|
||||
### On-Call
|
||||
- 主要: [人员]
|
||||
- 备用: [人员]
|
||||
```
|
||||
|
||||
### 外部公告
|
||||
|
||||
**Content Creator 准备**:
|
||||
- 产品更新博客文章
|
||||
- 社交媒体公告
|
||||
- 用户邮件通知
|
||||
- 文档更新
|
||||
|
||||
## 阶段门禁
|
||||
|
||||
进入 Phase 6 (Operate) 前：
|
||||
|
||||
| # | 标准 | 验证方法 |
|
||||
|---|------|----------|
|
||||
| 1 | 部署成功 | 健康检查通过 |
|
||||
| 2 | 烟雾测试通过 | 自动化测试 |
|
||||
| 3 | 监控正常 | 指标收集验证 |
|
||||
| 4 | 无 Critical 问题 | Issue 追踪 |
|
||||
| 5 | 用户反馈正常 | 支持渠道监控 |
|
||||
|
||||
---
|
||||
|
||||
**预计时间**: 1-2 天
|
||||
**下一阶段**: Phase 6 - Operate
|
||||
198
skills/.playbooks/phase-6-operate.md
Normal file
198
skills/.playbooks/phase-6-operate.md
Normal file
@@ -0,0 +1,198 @@
|
||||
# Phase 6: Operate Playbook
|
||||
|
||||
> 运营阶段 - 持续监控、维护、优化
|
||||
|
||||
---
|
||||
|
||||
## 阶段目标
|
||||
|
||||
确保系统稳定运行，持续监控性能，快速响应问题，推动持续改进。
|
||||
|
||||
## 输入文档
|
||||
|
||||
从 Phase 5 接收：
|
||||
1. 生产部署确认
|
||||
2. 监控配置
|
||||
3. 发布报告
|
||||
4. 已知问题列表
|
||||
|
||||
## 激活 Agents
|
||||
|
||||
| Agent | 角色 | 触发条件 |
|
||||
|-------|------|----------|
|
||||
| **Infrastructure Maintainer** | 基础设施维护 | 持续 |
|
||||
| **Support Responder** | 用户支持 | 按需 |
|
||||
| **Performance Benchmarker** | 性能监控 | 定时/告警 |
|
||||
| **Analytics Reporter** | 数据分析 | 每周 |
|
||||
| **Legal Compliance Checker** | 合规检查 | 每月 |
|
||||
|
||||
## 运营活动
|
||||
|
||||
### 1. 日常监控 (Daily)
|
||||
|
||||
**Infrastructure Maintainer 执行**:
|
||||
|
||||
```markdown
|
||||
## Daily Health Check
|
||||
|
||||
### 系统健康
|
||||
| 指标 | 当前值 | 阈值 | 状态 |
|
||||
|------|--------|------|------|
|
||||
| 可用性 | [值] | > 99.9% | ✅/⚠️/❌ |
|
||||
| 错误率 | [值] | < 0.1% | ✅/⚠️/❌ |
|
||||
| P95 延迟 | [值] | < 200ms | ✅/⚠️/❌ |
|
||||
| CPU 使用 | [值] | < 70% | ✅/⚠️/❌ |
|
||||
| 内存使用 | [值] | < 80% | ✅/⚠️/❌ |
|
||||
| 磁盘使用 | [值] | < 80% | ✅/⚠️/❌ |
|
||||
|
||||
### 告警回顾
|
||||
- [日期] [告警类型] - [处理状态]
|
||||
- [日期] [告警类型] - [处理状态]
|
||||
|
||||
### 备份验证
|
||||
- 数据库备份: ✅
|
||||
- 文件备份: ✅
|
||||
- 配置备份: ✅
|
||||
```
|
||||
|
||||
### 2. 周报 (Weekly)
|
||||
|
||||
**Analytics Reporter 执行**:
|
||||
|
||||
```markdown
|
||||
## Weekly Operations Report
|
||||
|
||||
### 关键指标趋势
|
||||
| 指标 | 本周 | 上周 | 变化 |
|
||||
|------|------|------|------|
|
||||
| DAU | [值] | [值] | [±%] |
|
||||
| 请求量 | [值] | [值] | [±%] |
|
||||
| 错误率 | [值] | [值] | [±%] |
|
||||
| 平均延迟 | [值] | [值] | [±%] |
|
||||
|
||||
### 事件摘要
|
||||
- 总事件: [数量]
|
||||
- P0: [数量]
|
||||
- P1: [数量]
|
||||
- P2: [数量]
|
||||
- MTTR: [平均恢复时间]
|
||||
|
||||
### 用户反馈
|
||||
- 新工单: [数量]
|
||||
- 解决: [数量]
|
||||
- 待处理: [数量]
|
||||
- 满意度: [评分]
|
||||
|
||||
### 下周计划
|
||||
1. [计划项 1]
|
||||
2. [计划项 2]
|
||||
```
|
||||
|
||||
### 3. 事件响应 (On-Demand)
|
||||
|
||||
**事件分级**:
|
||||
|
||||
| 级别 | 定义 | 响应时间 | 升级时间 |
|
||||
|------|------|----------|----------|
|
||||
| P0 | 服务完全不可用 | 5 分钟 | 30 分钟 |
|
||||
| P1 | 核心功能受影响 | 15 分钟 | 1 小时 |
|
||||
| P2 | 部分功能受影响 | 1 小时 | 4 小时 |
|
||||
| P3 | 小问题/建议 | 1 工作日 | 1 周 |
|
||||
|
||||
**事件处理流程**:
|
||||
|
||||
```
|
||||
┌─────────────────────────────────────────────────────────────┐
|
||||
│ Incident Response Flow │
|
||||
├─────────────────────────────────────────────────────────────┤
|
||||
│ │
|
||||
│ 告警触发 │
|
||||
│ │ │
|
||||
│ ▼ │
|
||||
│ ┌─────────────┐ │
|
||||
│ │ 确认影响 │ ← 评估范围和严重程度 │
|
||||
│ └──────┬──────┘ │
|
||||
│ │ │
|
||||
│ ▼ │
|
||||
│ ┌─────────────┐ │
|
||||
│ │ 建立渠道 │ ← 创建 Slack channel / 会议室 │
|
||||
│ └──────┬──────┘ │
|
||||
│ │ │
|
||||
│ ▼ │
|
||||
│ ┌─────────────┐ │
|
||||
│ │ 止血措施 │ ← 快速恢复服务 (回滚/重启/切换) │
|
||||
│ └──────┬──────┘ │
|
||||
│ │ │
|
||||
│ ▼ │
|
||||
│ ┌─────────────┐ │
|
||||
│ │ 根因分析 │ ← 确定根本原因 │
|
||||
│ └──────┬──────┘ │
|
||||
│ │ │
|
||||
│ ▼ │
|
||||
│ ┌─────────────┐ │
|
||||
│ │ 永久修复 │ ← 防止再次发生 │
|
||||
│ └──────┬──────┘ │
|
||||
│ │ │
|
||||
│ ▼ │
|
||||
│ ┌─────────────┐ │
|
||||
│ │ 事后复盘 │ ← 文档化经验教训 │
|
||||
│ └─────────────┘ │
|
||||
│ │
|
||||
└─────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
### 4. 合规检查 (Monthly)
|
||||
|
||||
**Legal Compliance Checker 执行**:
|
||||
|
||||
- [ ] 数据保留政策执行
|
||||
- [ ] 隐私政策更新
|
||||
- [ ] 安全补丁应用
|
||||
- [ ] 访问权限审查
|
||||
- [ ] 合规报告生成
|
||||
|
||||
## 持续改进
|
||||
|
||||
### 技术债务管理
|
||||
|
||||
```markdown
|
||||
## Tech Debt Register
|
||||
|
||||
| # | 项目 | 影响 | 优先级 | 计划 Sprint |
|
||||
|---|------|------|--------|-------------|
|
||||
| 1 | [债务描述] | High | P1 | Sprint X |
|
||||
| 2 | [债务描述] | Medium | P2 | Sprint Y |
|
||||
```
|
||||
|
||||
### 性能优化机会
|
||||
|
||||
- 识别慢查询
|
||||
- 监控资源使用趋势
|
||||
- 评估新技术方案
|
||||
|
||||
## 自动化维护
|
||||
|
||||
### 定时任务
|
||||
|
||||
| 任务 | 频率 | 执行者 |
|
||||
|------|------|--------|
|
||||
| 日志轮转 | 每日 | Infrastructure Maintainer |
|
||||
| 备份验证 | 每日 | Infrastructure Maintainer |
|
||||
| 安全扫描 | 每周 | Security Engineer |
|
||||
| 依赖更新 | 每月 | DevOps Automator |
|
||||
| 成本审查 | 每月 | Finance Tracker |
|
||||
|
||||
## 升级触发
|
||||
|
||||
当出现以下情况时，考虑启动新的迭代：
|
||||
|
||||
- 用户需求积压超过阈值
|
||||
- 技术债务影响开发效率
|
||||
- 性能下降超过 20%
|
||||
- 安全漏洞需要修复
|
||||
- 新功能需求
|
||||
|
||||
---
|
||||
|
||||
**持续时间**: 持续进行
|
||||
**升级路径**: 启动 Phase 0-1 进行新功能开发
|
||||
Reference in New Issue
Block a user