概要
OripaGate通常評価cronのテスト中に、候補readyと制作投入readyを混同し得る挙動が見つかった。候補検査側では制作投入readyのように見える表現が出たが、制作cronがMain Hubを再読込すると、対象はまだ0-A候補または0-B検査待ちの状態であり、production_readyではなかった。
この事故はOripaGateだけの話ではなく、次に作るinvest358の各cronでも、候補収集・候補検査・制作投入・高品質・訂正・改善ハンドオフを同じ「ready」という言葉で扱うと再発し得る。したがって、invest358 cron設計前の必須Gateとして記録する。
発生した問題
- 候補検査cronの会話上またはmemory上で、候補readyが制作投入readyのように見えた。
- 記事制作cronがHub正本を再読込したところ、対象候補はproduction_readyではなく、収集・検査前段の候補状態だった。
- このまま進めると、公式確認、一次情報確認、制作キュー同期が終わっていない候補を記事化する危険があった。
- 今回の確認範囲では、WordPress投稿、本文編集、公開反映は行っていない。
原因
- candidate_ready、ready_for_0B、production_readyの意味が工程ごとに明確に分離されていなかった。
- 検査cronの「ready」という表現が、制作cronに渡してよい状態なのか、次工程で検査すべき候補なのか曖昧だった。
- 制作cron側の取得条件に、対象site、workflow、article_type、content_set、制作stage、制作task_code、production_ready再読込確認を必須化するGateが不足していた。
- 古いworkflowや別カテゴリ、別サイトの参照が品質参考と制作対象の区別なしに見える余地があった。
実施した対策
- OripaGate通常評価では、candidate_ready / ready_for_0B / candidate_ready_onlyを制作投入readyではないと明文化した。
- 制作対象は、Main Hubの制作キューまたはWork Queueで、対象site、対象workflow、対象article_type、対象content_set、制作stage、制作task_code、production_ready=trueを再読込確認できた候補だけにした。
- memoryや会話上のready表現とHub正本が矛盾する場合は、QUEUE_SYNC_MISMATCHとして報告し、制作対象なし、PASS、完了扱いにしないことにした。
- 品質参考として他サイトを読むことと、他サイトや別workflowの候補を制作対象として読むことを分離した。
invest358 cron作成時の必須Gate
- cron作成前に、workflow_id、article_type_id、content_set、site_id、task_stage、task_codeを先に確定する。
- 収集cronは候補を集めるだけで、production_readyを付けない。
- 検査cronは、候補ready、追加確認、除外、制作投入readyを明確に分ける。
- 制作cronは、production_ready=trueだけでなく、制作stageと制作task_codeが一致することを再読込確認する。
- 高品質cron、訂正cron、改善ハンドオフcronは、制作候補キューではなく、それぞれのQAキュー、訂正キュー、改善キューだけを見る。
- 会話上のready、memory上のready、Hub正本のreadyがズレた場合は、必ずQUEUE_SYNC_MISMATCHとして止める。
- 「ready」という単語だけで工程判断しない。readyの種類と根拠を必ず併記する。
- 別サイト、別カテゴリ、旧workflow、参考用サイトの情報を、自分の制作対象キューとして読まない。
今後の扱い
invest358のcron内容を作る時は、このGateを前提に、候補収集、候補検査、記事制作、高品質、訂正、改善ハンドオフの各cronを設計する。特に金融・投資系は誤情報や断定表現のリスクが高いため、候補readyと制作投入readyの分離、一次情報確認、公開前Gateを通常評価系より強く扱う。