feat(ack): add Feishu bug review approval gate

docs/ack-feishu-bug-intake.md

@@ -2,16 +2,16 @@
 
 ## 目标
 
-让用户在飞书多维表格中跨设备记录文字和截图，随后由 ACK Coordinator 通过官方
-`lark-cli` 读取项目配置的 `ACK Ready` 视图，整理为独立、可验收、可幂等追踪的 ACK
-任务。不同项目通过不同 CLI profile 访问各自飞书租户。
+让用户在飞书多维表格中跨设备记录文字和截图，由 ACK Coordinator 在同一记录补全并
+反复修订修复逻辑与验收标准。用户明确审核通过后，才将批准版本整理为独立、可验收、
+可幂等追踪的 ACK 任务并启动三角色闭环。
 
 ## 非目标
 
 - 不用 Skill 承担人工记录入口。
 - 不抓取公开网页或依赖浏览器登录态。
 - 不把 App Secret、access token 或飞书用户凭据写入项目。
-- 第一版不反向更新飞书记录，不把飞书状态与 ACK 状态做双向同步。
+- 不在审核前把草案写入 `tasks.yaml`，也不把 ACK 执行状态持续双向同步到飞书。
 - 不把多条互不相关的 Bug 合成一次 Developer 派发。
 
 ## 项目配置契约
@@ -22,6 +22,7 @@
 | 字段 | 约束 |
 |------|------|
 | `provider` | 固定为 `feishu-base` |
+| `workflow` | 审核前协作固定为 `reviewed-writeback-v1`；缺省表示旧只读模式 |
 | `profile` | `lark-cli` profile 名称；每次命令显式传入 |
 | `baseToken` | 飞书 Base token |
 | `tableId` | 数据表 ID |
@@ -29,8 +30,8 @@
 | `fields` | 逻辑字段到飞书字段 ID/名称的映射 |
 
 `fields` 必须映射 `title`、`actual`、`expected`、`stepsToReproduce`、
-`acceptance`、`priority`、`attachments`、`updatedAt`。字段值只作为单个 argv 传给
-`lark-cli`，不经过 shell。
+`acceptance`、`priority`、`attachments`、`updatedAt`。启用审核前协作时还必须映射
+`fixLogic`。字段值只作为单个 argv 传给 `lark-cli`，不经过 shell。
 
 ## CLI 契约
 
@@ -40,6 +41,10 @@
 - profile 由项目显式选择；不得执行 `profile use` 或读取 active profile作为回退。
 - 子进程使用最小环境，不继承可能覆盖 profile/config/凭据或注入运行时的环境变量。
 - 记录读取使用 `base +record-list`、JSON 输出、指定 Base/table/view 和投影字段。
+- 草案写回只通过读取器的 `write-draft` 子命令调用 `base +record-upsert`，并且只允许修改
+  配置映射的 `fixLogic` 与 `acceptance`。
+- 批准后只通过 `import-approved` 生成规范任务字段和可重算的 `approvedPayloadHash`；任务
+  校验器拒绝审核字段与该 hash 不一致的 reviewed task。
 - 记录超过一页时按 offset/limit 继续读取，并设置总页数/记录数上限。
 - 附件仅通过 `base +record-download-attachment` 下载到调用者显式提供的临时目录。
 - 附件数量、单文件大小、批次总大小和子进程文件写入均有硬上限；落盘大小必须与
@@ -53,8 +58,9 @@
 - `sourceRef`：对 provider、profile、Base、table、record ID 做域隔离 SHA-256
   后得到的稳定匿名引用；原始 profile、Base token 与 record ID 不拼入引用文本；
 - `recordId` 与 `updatedAt`；
-- title、actual、expected、steps、acceptance、priority；
-- `enrichmentRequired`：缺失但允许 Coordinator 整理的 steps、acceptance、priority；
+- 绑定来源事实、附件元数据和审核字段的 `draftRevision`；
+- title、actual、expected、steps、可选 fixLogic、acceptance、priority；
+- `enrichmentRequired`：缺失但允许 Coordinator 整理的 steps、fixLogic、acceptance、priority；
 - 附件的 name/type/size 与可选本地临时路径；附件 token 只在下载命令内部使用；
 - 原始字段中无法映射但不影响导入的警告。
 
@@ -63,18 +69,21 @@ token 或 CLI 配置文件内容。
 
 ## Coordinator 整理规则
 
-1. 先运行读取器 `check`，确认 `lark-cli`、项目 profile 和所需只读能力可用。
+1. 先运行读取器 `check` 确认 `lark-cli` 和项目 profile，再单独核对 app 已获得所需读写
+   scope；`check` 不把用户 token 状态当作 app/bot scope 证明。
 2. 运行读取器 `plan` 读取 `ACK Ready` 视图并生成 create/refresh/unchanged/drift
    整理动作；需要看截图时使用临时下载目录。
-3. 将记录分类为 Bug、已有功能、接受的改进、样式偏好或超范围；只导入确认接受的项。
-4. 每条导入任务保存 `source.kind=feishu-base`、`source.ref`、`source.recordId`、
-   `source.updatedAt`，并把截图观察转成文字证据。
+3. 将记录分类并在飞书补全 `fixLogic` 与 `acceptance`；用户反馈时继续写回同一记录。
+4. 用户必须明确批准当前 `draftRevision`；通过前不写 `tasks.yaml`、不派发角色、不修改
+   应用代码。通过后每条导入任务保存 `source.kind=feishu-base`、`source.ref`、
+   `source.recordId`、`source.updatedAt`、`source.workflow`、`source.approvedRevision`、
+   `source.approvedPayloadHash`，并把截图观察转成文字证据。
 5. 导入前扫描已有任务的 `source.ref`。相同来源不得新建第二条任务。
 6. 来源更新但任务尚为 `open` 时可由 Coordinator刷新描述；任务已派发或进入终态时只报告漂移，由用户决定是否新开任务。
 7. 飞书记录删除、不可访问或 CLI 暂时失败时保留已有 ACK 任务，不反向删除。
 8. title、actual、expected、updatedAt 是不可推断的来源事实，部分缺失时 fail closed；
-   steps、acceptance、priority 缺失时由 Coordinator 根据来源事实和项目上下文补齐，
-   并写入 `evidence.intakeEnrichment`，不要求报告者返回飞书机械补录。
+   steps、fixLogic、acceptance、priority 缺失时由 Coordinator 根据来源事实和项目上下文
+   补齐并写回飞书。只有批准后的最终版本才导入任务板。
 9. 没有附件且所有 Bug 内容字段均为空的误建行跳过并输出 `blank_record_skipped`；带部分
    来源事实的残缺行不得静默跳过。