Antigravityでは更新できるのに、Codexでは最初うまくいかなかった。 この差を次に活かすため、連携を止めないための運用を明文化しておく。
失敗の本質
最初の失敗は実装ミスではなく、実行環境の差だった。 Codex実行時に `ENOTFOUND` が出ており、外部ホストへ到達できない状態だった。
ここを曖昧にすると「記事が悪いのか」「コードが悪いのか」「環境が悪いのか」が混ざってしまう。 だから最初に、原因の切り分けを手順に組み込む必要がある。
スムーズに連携するためにやること
1. 実行前に接続確認を固定する `npm run doctor` を必ず先に実行し、DNS・API・認証を確認する。
2. 公開は一括コマンドに統一する `npm run ship — posts/
3. 指示はMarkdownで明示する 記事の目的、公開状態、カテゴリ、タグをfront matterで明確化する。 「何をどこまでやるか」を文章で曖昧にしない。
4. 失敗時ログをそのまま残す `ENOTFOUND`、`401`、`403` などの実エラーをそのまま記録し、次回の判断材料にする。 感覚ではなくログで振り返る。
5. 成功条件を定義する 「投稿作成できた」「wp_idが書き戻った」「更新URLに反映された」を成功条件として固定する。
連携の実務ルール（今回の結論）
- 執筆と編集: Antigravity / Codex どちらでも可
- 公開判定: `doctor` が通った環境で実行
- 公開実行: `ship` コマンドに一本化
- 例外対応: 失敗時は記事修正より先にネットワーク・認証を確認
まとめ
今回の学びは、ツールの優劣より「運用の設計」が重要だということだった。 AntigravityでもCodexでも、同じチェックと同じ公開手順を通せば、連携は安定する。 次回はこの手順を前提に、記事作成から公開までを止めずに進める。
