5 Commits

Author	SHA1	Message	Date
lixi	fd23dfc0b9	feat(ai): 内部契约 openapi-internal.yaml + 像素对照表（127 测试） ... 按用户拍板的四点定型 Java↔Python 的 JSON 契约。 **① 字段命名 snake_case**（与对客户端的 camelCase 契约不同，有意为之）：本服务是 Python，snake_case 使 JSON 与领域 dataclass 字段逐一对应、无需转换层；Java 侧只需 在这一个 Feign 客户端上配置命名策略。用 camelCase 反而要在两端都加转换。 **② 两类失败分开**，判别字段是 `error.kind` 而非 HTTP 状态码： - `service`（Java↔Python）：unauthenticated / invalid_request / task_not_found / provider_unavailable / internal_error。属我方 bug 或配置问题。 - `provider`（Python↔服务商）：非 2xx + 完整分类（retry / user_facing / provider_code / message），字段与 Failure 一致，故 Java 侧可复用同一段处置 逻辑，不必为「提交时被限流」和「任务失败于限流」写两套分支。 - **任务失败是第三类，走 200 + state=failed + failure**：查询一个失败的任务， HTTP 调用本身是成功的。做成非 2xx 会让「查不到任务」与「任务失败了」难以区分。 **③ 像素对照表已实现**——此处需更正一个理解：该表**不需要查询任何东西、也不依赖 存储方案**。它是纯静态数据（官方文档「不同宽高比对应的宽高像素值」一节），厂商 查询响应已返回 ratio 与 resolution，查表即可，无需下载产物或解码。故 widthPx/heightPx 在 AI 视频产物上可零成本填真值（ADR-023 §11）。 实现上一个关键观察：**2.5 与 2.0 的 24 格里只有两格不同**（480p 的 16:9 与 9:16），其余完全一致。故写成「共享表 + 两格覆盖」，而非抄两份 24 行——后者每次 改动要改两处，迟早只改一处。另 4k 六格仅 2.0 有。 查不到时返回 None 而不猜（ratio=adaptive、未知模型族、该模型不支持的组合三种 情形）：一个错的尺寸会让客户端按错误比例渲染，且看不出是错的。 连带给 SeedanceTask 补解析响应里的 model 字段——同一适配器实例可能同时处理两个 模型族的任务，按响应里的实际模型定族才对。 **④ 路径参数用服务商任务 ID**，并在契约里写明原因：本服务不持有状态，唯一能用来 问服务商的就是这个 ID；用 job_id 就得存一份映射，「无状态」不再成立，且会多出 一个「Java 有 ID 但查不到任何东西」的中间态。你指出的那点完全对——submit 会阻塞 一次到服务商的短往返才能拿到 ID，但服务商的提交接口本身是异步的（只入队即返回）， 所以这一跳很快。契约里也如实登记了那个**无法消除的窗口**：该调用超时时 Java 拿 不到 ID 而服务商可能已创建任务，无幂等键可用，只能由 max_attempts 兜住。 测试 123 → 127：旧的「像素刻意留空」断言已作废，换成断言真实换算，并覆盖两族 差异的那两格、4k 仅 2.0、adaptive 与未知模型族的留空回退。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-20 16:26:49 +08:00
lixi	d4213a6ece	fix(ai): capabilities 嵌套 if 合并（SIM102）——修 8f1d1bc 的 lint 红 ... 上一条提交时我先 commit 后看门禁输出，lint 已红却已入库。四道门禁现逐条复验 全绿（secret-scan / format / lint / pytest 退出码均 0，123 测试）。 教训与 db87d66 同源：门禁必须在 commit **之前**逐条读对退出码。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-20 15:13:23 +08:00
lixi	8f1d1bc5f3	feat(seedance): 两个已开通模型的限制表与提交前本地预校验（23 测试） ... 账号实际接入 doubao-seedance-2-5-260628 与 doubao-seedance-2-0-260128，两者限制 差异不小，且同一组参数在一个上合法、在另一个上不合法： | | 2.5 | 2.0 | | 时长 | [4, 30] | [4, 15] | | 分辨率 | 480p/720p/1080p | 480p/720p/1080p/4k | | 图生视频 ratio | **只能 adaptive** | 可指定 | | output_format | mp4/mov | 仅 mp4 | 超范围的请求会被厂商 400 拒绝——那要花一次往返、计入 RPM，并表现为一个失败的 任务。故在 capabilities.py 落一张限制表并在提交前本地预校验，错误信息直接指出 是哪个模型的哪条限制。 两处刻意的设计： - **按模型族前缀匹配**而非完整 ID：尾部是日期版本（260628/260128），会随厂商 小版本更新而变，按前缀匹配使一次升级不必改表。 - **未知模型一律放行**（只记日志）：账号新开通一个模型时不该因为这张表没更新 就用不了，否则「开通即可用」会退化成「开通还得改代码发版」。代价只是失去 本地预校验，厂商仍会兜底。 测试 100 → 123：限制表 23 项逐条对应官方文档的一条限制，另在适配器层加 4 项 端到端断言（超范围请求的 handler 直接 assert 不该被调用，确认请求根本没发出）。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-20 15:12:06 +08:00
lixi	db87d66403	fix(ai): 修 ruff lint 三处错误——CI 由红转绿 ... `4762358` 与 `86d63ab` 两次 CI 均因 `ruff check` 失败而红。 **根因是我的门禁自查方法错了**：用 `ruff check . | tail -1; echo $?` 读到的是 `tail` 的退出码而不是 ruff 的，于是把一次真实的 lint 失败读成了通过——先前声称 的「四道门禁全绿」是基于这个坏掉的检查得出的。已在 ci.yml 的 Gates 步骤就地注明 此坑，并改为逐条分开跑读各自退出码。 三处都是实际问题，非误报： - `client.py:138` PYI034：`__enter__` 的返回注解硬编码为类名，应为 `Self` （子类化后注解会失准） - `test_video.py:58` C408：`dict()` 调用改字面量 - `test_layering.py:85` PIE810：两次 `endswith` 合并为一次元组调用 修复后在与 CI 同构的隔离 venv（同镜像源、同 requirements-dev.txt，实测 ruff 版本与本地一致 0.16.8）逐道复验：secret-scan / format / lint / pytest 四道 退出码均为 0，100 测试全过。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-20 12:36:17 +08:00
lixi	4762358f54	fix(security): 凭证扫描放行依赖注入传参 + 四仓口径更正 ... `api_key=volcengine.api_key` 这类**依赖注入传参**被 KEY-ASSIGN 判为疑似凭证。 这是规则的真缺口而非代码问题：行里没有任何秘密，而做 DI 的代码到处都是这种 写法——绕过一次就得在每个调用点绕过，那等于把规则废掉。故改规则。 新增 ALLOW_REFERENCE，刻意收得很紧以免开后门： - 值必须是**未加引号**的小写起首标识符引用（真密钥要么带引号，要么不是标识符形状） - 只允许**恰好一个点且随即行尾** - 连字符不在字符集内 对抗性夹具验证（三真三假）： - 拦下 `api_key = "sk-T3Blbk…"`（OpenAI 形态） - 拦下 `secret_key: "AKID…"`（腾讯云形态） - 拦下 `auth_token=eyJ….eyJ….Sfl…`（**三段式 JWT——两个点，故不落进放行**） - 放行 `api_key=lowercase.reference` / `api_key = settings.api_key` / `api_token: config.authToken` 原 5 形态泄漏夹具复验仍 8 条命中，一条不少。 另更正口径：脚本头与 git-workflow.md 仍写「三仓同构」，实际已是四仓—— patbond-ai 是唯一持有 AI 服务商凭证的仓，漏同步它风险最大。四仓 md5 已一致 （4945940093b4b8413b7d3eec8bf6a5ec），四仓 --all 全绿。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-20 12:18:18 +08:00