@lingjingai/scriptctl 0.65.4 → 0.65.7

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@lingjingai/scriptctl",
-  "version": "0.65.4",
+  "version": "0.65.7",
   "description": "剧本阶段统一 CLI：素材转 Script v4，并兼容 Script v3 的本地写作、精修、校验和发布。",
   "type": "module",
   "bin": {

package/skills/scriptctl/SKILL.md

@@ -2,8 +2,8 @@
 name: scriptctl
 description: "剧本 script.json 的本地阅读、定位、原子修改、整场整集回写、素材 ingest 与 revision publish CLI。处理 Script v3/v4、剧本资产与 state、Action、场景引用或视频证据核对时使用。"
 metadata:
-  version: "0.32.0"
-  scriptctl_version: "0.65.4"
+  version: "0.32.1"
+  scriptctl_version: "0.65.7"
   author: "official"
 ---
 
@@ -210,6 +210,7 @@ scriptctl ingest -s <素材> -w <workspace>     # 素材转 Script v4
 scriptctl synopsis generate -p "$S" --apply   # LLM 补全剧与分集梗概
 scriptctl audit-assets -p "$S"                # LLM 全剧资产一致性审计
 scriptctl review -p "$S" -s <视频目录>         # 派发 agent 逐集审核并修正
+scriptctl review -p "$S" -s <视频目录> --converge-only --resume-log <已有审核日志>  # 从当前稿的已保存审核记录续接全剧收尾
 scriptctl review -p "$S" -s <漫画ingest工作区>  # 对照 PDF 逐话审核并修正
 scriptctl create --title "…" -p "$S"          # 从零建空剧本
 scriptctl view -w <workspace>                 # 渲染或起审阅页
@@ -221,8 +222,11 @@ scriptctl checkout / status / publish         # 远端工作副本
 单个 PDF 或分话 PDF 目录自动进入漫画 ingest；`--step` 完成下一话，重跑续接已接受进度。漫画正文通过 `extend.scriptctl.source` 保存原 PDF 页码及画格/气泡/文字区域，`view` 可点击正文定位并高亮原页区域。文档模型通过 `ingest.comic-serial` 配置，内置路由为 NNYYAI `gemini-3.8-flash`，使用 `NNYYAI_API_KEY`、base64 PDF 与 `responseSchema`。
 
 `ingest` 的 Gemini 文本、结构化工具、视频和 PDF 文档请求先用配置的主模型，再按 3.8 Flash →
-3.7 Flash → 3.6 Flash 补齐未试模型，全部失败后使用豆包。Gemini 按 provider 的
-`maxAttempts` 重试暂时性错误，豆包最多尝试 3 次；明确拒绝时换模型，用户取消时停止。
+3.7 Flash → 3.6 Flash 在同渠道补齐未试模型。视频随后使用 GrsAI
+（`https://grsai.dakka.com.cn`）的 3.8 / 3.7 / 3.6 Flash，再进入豆包；其他请求在主渠道耗尽后进入豆包。
+GrsAI 使用 `GRSAI_API_KEY` 和 base64 视频，每个型号最多尝试 3 次；未配置密钥或主渠道已为该 GrsAI 地址时跳过此段。
+主渠道视频上传失败时，也从 GrsAI 开始使用本地视频继续请求。
+主渠道 Gemini 按 provider 的 `maxAttempts` 重试暂时性错误，豆包最多尝试 3 次；明确拒绝时换模型，用户取消时停止。
 豆包需要 `ARK_API_KEY`，`ARK_MODEL` 可指定端点。
 已完成集和跨集 context 保留，同 source、同 workspace 重跑会从失败集续接。
 
@@ -251,7 +255,7 @@ agent 并直接改文件。
 
 漫画 Agent 使用原页及局部图片逐页检查遗漏，再对照 action 核对正文、说话人、心声类别、顺序和来源。需要 `pdftoppm`；图片在 `review-pages/`，结果在 `.review/comic/episode-N.json` 和 `global.json`。新增 action 同时写来源，跨页引用保留全部页与区域。`viewed_pages` 只记录图片已加载；未看完整页集会留下 unresolved，不能据此宣称整话通过。漫画不生成时间戳，不执行 ASR；运行由 `--max-steps` 和 `--episode-timeout-ms` 限制。视频保留原有 ASR、校时和媒体预算流程。
 
-换壳仿写使用 `reskin`，各命令都以 NDJSON 逐条上报进度、完成部分保留续跑，模型用 `--model reskin|reskin-claude` 选择：`reskin analyze -p <原剧> -o <拆解.json>` 先通读全剧划分阶段与事件，再按阶段写事件事实、按集切节拍，并归纳全剧画像（原剧地区与台词语言、分项换壳适合度）；`reskin direction -p <原剧> --analysis <拆解.json> [--notes <要求>] [--custom <指定方向>]` 提出候选新壳或判断指定方向；`reskin plan -p <原剧> --analysis <拆解.json> --direction <方向说明> -o <换壳方案.json> [--until overall|events]` 逐层生成整体方案、各阶段事件和各阶段节拍，下层可回改上层并复查受影响部分；`reskin write -p <新剧> --source <原剧> --analysis <拆解.json> --plan <换壳方案.json> [--concurrency <n>]` 按结构表写新剧：先并行写隔一集的各集，再写它们之间的集并接上两头的衔接，`--concurrency 1` 严格按集序逐集写；每条正文记下所属新节拍，不写时间戳；`reskin review -p <新剧> --source <原剧> --analysis <拆解.json> --plan <换壳方案.json>` 做换壳审核（合理性、通顺、程序检查），事件格式与 `review` 相同；`reskin batch <清单.json> -o <目录>` 无人值守地按清单逐部跑完拆解到审核，拆解评出的适合度低于 3 且没写 pick 时停在拆解后，指定方向不可行或需要人工选方向时停在方向步，进度与成本报告写在 `batch-report.json` / `batch-report.md`。
+换壳仿写使用 `reskin`，命令通过 NDJSON 报告进度并保留已完成单元。流程为 `reskin analyze` 拆解、`reskin direction` 选择新壳、`reskin plan` 逐层设计、`reskin write --review-model <profile>` 逐集写作与审核、`reskin review --converge-only` 全剧收尾。写作在每个阶段内按集序执行，阶段之间并行；每集审核完成后，将累积事实账本交给下一集。全剧收尾检查阶段接缝，并由独立上下文通读实际成稿；发现方案层问题时回改方案、复查受影响正文，再读取修复结果。各命令通过 `--model` 选择 profile，写作通过 `--review-model` 指定审核 profile。原剧、拆解、方案和新剧路径分别显式传入 `-p`、`--source`、`--analysis`、`--plan` 等对应参数；用各子命令的 `--help` 查看完整调用。`reskin batch` 按清单逐部运行并保存进度和成本报告。
 
 纯剧本使用独立的审核指令与剧本工具：检查内部结构、引用和设定冲突，不要求时间戳；需要外部事实才能判定的内容保持 unresolved。`review --check` 的 `review_kind` 明确本次选择 script / text / comic / video。
 

package/skills/scriptctl/references/ingest-workflow.md

@@ -98,10 +98,13 @@ scriptctl ingest -s uploads/正片/ -w workspaces/正片 \
   --provider-model gemini-3.7-flash
 ```
 
-- `--upload-mode file-api|base64`：默认 `file-api`；`base64` 把自动转码后的本地视频放入 Gemini `inlineData`，文件必须小于 100 MB。
+- `--upload-mode file-api|base64`：默认采用 provider 的 `videoUploadMode`，内置 NNYYAI 为 `base64`，未配置时为 `file-api`；`base64` 把自动转码后的本地视频放入 Gemini `inlineData`，文件必须小于 100 MB。
 - `--provider-base-url`、`--provider-api-key` / `--provider-api-key-env`、`--provider-model`：只覆盖视频任务对应字段，其余字段继承 `--llm-config` 或内置配置。
 - provider 参数必须提供非空值；`--provider-api-key` 与 `--provider-api-key-env` 互斥。明文参数会暴露在进程参数和 shell history 中，常规调用使用环境变量方式；密钥不会写入 workspace、错误或命令输出。
-- Gemini 文本、结构化工具和视频请求先使用配置的主模型，再按 `gemini-3.8-flash → gemini-3.7-flash → gemini-3.6-flash` 尝试尚未调用的模型，全部失败后才进入豆包。默认路由与显式 provider/model 覆盖均使用此顺序；Gemini 保留原服务地址、凭据和模型名前缀。每个 Gemini 模型按 provider 的 `maxAttempts` 重试暂时性错误，豆包最多尝试 3 次；明确拒绝时直接换模型，用户取消时立即停止。豆包使用 `ARK_API_KEY`；`ARK_MODEL` 可指定端点，默认 `ep-20260721150136-98dj9`。视频的 file-api 和 base64 在 Gemini 模型间复用同一媒体；公共 Files API 上传重试耗尽时交由豆包上传本地视频。直接选择豆包时只调用豆包。
+- Gemini 请求先使用配置的主模型，再按 `gemini-3.8-flash → gemini-3.7-flash → gemini-3.6-flash` 在同渠道尝试尚未调用的模型，保留主渠道的服务地址、凭据和模型名前缀。每个模型按 provider 的 `maxAttempts` 重试暂时性错误；明确拒绝时直接换模型，用户取消时立即停止。
+- 视频的主渠道模型耗尽后，依次尝试 GrsAI（`https://grsai.dakka.com.cn`）的 `gemini-3.8-flash → gemini-3.7-flash → gemini-3.6-flash`，再进入豆包。GrsAI 使用独立的 `GRSAI_API_KEY`、base64 视频和 `responseSchema`，每个型号最多尝试 3 次；未配置密钥或主渠道已为该 GrsAI 地址时跳过此段。视频 CLI 的地址、凭据和模型覆盖只作用于主渠道。
+- 视频在主渠道的模型间复用媒体；切到 GrsAI 时复用 base64 内容，或从本地转码文件读取内容。主渠道 Files API 上传失败时，从 GrsAI 开始继续请求。豆包重新上传同一本地视频。默认路由与显式 Gemini provider/model 覆盖均使用该链；直接选择豆包时只调用豆包。
+- 豆包使用火山方舟 `https://ark.cn-beijing.volces.com/api/v3` 和 `ARK_API_KEY`，最多尝试 3 次；`ARK_MODEL` 可指定端点，默认 `ep-20260721150136-98dj9`。文本、结构化工具和 PDF 请求在主渠道 Gemini 型号耗尽后进入豆包。
 - `--provider-base-url` 指向 Gemini Developer API 兼容的服务根地址；`file-api` 模式要求该服务同时兼容 Files API。
 
 常用 flag：
@@ -109,7 +112,7 @@ scriptctl ingest -s uploads/正片/ -w workspaces/正片 \
 - `--concurrency <n>`：文本 fanout 并发，默认 30。视频逐集串行。
 - `--fps <n>`：视频采样帧率（>1 解锁亚秒级时间码）。默认 3。
 - `--step`：视频每次只处理下一个未完成集。
-- `--upload-mode <file-api|base64>`：视频媒体传输方式，默认 `file-api`。
+- `--upload-mode <file-api|base64>`：视频媒体传输方式，默认采用 provider 配置，内置 NNYYAI 为 `base64`。
 - `--video-output <dsl|json>`：视频模型输出格式，默认 `dsl`（逐行记录，输出 token 约为 JSON 的一半）；`json` 使用 Schema 约束的 JSON。两种格式解析为同一结构，产物一致。模型原文逐集保存：`dsl` 为 `ep/ep_NNN.ep`，`json` 为 `ep/ep_NNN.md`。
 - `--force`：当前视频 pipeline 的**同源**工作区可清掉产物和人工跳过记录重跑（**不能换源，也不能升级旧 pipeline workspace**）。
 
@@ -163,7 +166,7 @@ scriptctl read -p workspace/script.json   # 抽完当普通剧本读
 失败时 `status -j` 的 `errors[]` 按 `failure_type` / `failure_code` 给出稳定分类，并显式给出
 `retryable`。网络错误可含 `system_code`，HTTP 错误可含 `http_status`；Gemini 合规拦截可含
 `provider_source`、`provider_reason` 和 `safety_ratings`。Gemini 请求在当前路由内执行有限的传输
-重试，失败后继续下一 Gemini 模型，最后由已配置的豆包重试兜底；完整模型链都失败时，`attempts[]` 保留各自的 provider、model 和
+重试，失败后继续下一 Gemini 模型；视频还会尝试已配置密钥的 GrsAI 三个型号，最后由已配置的豆包重试兜底。完整模型链都失败时，`attempts[]` 保留各自的 provider、model 和
 失败分类。`usage.json` 记录实际调用的模型和用量。`failure_summary` 汇总 retryable / terminal
 数量和 `by_type`。`state` 仍只表示管线生命周期，合规拦截表现为
 `state=failed` + `failure_type=policy`。