详细实现。触发：/hany:implement。基于hany:require确认的示例和方案，拆解任务+分配Agent→并行实现→完成前验证→提交。
触发方式：/hany:implement
调用方：可独立触发
/hany:implement，也可由hany-autoStep 3 自动调用。
核心原则：严格按照确认的方案执行，不自行调整。不确定的地方必须问。发现问题必须指出。优先并行。时刻汇报进度。偏差立即汇报。
快速路径：AI 在 Step 0 中自动判断复杂度，简单任务自动跳过 Constitutional 门禁、文件结构映射和计划自检走 Step 0→1→4(快速拆解，含文件列表)→7→8→10→11。复杂任务走全流程。
详见
hany-common/procedures/interaction_rules.md
详见 hany-common/procedures/quality_modes.md
编码约束：读取
hany-common/rules/rules.md，11 条规则全程生效。
[按需加载] 本文件包含完整步骤手册。执行时：
- 启动阶段：仅读快速参考卡和"Step 0"即可开始
- 执行阶段：用 Read(offset/limit) 跳读到对应 Step 章节（参考下方行号区间）
- 已完成阶段：用 3 行摘要替代详细内容，释放上下文
行号参考（offset 跳读用）：Step 0 约第 72 行 | Step 1 约第 85 行 | Step 2 约第 92 行 | Step 3 约第 100 行 | Step 4 约第 117 行 | Step 5 约第 137 行 | Step 6 约第 149 行 | Step 7 约第 155 行 | Step 8 约第 202 行 | Step 9 约第 214 行 | Step 10 约第 234 行 | Step 11 约第 253 行
| 阶段 | 核心动作 | 确认节点 |
|---|---|---|
| Step 0 | 先想想看，输出思路 | — |
| Step 1 | 检查前置条件（需求文档是否存在） | — |
| Step 2 | Constitutional 门禁 | AskUserQuestion（不通过时） |
| Step 3 | 文件结构映射（新建/修改/删除文件清单） | AskUserQuestion |
| Step 4 | PRD 故事拆解 + Agent 分配 | AskUserQuestion |
| Step 5 | 计划自检（5 项自查） | — |
| Step 6 | 结构化计划文档写入 docs/hany/plans/ | AskUserQuestion |
| Step 7 | 并行实现（Team 分配 + 实时进度） | 偏差时 AskUserQuestion |
| Step 8 | 完成前验证门禁（运行命令+红旗词检测） | — |
| Step 9 | 过程检查 + 错误→规则抽象 | — |
| Step 10 | 提交协议 | — |
| Step 11 | 完成确认 | AskUserQuestion |
必须满足才能开始：
docs/hany/requirements/ 下存在已确认的需求文档[NEEDS CLARIFICATION] 标记前置条件不满足时，提示用户先执行
/hany:require。
启动时检查 docs/hany/plans/ 下是否有未完成的计划文档。如果有，使用 AskUserQuestion 询问：继续上次 / 重新开始。
见上方快速参考卡（按顺序从 Step 0 到 Step 11）。
⚠️ 若由
hany-auto调用，跳过此步（auto 已在之前阶段完成整体思考）。
触发后，先思考再执行。
思考完后，输出思路再进入 Step 1。
docs/hany/requirements/ 下是否存在已确认的需求文档/hany:require 确认需求和示例"实现前检查是否符合项目原则。不通过则不能进入实现。
详见
hany-common/procedures/constitutional_guard.md
门禁不通过 → 记录为例外并说明理由，用 AskUserQuestion 让用户确认是否接受。
定义任务前，先列出所有要创建/修改的文件及职责。
### 新建文件
| 文件路径 | 职责 |
### 修改文件
| 文件路径 | 修改内容 |
### 删除文件
| 文件路径 | 原因 |
用 AskUserQuestion 确认：确认 / 调整 / 取消。
### 故事 N：[标题]
- **作为** [角色] **我想要** [功能] **以便** [价值]
- **验收标准**：
- [ ] 给定 [前置条件]，当 [操作]，那么 [预期结果]
- **状态**：passes: false
将故事拆解为具体步骤，按并行组分配 Agent。
分配原则：同一文件修改分配给同一 Agent，同一故事步骤尽量分配给同一 Agent，每个 Agent prompt 必须自包含。
用 AskUserQuestion 确认：确认执行 / 调整步骤 / 调整分配 / 取消。
| 自查项 | 检查内容 |
|---|---|
| 需求覆盖度 | 每个需求都有对应故事/步骤 |
| 占位符扫描 | TBD/TODO/待定必须消除 |
| 类型一致性 | 函数签名、数据类型一致 |
| 依赖完整性 | 步骤间依赖完整标注 |
| 验收标准 | 每个故事有可测试的验收标准 |
自查不通过 → 修改 → 重新自查。
写入 docs/hany/plans/YYYY-MM-DD-<主题>.md，含目标、架构、技术栈、文件结构、用户故事、实现步骤、checkbox 跟踪。
用 AskUserQuestion 确认：确认写入 / 修改 / 取消。
严格按 Step 4 的分配方案，将每个并行组分发给对应 Agent。
并行处理规则见
hany-common/procedures/split_parallel.md
在启动并行组之前，必须分析文件依赖关系：
| 依赖强度 | 判定标准 | 并行策略 |
|---|---|---|
| 强依赖 | A文件被B文件直接引用；修改A会导致B必须同步修改 | 不并行，串行执行 |
| 中等依赖 | A和B都依赖同一个模块，但彼此不直接依赖 | 可并行，但需统一接口 |
| 无依赖 | 两个文件完全独立，修改互不影响 | 可以并行 |
[进度 X%] Agent-X 启动：[描述][进度 X%] Agent-X：[子步骤] ✅完成 / ❌失败[进度 X%] Agent-X 完成：耗时 [X]，变更文件：[列表]汇总（每完成一个并行组）：
[并行组 X 完成状态 - 进度 X%]
├── Agent-A: ✅ 完成（步骤 1.1, 1.3）
├── Agent-B: ✅ 完成（步骤 1.2）
└── Agent-C: ❌ 失败（步骤 1.4，原因：[说明]）
发现偏差 → 立即暂停汇报 → 等用户决定 → 继续。
不信任 Agent 报告。每个 Agent 返回后独立验证：git diff + 文件内容 + 语法/构建。验证通过后更新对应故事的 passes: true。
方案不可行 / 需求遗漏 / 发现更好方式 / Agent 失败 → 暂停 → 汇报 → 用户决定 → 继续。
任何 Agent 说"完成"之前，必须先通过验证门禁。
| 门禁项 | 检查方式 |
|---|---|
| 运行验证命令 | 必须实际运行语法检查、构建、测试命令，看到输出 |
| 红旗词检测 | 检查报告中"应该"、"可能"、"看起来"等不确定词 → 不允许 |
| 证据附带 | 每个"完成"声明必须附带验证命令输出 |
铁律：没有验证命令输出的"完成"声明不算数。
| 检查项 | 要求 |
|---|---|
| 语法检查 | 使用语言对应工具验证 |
| 引用依据 | 所有引用给出来源文件路径和行号 |
| 可验证 | 每项改动附带验证方式 |
| 方案一致性 | 实现与确认的方案一致 |
| 故事验收 | 每个故事验收标准都满足（passes: true） |
| 错误类型 | 处理方式 |
|---|---|
| 编码习惯问题（如忘处理 null） | 写入 docs/hany/rules.md 作为项目规则 |
| 项目特定问题（如某 API 特殊行为） | 写入项目笔记 |
| 一次性失误（如打错字） | 加测试覆盖 |
能写成测试的错误，必须写成测试。能写成规则的错误，必须写成规则。不能只修 bug 不留防線。
实现完成并验证通过后，按规范提交。
<type>: <subject>
<body with decision trailers>
Type：feat / fix / refactor / docs / test / chore
决策 Trailer（可选）：
Constraint: [技术/业务约束]
Rejected: [被排除的方案及原因]
Confidence: [高/中/低]
AskUserQuestion 确认：确认完成 / 有遗漏 / 需要调整确认通过：由 hany-auto 编排器自动路由至验证阶段（verify-small / verify-project）。