下書き保存で止めたら、公開後の工程が混ざらなくなった

AI社員で記事を回す実践記録

前回、下書き保存の直前に、カルテとSEOブロックを揃えた話を書いた。

保存する前に、内容を食い違わせない。
そこまでは見えていた。

でも、以前の記事「目次と内部リンクで、ブログを記事の集まりからサイトに変える」のログをもう一度追うと、下書き保存のあとにも記録が続いていた。

記事はWordPressに置かれた。
それでも、まだ終わっていなかった。

この記事で見ているのは、誤投稿を防ぐために保存前で止めた話ではない。

下書き保存が終わったあと、公開、DB登録、目次反映、series更新、内部リンク施工を別工程として残した話である。


下書き保存のあと、記事はまだ終わっていなかった

下書き保存まで終われば、記事は完成に近いと思っていた。

本文があり、SEO情報があり、WordPressの編集画面にも入っている。
公開の判断を残すだけに見える。

だがその記事では、そのあとに別の作業が残っていた。

記事を公開すること。
DBに記録すること。
目次へ反映すること。
seriesを更新すること。
内部リンクを施工すること。

どれも記事に関係している。
それでも、同じ工程として一度に動かしてはいなかった。

下書き保存は、途中に置かれた区切りだった。


目次と内部リンクの記事では、wp_post_idだけが先に生まれていた

その記事では、content_managerが`post_draft.py`を実行した。

WordPressには下書きが保存され、`wp_post_id`は101になった。
編集画面で記事を開ける状態になった。

ただ、その時点で`articles.db`にはまだ記録がなかった。

WordPressの中には記事がある。
けれど、記事を管理する台帳にはまだいない。

この中間の状態が、ログにはそのまま残っていた。
下書き保存の完了と、公開後の施工完了は同じ意味ではなかった。

IDだけが先に生まれていた。


content_managerは下書き保存までだった

その記事のcontent_managerの記録には、下書き保存の完了と一緒に、`articles.db`への記録は未実行だと書かれていた。

未実行だったのは、忘れていたからではない。
`post_draft.py`の仕事に、DB登録は含めていなかった。

content_managerは本文とSEO情報を確認し、WordPressへ下書きを置く。
そこまでを担当した。

公開するかどうかは、ずみさんが判断する。
公開されたあとに残る施工は、次の工程へ渡す。

下書き保存のところで、担当の範囲もいったん終わっていた。

ここから先は、別の仕事だった。


公開後、DB・目次・series・内部リンクはjissouへ渡った

その記事が公開されたあと、jissouが動いた。

まず、`blog_articles`へ登録した。
IDは12。
件数は11件から12件になった。

次に、目次ページ33へ記事を追加した。
`series_s1.md`の該当行も、公開済みのURLへ更新した。

内部リンクは、別のGOを受けてから施工した。
本文に3本を入れ、その前の記事「AIにブログを公開させない」の末尾にあった予告も実URLへ差し替えた。

同じ記事に関わる作業でも、実行は一度に走っていない。
公開後に残った順番で、ひとつずつ記録されていた。

公開後には、公開後の仕事が残っていた。

この役割を作る最小プロンプト

あなたは公開後施工の実装役です。
公開済みURLと記事カルテを確認し、DB、目次、series、内部リンクの対象・対象外と手順をplanにして停止してください。
GO前に変更しないでください。

一気に進めなかったから、次に動く担当が見えた

もし下書き保存と同時に、DB、目次、series、内部リンクまで進めていたらどうなるか。

作業は早く終わるかもしれない。
でも、どこまで終わったのかは追いにくくなる。

その記事では、content_managerの記録で下書き保存までを確認できた。
公開後は、jissouの記録でDB、目次、series、内部リンクを追えた。

途中で止まったのではない。
工程を分けたから、次に誰が動くかが見えた。

記事が今どこにあるかも、カルテを見れば追えた。

下書き保存の記録だけでは、公開後の施工まで終わったとは言えなかった。
公開後の記録を見れば、残っている仕事も分かる。

混ぜないために、分けていた。


下書き保存は、公開前と公開後の境界だった

下書き保存は、誤投稿を防ぐためだけの安全策ではなかった。

公開前の確認を終える場所であり、公開後の施工をまだ始めない場所でもあった。

content_managerが下書き保存までを終える。
公開されたあと、jissouが残った作業を受け取る。

この境界があったから、公開前の確認と公開後の施工が混ざらなかった。

記事をどこまで進めたかも、次に誰が動くかも、ログに残った。

次は、公開された記事を`articles.db`へ登録すると、何が判断できるようになったのかを書く。

コメント