Feature 开发闭环

Yoda 的 Feature 工作流由两个彼此联动的界面组成：

• Feature 交付是唯一的事实源，保存阶段、状态、Task、Issue、产物审批和交付历史。
• Team Room是执行现场，由产品设计、工程、质量、功能文档和 PR / SEO 等角色接力产出证据。

这避免了“房间说已经完成，但项目 Feature 还停在问题阶段”的双重状态。Agent 的交接只能提交待审核草稿；只有 Feature 交付中的明确审批和门禁操作才能推进流程。

问题 → 产品与 UI/UX 设计 → 技术规划 → 代码实现 → 测试验证
     → 功能文档 → PR / 发布 / SEO 文档 → 完成

Team Room 把技术规划 + 实现合并成一个工程步骤、把发布 + 完成合并成一个传播步骤，因此仍以熟悉的六段进度呈现，但状态始终来自上面的完整交付链。

什么时候用

Feature 工作流适合：

• 从用户反馈或 Issue 出发设计并实现新能力
• 涉及交互、状态、数据链路和验收标准的跨层功能
• 合并前必须补齐验证、用户文档、PR 说明与发布传播素材
• 希望多个 Runtime 分工，同时保留人工门禁与可追溯证据

边界清晰的小错误通常使用标准任务更快。Feature 的价值是让“大功能的设计、代码、验证和文档不再各走各路”。

启动 Feature

首页

1. 选择项目和工作区策略。
2. 在 Workflow 中选择 Feature。
3. 写下问题、目标用户、预期结果、证据和约束。
4. 启动任务；Yoda 会创建或复用一个 Feature，关联 Task 和来源 Issue，再进入 Team Room。

分支或 Issue

在创建任务弹窗中选择分支或 Issue，再把执行方式切换为 Feature 工作流。相同 Task 的重试会复用已有的活动 Feature 和完整 Room，不会悄悄复制一条交付链。

即使重复点击或请求同时到达，Yoda 也会先在数据库中原子认领这个 Task 的权威 Feature，再只初始化一个活跃 Room。活跃 Room 使用中的 Task 会显示锁定状态，不能从 Feature 交付中误解绑。

Pull Request 已处在实现后的审查阶段，因此使用标准执行方式。

完整门禁

SEO 不适用时也不能直接省略：SEO 文档需要写明 N/A 及原因。这样“没做”和“确认不需要”不会混在一起。

Agent 交接不是自动放行

成员完成当前工作后，会发送带真实路径和验证证据的 Ready 交接。Yoda 会校验当前阶段、负责人、接收人和产物类型，然后把产物放入 Feature 交付：

1. 新产物状态为 草稿，不会自动变成已批准。
2. 每个产物记录来源 Task、Room、消息和成员。
3. 同类型的新提案会让旧证据变为 过期，避免旧审批绕过新改动。
4. 实现 Ready 会把当前 Task 移到 审查，但仍不会替你批准 Feature 门禁。

从 Room 标题栏打开 Feature 交付，检查真实文件和门禁说明，将需要的产物设为 已批准，再推进阶段。回到 Room 后点击 继续当前阶段，Feature Lead 会收到数据库中的最新阶段，并且只能委派当前负责人。

阻塞、退回与返工

• Blocked 交接会留下具体阻塞和所需行动，但不会擅自改变整个 Feature 的状态。
• Quality 发现缺陷时，先在 Feature 交付退回到代码实现，再继续 Room；修复后的 Task 重新进入审查，然后再次验证。
• 设计或技术方案改变时，新证据会使旧证据过期；后续阶段必须重新确认。
• Runtime 结束或消息里写了“通过”都不算门禁通过。只有主进程对当前 Feature 的审批与推进有效。
• Feature 被阻塞、取消或完成后，在途 Agent 回复不会再写入产物，也不会把 Task 推进到审查；恢复后必须根据最新阶段重新交接。
• @all、未来阶段负责人和格式错误的证据都会被路由守卫拦下。

怎么写好初始问题

不需要先写完整 PRD，但建议给出原始事实：

问题：谁在什么场景遇到了什么困难？
目标：希望用户最终能完成什么？
证据：错误、截图、Issue、文件位置或复现步骤。
约束：兼容性、性能、时间、不能改动的范围。
成功标准：看到什么结果，才算真正解决？

Yoda 会把这些内容带入同一个 Feature，而不是让每个 Agent 重新猜测背景。

什么才算完成

完成的 Feature 应同时找得到：清晰的问题与成功标准、产品和 UI/UX 决策、技术方案、关联代码 Task、可复现测试证据、用户功能文档、PR 文档、发布说明和 SEO / N/A 说明。

Feature 工作流不会绕过仓库权限。需要运行 CI、审查 diff 或合并分支时，继续使用审查、归档与合并；只有原始请求和仓库规则授权后，Yoda 才会执行外部 PR、合并或发布操作。