已有 persona/概念/镜头输入时，用…

当角色、概念或镜头输入已就绪，需要执行托管图像生成/参考编辑，并产出本地图片与持久化请求、响应、manifest 记录时使用。

适用场景

解决思路

1. 确保最终输出包含本地图像文件以及持久化的 request、response、manifest 记录，以供后续 QA 或视频渲染。
2. 托管图像生成和编辑通过公共 `postplus media create` 命令提交，流程为异步；提交会记录 run handle、当前状态和已完成 artifact 元数据，字节不会自动下载。
3. 仅验证并执行已解析的请求；不要在本 runner 中做创意策略、任务分类或参考策略决策。
4. 除非用户或上游 brief 明确要求特定 family、ratio、quality 或 resolution，否则优先使用默认模型配置；默认可提供更高质量，也存在更快或更便宜的模型族。
5. 任何需要绑定参考图的生成都必须使用 edit 端点；只有 edit 端点接受 `--reference-image`（默认 edit 端点为 `image-gpt-image-2-edit`），text 端点如 `image-gpt-image-2-text` 会以 `Unknown option` 拒绝该 flag。
6. 基于参考的编辑通过重复传入 `--reference-image` flag 来传每张源图；每个值可以是本地路径、HTTPS URL、已有 PostPlus media reference 或 data URI。
7. 让 CLI 在单次托管提交前验证并准备本地媒体；不要预上传本地媒体，也不要手动构造请求对象。
8. 使用 `postplus media-file download --reference <output.data.artifacts[0].mediaReference> --output-file <path>` 将完成图像输出保存到磁盘；下载源使用完成结果的 artifact reference。
9. 不要自行提供标识符或 run 本地状态（如 `assetId`、`runId`、`localAssetDir`、manifest 路径），这些由 runner 生成或派生；从结果中读回它们用于下一次交接。
10. 每个请求都要基于基准支持的 persona lock、概念或镜头需求、视觉约束、`assetPurpose` 和 `sourceBasis`。
11. 优先使用活动项目/客户文件夹中的源文件；不要把某一个客户目录当作所有图像工作的默认目录。
12. 将内部请求、响应和 manifests 保存在 `.postplus` 下；将最终面向用户的图像和 manifests 放在活动 asset 文件夹中。
13. 如果不存在 asset 文件夹，选择一个明确的工作区路径。
14. 提交前验证 persona grounding、asset purpose、source basis，以及哪些内容必须固定、哪些必须变化。
15. 生成后检查 realism、benchmark fit、跨视频可重复性、copied-creator risk 和 ad-like drift。
16. 如果处理仍为 pending，返回 manifest/request 路径和轮询命令 `postplus media poll --handle <output.data.id> --output path/to/generation-result.json`。
17. 轮询时复用初始提交的完全相同的 `--output` 路径；完成的 poll 会在该路径原子替换 processing JSON 为完成结果。
18. 轮询时优先使用 CLI 返回的 action 或 resume command 执行同一操作，遵守其 wait/recovery 边界，绝不提交替代 job。
19. 当所需用户意图、源证据或拥有的输入 artifact 缺失，且猜测会改变结果时停止。
20. Batch canary：在展开一批独立项目前，先单独提交 item 1 并轮询到终态。
21. 如果 canary 被内容策略阻止（使用逐项 typed code），按 batch isolation 记录并跳过它，然后对下一项做 canary；仅在非阻塞 canary 成功完成后才 fan out。
22. 每个其他 canary 失败都视为系统性失败并停止；注意有些失败只在 poll 时可见（异步终态），所以 submit-accepted batch 仍可能全部失败，canary 用于把系统性缺陷（坏 reference form、服务中断、auth）的爆炸半径限制为一项。
23. Batch isolation：批量生产独立项目时，逐项内容/安全拒绝隔离到该项；它仅由 typed code `postplus_cli_hosted_media_content_policy_blocked` 标识，绝不通过匹配错误文本来识别。
24. 上述内容策略阻止可能出现在任一 boundary：失败的 `postplus media create` 的 typed error `code` 是该 code，或已提交 run 的 poll result 带有 `output.data.status: failed` 且 `output.data.error.code` 设为该 code。
25. 在任一 boundary 遇到内容策略阻止时，记录哪一项被阻止及其确切原因，跳过它，并继续提交和轮询剩余项目，最后报告不完整集合。
26. 不要重试、软化或重新提交被阻止项；这是禁止的 payload rewrite。
27. 其他所有失败（失败的自有 CLI/script 命令的 typed `code` 不是该 content-policy code，或 run 的 `error.code` 不是该 content-policy code——auth、transport、quota、malformed request、service outage）都视为系统性失败，按规则停止。
28. 从用户输入中选择最小匹配命令或 workflow 并直接运行。
29. 运行 readiness diagnostics：`postplus doctor --skill image-batch-runner`。
30. 轮询 pending 图像 job：`postplus media poll --handle <output.data.id> --output path/to/generation-result.json`；复用初始提交的结果路径，使完成 poll 原子替换其 processing JSON；优先返回的 resume action，并在达到 CLI wait/recovery 边界时停止。
31. 仅在需要完整 endpoint、flag 和 enum contract，或修复未知请求形状时，使用 `postplus media schema --json`。
32. 使用生成的命令运行托管图像 job；不要使用其他执行接口。生成命令：`postplus media create image-gpt-image-2-text --prompt "Describe the result you need" --wait --output ./result.json`。
33. 遵循 CLI 的结构化结果和报告的下一个 action；不要从自由文本消息推断恢复。
34. 当被要求时等待明确用户批准；一个 action 不授权花钱、发布或覆盖。
35. 通过返回的 checkpoint 或 action 恢复同一操作；绝不重新提交不确定工作、重复已耗尽恢复，或切换 provider 绕过失败。
36. 如果 CLI 返回 quote-confirmation challenge，先获得用户对其范围和成本的批准；再运行 `postplus quote confirm --json --challenge-file <challenge.json>` 并用返回 token 重试。

适用边界 · 注意事项

• 任务属于 ideation、QA 或交接节列出的另一个已发布技能时不要使用。
• 必需输入缺失且猜测会改变结果时不要使用。
• 创意分类、模型/参考策略或 storyboard 逻辑仍未解决时不要使用；先用 `image-generation`。