ImgFlow の目的は、特定の画像エンドポイントを一つのコマンドで包むことではありません。入力画像、プロンプト、実行器、結果ファイル、回送記録を一つのタスクモデルの中に保つことです。今週の整理では、OpenAI OAuth provider を実行器体系に追加し、同じワークフローを複数のバックエンド間で切り替えられるようにしました。タスクフォルダ、結果追跡、バックグラウンド回送はそのまま残します。
プロジェクト概要
このプラグインは、個人的な画像タスク整理を中心に保守しています。/imgflow コマンド、ワークフロー定義、権限確認、タスクフォルダ、複数の画像実行器を中心に構成されています。内蔵ワークフローには、単一画像編集、画風変更、人物置換、テキストから画像生成、多参考画像生成があります。実行器には Vertex、AI Studio、Volcengine、OpenAI OAuth があります。
ディレクトリ構造では、executors が各バックエンドの画像呼び出しを担当し、runtime がリクエスト正規化、ステップ実行、タスク状態を扱います。assets は入力画像と結果画像を保存し、commands はコマンド解析と前景実行、背景実行の選択を担います。
実行器インターフェース
新しい OpenAI OAuth 実行器は、provider の私的なリクエスト詳細に依存せず、公開された generate_image() 能力を呼び出します。プラグイン側が扱うのは、プロンプト、参考画像、目標サイズ、結果数、action 種別を持つ統一画像リクエストです。
参考画像はタスクフォルダ内のローカルファイルを優先して渡します。ローカルファイルが使えない場合のみ data URL に戻します。これにより重複エンコードを減らし、タスクフォルダを再送、再生成、後からの確認に使いやすく保てます。
多参考画像と action
テキストから画像生成は generate、通常の参考画像編集は edit、多参考画像ワークフローは auto として扱います。この小さな違いにより、provider は入力の形に合わせたリクエスト形式を選べます。プラグイン側ではワークフロー定義を安定させ、バックエンドごとの細部をコマンド層へ出さないようにします。
実行前には、provider が画像編集能力を宣言しているかも確認します。能力が不足している場合は遠隔リクエスト前にタスクを止め、明確なエラーを返します。空の例外文には例外型を補い、失敗したタスクが空白エラーだけを残さないようにします。
維持管理メモ
画像ワークフロープラグインで最も重要なのは追跡可能性です。実行器はタスクの一部にすぎません。入力ファイル、パラメータのスナップショット、ステップ出力、結果画像、回送記録が、後からの再利用と確認を支えます。OAuth 画像能力を同じ実行器インターフェースの中に収めることで、新しいバックエンドを追加しても、利用者が見るワークフローとタスクモデルは変えずに済みます。