dev-workflowlisted

# 开发工作流：本地功能分支 + 测试用例门禁（核心开发专用） 核心逻辑：**main 必须永远绿，且 main 上的内容必须是用户验收过的**。所有核心改动（新功能、bug 修复）走「测试方供用例 → 本地功能分支开发 → 全量测试（机器门禁）→ 构建测试包给用户安装验收（人工门禁）→ 合并回 main」。两道门禁各管一层：机器门禁防「改 A 坏 B」的客观回归，人工门禁防「用例全绿但不是用户想要的样子」的主观偏差——用例是需求的机器翻译，翻译本身可能有漏（尤其界面、体验、文案这类难以完全用例化的维度），人在合并前把关补上这层。 2026-09-07 起远端 GitHub PR / CI 流程取消（存量仓库的 ci.yml 保留不动、不主动删），裁决全部本地化。三权分立不变：**用例定义权归测试 Agent（Hopper / TestEngineerAgent）**——需求先转成验收用例（用例先行），开发 Agent 不写用例、不改用例；**代码实现权归开发 Agent**——只改实现代码去满足用例，永远不反向改用例迁就实现；**结果裁决权**归两道门禁 + Hopper 事后归档验收。 **流程总览**（各步细节见正文与 references）： 1. 第 0 步：定性——这次需求是不是核心开发 2. 第 1 步：开工门禁——main 上必须有本次需求的未通过用例组 3. 第 2 步：建 worktree + 功能分支 4. 第 3 步：开发（用例目录只读、问题终止上报） 5. 第 4 步：对齐 main + 检查用例变更 6. 第 5 步：全量测试（机器门禁） 7. 第 6 步：构建测试包 + 用户验收（人工门禁） 8. 第 7 步：超集校验 + 合并回 main 9. 第 8 步：收尾（Hopper 归档、清理） ## 第 0 步：定性——这次需求是不是核心开发 项目是软件项目 ≠ 这次需求就是核心开发。每次触发先判断：**改动会不会触碰核心源代码的运行行为、应不应该由测试用例来覆盖**——是则走本流程；纯文档、README、版本号、配置、格式调整是杂事，main 直改（`git add` → `/commit`）。拿不准时**从严走本流程或直接问用户**，宁重勿漏——把核心改动当杂事直改进 main，等于绕过两道门禁。 混合需求（核心功能 + 顺带文档）正常走本流程：琐碎文件修改不作为分支的开发目标，但功能开发必须同步的文档（README、CHANGELOG）在分支上顺带改是允许的，不算违规。 ## 第 1 步：开工门禁——main 上必须有本次需求的未通过用例组 以 **main 的最新提交**为基准检查（`git show main:test-cases/pending/` 之类，不能用脏工作区的状态冒充 main 状态）：`test-cases/` 目录结构齐全，且 `pending/` 下存在本次需求对应的用例组（`requirement.md` + 用例文件）。 不满足则**阻塞暂停，向用户汇报**：请用户找测试 Agent（Hopper）提供最新的测试用例和需求文档并同步进项目。开发 Agent 不自己补用例——这是用例定义权的边界。过渡期（Hopper 供用例能力就绪前）用户手工提供用例也走同一结构，流程不区分用例来源。 目录结构、权限、同步机制全貌见 `references/test-cases.md`（开工前读一次）。 ## 第 2 步：建 worktree + 功能分支 ```bash cd