37 KiB
Vibe-Kanban 工作流程規劃文件
版本: 1.0 日期: 2025-01-15 狀態: 規劃階段
概述
本文件定義一個完整的軟體開發工作流程,透過多個 AI 代理協作完成從需求探索到部署的完整生命週期。
目錄
1. 工作流程總覽
┌─────────────────────────────────────────────────────────────────────────────┐
│ VIBE-KANBAN 工作流程 │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ 階段1: 需求探索 │
│ ┌────────────┐ ┌────────────┐ │
│ │Brainstorm │ ──▶ │ CEO Review │ │
│ │ (PM) │ │ (商業價值) │ │
│ └────────────┘ └────────────┘ │
│ │ │ │
│ │ ┌────────────┘ │
│ ▼ ▼ │
│ 階段2: 規格設計 │
│ ┌────────────┐ ┌────────────┐ ┌────────────┐ ┌────────────┐ │
│ │ PRD │ ──▶ │ API Design │ ──▶ │ DB Schema │ ──▶ │ UX/原型 │ │
│ │ (PM) │ │ (後端) │ │ (DBA) │ │ (UX) │ │
│ └────────────┘ └────────────┘ └────────────┘ └────────────┘ │
│ │ │ │ │ │
│ └───────────────────┴───────────────────┴───────────────────┘ │
│ │ │
│ ▼ │
│ 階段3: 審核 ┌────────────┐ │
│ ┌────────────┐ │ Design │ │
│ │Design Review│ ◀────────────────────│ Review │ │
│ │ (通盤審核) │ │ (退回修改) │ │
│ └────────────┘ └────────────┘ │
│ │ │
│ │ 通過 │
│ ▼ │
│ 階段4: 任務拆分 │
│ ┌────────────────────────────────────────────────────────────────────┐ │
│ │ Task Breakdown │ │
│ │ (平行拆分前後端任務) │ │
│ └────────────────────────────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ 階段5: 實作 │
│ ┌────────────┐ ┌────────────┐ │
│ │ Frontend │ │ Backend │ │
│ │implementation│ │implementation│ │
│ └────────────┘ └────────────┘ │
│ │ │ │
│ └─────────────────┬───────────────────┘ │
│ ▼ │
│ 階段6: 驗收 │
│ ┌────────────────────────────────────────────────────────────────────┐ │
│ │ QA Testing │ │
│ │ (依照驗收標準測試) │ │
│ │ (不通過 → 退回步驟4) │ │
│ └────────────────────────────────────────────────────────────────────┘ │
│ │ │
│ │ 通過 │
│ ▼ │
│ 階段7: 合併審核 │
│ ┌────────────────────────────────────────────────────────────────────┐ │
│ │ PR Review │ │
│ │ (人類驗證) │ │
│ │ (不通過 → 退回步驟4) │ │
│ └────────────────────────────────────────────────────────────────────┘ │
│ │ │
│ │ 通過 │
│ ▼ │
│ 階段8: 部署 │
│ ┌────────────────────────────────────────────────────────────────────┐ │
│ │ Deploy │ │
│ │ (OPS) │ │
│ └────────────────────────────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ ┌────────────┐ │
│ │ 完成 │ │
│ └────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────────────────┘
2. 現有技能映射
2.1 可直接複用的技能
| 階段 | 技能名稱 | 檔案位置 | 用途 |
|---|---|---|---|
| 1. Brainstorming | brainstorming |
skills/brainstorming/ |
PM 需求探索 |
| 1. CEO Review | plan-ceo-review |
gstack/plan-ceo-review/ |
商業價值審核 |
| 3. Design Review | design-review |
gstack/design-review/ |
視覺/架構審核 |
| 3. Design Review | plan-design-review |
gstack/plan-design-review/ |
設計計畫審核 |
| 4. Task Breakdown | dispatching-parallel-agents |
skills/dispatching-parallel-agents/ |
平行任務分配 |
| 4. Task Breakdown | subagent-driven-development |
skills/subagent-driven-development/ |
子代理驅動開發 |
| 5. Implementation | writing-plans |
skills/writing-plans/ |
撰寫實作計畫 |
| 6. QA | qa |
gstack/qa/ |
QA 測試驗收 |
| 7. PR Review | review |
gstack/review/ |
PR 代碼審核 |
| 7. PR Review | requesting-code-review |
skills/requesting-code-review/ |
請求代碼審核 |
| 8. Deploy | land-and-deploy |
gstack/land-and-deploy/ |
合併與部署 |
| 8. Deploy | setup-deploy |
gstack/setup-deploy/ |
部署配置 |
2.2 現有技能功能摘要
brainstorming
- 輸入: 使用者的初步想法
- 輸出: 設計文件
- 流程: 探索專案 → 提問澄清 → 提案 → 設計文件
plan-ceo-review
- 輸入: 設計文件或計畫
- 輸出: 審核報告 + 擴展建議
- 模式: SCOPE_EXPANSION, SELECTIVE_EXPANSION, HOLD_SCOPE, SCOPE_REDUCTION
- 檢查: 架構、錯誤處理、安全性、效能、測試、部署
qa
- 輸入: 驗收標準 + 測試 URL
- 輸出: QA 報告 + Bug 修复
- 流程: 探索 → 測試 → 文件化 → 修复 → 驗證
land-and-deploy
- 輸入: PR 編號
- 輸出: 部署報告
- 流程: 預檢查 → 合併 → 部署 → Canary 驗證
3. 新建技能定義
3.1 pm-prd - 產品需求文件技能
---
name: pm-prd
description: "產品經理撰寫 PRD 和驗收標準。根據 brainstorming 輸出產出結構化的產品需求文件,包含功能性需求、非功能性需求、驗收標準。觸發時機:CEO 審核通過後。"
---
## 職責
PM 角色的AI 代理,負責:
1. 將 brainstorming 的想法轉化為結構化 PRD
2. 定義功能性需求
3. 定義非功能性需求- 效能、安全性、可用性等
4. 設定驗收標準
5. 優先順序排序
## 輸入
- Brainstorming 輸出文件
- CEO 審核結果
- 專案上下文 (CLAUDE.md, ARCHITECTURE.md 等現有文件)
## 輸出
- PRD 文件: `docs/prd/{YYYY-MM-DD}-{feature-slug}.md`
## PRD 模板結構
```markdown
# PRD: {功能名稱}
## Metadata
- 撰寫日期: {date}
- 狀態: Draft | Review | Approved
- 作者: PM Agent
- 關聯 Brainstorm: {link}
## 背景
### 問題陳述
### 目標使用者
### 商業價值
## 功能性需求
### FR-001: {需求標題}
- 描述:
- 優先級: P0 | P1 | P2
- 使用者故事: 作為{role},我想要{action},以便{benefit}
### FR-002: ...
## 非功能性需求
###NFR-001: 效能
- 描述: 頁面載入時間< 2秒
- 量測方式: ...
### NFR-002: 安全性
- 描述: 所有 API 需驗證
- 量測方式: ...
##驗收標準
### AC-001: {驗收項目}
- Given: 前置條件
- When: 觸發動作
- Then: 預期結果
- 自動化: 是/否
- 測試腳本: (連結到測試案例)
### AC-002: ...
## 排期建議
- Phase 1: ...
- Phase 2: ...
## 依賴
- 外部依賴: ...
- 內部依賴: ...
## 風險評估
- 風險: ...
- 緩解措施: ...
流程
graph TD
A[讀取 Brainstorming 文件] --> B[分析需求結構]
B --> C[產出功能性需求]
B --> D[產出非功能性需求]
C --> E[定義驗收標準]
D --> E
E --> F[優先級排序]
F --> G[風險評估]
G --> H[撰寫 PRD 文件]
H --> I[人類審核]
I -->|通過| J[進入下一階段]
I -->|修改| C
相依技能
- 前置:
brainstorming,plan-ceo-review - 後續:
be-api-design,dba-schema,ux-prototype
---
### 3.2 `be-api-design` - API 設計技能
```yaml
---
name: be-api-design
description: "後端工程師設計 API 規格。根據 PRD 產出 OpenAPI 3.0 規格文件,包含端點、請求/回應結構、錯誤處理。觸發時機:PRD 審核通過後。"
---
## 職責
後端工程師角色的 AI 代理,負責:
1. 分析 PRD 中的功能性需求
2. 設計 RESTful API 端點
3. 定義請求/回應 schema
4. 設計錯誤處理機制
5. 考量 API 版本控制
6. 產出 OpenAPI 3.0 規格
## 輸入
- PRD 文件
- 現有 API 風格 (專案中現有的 API 規格)
- 資料模型上下文
## 輸出
- API 規格文件: `docs/api/{YYYY-MM-DD}-{feature-slug}.yaml`
## API 設計模板
```yaml
openapi: 3.0.3
info:
title: {API名稱}
version: 1.0.0
description: |
{API 描述}
相關 PRD: {PRD 連結}
paths:
/api/v1/{resource}:
get:
summary: {操作描述}
tags:
- {標籤}
parameters:
- name: {參數名}
in: query | path | header
required: true | false
schema:
type: string
responses:
'200':
description: 成功回應
content:
application/json:
schema:
$ref: '#/components/schemas/{Schema}'
'400':
description: 請求錯誤
'401':
description: 未授權
'500':
description: 伺服器錯誤
components:
schemas:
{SchemaName}:
type: object
properties:
{property}:
type: {type}
description: {描述}
required:
- {required_fields}
設計考量清單
安全性
- 所有端點都有適當的認證機制
- 輸入驗證
- 速率限制
- CORS 配置
效能
- 分頁支援
- 快取策略
- 批次操作支援
可靠性
- 錯誤回應格式統一
- 重試機制建議
- 冪等性設計
流程
graph TD
A[讀取 PRD] --> B[識別資源與操作]
B --> C[設計端點結構]
C --> D[定義 Schema]
D --> E[設計錯誤處理]
E --> F[安全性審查]
F --> G[效能考量]
G --> H[產出 OpenAPI 文件]
H --> I[人類審核]
I -->|通過| J[進入 DB 規劃]
I -->|修改| C
相依技能
- 前置:
pm-prd - 後續:
dba-schema
---
### 3.3 `dba-schema` - 資料庫綱要技能
```yaml
---
name: dba-schema
description: "DBA 規劃資料庫綱要。根據 API 規格設計資料庫 schema,包含索引策略、遷移計畫、效能考量。觸發時機:API 設計完成後。"
---
## 職責
DBA 角色的 AI 代理,負責:
1. 分析 API 規格中的資料結構
2. 設計正規化的資料庫 schema
3. 規劃索引策略
4. 設計遷移計畫
5. 效能優化建議
## 輸入
- API 規格文件
- PRD 文件 (了解業務需求)
- 現有資料庫 schema (如有)
## 輸出
- Schema 文件: `docs/db/{YYYY-MM-DD}-{feature-slug}.sql`
- 遷移計畫: `docs/db/migrations/{version}-{description}.sql`
## Schema 設計模板
```sql
-- Migration: {feature_name}
-- Version: {version}
-- Date: {date}
-- Author: DBA Agent
-- Related API: {API規格連結}
-- ====== Tables ======
CREATE TABLE {table_name} (
idBIGSERIAL PRIMARY KEY,-- 效能考量
created_at TIMESTAMPTZ NOT NULL DEFAULT NOW(),
updated_at TIMESTAMPTZ NOT NULL DEFAULT NOW(),
-- 業務欄位
{column_name} {type} {constraints},
-- ...
);
-- ====== Indexes ======
-- 主要查詢索引
CREATE INDEX idx_{table}_{column} ON {table_name} ({column});
-- 複合索引 (考量查詢模式)
CREATE INDEX idx_{table}_{columns} ON {table_name} ({column1}, {column2});
-- ======Constraints ======
-- 外鍵關聯
ALTER TABLE {table_name}
ADD CONSTRAINT fk_{relation}
FOREIGN KEY ({column})
REFERENCES {related_table}({related_column})
ON DELETE CASCADE;
-- ====== Triggers ======
-- 自動更新 updated_at
CREATE TRIGGER update_{table}_updated_at
BEFORE UPDATE ON {table_name}
FOR EACH ROW
EXECUTE FUNCTION update_updated_at_column();
-- ====== Comments ======
COMMENT ON TABLE {table_name} IS '{描述}';
COMMENT ON COLUMN {table_name}.{column} IS '{描述}';
設計原則
正規化
- 達到第三正規化 (3NF)
- 視查詢模式進行反正規化優化
索引策略
- 主鍵: 自動建立
- 外鍵: 視查詢頻率決定
- 常用篩選條件: 建立索引
- 複合索引: 依查詢模式設計
效能考量
- 大表分區策略
- 讀寫分離建議
- 連線池配置
流程
graph TD
A[讀取 API 規格] --> B[識別資料實體]
B --> C[設計資料表]
C --> D[定義關聯]
D --> E[規劃索引]
E --> F[遷移計畫]
F --> G[效能審查]
G --> H[產出 Schema 文件]
H --> I[人類審核]
I -->|通過| J[進入 UX 原型]
I -->|修改| C
相依技能
- 前置:
be-api-design - 後續:
ux-prototype
---
### 3.4 `ux-prototype` - UX 原型技能
```yaml
---
name: ux-prototype
description: "UX 設計師產出原型設計。根據 PRD 和 API 規格設計使用者介面原型,整合 pancel.dev 或其他工具。觸發時機:API 和 DB 設計完成後。"
---
## 職責
UX 設計師角色的 AI 代理,負責:
1. 分析 PRD 中的使用者故事
2. 設計使用者流程
3. 產出線框圖
4. 設計互動原型
5. 確保設計與 API 規格對應
## 輸入
- PRD 文件
- API 規格文件
- DB Schema (了解資料結構)
## 輸出
- 設計文件: `docs/design/{YYYY-MM-DD}-{feature-slug}/`
- `user-flow.md` - 使用者流程
- `wireframes/` - 線框圖
- `prototype-link.md` - 原型連結
## 設計流程
### 1. 使用者流程圖
```markdown
# User Flow: {功能名稱}
## 流程圖
```mermaid
graph TD
A[登入頁面] --> B{已登入?}
B -->|是| C[首頁]
B -->|否| D[註冊/登入]
D --> E[填寫表單]
E --> F[提交]
F --> G{驗證成功?}
G -->|是| C
G -->|否| H[錯誤提示]
H --> D
頁面清單
| 頁面 | URL | 描述 | API 端點 |
|---|---|---|---|
| 登入 | /login | 使用者登入 | POST /api/v1/auth/login |
| 首頁 | / | 產品首頁 | GET /api/v1/dashboard |
### 2. 元件對應表
```markdown
# 元件與 API 對應
## 頁面: {page_name}
| 元件 | 資料來源 | API 端點 | 快取策略 |
|------|---------|---------|---------|
| 使用者列表 |Users API | GET /api/v1/users | SWR|
| 搜尋框 | Search API | GET /api/v1/search | Debounce |
3. 線框圖描述
使用文字描述關鍵頁面的線框圖:
# Wireframe: {page_name}
## 佈局
┌─────────────────────────────────────────┐ │Header│ │ Logo Nav │ User │ ├─────────────────────────────────────────┤ │ │ │ Main Content │ │ ┌─────────────────────────────────┐│ │ │ ││ │ │Content Area ││ │ │ ││ │ └─────────────────────────────────┘│ │ │ ├─────────────────────────────────────────┤ │ Footer │ └─────────────────────────────────────────┘
## 元件清單
- Header: 導航列
- ContentArea: 主要內容區
- Footer: 頁尾
##原型工具建議
選項 1: pancel.dev
- 優點: 快速產出、AI 協助
- 適用: 快速原型、內部工具
選項 2: Figma
- 優點: 專業設計、協作
- 適用: 產品設計、客戶展示
選項 3: 文字描述 + HTML
- 優點: 版本控制、直接實作
- 適用: 技術團隊
流程
graph TD
A[讀取 PRD 和 API 規格] --> B[識別使用者故事]
B --> C[設計使用者流程]
C --> D[繪製線框圖]
D --> E[元件與 API 對應]
E --> F[產出原型]
F --> G[人類審核]
G -->|通過| H[進入 Design Review]
G -->|修改| D
相依技能
- 前置:
pm-prd,be-api-design,dba-schema - 後續:
design-review
---
## 4. 主控技能設計
### 4.1 `vibe-kanban` 技能
```yaml
---
name: vibe-kanban
description: "完整的軟體開發工作流程協調器。管理從需求探索到部署的完整生命週期,支援階段間轉換、退回機制、狀態持久化。觸發方式:/vibe-kanban"
---
## 職責
工作流程的主控協調器,負責:
1. 狀態機管理 - 追蹤當前階段
2. 階段間轉換 - 自動觸發對應技能
3. 退回機制 - 處理審核不通過
4. 狀態持久化 - 儲存工作流進度
5. 進度報告 - 提供視覺化狀態
## 命令
- `/vibe-kanban start` - 開始新工作流
- `/vibe-kanban status` - 查看當前狀態
- `/vibe-kanban next` - 前往下一階段
- `/vibe-kanban back [reason]` - 退回上一階段
- `/vibe-kanban skip` - 跳過當前階段 (需確認)
## 狀態機
見 [第5節](#5-狀態機設計)
## 狀態持久化
```yaml
# .gstack/kanban/{project-slug}/state.yaml
version: 1.0
project: {project-name}
created_at: {ISO timestamp}
updated_at: {ISO timestamp}
current_phase: PRD
phase_status: IN_PROGRESS # PENDING | IN_PROGRESS | COMPLETED | BLOCKED
history:
- phase: BRAINSTORM
status: COMPLETED
started_at: 2025-01-15T10:00:00Z
completed_at: 2025-01-15T11:30:00Z
duration_minutes: 90
output: docs/brainstorm/2025-01-15-feature-x.md
triggered_skill: brainstorming
- phase: CEO_REVIEW
status: COMPLETED
started_at: 2025-01-15T11:30:00Z
completed_at: 2025-01-15T14:00:00Z
duration_minutes: 150
output: docs/ceo-review/2025-01-15-feature-x.md
triggered_skill: plan-ceo-review
notes: "通過,建議擴展範圍"
artifacts:
brainstorm: docs/brainstorm/2025-01-15-feature-x.md
prd: null # 待產出
api_spec: null
db_schema: null
ux_prototype: null
blockers: []
next_actions:
- "執行 /pm-prd 產出PRD"
階段轉換邏輯
# 階段轉換條件
TRANSITIONS = {
"BRAINSTORM": {
"next": "CEO_REVIEW",
"skill": "brainstorming",
"required_artifacts": ["brainstorm.md"],
"auto_trigger": True
},
"CEO_REVIEW": {
"next": "PRD",
"skill": "plan-ceo-review",
"required_artifacts": ["ceo-review.md"],
"approval_required": True
},
"PRD": {
"next": "API_DESIGN",
"skill": "pm-prd",
"required_artifacts": ["prd.md"],
"approval_required": True
},
"API_DESIGN": {
"next": "DB_SCHEMA",
"skill": "be-api-design",
"required_artifacts": ["api-spec.yaml"],
"approval_required": True
},
"DB_SCHEMA": {
"next": "UX_PROTOTYPE",
"skill": "dba-schema",
"required_artifacts": ["schema.sql"],
"approval_required": True
},
"UX_PROTOTYPE": {
"next": "DESIGN_REVIEW",
"skill": "ux-prototype",
"required_artifacts": ["prototype/"],
"approval_required": True
},
"DESIGN_REVIEW": {
"next": "TASK_BREAKDOWN",
"skill": "design-review",
"required_artifacts": ["review-report.md"],
"approval_required": True,
"can_fail_back_to": "PRD"# 可退回到PRD 階段
},
"TASK_BREAKDOWN": {
"next": "IMPLEMENTATION",
"skill": "dispatching-parallel-agents",
"required_artifacts": ["tasks.md"],
"approval_required": False
},
"IMPLEMENTATION": {
"next": "QA",
"skill": None,# 手動實作
"required_artifacts": ["code/"],
"approval_required": False
},
"QA": {
"next": "PR_REVIEW",
"skill": "qa",
"required_artifacts": ["qa-report.md"],
"approval_required": False,
"can_fail_back_to": "TASK_BREAKDOWN" # QA不通過退回步驟四
},
"PR_REVIEW": {
"next": "DEPLOY",
"skill": "review",
"required_artifacts": ["pr-review.md"],
"approval_required": True,
"can_fail_back_to": "TASK_BREAKDOWN" # PR審核不通過退回步驟四
},
"DEPLOY": {
"next": "COMPLETED",
"skill": "land-and-deploy",
"required_artifacts": ["deploy-report.md"],
"approval_required": False
}
}
流程圖
stateDiagram-v2
[*] --> BRAINSTORM: /vibe-kanban start
BRAINSTORM --> CEO_REVIEW: 通過
CEO_REVIEW --> PRD: 通過
CEO_REVIEW --> BRAINSTORM: 退回修改
PRD --> API_DESIGN: 通過
PRD --> CEO_REVIEW: major changes
API_DESIGN --> DB_SCHEMA: 通過
API_DESIGN --> PRD: 需求不符
DB_SCHEMA --> UX_PROTOTYPE: 通過
DB_SCHEMA --> API_DESIGN: schema衝突
UX_PROTOTYPE --> DESIGN_REVIEW: 完成
UX_PROTOTYPE --> DB_SCHEMA: 資料結構不符
DESIGN_REVIEW --> TASK_BREAKDOWN: 通過
DESIGN_REVIEW --> PRD: 設計不符需求
TASK_BREAKDOWN --> IMPLEMENTATION: 任務拆分完成
IMPLEMENTATION --> QA: 實作完成
QA --> TASK_BREAKDOWN: 測試不通過
QA --> PR_REVIEW: 測試通過
PR_REVIEW --> DEPLOY: 審核通過
PR_REVIEW --> TASK_BREAKDOWN: 審核不通過
DEPLOY --> COMPLETED: 部署成功
DEPLOY --> IMPLEMENTATION: 部署失敗
COMPLETED --> [*]
進度報告
執行 /vibe-kanban status 時顯示:
╔══════════════════════════════════════════════════════════════╗
║ VIBE-KANBAN 狀態 ║
╠══════════════════════════════════════════════════════════════╣
║專案: feature-user-auth ║
║ 當前階段: PRD (撰寫產品需求文件) ║
║ 狀態: IN_PROGRESS ║
║ ║
║已完成階段: ║
║ ✅ BRAINSTORM (90 分鐘) ║
║ ✅ CEO_REVIEW (150 分鐘) ║
║ ║
║ 待完成階段: ║
║ ⏳ PRD ← 你在這裡 ║
║ ⬜ API_DESIGN ║
║ ⬜ DB_SCHEMA ║
║ ⬜ UX_PROTOTYPE ║
║ ⬜ DESIGN_REVIEW ║
║ ⬜ TASK_BREAKDOWN ║
║ ⬜ IMPLEMENTATION ║
║ ⬜ QA ║
║ ⬜ PR_REVIEW ║
║ ⬜ DEPLOY ║
║ ║
║產出文件: ║
║ docs/brainstorm/2025-01-15-feature-x.md✅ ║
║ docs/ceo-review/2025-01-15-feature-x.md ║
║ docs/prd/ (待產出) ║
║ ║
║ 下一步: 執行 /pm-prd 產出PRD ║
╚══════════════════════════════════════════════════════════════╝
---
## 5. 狀態機設計
### 5.1 階段定義
| 階段 | 名稱 | 觸發技能 | 輸入 | 輸出 | 失敗退回 |
|------|------|---------|------|------|---------|
| 1 | BRAINSTORM | brainstorming | 使用者想法 | brainstorm.md | - |
| 2 | CEO_REVIEW | plan-ceo-review | brainstorm.md | review-report.md |階段1 |
| 3 | PRD | pm-prd | review-report.md | prd.md | 階段2 |
| 4 | API_DESIGN | be-api-design | prd.md | api-spec.yaml | 階段3 |
| 5 | DB_SCHEMA | dba-schema | api-spec.yaml | schema.sql | 階段4 |
| 6 | UX_PROTOTYPE | ux-prototype | prd.md + api-spec.yaml + schema.sql | prototype/ | 階段5 |
| 7 | DESIGN_REVIEW | design-review | prototype/ | review-report.md | 階段3 |
| 8 | TASK_BREAKDOWN | dispatching-parallel-agents | tasks.md | task-assignments | 階段7 |
| 9 | IMPLEMENTATION | 手動 | task-assignments | code/ | 階段8 |
| 10 | QA | qa | code/ + acceptance-criteria | qa-report.md | 階段8 (步驟四) |
| 11 | PR_REVIEW | review | code/ | pr-review.md | 階段8 (步驟四) |
| 12 | DEPLOY | land-and-deploy | pr-approved | deploy-report.md | 階段9 |
### 5.2 退回邏輯
```python
#退回規則
ROLLBACK_RULES = {
"QA_FAILED": {
"from_phase": "QA",
"to_phase": "TASK_BREAKDOWN",
"reason": "測試不通過,需要重新實作"
},
"PR_REVIEW_FAILED": {
"from_phase": "PR_REVIEW",
"to_phase": "TASK_BREAKDOWN",
"reason": "代碼審核不通過,需要修改"
},
"DESIGN_REVIEW_FAILED": {
"from_phase": "DESIGN_REVIEW",
"to_phase": "PRD",
"reason": "設計審核不通過,需求需要調整"
},
"DEPLOY_FAILED": {
"from_phase": "DEPLOY",
"to_phase": "IMPLEMENTATION",
"reason": "部署失敗,需要修復"
}
}
6. 文件結構規劃
.gstack/
└── kanban/
└── {project-slug}/
├── state.yaml# 工作流狀態
├── history/
│ ├── brainstorm-{date}.md│ ├── ceo-review-{date}.md
│ ├── prd-{date}.md
│ └── ...
└── artifacts/
├── prd/
├── api/
├── db/
└── design/
docs/
├── brainstorm/
│ └── {date}-{feature}.md
├── prd/
│ └── {date}-{feature}.md
├── api/
│ └── {date}-{feature}.yaml
├── db/
│ ├── {date}-{feature}.sql│ └── migrations/
│ └── {version}-{description}.sql
├── design/
│ └── {date}-{feature}/
│ ├── user-flow.md
│ ├── wireframes/
│ └── prototype-link.md
├── qa/
│ └── qa-report-{date}.md
└── deploy/
└── deploy-report-{date}.md
skills/
├── vibe-kanban/
│ ├── SKILL.md
│ ├── references/
│ │ └── workflow-diagram.md
│ └── templates/
│ └── state-template.yaml
├── pm-prd/
│ ├── SKILL.md
│ └── templates/
│ └── prd-template.md
├── be-api-design/
│ ├── SKILL.md
│ └── templates/
│ └── openapi-template.yaml
├── dba-schema/
│ ├── SKILL.md
│ └── templates/
│ └── schema-template.sql
└── ux-prototype/
├── SKILL.md
└── templates/
├── user-flow-template.md
└── component-mapping-template.md
7. 實施優先順序
Phase 1: 核心框架 (Week 1)
-
vibe-kanban 主控技能 - 最高優先級
- 狀態機核心邏輯
- 狀態持久化
- 階段轉換
-
pm-prd 技能 - 高優先級
- PRD 模板
- 驗收標準定義
Phase 2: 設計階段 (Week 2)
-
be-api-design 技能 - 中優先級
- API 規格產出
- OpenAPI 模板
-
dba-schema 技能 - 中優先級
- Schema 設計
- 遷移計畫
-
ux-prototype 技能 - 中優先級
- 使用者流程
- 元件對應
Phase 3: 整合測試 (Week 3)
- 整合測試
- 完整流程演練
- 邊界條件測試
- 退回機制測試
Phase 4: 優化 (Week 4)
-
性能優化
- 並行執行優化
- 快取策略
-
文件完善
- 使用指南
- 最佳實踐
8. 退回機制設計
8.1 退回觸發條件
# 退回觸發條件定義
ROLLBACK_TRIGGERS:
QA:
conditions:
- 測試覆蓋率< 80%
-關鍵功能測試失敗
- 效能未達標
target_phase: TASK_BREAKDOWN
message: "QA 測試未通過,需要返回任務拆分階段重新實作"
PR_REVIEW:
conditions:
- 代碼審核拒絕
- 安全漏洞發現
- 架構問題
target_phase: TASK_BREAKDOWN
message: "PR 審核未通過,需要返回任務拆分階段修改"
DESIGN_REVIEW:
conditions:
- 設計與需求不符
- UX 問題嚴重
- 技術不可行
target_phase: PRD
message: "設計審核未通過,需要返回 PRD 階段重新定義需求"
8.2 退回後處理
# 退回後的處理流程
ROLLBACK_PROCESS:
steps:
- name: "記錄退回原因"action: "write_to_history"
data:
phase: "{from_phase}"
reason: "{reason}"
timestamp: "{ISO timestamp}"
- name: "通知相關代理"
action: "notify_agents"
agents:
- "PM (if phase <= PRD)"
- "Backend (if phase > PRD)"
- "UX (if phase >= UX_PROTOTYPE)"
- name: "清理階段產出"
action: "archive_artifacts"
target: "{current_phase}"
- name: "恢復到目標階段"
action: "restore_state"
target_phase: "{target_phase}"
- name: "重新開始"
action: "trigger_skill"
skill: "{target_skill}"
9. 驗收標準模板
9.1 通用驗收標準
#驗收標準模板
## AC-001: {驗收項目名稱}
### Given (前置條件)
- 條件 1
- 條件 2
### When (觸發動作)
- 動作描述
### Then (預期結果)
- 結果 1
- 結果 2
### 測試資訊
- **優先級**: P0 | P1 | P2
- **類型**: 功能性 | 非功能性
- **自動化**: 是 | 否
- **測試腳本**: `tests/{test-file}`
---
## 驗收標準範例
### AC-001: 使用者登入功能
#### Given
- 使用者已註冊帳號
- 登入頁面已載入
#### When
- 使用者輸入正確的 email 和密碼
- 使用者點擊「登入」按鈕
#### Then
- 系統驗證帳號密碼
- 使用者被導向首頁
- Session 被建立
#### 測試資訊
- **優先級**: P0
- **類型**: 功能性
- **自動化**: 是
- **測試腳本**: `tests/auth/login.test.ts`
9.2 非功能性驗收標準
# 非功能性驗收標準
##NFR-001: 效能
### 頁面載入時間
-首頁載入 < 2 秒 (P95)
- API 回應 < 500ms (P95)
### 測試方法
- 使用 Lighthouse 測量
- 使用 k6 進行負載測試
---
##NFR-002: 安全性
### 認證與授權
- 所有 API 端點需驗證
- 實作 RBAC (Role-Based Access Control)
### 測試方法
- OWASP ZAP 掃描
- 滲透測試
---
##NFR-003: 可用性
### 正常運行時間
- 99.9% SLA
- 計畫性維護除外
### 測試方法
- 監控系統日誌
- Uptime 監控
附錄
A. 相關文件連結
- Brainstorming 技能:
/skills/brainstorming/SKILL.md - CEO Review 技能:
/gstack/plan-ceo-review/SKILL.md - QA 技能:
/gstack/qa/SKILL.md - Land and Deploy 技能:
/gstack/land-and-deploy/SKILL.md
B. 參考資料
- OpenAPI 規格: https://spec.openapis.org/oas/v3.1.0
- Gherkin 語法: https://cucumber.io/docs/gherkin/
- 12-Factor App: https://12factor.net/
C. 版本歷史
| 版本 | 日期 | 變更 |
|---|---|---|
| 1.0 | 2025-01-15 | 初版規劃文件 |