-
排查任务时经常要么去问 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>
-
之前上传后只显示 uuid 文件名，传多个参考图/视频时分不清哪个是哪个。server.py 把原始 文件名塞进存盘文件名（<aid>__<原名>.ext），前端从 URL 反解出来显示在缩略图下方，旧任务 （改动前上传的，URL里没有__分段）会退化成显示uuid，不算错误只是没有原名可用。 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>
-
用 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>
-
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>
-
本地开发（脱离办公网络，只能走公网反代），未在真实 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> -
- 从服务器同步 gateway.py、gateway-run.sh 等此前本地缺失的核心/调试脚本，修正与 服务器的漂移（此前 push 的本地副本一直缺 gateway.py 这个核心文件） - h3-console/server.py：_refresh_from_gateway 遇到 404 且任务未到终态时判 failed， 不再让后端进程重启丢失的任务永远显示"运行中" - h3-console/DESIGN.md、CHANGELOG.md 同步记录 fl2va/ref2va 默认基线改 2/2 分裂、 frames 上限改按 rows 动态判定的相关变更
-
包含 llama.cpp 部署脚本、MiniMax-H3 探查/运行脚本、h3-console Web 管理台源码， 以及运维文档（CLAUDE.md/HANDOFF.md/llm-setup.md/CHANGELOG.md）。 排除生成的图片/视频/音频产物、.venv、__pycache__ 等运行时/构建产物。