kintone-customize-manager/.sisyphus/plans/core-features.md

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

• 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

---

• 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

---

• 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

---

• 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

---

• 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

---

• 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

---

• 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

---

• 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

---

• 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

---

• 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

---

• 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

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 场景证据文件存在
• 应用可启动并运行