Files
kintone-customize-manager/.sisyphus/plans/core-features.md
xue jiahao da7f566ecf feat(core): implement Kintone Customize Manager core features
Wave 1 - Foundation:
- Add shared TypeScript type definitions (domain, kintone, version, ipc)
- Implement storage module with safeStorage encryption
- Implement Kintone REST API client with authentication
- Add IPC handlers for all features
- Expose APIs via preload contextBridge
- Setup Zustand stores for state management

Wave 2 - Domain Management:
- Implement Domain store with IPC actions
- Create DomainManager, DomainList, DomainForm components
- Connect UI components to store

Wave 3 - Resource Browsing:
- Create SpaceTree component for browsing spaces/apps
- Create AppDetail component for app configuration view
- Create CodeViewer component with syntax highlighting

Wave 4 - Deployment:
- Create FileUploader drag-and-drop component
- Create DeployDialog with step-by-step deployment flow
- Implement deployment IPC handler with auto-backup

Wave 5 - Version Management:
- Create VersionHistory component
- Implement version storage and rollback logic

Wave 6 - Integration:
- Integrate all components into main App layout
- Update main process entry point
- Configure TypeScript paths for renderer imports
2026-03-12 11:03:48 +08:00

858 lines
28 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

# Kintone Customize Manager - 核心功能实现计划
## TL;DR
> **Quick Summary**: 实现 Kintone Customize Manager 的核心功能,包括多 Domain 管理、资源浏览、拖拽部署和版本管理。
>
> **Deliverables**:
> - 多 Domain 配置管理(创建/编辑/删除/切换)
> - Space 和 App 浏览树
> - 拖拽文件部署到 Kintone
> - 版本历史管理
> - Kintone API 封装
>
> **Estimated Effort**: Large
> **Parallel Execution**: YES - 6 waves
> **Critical Path**: 类型定义 → Store → API 封装 → Domain 管理 → App 详情 → 部署功能
---
## Context
### Original Request
按照 REQUIREMENTS.md 创建任务计划,实现 Kintone Customize Manager 桌面应用的核心功能。
### Interview Summary
**Key Discussions**:
- **项目状态**: 全新项目,已使用 electron-vite 脚手架初始化并引入依赖库
- **优先级**: 核心功能优先Domain 管理 + 部署)
- **测试策略**: 仅 QA 验证(不需要单元测试)
**Research Findings**:
- 项目已配置 electron-vite + electron-builder
- 已安装 LobeHub UI + Ant Design 6 + CodeMirror 6
- 主进程入口已创建src/main/index.ts
- 基础项目结构已建立
---
## Work Objectives
### Core Objective
实现 Kintone Customize Manager 的核心功能,让用户能够管理多个 Kintone 实例、浏览应用资源、拖拽部署自定义代码。
### Concrete Deliverables
- `src/main/kintone-api.ts` - Kintone REST API 封装
- `src/main/storage.ts` - 文件系统和密码存储
- `src/renderer/src/stores/domainStore.ts` - Domain 状态管理
- `src/renderer/src/components/DomainManager/` - Domain 管理 UI
- `src/renderer/src/components/SpaceTree/` - Space/App 浏览树
- `src/renderer/src/components/AppDetail/` - App 详情页
- `src/renderer/src/components/FileUploader/` - 拖拽部署组件
- `src/renderer/src/components/VersionHistory/` - 版本历史
### Definition of Done
- [ ] 可创建/编辑/删除 Domain 配置
- [ ] 可浏览 Space 和 App 列表
- [ ] 可拖拽文件部署到 Kintone
- [ ] 部署前自动备份当前版本
- [ ] 可查看版本历史
### Must Have
- 密码使用 safeStorage 加密存储
- 所有 Kintone API 调用有错误处理
- 部署前有确认 Dialog 和代码对比
### Must NOT Have (Guardrails)
- 不包含 Plugin 管理功能P2 需求)
- 不包含批量操作功能P1 需求)
- 不包含国际化(初始版本仅中文)
- 不实现单元测试(仅 QA 验证)
### Commit Policy (IMPORTANT)
**一个任务 = 一次提交**
- ✅ 每个任务完成后必须单独提交
- ✅ 提交信息格式:`type(scope): description`(约定式提交)
- ❌ 不要将多个任务合并到一次提交中
- ⚠️ 如果计划中标注 "groups with N",同 Wave 任务可合并提交
**提交类型**`feat` | `fix` | `refactor` | `docs` | `style` | `test` | `chore`
**提交前检查清单**
1. 完成该任务的所有 "What to do" 内容
2. 通过 `npx tsc --noEmit` 类型检查
3. 执行该任务的 QA Scenarios 并保存证据到 `.sisyphus/evidence/`
4. 代码格式化(`npm run format`
- 不包含 Plugin 管理功能P2 需求)
- 不包含批量操作功能P1 需求)
- 不包含国际化(初始版本仅中文)
- 不实现单元测试(仅 QA 验证)
---
## Verification Strategy
> **ZERO HUMAN INTERVENTION** — ALL verification is agent-executed. No exceptions.
### Test Decision
- **Infrastructure exists**: NO
- **Automated tests**: None
- **Framework**: None
- **Agent-Executed QA**: ALWAYS (mandatory for all tasks)
### QA Policy
Every task MUST include agent-executed QA scenarios. Evidence saved to `.sisyphus/evidence/task-{N}-{scenario-slug}.{ext}`.
- **Frontend/UI**: Use Playwright — Navigate, interact, assert DOM, screenshot
- **API/Backend**: Use Bash (curl) — Send requests, assert status + response fields
- **Main Process**: Use Bash (ts-node) — Run IPC handlers, verify responses
---
## Execution Strategy
### Parallel Execution Waves
```
Wave 1 (Start Immediately — foundation + types):
├── Task 1: 共享类型定义 [quick]
├── Task 2: 主进程存储模块 [quick]
├── Task 3: Kintone API 封装 [deep]
├── Task 4: IPC 通信处理 [quick]
├── Task 5: Preload API 暴露 [quick]
└── Task 6: Zustand Store 基础 [quick]
Wave 2 (After Wave 1 — Domain 管理):
├── Task 7: Domain Store 完整实现 [quick]
├── Task 8: DomainManager UI 组件 [visual-engineering]
├── Task 9: Domain 表单 Dialog [visual-engineering]
└── Task 10: Domain 列表连接 Store [quick]
Wave 3 (After Wave 2 — 资源浏览):
├── Task 11: SpaceTree 组件 [visual-engineering]
├── Task 12: App 列表渲染 [visual-engineering]
├── Task 13: App 详情页布局 [visual-engineering]
└── Task 14: 代码查看器组件 [visual-engineering]
Wave 4 (After Wave 3 — 部署功能):
├── Task 15: FileUploader 拖拽组件 [visual-engineering]
├── Task 16: 部署位置选择器 [visual-engineering]
├── Task 17: 代码 Diff 对比组件 [visual-engineering]
├── Task 18: 部署确认 Dialog [visual-engineering]
└── Task 19: 部署执行 IPC 处理 [deep]
Wave 5 (After Wave 4 — 版本管理):
├── Task 20: 版本历史存储逻辑 [quick]
├── Task 21: VersionHistory UI 组件 [visual-engineering]
├── Task 22: 版本对比功能 [visual-engineering]
└── Task 23: 版本回滚部署 [deep]
Wave 6 (After Wave 5 — 集成 + QA):
├── Task 24: App 页面集成 [deep]
├── Task 25: 端到端 Playwright QA [unspecified-high]
└── Task 26: Git 清理 + 标签 [git]
Critical Path: Task 1 → Task 6 → Task 7 → Task 10 → Task 11 → Task 13 → Task 15 → Task 19 → Task 24 → Task 25
Parallel Speedup: ~65% faster than sequential
Max Concurrent: 5-6 (Waves 1, 3, 4)
```
---
## TODOs
- [x] 1. 共享类型定义
**What to do**:
- 创建 `src/renderer/src/types/domain.ts` - Domain 配置类型
- 创建 `src/renderer/src/types/kintone.ts` - Kintone API 响应类型
- 创建 `src/renderer/src/types/version.ts` - 版本历史类型
- 创建 `src/renderer/src/types/ipc.ts` - IPC 通信类型
**Must NOT do**:
- 不要包含业务逻辑(仅类型定义)
- 不要使用 `any` 类型
**Recommended Agent Profile**:
- **Category**: `quick`
- **Skills**: []
- **Reason**: 简单的类型定义文件,无复杂逻辑
**Parallelization**:
- **Can Run In Parallel**: YES
- **Parallel Group**: Wave 1 (with Tasks 2-6)
- **Blocks**: Tasks 3, 7, 11, 20
- **Blocked By**: None
**References**:
- `REQUIREMENTS.md:272-284` - Domain 数据结构
- `REQUIREMENTS.md:405-437` - Download/Version 数据结构
- `REQUIREMENTS.md:527-545` - Deploy 数据结构
**Acceptance Criteria**:
- [ ] `src/renderer/src/types/domain.ts` 包含 Domain 接口
- [ ] `src/renderer/src/types/kintone.ts` 包含 Kintone API 响应类型
- [ ] `src/renderer/src/types/version.ts` 包含 Version 接口
- [ ] `src/renderer/src/types/ipc.ts` 包含 IPC 请求/响应类型
**QA Scenarios**:
```
Scenario: 类型定义编译检查
Tool: Bash (tsc)
Preconditions: 项目根目录
Steps:
1. 运行 `npx tsc --noEmit`
2. 验证输出无错误
Expected Result: 编译通过,无类型错误
Evidence: .sisyphus/evidence/task-1-types-check.txt
```
**Commit**: YES (groups with 2-6)
- Message: `feat(types): add shared TypeScript type definitions`
- Files: `src/renderer/src/types/*.ts`
---
- [x] 2. 主进程存储模块
**What to do**:
- 创建 `src/main/storage.ts` - 文件系统操作
- 实现 safeStorage 加密存储密码
- 实现 Domain 配置的读取/保存
- 实现版本历史的存储逻辑
- 实现下载文件的存储逻辑
**Must NOT do**:
- 不要硬编码路径(使用 electron-store
- 不要明文存储密码
**Recommended Agent Profile**:
- **Category**: `quick`
- **Skills**: []
- **Reason**: 主进程工具模块,无 UI 交互
**Parallelization**:
- **Can Run In Parallel**: YES
- **Parallel Group**: Wave 1 (with Tasks 1, 3-6)
- **Blocks**: Tasks 3, 7, 20
- **Blocked By**: None
**References**:
- `REQUIREMENTS.md:125-145` - safeStorage 使用示例
- `REQUIREMENTS.md:197-214` - 本地存储结构
- `package.json:31` - electron-store 依赖
**Acceptance Criteria**:
- [ ] `src/main/storage.ts` 包含 saveDomain/getDomain/deleteDomain 函数
- [ ] 密码使用 safeStorage 加密
- [ ] 配置文件保存在 `~/.kintone-manager/config.json`
- [ ] Linux 环境检测 safeStorage 后端
**QA Scenarios**:
```
Scenario: 存储模块功能验证
Tool: Bash (ts-node)
Preconditions: 主进程环境
Steps:
1. 编写测试脚本调用 saveDomain
2. 调用 getDomain 验证读取
3. 调用 deleteDomain 验证删除
Expected Result: CRUD 操作均成功,返回预期结果
Evidence: .sisyphus/evidence/task-2-storage-test.txt
```
**Commit**: YES (groups with 1, 3-6)
- Message: `feat(main): implement storage module with safeStorage`
- Files: `src/main/storage.ts`
---
- [x] 3. Kintone API 封装
**What to do**:
- 创建 `src/main/kintone-api.ts` - Kintone REST API 客户端
- 实现认证(密码认证 + API Token
- 实现 Space 列表获取
- 实现 App 列表获取
- 实现 App 配置获取
- 实现文件上传/下载
- 实现应用配置更新(部署)
**Must NOT do**:
- 不要包含 UI 逻辑
- 不要硬编码域名和凭证
**Recommended Agent Profile**:
- **Category**: `deep`
- **Skills**: []
- **Reason**: 核心业务逻辑,需要处理认证、错误重试、文件流
**Parallelization**:
- **Can Run In Parallel**: YES
- **Parallel Group**: Wave 1 (with Tasks 1, 2, 4-6)
- **Blocks**: Tasks 11, 12, 19
- **Blocked By**: Task 1 (types), Task 2 (storage)
**References**:
- `REQUIREMENTS.md:331-345` - Kintone API 端点
- `REQUIREMENTS.md:502-522` - 部署 API 端点
- `REQUIREMENTS.md:77-88` - 密码认证 vs API Token
**Acceptance Criteria**:
- [ ] `src/main/kintone-api.ts` 包含 KintoneClient 类
- [ ] 支持密码认证和 API Token 认证
- [ ] 实现 getSpaces/getApps/getAppConfig 方法
- [ ] 实现 uploadFile/downloadFile方法
- [ ] 实现 updateAppConfig 方法(部署)
- [ ] 所有方法有错误处理和超时控制30 秒)
**QA Scenarios**:
```
Scenario: Kintone API 连接测试
Tool: Bash (ts-node)
Preconditions: 有效的 Kintone 凭证
Steps:
1. 创建 KintoneClient 实例
2. 调用 getSpaces() 获取 Space 列表
3. 调用 getApps(spaceId) 获取 App 列表
Expected Result: 成功返回 Space 和 App 列表,无错误
Evidence: .sisyphus/evidence/task-3-api-test.txt
Scenario: 错误处理验证
Tool: Bash (ts-node)
Preconditions: 无效的 Kintone 凭证
Steps:
1. 创建 KintoneClient 实例(错误凭证)
2. 调用 getSpaces()
Expected Result: 抛出认证错误,错误信息清晰
Evidence: .sisyphus/evidence/task-3-api-error.txt
```
**Commit**: YES (groups with 1, 2, 4-6)
- Message: `feat(main): implement Kintone REST API client`
- Files: `src/main/kintone-api.ts`
---
- [x] 4. IPC 通信处理
**What to do**:
- 创建 `src/main/ipc-handlers.ts` - IPC 请求处理
- 实现 Domain 管理的 IPC 处理create/update/delete/list
- 实现资源浏览的 IPC 处理getSpaces/getApps/getAppConfig
- 实现部署的 IPC 处理deploy/download
- 实现版本管理的 IPC 处理getVersions/rollback
**Must NOT do**:
- 不要包含业务逻辑(调用 kintone-api 和 storage
- 不要直接操作 DOM 或 UI
**Recommended Agent Profile**:
- **Category**: `quick`
- **Skills**: []
- **Reason**: 简单的 IPC 路由和错误处理
**Parallelization**:
- **Can Run In Parallel**: YES
- **Parallel Group**: Wave 1 (with Tasks 1-3, 5-6)
- **Blocks**: Tasks 7-10, 19
- **Blocked By**: Task 2 (storage), Task 3 (kintone-api)
**References**:
- `src/main/index.ts:58` - 现有 IPC 示例
- `REQUIREMENTS.md:228-268` - Domain 管理功能需求
**Acceptance Criteria**:
- [ ] `src/main/ipc-handlers.ts` 包含所有 Domain 管理 handler
- [ ] 包含所有资源浏览 handler
- [ ] 包含部署和下载 handler
- [ ] 包含版本管理 handler
- [ ] 所有 handler 返回统一格式:`{ success: boolean, data?: T, error?: string }`
**QA Scenarios**:
```
Scenario: IPC handler 调用测试
Tool: Bash (ts-node)
Preconditions: 主进程运行中
Steps:
1. 使用 ipcMain.invoke 调用 handler
2. 验证返回格式符合约定
Expected Result: 所有 handler 返回成功,格式正确
Evidence: .sisyphus/evidence/task-4-ipc-test.txt
```
**Commit**: YES (groups with 1-3, 5-6)
- Message: `feat(main): implement IPC handlers for all features`
- Files: `src/main/ipc-handlers.ts`
---
- [x] 5. Preload API 暴露
**What to do**:
- 更新 `src/preload/index.ts` - 暴露 API 到渲染进程
- 定义 `src/preload/index.d.ts` - TypeScript 类型
- 使用 contextBridge 暴露安全的 API
- 包含所有 IPC 调用的封装
**Must NOT do**:
- 不要暴露完整的 ipcRenderer不安全
- 不要包含业务逻辑
**Recommended Agent Profile**:
- **Category**: `quick`
- **Skills**: []
- **Reason**: 标准的 Electron preload 模式
**Parallelization**:
- **Can Run In Parallel**: YES
- **Parallel Group**: Wave 1 (with Tasks 1-4, 6)
- **Blocks**: Tasks 7-26 (all renderer tasks)
- **Blocked By**: Task 4 (ipc-handlers)
**References**:
- `src/preload/index.ts` - 现有 preload 脚本
- `src/preload/index.d.ts` - 现有类型定义
- `AGENTS.md:IPC 通信规范` - IPC 通信规范
**Acceptance Criteria**:
- [ ] `src/preload/index.ts` 暴露 window.api 对象
- [ ] `src/preload/index.d.ts` 定义 ElectronAPI 接口
- [ ] 包含所有 Domain 管理 API
- [ ] 包含所有资源浏览 API
- [ ] 包含所有部署和版本管理 API
- [ ] contextIsolation 启用
**QA Scenarios**:
```
Scenario: Preload API 可用性检查
Tool: Bash (Playwright)
Preconditions: 应用启动
Steps:
1. 打开开发者工具
2. 在 Console 中执行 `typeof window.api`
Expected Result: 返回 'object'API 对象存在
Evidence: .sisyphus/evidence/task-5-preload-check.png
```
**Commit**: YES (groups with 1-4, 6)
- Message: `feat(preload): expose IPC APIs via contextBridge`
- Files: `src/preload/index.ts`, `src/preload/index.d.ts`
---
- [x] 6. Zustand Store 基础架构
**What to do**:
- 创建 `src/renderer/src/stores/domainStore.ts` - Domain 状态
- 创建 `src/renderer/src/stores/appStore.ts` - App 浏览状态
- 创建 `src/renderer/src/stores/deployStore.ts` - 部署状态
- 创建 `src/renderer/src/stores/versionStore.ts` - 版本历史状态
- 使用 persist 中间件持久化
**Must NOT do**:
- 不要包含 UI 逻辑
- 不要直接调用 IPC在 actions 中调用)
**Recommended Agent Profile**:
- **Category**: `quick`
- **Skills**: []
- **Reason**: 标准 Zustand 模式
**Parallelization**:
- **Can Run In Parallel**: YES
- **Parallel Group**: Wave 1 (with Tasks 1-5)
- **Blocks**: Tasks 7-26 (all UI components)
- **Blocked By**: Task 1 (types), Task 5 (preload API)
**References**:
- `AGENTS.md:Zustand Store 规范` - Zustand 规范
- `package.json:37` - zustand 依赖
- `REQUIREMENTS.md:269-284` - Domain 数据结构
**Acceptance Criteria**:
- [ ] `domainStore.ts` 包含 domains/currentDomain/actions
- [ ] `appStore.ts` 包含 spaces/apps/currentApp
- [ ] `deployStore.ts` 包含 deployParams/status
- [ ] `versionStore.ts` 包含 versions/currentVersion
- [ ] 所有 store 使用 persist 中间件
- [ ] TypeScript 类型完整
**QA Scenarios**:
```
Scenario: Store 基础功能验证
Tool: Bash (Playwright)
Preconditions: 应用启动
Steps:
1. 打开开发者工具 Console
2. 验证 store 存在并可访问
Expected Result: 所有 store 可访问,无错误
Evidence: .sisyphus/evidence/task-6-store-check.png
```
**Commit**: YES (groups with 1-5)
- Message: `feat(renderer): setup Zustand stores for all features`
- Files: `src/renderer/src/stores/*.ts`
---
- [x] 7. Domain Store 完整实现
**What to do**:
- 完善 `domainStore.ts` - 添加 IPC 调用
- 实现 loadDomains - 加载所有 Domain
- 实现 addDomain - 添加新 Domain
- 实现 updateDomain - 更新 Domain
- 实现 deleteDomain - 删除 Domain
- 实现 setCurrentDomain - 切换 Domain
- 实现 testConnection - 测试连接
**Must NOT do**:
- 不要包含 UI 逻辑
- 不要硬编码错误处理
**Recommended Agent Profile**:
- **Category**: `quick`
- **Skills**: []
- **Reason**: Store 逻辑扩展
**Parallelization**:
- **Can Run In Parallel**: YES
- **Parallel Group**: Wave 2 (with Tasks 8-10)
- **Blocks**: Tasks 8-10 (Domain UI)
- **Blocked By**: Task 6 (store基础), Task 5 (preload API)
**References**:
- `src/renderer/src/stores/domainStore.ts` - 基础 store
- `REQUIREMENTS.md:228-268` - Domain 管理功能
**Acceptance Criteria**:
- [ ] 所有 actions 调用 window.api
- [ ] 错误处理完善
- [ ] 状态更新正确
- [ ] 连接状态检测实现
**QA Scenarios**:
```
Scenario: Domain CRUD 操作
Tool: Bash (Playwright)
Preconditions: 应用启动
Steps:
1. 调用 addDomain 添加测试 Domain
2. 调用 loadDomains 验证已添加
3. 调用 updateDomain 更新信息
4. 调用 deleteDomain 删除
Expected Result: 所有操作成功,状态正确更新
Evidence: .sisyphus/evidence/task-7-domain-crud.txt
```
**Commit**: YES
- Message: `feat(store): implement domain store actions with IPC`
- Files: `src/renderer/src/stores/domainStore.ts`
---
- [x] 8. DomainManager UI 组件
**What to do**:
- 创建 `src/renderer/src/components/DomainManager/DomainManager.tsx`
- 创建 `src/renderer/src/components/DomainManager/DomainList.tsx`
- 创建 `src/renderer/src/components/DomainManager/DomainItem.tsx`
- 使用 LobeHub UI + Ant Design 组件
- 显示 Domain 列表和连接状态
**Must NOT do**:
- 不要包含业务逻辑(使用 store
- 不要直接调用 IPC
**Recommended Agent Profile**:
- **Category**: `visual-engineering`
- **Skills**: []
- **Reason**: UI 组件开发,需要设计布局
**Parallelization**:
- **Can Run In Parallel**: YES
- **Parallel Group**: Wave 2 (with Tasks 7, 9-10)
- **Blocks**: Tasks 10 (连接 Store)
- **Blocked By**: Task 7 (domain store)
**References**:
- `AGENTS.md:UI 组件规范` - LobeHub UI + antd-style
- `src/renderer/src/App.tsx` - 现有组件示例
- `package.json:27-30` - LobeHub UI + Ant Design
**Acceptance Criteria**:
- [ ] DomainManager 组件包含 Domain 列表
- [ ] DomainItem 显示名称、域名、连接状态
- [ ] 使用 antd-style 样式
- [ ] 支持暗黑模式
- [ ] 响应式布局
**QA Scenarios**:
```
Scenario: DomainManager 渲染检查
Tool: Playwright
Preconditions: 应用启动,有测试 Domain
Steps:
1. 导航到 DomainManager 页面
2. 验证 Domain 列表渲染
3. 验证连接状态图标显示
Expected Result: Domain 列表正确显示,样式正确
Evidence: .sisyphus/evidence/task-8-domain-manager-render.png
```
**Commit**: YES
- Message: `feat(ui): create DomainManager components`
- Files: `src/renderer/src/components/DomainManager/*.tsx`
---
- [x] 9. Domain 表单 Dialog
**What to do**:
- 创建 `src/renderer/src/components/DomainManager/DomainForm.tsx`
- 实现创建 Domain 表单
- 实现编辑 Domain 表单
- 使用 Ant Design Form + Modal
- 表单验证(必填字段、格式检查)
**Must NOT do**:
- 不要包含业务逻辑(提交调用 store
- 不要硬编码验证规则
**Recommended Agent Profile**:
- **Category**: `visual-engineering`
- **Skills**: []
- **Reason**: 表单 UI 组件
**Parallelization**:
- **Can Run In Parallel**: YES
- **Parallel Group**: Wave 2 (with Tasks 7-8, 10)
- **Blocks**: Tasks 10 (表单使用)
- **Blocked By**: Task 7 (domain store)
**References**:
- `REQUIREMENTS.md:228-247` - Domain 创建/编辑需求
- `AGENTS.md:UI 组件规范` - Ant Design 使用
**Acceptance Criteria**:
- [ ] DomainForm 组件支持创建和编辑模式
- [ ] 必填字段验证(名称、域名、用户名、密码)
- [ ] 认证类型切换(密码/API Token
- [ ] API Token 字段条件显示
- [ ] 提交成功关闭 Dialog
**QA Scenarios**:
```
Scenario: 创建 Domain 表单
Tool: Playwright
Preconditions: 应用启动
Steps:
1. 点击"添加 Domain"按钮
2. 填写表单所有字段
3. 提交表单
4. 验证成功提示和 Dialog 关闭
Expected Result: 表单提交成功Domain 添加到列表
Evidence: .sisyphus/evidence/task-9-domain-form-create.png
Scenario: 表单验证
Tool: Playwright
Preconditions: 打开创建 Domain Dialog
Steps:
1. 不填写任何字段,点击提交
2. 验证错误提示显示
Expected Result: 显示必填字段错误提示
Evidence: .sisyphus/evidence/task-9-domain-form-validation.png
```
**Commit**: YES
- Message: `feat(ui): create DomainForm dialog component`
- Files: `src/renderer/src/components/DomainManager/DomainForm.tsx`
---
- [x] 10. Domain 列表连接 Store
**What to do**:
- 更新 `DomainManager.tsx` - 连接 Domain Store
- 使用 useDomainStore 获取状态
- 实现添加/编辑/删除按钮事件
- 实现 Domain 切换功能
- 实现连接状态检测
**Must NOT do**:
- 不要创建新的 store
- 不要直接调用 IPC
**Recommended Agent Profile**:
- **Category**: `quick`
- **Skills**: []
- **Reason**: 连接现有 store 和组件
**Parallelization**:
- **Can Run In Parallel**: NO
- **Parallel Group**: Sequential (after Tasks 7-9)
- **Blocks**: Tasks 11-26 (需要 Domain 切换)
- **Blocked By**: Tasks 7, 8, 9
**References**:
- `src/renderer/src/stores/domainStore.ts` - Domain Store
- `src/renderer/src/components/DomainManager/` - 现有组件
**Acceptance Criteria**:
- [ ] DomainManager 显示所有 Domain
- [ ] 点击 Domain 切换当前 Domain
- [ ] 添加按钮打开创建 Dialog
- [ ] 编辑按钮打开编辑 Dialog
- [ ] 删除按钮显示确认 Dialog
**QA Scenarios**:
```
Scenario: Domain 切换
Tool: Playwright
Preconditions: 有多个 Domain
Steps:
1. 点击 Domain A
2. 验证当前 Domain 状态更新
3. 验证连接状态检测触发
Expected Result: Domain 切换成功,状态更新
Evidence: .sisyphus/evidence/task-10-domain-switch.txt
```
**Commit**: YES
- Message: `feat(ui): connect DomainManager to store`
- Files: `src/renderer/src/components/DomainManager/DomainManager.tsx`
---
- [x] 11. SpaceTree 组件
**What to do**:
- 创建 `src/renderer/src/components/SpaceTree/SpaceTree.tsx`
- 创建 `src/renderer/src/components/SpaceTree/SpaceNode.tsx`
- 创建 `src/renderer/src/components/SpaceTree/AppNode.tsx`
- 使用 Ant Design Tree 组件
- 显示 Space 分组和 App 列表
- 支持搜索和过滤
**Must NOT do**:
- 不要包含业务逻辑(使用 appStore
- 不要直接调用 IPC
**Recommended Agent Profile**:
- **Category**: `visual-engineering`
- **Skills**: []
- **Reason**: UI 树形组件开发
**Parallelization**:
- **Can Run In Parallel**: YES
- **Parallel Group**: Wave 3 (with Tasks 12-14)
- **Blocks**: Tasks 13-14 (App 详情)
- **Blocked By**: Task 10 (Domain 切换)
**References**:
- `REQUIREMENTS.md:296-330` - 资源浏览功能
- `AGENTS.md:UI 组件规范` - Ant Design Tree
**Acceptance Criteria**:
- [ ] SpaceTree 显示所有 Space
- [ ] 每个 Space 下显示 App 列表
- [ ] 支持展开/折叠 Space
- [ ] 点击 App 节点触发选择事件
- [ ] 支持按名称搜索 App
**QA Scenarios**:
```
Scenario: SpaceTree 渲染
Tool: Playwright
Preconditions: 已选择 Domain有 Space 和 App
Steps:
1. 导航到资源浏览页面
2. 验证 Space 列表渲染
3. 展开 Space验证 App 列表显示
Expected Result: Space 和 App 正确显示,树形结构完整
Evidence: .sisyphus/evidence/task-11-spacetree-render.png
Scenario: App 搜索
Tool: Playwright
Preconditions: SpaceTree 已加载
Steps:
1. 在搜索框输入 App 名称关键词
2. 验证过滤后的 App 列表
Expected Result: 只显示匹配的 App
Evidence: .sisyphus/evidence/task-11-spacetree-search.png
```
**Commit**: YES
- Message: `feat(ui): create SpaceTree component for browsing resources`
- Files: `src/renderer/src/components/SpaceTree/*.tsx`
---
- [ ] 12-26. [待补充 - 由于输出限制,任务 12-26 将在后续会话中补充]
> **Note**: 受模型输出 token 限制,任务 12-26 的完整详情需要在执行过程中补充。
> 关键任务包括:
> - Task 12: App 列表渲染
> - Task 13: App 详情页布局
> - Task 14: 代码查看器组件
> - Task 15-19: 部署功能FileUploader、位置选择、Diff 对比、确认 Dialog、部署执行
> - Task 20-23: 版本管理存储、UI、对比、回滚
> - Task 24: App 页面集成
> - Task 25: 端到端 Playwright QA
> - Task 26: Git 清理 + 标签
**执行策略**: 按照 Execution Strategy 中的 Wave 3-6 逐步执行,每个任务的详细规格参考 REQUIREMENTS.md 对应章节。
---
## Final Verification Wave
> 4 review agents run in PARALLEL. ALL must APPROVE. Rejection → fix → re-run.
- [ ] F1. **Plan Compliance Audit** — `oracle`
Read the plan end-to-end. For each "Must Have": verify implementation exists (read file, curl endpoint, run command). For each "Must NOT Have": search codebase for forbidden patterns — reject with file:line if found. Check evidence files exist in .sisyphus/evidence/. Compare deliverables against plan.
Output: `Must Have [N/N] | Must NOT Have [N/N] | Tasks [N/N] | VERDICT: APPROVE/REJECT`
- [ ] F2. **Code Quality Review** — `unspecified-high`
Run `tsc --noEmit` + linter + `bun test`. Review all changed files for: `as any`/`@ts-ignore`, empty catches, console.log in prod, commented-out code, unused imports. Check AI slop: excessive comments, over-abstraction, generic names (data/result/item/temp).
Output: `Build [PASS/FAIL] | Lint [PASS/FAIL] | Tests [N pass/N fail] | Files [N clean/N issues] | VERDICT`
- [ ] F3. **Real Manual QA** — `unspecified-high` (+ `playwright` skill if UI)
Start from clean state. Execute EVERY QA scenario from EVERY task — follow exact steps, capture evidence. Test cross-task integration (features working together, not isolation). Test edge cases: empty state, invalid input, rapid actions. Save to `.sisyphus/evidence/final-qa/`.
Output: `Scenarios [N/N pass] | Integration [N/N] | Edge Cases [N tested] | VERDICT`
- [ ] F4. **Scope Fidelity Check** — `deep`
For each task: read "What to do", read actual diff (git log/diff). Verify 1:1 — everything in spec was built (no missing), nothing beyond spec was built (no creep). Check "Must NOT do" compliance. Detect cross-task contamination: Task N touching Task M's files. Flag unaccounted changes.
Output: `Tasks [N/N compliant] | Contamination [CLEAN/N issues] | Unaccounted [CLEAN/N files] | VERDICT`
---
## Commit Strategy
- **Wave 1**: `feat(core): foundation modules` — types, storage, kintone-api, ipc, preload, stores
- **Wave 2**: `feat(domain): domain management` — domain store, DomainManager UI, DomainForm
- **Wave 3**: `feat(browse): resource browsing` — SpaceTree, AppList, AppDetail, CodeViewer
- **Wave 4**: `feat(deploy): drag-and-drop deployment` — FileUploader, position selector, diff view, deploy dialog
- **Wave 5**: `feat(version): version management` — version history, diff comparison, rollback
- **Wave 6**: `feat(integration): app integration + QA` — full app page, Playwright tests
---
## Success Criteria
### Verification Commands
```bash
npx tsc --noEmit # Expected: no errors
npm run dev # Expected: dev server starts successfully
npm run build # Expected: production build completes
```
### Final Checklist
- [ ] 所有"Must Have"功能实现
- [ ] 所有"Must NOT Have"功能未实现
- [ ] 所有编译通过tsc --noEmit
- [ ] 所有 QA 场景证据文件存在
- [ ] 应用可启动并运行