宜博 / 2080tiserver

任务详情页里的参考视频缩略图之前固定 340×200 + object-fit:cover。横屏视频还行，
竖屏参考视频（比如 480×832）会被裁得只剩中间一条窄带，看不全——参考视频本来就是
要让人核对内容对不对，裁切是硬伤。改成按视频真实宽高比等比缩放（不超过340宽/400高），
横竖屏都不再裁切。

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PA1AWh8e7wJ3vyhKBAEQux

2026-08-20 那节早就过期了（写的时候 minimax-h3/gateway.py 还是生产后端，raylight
还没上线）。新增最新状态节：raylight 是现在的生产后端、今天的六项改动（编码bug修复、
排队优先级插队、重启保留队列、ComfyUI健康检查、/v1/models修真实数据、详情页新字段）
都已部署验证并推送，当前各服务实测状态，以及磁盘空间收紧这个待留意项。旧节保留作历史
记录，加了架构已变更的提示。

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PA1AWh8e7wJ3vyhKBAEQux

排查任务时经常要么去问 sqlite 里存的原始请求参数，要么去查 ComfyUI 自己的 /history
拿实际发给模型的完整 workflow graph——两者详情页都没有，只能手动 SSH 上去查。

- raylight/server.py 加 GET /v1/videos/{jid}/comfy_history，透传 ComfyUI 的
  /history/{prompt_id}（这份数据在 ComfyUI 进程内存里，没有落盘，ComfyUI 重启后
  查不到，接口会给出明确提示而不是裸错误）。
- h3-console/server.py 加对应代理。
- 详情页底部加两个默认折叠的区块：原始参数（req 原样 JSON，纯前端渲染，不用额外
  请求）、ComfyUI History（懒加载，点开才去问后端，避免 queued/running 状态每次
  轮询详情都多打一次 ComfyUI）。
- 顺带把生成结果视频从页面底部挪到状态/操作按钮那一行下面，不用再滚到底部看结果。

已在服务器重启验证：接口对已经清空 history 的任务（ComfyUI 重启后）正确返回明确
错误而不是裸 500；重启期间 14 条排队任务原样保留。

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PA1AWh8e7wJ3vyhKBAEQux

/v1/models 之前硬编码3个预设，模型文件名对应的是已删除的 api.py/gateway.py 那套旧
架构（minimax-h3-fl2va-nf4.safetensors 等），跟 raylight 现在实际加载的模型
（minimax_h3_fl2va_pruned_int8_convrot.safetensors 等）完全对不上，档位也只有3个，
跟前端下拉框实际支持的8个分辨率（RESOLUTION_CEILINGS）不一致——外部调这个接口查
"支持哪几档"拿到的是错的过期数据。

raylight/server.py 加 GET /v1/resolutions，返回 RESOLUTION_CEILINGS 的实时内容；
h3-console 的 /v1/models 改成实时调这个接口拼 presets，顺带把 partitions 里的模型
文件名也换成当前实际使用的。

已在服务器上重启验证：/v1/resolutions 返回全部8档，h3-console /v1/models 端到端
拿到一致数据；重启过程中17条排队任务全部保留（用到了上一次改的排队恢复逻辑）。

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PA1AWh8e7wJ3vyhKBAEQux

任务 f2de718e1e30（参考视频文件名带中文）秒失败：h3-console 上传时的文件名清洗用了
Python 3 默认的 Unicode \w，中文被当合法字符保留，资源 URL 里带着原始中文传给
urllib.request.urlopen，http.client 构造请求行要求纯 ASCII 直接炸了。改成请求前对
URL 的 path 部分 quote 一遍。

排查时发现 raylight 重启会把所有排队中的任务直接标记 cancelled（内存队列重启即清空，
sqlite 里的 queued 记录没有任何路径被重新入队）。改成 Job 加 queue_seq、Q 换成
PriorityQueue，重启时排队任务原样保留、按序重新入队；顺带加了 POST
/v1/videos/{jid}/prioritize 插队接口和对应的 h3-console 代理 + 前端"优先插队"按钮。

