FACTUAL ACTIVITY RECORD · 実際の作業をもとにした活動記録
Editorial生成と横断確認を改善する
prompt受渡し、structured output schema、failure診断、全Channel一覧を実運用へ揃える
目的
Editorial生成を実processで確認すると、structured output schemaの定数に型がなくstrict validationで拒否される可能性、promptを起動argumentへ置く扱い、標準error行ではなく情報的stderrだけがfailure理由に出る問題があった。
生成processの入力・schema・diagnosticをCodexの実interfaceへ揃え、Control CenterでもChannelごとの画面を移動せず全Executionと記事本文を横断確認できるようにすることを目指した。
実装
日次実行入口のoutput schemaで、すべてのconstへJSON型を明示した。schemaとpromptをexportしてtest可能にし、生成promptは起動argumentではなく標準入力から渡す形へ変更した。
Codex JSONL streamからerror、turn.failed、task.failedを解析し、nested error messageをbounded diagnosticとして保持する。終了codeが非0ならこのdiagnosticを優先し、なければstderrへfallbackする。root eventのrecord処理はprocess終了結果より先に完了させる。
管理applicationへEditorial画面を追加し、全ChannelのExecutionを一つの一覧から状態、対象日、attemptとともに開けるようにした。statusは運用者向けlabelへ変換する。
記事確認画面はscreening結果と判断を日本語labelで示し、元記事linkと抽出本文全文をDisclosureGroupから確認できるようにした。indeterminate記事では承認選択を出さず、database境界と同じ判断制約をUIへ反映した。
testは全constに型があること、promptが標準入力へ渡ること、JSONL failureから実messageを抽出することを追加で検査し、fixture側もprompt受信を必須にした。
図を描画しています…
確認したこと
確認結果
structured output schemaは定数を含めてJSON型が明示され、strict parserへ渡せる形になった。
promptはprocess argumentに展開されず標準入力へ送られ、fixtureが受信を確認する。
generation failureは情報的stderrではなくJSONLの実error messageを優先して記録する。
Control Centerで全Execution、screening、判断、元記事、抽出本文を一つのEditorial導線から確認できるようになった。
完了とした根拠
schema、prompt、failure diagnosticが実process contractへ揃い、全Channelを横断するExecution／記事確認UIと対応testが対象へ反映されたことを完了基準とした。