FACTUAL ACTIVITY RECORD · 実際の作業をもとにした活動記録
Editorial Runnerの設計とfixtureを確定する
Channel単位の収集、記事判断、全Agent編集、fresh rerunの境界を先に固定する
目的
Editorial Runnerには、source単位の自動処理やretry・resumeを前提にした古い設計が残り、Channel、Feed、人による記事判断、全Agentの編集会議という新しい運用と一致していなかった。
database実装へ入る前に、実行単位、状態遷移、失敗時の扱い、isolated Codexの出力、Editorial Roomへの登録、local fixtureの関係を一つの設計へ固定することを目指した。
実装
統合仕様で1 Channelを1回のCodex taskと1本の記事draftの単位にした。Channelは複数Feedを持ち、毎時0分に指定hourと一致したものだけを実行する。停止中のcatch-up、自動retry、自動resumeは行わず、再実行は記事取得から始まるfresh Executionとした。
Editorial domainはChannels、Feeds、Runs、Run Executions、Execution Feeds、Run Itemsの6 tableへ限定する設計にした。状態は収集待ちから収集、判断待ち、生成待ち、生成、成功へ進み、途中failureと判断待ちからのstopを明示する。lease、checkpoint、reconciliation、独自audit tableは作らない。
記事は前日JST分だけを安全に取得し、抽出本文を全文chunkへ分割して全chunkをscreeningする。1件でも欠落やprovider failureがあれば記事全体を承認不可とし、Control Centerで記事単位の判断後、承認済み記事が1件以上ある場合だけglobal FIFOへ送る。
isolated Codexはfresh rootで全Agentの日英考察をexact 1件ずつ集め、Content Directorが方針を統合し、Narrative Designerが日英記事へ仕上げる設計とした。Runnerは生成・補完・翻訳を行わず、strict draftを検証して保存するだけにした。
database migrationとfixture説明を、単一のEditorial Desk Room、Channel、Feed、Execution、記事判断、全Agent出力の関係を確認できるdatasetへ更新し、検証scriptの期待値も新しい設計へ合わせた。
図を描画しています…
確認したこと
確認結果
実装前gateとしてChannel／Feed、6 table、status lifecycle、human decision、fresh rerunの責務が仕様へ固定された。
自動retry／resume／catch-up、one-time claim、approval artifact、reconciliation operationを持ち込まない境界が明記された。
全Agent日英考察、日英draft、2つの確認role、単一Editorial Roomという出力contractが定義された。
fixtureとlocal検証の期待値が設計へ同期され、次のdatabase実装がこのcontractから開始できる状態になった。
完了とした根拠
実行単位、database責務、status、失敗・再実行、screening、人による判断、Codex出力、Room登録、fixtureが矛盾なく一つの設計へ揃ったことを、設計確定の完了基準とした。