另外把 8月24日提交过、但实际从未部署到服务器的 ComfyUI 存活探测（_comfyui_alive）
重新加回，并解决了 raylight/server.py 和 raylight/scripts/server.py 长期分叉的问题。

已在服务器上验证：重启后 17 条排队任务原样保留、顺序不变；插队接口直接测试和通过
console 代理都验证通过；/health 的 comfy_alive 检查确认生效。

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PA1AWh8e7wJ3vyhKBAEQux

用户要求把新建任务默认参数改成竖屏。text/fl2va/ref2va 三个 tab 统一改，新增
DEFAULT_RES/DEFAULT_DUR 常量，initParamSelects（初次加载）和 clearForm（清空表单）
都改成读这两个常量，不再各自硬编码。480×832 下 10s(243帧) 远低于1125帧上限，安全。

已同步覆盖服务器 /data/models/minimax-h3/console/static/index.html（先确认服务器旧
文件跟本地 git HEAD 完全一致，再推），server.py 按请求读文件不缓存，无需重启，
curl 已验证线上生效。

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

- CHANGELOG/h3-console/README/llm-setup：frpc.qwen.ini 里 [qwen-gw-20260610]
  （gateway.wudaima.com → 8080）2026-08-29 已删除，服务器上备份为
  frpc.qwen.ini.bak-20260829，三处文档同步更新，去掉过期的"走不通"描述。
- raylight/notes.md：调研 FastVideo/FastH3（H3 的4步蒸馏版），结论暂不可行——
  没有量化权重导致 bf16 在 Turing 上跑不动 attention、VSA 加速官方只支持
  Blackwell、且不是 ComfyUI-native。另外实测算了 RTF，现有 base H3 在这台
  机器上离"N秒视频<N秒生成"差1-2个数量级，FastH3 全量落地乐观推算也摸不到
  实时线，不建议投入。

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01EhWwz7mLf5PLBn6noJoAcG

MiniMax-H3 竖屏走的还是 width/height 机制，没有单独的 orientation 字段。给4个已实测
横屏档位（1344×768/832×480/448×256/1024×576）各配一个宽高互换的竖屏选项，帧数上限
沿用对应横屏档位的实测值（同总像素数，显存/耗时特征预期一致，但没有专门重跑过竖屏
OOM 边界测试）。前端 RESOLUTIONS 和后端 RESOLUTION_CEILINGS 保持同步。

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01EhWwz7mLf5PLBn6noJoAcG

