# 任务：VDN 引擎臂正式集成 KAP —— 新增 H3 profile `vdn-8`

## 背景与授权（已定谳，勿再论证）
- 2026-09-08 Kai 盲测终审：VDN 臂（ApplyVDNH3 int8-convrot + turbo adapter, flex）241f 同速下细节 2.5× 全面胜出 LightX2V 8Step。Kai 拍板：「将 VDN 工作流正式集成到 kap 中」。
- 本次交付 = KAP 新增 **可选 profile `vdn-8`**。不改任何现有 profile 行为，不切默认档，不动 useCase 映射。

## 现场事实（已预检，代码为准，发现不符以代码为准并在报告中纠正）
- 仓库：`/data/workspace/kais-aigc-platform`（=10588 运行真源），分支 `feat/reverse-dag-view` @ d3eb69e0。
- 参照模板：commit cede2e5f（lightx2v-4-v11/v12 集成）与 d3eb69e0（per-mode profile 语义守卫）。
- 核心文件：`src/routes/production/minimax-h3/{config.ts(864行), generate.ts(1390行), ref2va.ts(822行), i2va.ts, t2va.ts, __tests__/}`。
- 校验机制现状：H3_EXPOSED_PROFILES（config.ts L760）驱动 generate.ts L843-854 校验；路由分支在 generate.ts L1015-1034；ref2va/i2va 是否复用该路由需你实读定谳。
- ComfyUI 侧全部在位：`ApplyVDNH3` 节点 **:8188 与 :8190 均可用**（object_info 已实测）；权重目录 `/data/models/comfyui/vdn/vdn-minimax-h3-int8-convrot-comfyui/`（容器内可见，`vdn_checkpoint` 选项值=该目录名）。
- 获胜臂权威蓝图：`/tmp/case08_241_dual.py`（0907 实跑成功，prompt_id=5d732d1e）。核心差异 = model_chain 节点：
```json
{"class_type": "ApplyVDNH3", "inputs": {
  "model": ["<UNETLoader id>", 0],
  "vdn_checkpoint": "vdn-minimax-h3-int8-convrot-comfyui",
  "apply_turbo_adapter": true, "strength": 1.0, "lora_mode": "merge",
  "branch_weights": "stream", "retain_buffers": "off",
  "attention_backend": "flex", "verbose": true}}
```
- 其余与现役 8 步链同：UNETLoader 基模 `minimax_h3_fl2va_int8_convrot.safetensors`、er_sde/beta/8步/denoise 1.0、**无 SigmaShift 节点**（8步链自带 shift 语义）、ref2va autogrow 键=点前缀 `ref_images.ref_image_N` + `ref_image_size:"match"`。
- VDN 硬边界（0907 两次 OOM 定谳，写进 guard 注释）：**所有模式 length 上限 241f @1216×672（3 参考图）**；362f 必 OOM。
- 互斥（此臂禁插）：LightX2V/Turbo LoRA 叠加、SOL attention、kitchen/TESpeed 节点。

## 实施项
1. **config.ts**：新增 `H3_VDN` 配置块（checkpoint 名 + ApplyVDNH3 全参数 + steps:8）；`H3ProfileName` 加 `"vdn-8"`；`H3_PROFILES` 加条目（label 注明 8步+VDN adapter）；`H3_EXPOSED_PROFILES` 追加。
2. **硬边界守卫**：vdn-8 profile 时 `length > 241` → 400 拒绝（带边界说明文案）。放在 profile 语义守卫层（参照 d3eb69e0 模式）。
3. **generate.ts**：新增 `buildH3WorkflowVDN(opts)`（参考 buildH3WorkflowLightX2V 的图结构，但 model_chain 换 ApplyVDNH3、无 LoRA loader、无 SigmaShift）+ 路由分支。t2va/i2va/ref2va 三模式的覆盖方式按你实读的架构定（若 ref2va.ts 独立建图则同模式加分支），判断依据写进报告。
4. **__tests__**：新增用例：profile 校验接受 vdn-8；构造图断言（含 ApplyVDNH3 且参数正确 / 不含 LoraLoaderModelOnly / 基模 int8_convrot / er_sde+beta+8步）；length>241 → 400。
5. **构建**：`npm run build` 通过。
6. **部署**：`sudo -n systemctl restart kais-aigc-platform`（若 sudo 免密不可用 → 立即报告阻塞，禁止 kill -9 主进程硬来）。部署前后按 kap-deploy-port-bind-verification 纪律：记录 `ss -tlnp | grep 10588` PID vs `systemctl show -p MainPID`，重启后复验 MATCH。若 ss PID ≠ MainPID 先按 h3-profile-rollout-discipline §3 孤儿诊断链处置。
7. **冒烟（真实渲染 1 发）**：KAP `POST :10588/api/production/minimax-h3/generate`，mode=ref2va、profile=vdn-8、1216×672、length=97、seed 任意、3 参考图 `/home/kai/文档/LTX/validition_v1/08/{1.jpg,2.jpg,bg.png}`、短 prompt。完成判定 = ComfyUI `/history/<id>` `status_str=="success"` 且产物落盘（⚠️ 0908 坑：容器 output 已重定向 `/mnt/agents/output/gpuN/kgr_out`，勿按容器内老路径判 no_output；以 KAP 返回/history 记录的文件路径为准）。冒烟是连通性验证不比质量。
8. 冒烟前若发现 GPU 被占（两实例 /queue 非空或 vram_retry 排队）：等待排空再冒烟，**不要打断在跑任务**。

## 硬性证据约束
- 一切结论带 文件:行号 或命令输出。i2va/t2va/ref2va 路由架构必须实读后定谳，禁止照抄本 prompt 推断。
- 与我给的事实冲突时以代码为准，报告里单列「事实纠正」节。
- 边界数字 241f 来源=0907 实测 OOM，不重新做边界实验。

## 输出契约
- 提交：只 add 你改的文件分批 commit，message 风格照 cede2e5f（`feat(h3): ...` + 中文一句理由）。仓库现存的 docker-compose yml 改动与已删 png 等脏文件**与本次无关，禁止触碰/提交**。
- 报告：`/tmp/vdn-kap-integration-report.md`——改动清单(file:lines) / 三模式路由判断依据 / 测试结果原文 / 部署 PID 证据(前后对照) / 冒烟证据(prompt_id+产物路径+耗时) / 残留 P1P2。
- 结尾 ≤300 字摘要 + 明确交付结论（已交付 / 阻塞+原因）。

## 派发时现场（供参考）
内存 avail=106G；:8188/:8190 队列空；老司机并发 1（<5 安全线）。