工作入口

目的

为 feature、bug、技术债、实验和事故 action 定义统一入口。

工具

从需求到开发的工具流

更完整的协作流程见 16-三角色协作流程-three-role-collaboration-flow.md。

工作类型

最小闭环字段

草台团队最容易断在“有人提了，但没人推进；有人做了，但没人拍板”。所以每个工作项至少要有这些字段：

Driver 和 Approver 可以是同一个人，但字段必须显式。多人共同负责等于没人负责。

开发就绪定义

工作进入开发前必须满足：

1. 问题说明清楚。
2. 用户或客户是谁清楚。
3. 成功信号或验收标准清楚。
4. Driver 和 Approver 明确。
5. 优先级理由和目标时间明确。
6. 依赖列出。
7. 数据、安全、生产风险已标注。
8. 目标 repo 或产品区域已知。

草台版最低要求可以更短：

目标
-> 用户 / 问题
-> Driver
-> Approver
-> Scope
-> 验收标准

这 6 项不满足时，只能进入 clarification / planning，不能进入 implementation。

用户可见功能还需要明确 Business Approver。它可以和 Approver 是同一个人，但必须有人负责业务验收。

产品闭环细节见 20-产品闭环-product-closure.md。

三角色开发准入

进入开发前，三类角色各自确认一件事：

状态模型

使用简单共享状态：

Intake -> Clarifying -> Planned -> In Progress -> In Review -> Ready to Release -> Done
                           -> Blocked
                           -> Rejected
                           -> Cancelled

状态含义：

紧急通道

线上事故、客户现场、老板急活可以先处理，但必须补闭环。执行人临时成为 Driver；直属小组长或当班负责人是 Approver。

先止血
-> 24 小时内补任务卡
-> 补 PR / patch / 发布记录
-> 补验证证据
-> 明确后续 action

紧急通道不能绕过 review 和记录，只是允许先止血再补齐。连续出现同类紧急任务时，必须创建复盘或技术债任务。

这些事项不能只走事后补审：

1. 权限和鉴权变化。
2. 支付、计费、提现、资金相关逻辑。
3. 客户数据导出或删除。
4. 生产密钥、证书、云权限变化。
5. 破坏性数据库 migration。
6. 大范围批量操作。

Linear 设置建议

后续 Agent 就绪要求

这一节在人类闭环稳定后再看。当前阶段先保证人类任务字段完整。

Agent 执行需要工作项包含：

1. 任务标题。
2. 验收标准。
3. Repo 和分支策略。
4. Scope 边界。
5. Reviewer。
6. 允许工具或风险等级。
7. Human Approver。
8. 预期 artifact 类型。

缺少这些字段时，应先创建 planning task，而不是直接启动执行 run。

下一步阅读

读完或填完这份文档后，通常继续看：

• 14-任务联动-task-linkage.md：任务进入系统后，继续看任务、PR、文档和发布如何互相链接。