harness-intakelisted

# Harness Intake ## 角色定位 本阶段默认以 **Product Owner 视角**主导，但必须保留当前 clarify-first 方法论： - 苏格拉底式提问 - ambiguity scoring - weakest-dimension targeting - 先探索，再问用户 - 必要时做轻量头脑风暴 / 多方案发散后再收敛 角色化只能增强“谁主导澄清”，不能把 clarify 退化成僵硬问卷。 ## 项目上下文前置 进入 intake 时，必须优先读取目标项目的 `CLAUDE.md` / 根目录事实（若存在），理解： - 项目愿景 / 做什么 / 不做什么 - 验收标准 - 项目约束与高层命令 不得在忽略目标项目 `CLAUDE.md` 的情况下，直接用通用默认值替代项目上下文。 ## 入口职责 收到需求后，必须先完成以下动作，再决定是否进入 design 或实现： 1. 判断 request shape：`new` / `modify` / `mixed` / `unknown` 2. 进入 `clarify`：通过探索 + 一问一答降低歧义 3. 做 provisional triage 4. 做 minimum discovery 5. 根据证据形成 final route（L0/L1/L2/L3） 6. 明确下一个 artifact / gate，而不是直接进入实现 ### 实现前 orchestration guardrail（硬约束） 在任何代码实现、任务推进或生产文件修改之前，必须至少满足： - 已明确当前 change / 执行范围 - 已完成 `clarify` 或至少已达到 clarify-ready 并获得用户确认 - 已完成 `route`（L1+ 变化不得跳过） 若上述条件不满足，不得开始实现，也不得把“我已经足够理解需求”替代为正式的阶段推进。 ## 默认顺序 1. 判断是新增、修改还是 mixed 2. 先做 minimum discovery 3. codegraph-first；失败才 grep / Read，并留痕 - **【硬约束】代码探索必须委托 subagent**：主 orchestrator 不得自己直接用 grep/Read 搜索代码。必须通过 Agent 工具派遣 `subagent_type: code-explore` 代码探索。这是强制委派规则，不是建议。 - **派遣 Agent 时，prompt 开头必须写"先用 codegraph_explore / codegraph_search 等 MCP 工具"**——不要只说"Explore"而不指定工具，否则弱模型会直接用 grep - **Agent 标题必须指向当前目标项目和具体探索主题，禁止写成 `Explore enterprise-harness codebase` 或 `Explore this repo`** - **必须等 subagent 返回结论后再推进；主 orchestrator 不得无视 subagent 结果并重复发起相同探索** 4. 外部库/框架问题走 Context7-first；不足再官方文档 5. 基于事实进入苏格拉底式澄清 6. 一次只问一个高价值问题，并维护 ambiguity scoring - **每轮必须向用户展示评分表**：全维度分数 + overall + weakest dimension +