公网审计发现 qwen.wudaima.com/console 无鉴权可直调（已知问题一直没排上），以及
comfyui.wudaima.com 也在裸奔（raylight 上线后 8188 常驻监听，旧的"隧道空挂"假设
已经过期，没人重新审计过）。两处都已实测确认修复生效：console 的 /v1/* 全部接口
要求 Authorization: Bearer <token>（H3_CONSOLE_AUTH_TOKEN 环境变量），ComfyUI 隧道
用 frp 原生的 http_user/http_pwd 加了基本认证。

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SURs92UuTkFxDF4RXsEFJi

之前塞在 #job-list 第一行，列表一滚就跟着跑没了；挪到 #sidebar-filters
外面单独一行，选中态（新建视图时高亮）用 renderSidebar() 里同步 class
的方式保留，回收站视图沿用原来的隐藏逻辑。

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01JDWoVwpqrsyzv9LRszTw9d

/v1/videos 一直硬编码 limit=50，服务器上实际232条未删除任务，超出的
根本没请求回来——不是滚动条的问题。改成滚到底部自动翻页加载；同时给
/v1/videos 加 q/status/kind/sort 参数（向后兼容），左侧栏加对应的
搜索框/状态筛选/类型筛选/排序切换。已部署到服务器并用真实数据验证过。

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01JDWoVwpqrsyzv9LRszTw9d

服务器意外重启后 raylight/h3-console 全灭才发现之前没有任何开机自启配置，
补上三个 unit（raylight.service 只管开机拉起一次，两个 h3-console 实例走
Restart=on-failure），详见 CHANGELOG。

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

任务详情页(viewThumb)和上传表单缩略图(wrapWithDelete)都是同一个模式：caption跟media
的DOM顺序对调即可，.thumb-wrap是flex-direction:column，顺序决定视觉位置，不用改CSS。
顺带排查了用户反馈的另一个问题"点击图片变下载"——查了一个具体任务(1cc42a8669a1)的参考图
实际引用的是外部图床(shadiao-2d.oss-cn-aliyuncs.com)，那边响应头自己带了
Content-Disposition:attachment，是外部服务器强制的，不是咱们代码的bug；对比测试过咱们
自己/v1/assets上传的图片没有这个问题。

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

批次中途被watchdog误杀重启打断的5个案例重新提交后也都跑完了，26个可提交案例
（5个结构性不支持的除外）现在全部done。剩下的是人工过一遍视频补观感评价。

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

watchdog.sh按step字段判断denoise是否卡死，但没考虑到step到达total_steps(采样跑完)后
还有VAE解码+存盘这段没有独立进度信号的尾巴，step会停在最终值不变。这段被并入denoise
阶段的10分钟宽限，实测至少一个1344×768长帧数案例这个阶段本身就超过608秒，被误判卡死、
自动整机重启，打断了h3-showcase批量重跑中5个正在跑/排队的任务。修复：给这个阶段单独
一档30分钟宽限(STALL_LIMIT_POSTPROC)。已部署重启watchdog，被打断的5个任务已重新提交
(新任务ID同步进h3-showcase-cases.md)。

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

之前"22已提交"从没回头核实过真实结果——查console.sqlite3发现26个已提交案例里只有10个
真的跑完(done)，其余16个(15 cancelled+1 failed)被期间的服务重启从队列里取消了，状态
停留在没人发现的地方。用存量req_json逐个重新POST /v1/videos入队（新任务ID见表格），
没有重跑那10个已完成的。顺带发现"不支持"统计漏了1.8#2，实际是5个不是4个。

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

/health 之前只读 STATE["model"]（worker()线程启动时设一次"ready"，之后再不更新），
一次OOM把ComfyUI(8188)进程本身搞崩溃退出后，server.py这层壳没死，/health继续骗人报
ready近20分钟，期间提交的任务全部秒失败(ConnectError)才被人工发现。改成每次/health都
真的探测一次8188(GET /system_stats，2秒超时，跟start.sh自己的就绪检测用同一个端点)。
不解决actor崩溃不自愈本身（上游代码问题），只是让崩溃能被更快发现。

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

跟刚才那次代码删除操作对齐文档：workload表、「MiniMax-H3脚本」一节都还在按"代码还在，
只是改名.disabled"描述，但今天已经整个删掉了（改名禁用被绕过重新手动启动过一次）。
顺带把raylight那行"124帧会OOM"的过期结论也更新掉——这是2026-08-22切SAGE_FP16前的
旧数据，一直没同步到这张表，容易误导。

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

生产已全面切到 raylight（2026-08-22起），minimax-h3 的路由代码(gateway.py/api.py等)
今天已经从服务器上删除（保留console/models/venv/outputs/logs）。本地这份是同样的代码，
删前打包备份到 ~/Documents/lemonAI/2080tiserver-backups/
minimax-h3-local-repo-backup-20260824.zip，另外服务器上实际删除的文件也单独打包
下载在同目录 minimax-h3-code-backup-20260824.tar.gz（包含console/models/venv/outputs/
logs之外的全部内容，比本地这份更全，含DISABLED-README.md等本地没有的文件）。

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

排查用户重跑的ref2va任务(1344×768×362帧×3参考图)时发现同一配置当天5次提交4次失败，
查到已有的分辨率/帧数安全上限sweep表全部是0参考图(partition:text)测出来的，从没验证过
带参考图时是否成立。这次任务的真实失败根因是FSDP初始化阶段GPU2/GPU3 OOM（不是一直以来
"GPU0先炸"的老结论），证实带参考图的conditioning张量广播到每个FSDP rank后显存开销明显
更高。写进 raylight/README.md 已知限制第1条、raylight/notes.md、CHANGELOG.md。

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

之前上传后只显示 uuid 文件名，传多个参考图/视频时分不清哪个是哪个。server.py 把原始
文件名塞进存盘文件名（<aid>__<原名>.ext），前端从 URL 反解出来显示在缩略图下方，旧任务
（改动前上传的，URL里没有__分段）会退化成显示uuid，不算错误只是没有原名可用。

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

pipeline 本身支持 cfg_scale/negative_prompt，之前一直裸跑默认值没传。同时补上
2026-08-21 分辨率/Turbo 对比的实测结论：原生1344×768肉眼优于832×480，但ref2va场景下
Turbo开/4步反而比关Turbo跑20步更好（跟纯T2V的旧结论相反，说明这条要按分区分别测）。

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

停 minimax-h3 后反复自己重新起来，一开始误以为是有同事在用（这个归因是错的，已在文档里更正——
用户确认当时只有一个人在用这台机器）。排查 cron/systemd/tmux/screen/supervisor 均未发现自动
重启机制，最后查到系统级 PM2（Node.js进程管理器，跑了75小时，管着这台机器本来就有的其他
基础设施）在托管 stable-diffusion-webui-forge 和一个 embedding 服务，子进程被kill会自动重启——
已 pm2 delete + pm2 save 彻底清除。minimax-h3(gateway.py/api.py)本身不在PM2管辖范围内，真正
触发源没查到，改用把api.py/gateway.py本体也改名成.disabled-20260824的办法从根上堵死（不管
触发源是什么，python -m uvicorn api:app 的 import 直接失败）。验证45秒零重启尝试，raylight/
console全程未受影响，四卡GPU稳定在160-162MB纯基线。

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

重置显存：raylight/server.py 加 /admin/reset-gpu（不挂在具体任务上的通用硬重启入口，应对
actor崩溃不自愈、显存卡在高位但JOBS里没有running任务的情况）。h3-console/server.py 加对应
代理端点 + 一个25秒的"重置中"窗口锁——硬重启期间端口直接连不上，提交新任务只会拿到一个费解
的连接失败，改成明确的409告诉用户还要等多久。前端加"重置显存"按钮，触发后禁用提交按钮、
轮询/health直到真正恢复。停止运行中任务(cancel)同样会触发这个锁。

下线旧接口：排查一次OOM发现GPU1被另一进程占着——另一个并发会话手动拉起了旧的
minimax-h3/gateway.py+api.py四个worker，测试他们改的代码，跟raylight抢卡。按端口停掉，
停了两次都被重新拉起（没有cron/systemd/supervisor在自动重启，是手动执行start-all.sh），
所以把start-all.sh/start-gateway.sh改名成.disabled-20260824，留DISABLED-README.md说明
原因和恢复方法，代码权重都没删。

顺带查到两处过期文档：LLM(llm38)容器实际6天前就已经Exited了，qwen.wudaima.com早就打不通，
不是本次操作停的；"（常驻）whisper GPU3"这条也是过期信息，当时机器上根本没有whisper进程，
实际常驻的是stable-diffusion-webui-forge和一个embedding服务，跟本仓库两条工作线都无关，
已经一并停掉。CLAUDE.md/CHANGELOG都同步更新了。

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

之前撞过好几次 CUDA OOM，事后查 nvidia-smi 才发现是别的工作负载（比如旧 minimax-h3 四卡
worker）在偷偷抢显存，提交任务前完全看不出来。raylight/server.py 的 /health 新增 gpus 字段
（直接读 nvidia-smi，不缓存），console 的 /v1/backends 是纯透传所以不用改，前端在原来的
"后端: ready/排队/运行中"下面加每张卡的显存占用(GB)/百分比/利用率，超过18GB标⚠。

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

之前上传选错/传多了只能清空整个表单重来。每个预览缩略图右上角加一个×删除按钮，点击从
已选列表移除；首尾帧删除时顺带清空对应file input的值，不然重选同一个文件浏览器不会触发
change事件。setThumbs统一改成从uploaded状态重新渲染的renderRefThumbs/renderFl2vaThumbs/
renderTags，删除后重渲染逻辑一致。

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

排队/取消：新增 cancelled 状态区分"排队未跑就被取消"和"运行中被打断"；运行中任务现在能点
"停止"——实测确认 ComfyUI 的 /interrupt 打断不了 Raylight 的 Ray 子进程（打断前后 GPU 一直
100%利用率），唯一办法是硬重启整个服务，已实测两种场景（初始化阶段/满载采样阶段）都能正确
收回 GPU。

参考视频/音频：GenReq 加 reference_video_urls/reference_audio_urls，用 ComfyUI 核心节点
LoadVideo→GetVideoComponents 接参考视频（自动带上视频自己的音轨），LoadAudio 接独立音频。
console 上传接口按类型分级限流，"多参考图生视频"tab 加对应上传框，task.html 的参考图/视频/
音频现在都能直接预览播放（不再只显示文件名），不再需要跳出去看。

顺带修复：报错文本截取从头/尾盲截改成直接定位"XxxError: ..."模式，不会再被 traceback 里的
超长张量 dump 淹没掉真正的报错原因；console 自己的 partition 判断补上新字段，跟 raylight 那份
保持一致。

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

整理飞书 H3 使用手册的 26 个官方示范案例（docs/todo/h3-showcase-cases.md，含提交状态追踪），
补充提示词方法论（raylight/h3-prompt-guide.md，含电影摄影术语表、diegetic/non-diegetic
声音分层框架）、跨模型调研（raylight/deep-research-cinematic-prompt.md）和提示词质量打分
benchmark（raylight/h3-prompt-benchmark.md），CHANGELOG 记录本轮踩的坑（自评分数虚高、
避雷词换句式复发、提示词时长要跟实际frames对齐）。配套的 h3-prompt-writer skill 在
.claude/skills/ 下，按项目约定被 gitignore，不随此提交进库。

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

用 Turing 版 SageAttention2 替换 TORCH_MATH 后端，解开了之前反复出现的 832×480×124帧/
448×256×362帧/1024×576×60帧 OOM；又修复了 asyncio.CancelledError 被 contextlib.suppress
(Exception) 漏接导致任务卡死在 running 的根因 bug。基于修复后的完成检测，实测出 4 个分辨率
的真实 CUDA OOM 上限（448×256 是画质上限，非显存上限），写进 server.py 的提交校验和
console 的分辨率/时长下拉联动，超上限请求直接拒绝而不是排队后才失败。详细过程和数据见
CHANGELOG.md 和 raylight/notes.md。

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

新建 remote-access-from-home.md 记录能用（HTTP 隧道 qwen.wudaima.com）/不能用（SSH
公网隧道 22→6000，TCP 通但 SSH 握手被断）两条路径；docs/todo/ssh-public-tunnel-broken.md
跟踪修复；CHANGELOG/CLAUDE.md 同步记一笔。

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

CFG scale/negative prompt 参数入口（api.py + console 前端「高级参数」）、
参考素材点击插入 <Picture N>/<Video N> 标记、RTX PRO 6000 int8-convrot
冒烟测试成功的记录（h3-rtxpro6000/ 新目录）。这些改动之前只存在于服务器
磁盘和本地磁盘，没进 git，这次是同步不是新增功能。

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

查 DiffSynth-Studio pipeline 源码确认：references 非空时 keyframes 被
静默忽略，不报错。api.py 没有校验，今天的真实任务因为 prompt 里写
@图片N 但没真的挂 reference_image_urls，误以为身份参考图生效了。

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

补齐 h3-rtxpro6000-setup.md（另一线程的调研，之前只在磁盘上没提交）。
新增 raylight-comfyui-multi-gpu-eval.md：2K 分辨率外推显示 2080Ti 显存
需求随 rows 超线性增长，DiffSynth-Studio 现有架构不支持多卡拆分单次生成；
调研到 Raylight（ComfyUI 插件）支持 Turing+PCIe+MiniMax-H3 的序列并行，
但要换整套推理引擎，是独立迁移项目。建议先做 quality-tuning-plan.md
里不用下载东西的两项，排除画质问题不是量化精度导致的，再决定要不要推进。

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

本地开发（脱离办公网络，只能走公网反代），未在真实 GPU 上验证，详见
docs/todo/verify-video-reference-on-gpu.md。

- minimax-h3/api.py: GenReq 加 reference_video_urls，_references() 打通到
  pipeline 已支持的 video/video_audio 参考类型
- h3-console/server.py: /v1/assets 加视频上传支持（mp4/mov/webm，200MB）
- h3-console/static/index.html: 参考视频多选上传 + URL 直填 + 预览，
  重跑/任务详情页同步支持

新增 docs/todo 与 docs/done：把「明天要验证」和「画质改进方案」落成文档，
docs/README.md 做索引，不重复 CHANGELOG 已有的细节。

/v1/videos/{jid}/file 两条返回路径都没设文件名，浏览器只能从 URL 猜，
URL 以 /file 结尾没扩展名，猜出来都是 file.mp4，多个任务的视频存到同一个
下载目录会互相覆盖。加上 filename="h3-{任务id}.mp4"，id 天然唯一。

_try_submit 在 gateway_id 还是 NULL 的窗口里可能被 create_video/get_video/
reconciler_loop 并发调用，导致同一个任务被提交给 gateway 两次，两张卡各烧
一遍 GPU、其中一条变成没人追踪的孤儿任务。加进程内 _SUBMITTING 集合堵住这
个竞态窗口。

任务详情页只显示帧数不显示秒数，加一行按 24fps 折算的"时长"。

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

HANDOFF.md 加了 2026-08-20 夜的最新状态一节（前置，不覆盖历史）：记录当前各服务
实际运行状态、今天做的十项改动摘要、以及一个重要发现——qwen.wudaima.com 现在
实际上是 minimax-h3 的 gateway.py 在占用（llm38 容器当前未运行），不是 Qwen LLM。

代码改动（此前几轮已分别验证部署，这次一并入库）：
- h3-console/server.py、static/index.html：H3_CONSOLE_BASE_PATH 子路径支持，
  用于挂到 qwen.wudaima.com/console
- h3-console/README.md：同步子路径部署说明、gateway.wudaima.com 排查结论
- minimax-h3/api.py：ROWS_LIMIT 支持环境变量覆盖（边界探测用）
- CLAUDE.md：当前负载表格更新 h3-console 的双实例/公网访问方式

API.md 加「任务记录会落盘」一节，讲清 jobs_gpu{N}.sqlite3 是什么、
in-flight 状态为什么没法恢复、只影响直连 api.py/gateway.py 的场景。

h3-console/README.md 补上用户反馈"播放/下载好像有问题"后排查出的三个坑
（download/poll 字段抄错 id、5 秒轮询冲掉播放中的 video、下载接口不支持
Range），以及回滚一节更新——这次的持久化改动碰了 api.py 本身，不再是
"kill console 就完事"。

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

worker()/create() 每次状态变化都写一份到 sqlite（四张卡各一个独立文件），
进程启动时读回内存；in-flight 的 queued/running 记录重启后没法恢复，改判为
failed 并写清原因，不再卡成一条永远"运行中"但没人会再碰的死记录。

落地前用不依赖 torch/GPU 的独立单测验证了 done 保留/running→failed 改判/
upsert 覆盖不重复，再按"只重启空闲的那张卡"逐张滚动重启四个后端上线，
用真实任务验证过重启后 api.py 自己（不经过 console 那层兜底）能找回完整记录。

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

任务行右侧「⋯」菜单可删除，左下角回收站入口可查看/恢复已删除任务。
server.py：jobs 表加 deleted_at 列，DELETE /v1/videos/{id} 软删除、
POST .../restore 恢复，GET /v1/videos?trash=true 切换视图。
不影响弹性调度器的 pending 计数（删除只隐藏，不取消底层任务）。

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>