# 工单 Lane A — KAP 无限画布：数据同步链审计（KMC→画布 sync 面）

## 0. 任务性质
**只读审计批，非修码批。** 产出 = 审计报告 markdown 文件，唯一允许写入 = 报告文件本身。
最终目标：所有发现必须服务于 KMC（kais-movie-pipeline 创作管线）与 KGR（kais-gold-remount 金标复刻工厂）的工程目标——即画布作为两者的资产交付面，同步链的任何数据丢失/错位/静默失败都直接伤害生产。

## 1. 背景已知事实（实测锚点，直接采用勿重新推导；与实探冲突处以实探为准并在报告注明）

- KAP 仓：`/data/workspace/kais-aigc-platform`，当前分支 `feat/ui-direct-action-fix`，HEAD `333df7b6`
- 画布后端路由真源：`src/routes/canvas/v2/`（save-v2.ts / load-v2.ts / sync-assets.ts / import-from-dir.ts 2306行 / nodes.ts / links.ts / branches.ts 等，共 ~5792 行）
- DB：`data/db2.sqlite`（**只读查询**：用 `sqlite3 "file:data/db2.sqlite?mode=ro"`）。实测规模：canvas_nodes=11485 行，canvas_links=21904 行；另有表 canvas_branches / canvas_variant_groups / canvas_graph_meta / canvas_writeback_queue / kv_canvasEvent / o_assets / o_image
- KMC 侧消费方（只读）：`/data/workspace/kais-hermes-skills/skills/kais-movie-pipeline/pipeline/phases/p15_canvas_sync.py`（画布对账修复工具，自述 NOT registered in PHASE_REGISTRY）+ `pipeline/runner.py` L450-520 附近的 Phase 37 canvas sync 事件钩子（on_phase_complete → HTTP :10588 save-v2）
- KAP 服务**正在运行**（:10588），生产系统，禁任何写操作

## 2. 历史审计线索（来自既往会话的缺陷记录，逐条验证「已修 / 仍存在 / 部分修复」，这是你的重点核查清单）

1. `canvas_sync` 曾向 o_assets 查 filePath 列——实际该列在 o_image 表（需 JOIN）。验证现状。
2. p15_canvas_sync.py 未注册进 PHASE_REGISTRY，runner 永不执行它——纯手工工具。这个设计是否留下「degrade-tolerant 订阅者静默丢同步」无兜底的缺口？
3. 跨 phase artifact ID 碰撞：多个 phase 的 list output 共享 asset id 前缀导致画布节点覆盖。
4. 幻影 OSS URL：`_fs_to_oss_url()` 在文件不存在于静态服务根时生成 404 URL。
5. project_id 分裂：resume 时不传 --project-name 回退 env var 可能指向另一项目，节点泄漏到错误项目。
6. canvas_writeback_queue 表：找出它的生产者与消费者，验证队列是否有人消费（孤儿队列=回写丢失）。
7. save-v2 的幂等语义：同 node_id 重复 save 是 upsert 还是重复插入？实测 DB 中是否有重复 node_id。

## 3. 审计任务（C1-C5）

- **C1 同步链端到端**：KMC runner.py 钩子 → KAP :10588 save-v2 → canvas_nodes 表。逐跳核验：字段类型契约（pipeline 发的 JSON vs save-v2 校验）、错误响应形态（{code,data,message} 包装）、degrade 吞错面。给出「一条 phase 产物从管线落盘到画布可见」的完整跳数图，标注每跳的失败模式与可观测性。
- **C2 sync-assets.ts + import-from-dir.ts**：2306 行的大文件重点读。dir 扫描的正确性（maxdepth、文件列表漂移）、upsert 幂等、部分失败的中断语义。
- **C3 DB 一致性实测**：只读 SQL 实测——重复 node_id 计数、孤儿 links（端点节点不存在的边）、o_assets 与 canvas_nodes 的数量对账、phantom URL 抽样（抽 10 条 file_path 实测文件存在性）。
- **C4 p15_canvas_sync.py 与 runner 钩子的双轨审视**：两条同步路径（agent-path sync_fn vs CLI register_canvas_sync）是否可能双写/互相覆盖；p15 若手工跑，其 sanitize 规则与 save-v2 校验规则是否同源（漂移风险）。
- **C5 改进建议**：每条建议标注服务对象（KMC 生产效率 / KGR 复刻精度 / 平台可靠性）与实施成本（S/M/L）。

## 4. 红线（违反=交付作废）

1. **绝对只读**：禁改任何仓内文件；禁 POST/PUT/DELETE 任何 KAP API；禁 sqlite 写；禁重启服务；禁碰 :10588 在跑进程。
2. sqlite 一律 `file:...?mode=ro` 只读连接。
3. curl 允许但仅限 GET 只读端点（如 GET /api/... 健康检查、列表类）。
4. 唯一写入 = `/tmp/kap-canvas-review/report-A.md`。

## 5. 输出契约

报告写 `/tmp/kap-canvas-review/report-A.md`，结构：
1. **执行摘要**（≤200 字 + P0 清单）
2. **问题清单**：P0/P1/P2 分级，每条格式 = 现象 → 证据（文件:行号 或 SQL 实测输出）→ 根因 → 对 KMC/KGR 的影响 → 修复建议（含成本 S/M/L）
3. **历史线索核查表**：第 2 节 7 条逐条给「已修/仍存在/部分修复」+ 证据
4. **改进建议**（标注服务对象）
5. **验证方式**（operator 如何独立复核你的结论）

## 6. 硬性证据约束
所有结论必须引用 文件:行号 或实测命令输出；禁止无证据推断；不确定标「待验证」。报告结尾附 ≤300 字摘要。