ImgFlow 的目标不是把某个图像接口包成单条命令，而是把输入图片、提示词、执行器、结果文件和回发记录放进同一套任务模型里。本周的整理把 OpenAI OAuth provider 接入执行器体系，使同一个流程可以在不同后端之间切换，同时保留任务目录、结果追踪和后台回发。
项目概览
这是一个面向个人图像任务整理的插件。它围绕 /imgflow 命令、流程定义、授权、任务目录和多个图像执行器展开。内置流程包括单图编辑、换风格、替换人物、文生图和多参考图；执行器包括 Vertex、AI Studio、Volcengine 与 OpenAI OAuth。
目录结构中，executors 负责不同图像后端，runtime 负责请求标准化、步骤执行与任务状态，assets 保存输入图、中间图和结果图，commands 处理命令解析和前后台执行选择。
执行器接口
新增的 OpenAI OAuth 执行器没有再读取 provider 的内部请求细节，而是调用 provider 暴露的 generate_image() 能力。这样插件只关心统一的图像请求：文字提示、参考图列表、目标尺寸、结果数量和动作类型。
参考图会优先使用任务目录中的本地文件路径。只有在本地文件不可用时，执行器才回退到 data URL。这样的处理可以减少重复编码，也能让任务目录继续作为后续重发、重新生成和问题排查的材料来源。
多参考图与动作选择
文生图请求会标记为 generate，常规参考图编辑标记为 edit，多参考图流程保留为 auto。这个区别看起来很小，但能让 provider 根据输入形态选择更合适的请求方式。插件侧则保持流程定义稳定，不把每个后端的细节泄漏到命令层。
执行前还会检查 provider 是否声明了图片编辑能力。缺少能力时，任务会在进入远端请求前停止，并返回清晰错误。空异常文本也会补充异常类型，避免任务失败后只留下空白错误。
维护心得
图像流程插件最重要的是让任务可追溯。执行器只是任务中的一个组件；输入图、参数快照、步骤输出、结果图和回发记录才是后续复用和审阅的基础。把 OAuth 图像能力收进统一执行器接口后，新的后端可以加入，而不会改变用户面对的流程和任务模型。