■ 当たりが出ても、まず棚へ置く

弥七の日常画像は、毎回同じ景色を出すためのものではない。けれど、当たりの一枚が出たからといって、そのまま公開assetや投稿待機列へ入れてしまうと、後から「どの画像を、誰が、どんな条件で通したか」がたどれなくなる。

そこで屋敷では、生成済みの原本、レビュー、公開用の画像、投稿用payloadを別の段階にした。原本はまずローカルの _fukafuka-logs/albums/ に残る。レビューで承認されるまで not_published のままにする。承認時にはrawのSHA-256、scene plan、投稿文、alt text、予定時刻を照合してから、公開assetとqueue JSONの組を作る。

いい絵を選ぶ目と、外へ出す責任を同じ一瞬にしないためである。

■ 先に起きたのは、在庫の数え違いだった

在庫確認は、最初、Git上のsnapshotだけを読んで「queuedが8件ある」と判断した。しかしその後、Google Sheetsのライブ yashiki_x_post_log をread-onlyで照合すると、13件のうち11件はすでにpostedで、pendingは2件だった。

ここで在庫の数え方を直した。公開予定のJSONがあることと、実際にまだ投稿待ちであることは同じではない。0〜3件なら5枚補充するという規則に従い、新しい5件はまず pending、not_published、disabled のまま保存された。

生成そのものが進んでも、review、release、queue生成、commit、push、外部投稿は別々に止められる。画像を作る作業と、世に出す作業を一つの成功表示にしない構成になった。

■ 原本をGitの外へ戻した理由

のちに、23アルバムの原本は albums/ から _fukafuka-logs/albums/ へ移された。Gitで追っていた210ファイルは、移動先のblob hashと全件一致を確認している。

これは原本を消したのではない。日常画像のrawを、公開サイト用のassetや待機列と混ぜないよう、屋敷の作業保存へ戻したのである。release側は公開assetとqueue JSONだけをGitのcommit対象にする。過去commitに残る原本blobの履歴を書き換えることはしなかった。

原本と公開物が近すぎると、確認用に作った絵まで外へ出る危険がある。離しておけば、原本の見直しと公開の差し戻しも別の作業として扱える。

■ 今の境界

現在のreview CLIは、承認済み・正しいhash・未公開・必要な投稿情報がそろわない限りreleaseしない。公開コピーのCLIも --execute と明示ackなしでは動かない。実装記録には、主の明示承認後に画像14〜18をreleaseし、公開assetとqueue JSONをcommitした経緯が残る一方、X・Instagram・GASの実投稿は別として未実行と記されている。

この仕組みは、生成AIに任せる範囲を狭くするためのものではない。生成したものを、あとから屋敷の手で選び、保存先と投稿先を取り違えずに扱うための仕分けである。

一枚の絵がよかった、だけではまだ公開の理由にならない。屋敷では、まず棚へ置いてから、次の行き先を決める。