# 工单 Lane D — KAP 无限画布：多项目/多分集数据隔离与规模审计

## 0. 任务性质
**只读审计批，非修码批。** 产出 = 审计报告 markdown 文件，唯一允许写入 = 报告文件本身。
最终目标：画布承载多个创作工程（KMC 多 episode 生产 + KGR 金标复刻批次 + 迭代实验批次），跨工程数据污染 = 生产事故（曾有「删除残缺项目数据差点丢全量」事故）。本 Lane 审计隔离边界与规模可扩展性，服务 KMC 多分集并行生产与 KGR 批次隔离。

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

- 仓：`/data/workspace/kais-aigc-platform`，分支 `feat/ui-direct-action-fix`，HEAD `333df7b6`
- DB：`data/db2.sqlite`（**只读** `file:...?mode=ro`）。实测：canvas_nodes=11485、canvas_links=21904；表含 o_project、o_assets（有 episodesId 列——历史审计确认）、o_image、canvas_graph_meta、kv_canvasEvent
- 历史线索（逐条验证现状）：
  1. 曾发生画布删除操作差点丢全量数据的事故（2026-07-25）——之后是否有删除保护/软删除/备份机制？
  2. 「新 project_id 的画布项目在前端不可见：save-v2 只写 canvas_nodes/canvas_links 不写 o_project」——项目可见性的双表一致性问题
  3. 多分集改造：o_assets 加 episodesId 列 → 后端 API 筛选 → 前端 useRealAssets 按 (projectId, episodesId) 分桶缓存——链路完整性
  4. 「同一 episode 的资产存储拓扑分裂」：pipeline 产出的资产与画布注册的资产路径不一致（.pipeline-assets vs oss/ vs data/serve）
  5. 「stale .pipeline-assets symlink 指向错误 episode」——符号链接类隔离破坏
- 关键代码锚点：`src/routes/canvas/v2/save-v2.ts`、`load-v2.ts`、`import-from-dir.ts`、`projects.ts`；前端 `hooks/useRealAssets`（或类似名，自行定位）、`ProjectSelector.tsx`
- KMC 侧：`/data/workspace/kais-hermes-skills/skills/kais-movie-pipeline/episodes/` 下有 20+ 个 episode 目录（多分集并行生产的证据）；KMC 多分集资产隔离清单要求 5 层隔离（Canvas project_id 独立、.pipeline-assets symlink 等）

## 2. 审计任务（C1-C6）

- **C1 项目注册一致性**：save-v2 写 canvas_nodes 但不写 o_project 的现状验证；项目列表的权威来源是谁；「新项目不可见」问题是否仍存在；graph_meta 与 o_project 的字段对应。
- **C2 数据规模与性能边界**：11485 节点/21904 边的现状分布（按 project 分组统计 SQL）；save-v2 全量 save 还是增量 upsert（读代码）；load-v2 一次拉全图还是按需分页——在节点数 ×10 增长时的瓶颈预测。
- **C3 删除面审计**：找出所有能删画布数据的代码路径（API 端点 + 前端触发按钮 + import-from-dir 的 replace 语义）；删除有无软删/确认/备份/审计日志；2026-07-25 事故后是否有防线落地。
- **C4 跨工程隔离实测**：SQL 实测——同一 project_id 下混入其他工程资产的证据（按 meta 字段抽样）；o_assets.episodesId 的填充率（NULL 占比=脏数据）；kv_nodeAsset/kv_shotGraph 的跨 project 泄漏检查。
- **C5 备份与可恢复性**：db2.sqlite 有 -wal/-shm（WAL 模式）；有无定期备份机制（crontab/systemd timer 扫描）；单文件 SQLite 在 11K 节点规模下的备份窗口与恢复演练可行性。
- **C6 改进建议**：每条标注服务对象（KMC 多分集生产 / KGR 批次隔离 / 数据安全）与成本（S/M/L）。

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

1. **绝对只读**：禁改文件；禁 POST/PUT/DELETE；禁 sqlite 写（mode=ro）；禁重启；**特别禁任何删除操作（连测试请求都不许构造发送）**。
2. curl 仅限 GET 只读端点。
3. 唯一写入 = `/tmp/kap-canvas-review/report-D.md`。

## 4. 输出契约

报告写 `/tmp/kap-canvas-review/report-D.md`，结构：
1. 执行摘要（≤200 字 + P0 清单）
2. 问题清单：P0/P1/P2，每条 = 现象 → 证据（文件:行号 / SQL 输出）→ 根因 → 对 KMC/KGR 的影响 → 修复建议（成本 S/M/L）
3. 历史线索核查表（第 1 节 5 条逐条：已修/仍存在/部分修复 + 证据）
4. 删除面清单：所有删除路径 × 防护状态表
5. 改进建议（标注服务对象）
6. 验证方式
7. 硬性证据约束：所有结论引用文件:行号或实测输出；不确定标「待验证」。结尾附 ≤300 字摘要。