# Dada 开发约定

## 适用范围

本约定自当前“Dada P0-A Windows 单机内测版”第一版开发起立即生效，适用于任务计划中的每个 `TASK-*`，也适用于第一版完成后的问题修改和相关工单。

## 开发约定

- 每个 `TASK-*` 或后续工单都是独立交付单元。完成测试与回归后，必须形成范围明确的本地 Git 提交，推送到 `intelligrow` 组织仓库的同名 Gitea 远端分支，并记录任务号、完整提交 SHA、远端分支和远端哈希核对结果。不得等第一版全部开发完成后再统一提交；本地未提交、推送失败、仅推送个人命名空间或远端哈希不一致时，不得宣告当前任务完成，也不得开始下一任务。
- 修复任何工单必须在独立的 git worktree 中进行；开工前先用 `git worktree add` 创建专属工作目录，避免污染主工作区、便于多工单并行。修 CI 配置（Dockerfile、Drone 流水线等）可以直接在主仓库改，因为 CI 改动要打 tag 才能触发构建。
- 处理任何工单必须先检查并使用适用的 Superpowers Skill；在分析、提问、制定计划或改代码前，至少先启用 `using-superpowers`，并按任务性质继续使用 `systematic-debugging`、`test-driven-development`、`using-git-worktrees`、`verification-before-completion` 等相关技能。若判断没有适用技能，必须简短说明原因后再继续。
- 新功能需求类工单必须先使用 Superpowers 的 `brainstorming` 技能帮助澄清目标、约束和方案，再进入计划或实现；缺陷类工单必须先使用 `systematic-debugging` 技能复现问题并分析 root cause，再开始修复，禁止在根因未明确时直接改代码。
- 实现或修复工单完成后，必须继续按 Superpowers 收尾流程执行验证、代码审查、PR/合并准备和工作区清理；通常应依次使用 `verification-before-completion`、`requesting-code-review`、`finishing-a-development-branch` 等适用技能，在完成这些流程前不得声称工单已结束。