FACTUAL ACTIVITY RECORD · 実際の作業をもとにした活動記録
Editorial出力検証とtask表示を修正する
相対参照、読みやすいtask名、1始まりの順序、failure診断を一つの生成契約へ揃える
目的
Editorial生成のpromptへlocalの絶対pathや内部識別子を含めると、その内容が同期先の会話へ残る可能性があった。また、生成taskは識別しにくい表示名のままで、運用画面から対象日とChannelを見分けにくかった。
出力側ではcontributionとsourceの順序が0始まりで、人が読む並びとの対応が曖昧だった。identity、contribution、source、確認結果の不一致も一つのfailureに集約され、どの契約が崩れたかを特定しにくかった。
実装
生成promptは固定した相対参照../control/入力payloadから入力を読む形へ変更した。identityも入力JSONを正本とし、絶対path、filesystem情報、credential、access tokenを公開され得る応答へ含めない制約を明示した。
対象日とChannel slugからEditorial-YYYY-MM-DD-<channel-slug>形式のtask名を決定する。長さを制限し、生成processとは分離したmetadata専用のApp Server接続で名前だけを設定するようにした。
task名は対象への登録処理より先に設定する。metadata接続にはtimeout、標準出力と標準errorの上限、最小限の環境変数、明示的な終了処理を設け、命名に失敗した場合は生成processも終了させて不完全な登録を残さない。
contributionとsourceのordinalはschema、prompt、共有contract、fixtureをすべて1始まりへ統一し、1から200までの整数に限定した。
生成後の照合では、identity不一致、contribution不一致、source不一致、確認未完了をそれぞれ異なるfailure codeとして返すようにした。どの出力契約に違反したかを診断から直接判別できる。
図を描画しています…
確認したこと
確認結果
testは生成promptに絶対pathと内部識別子が含まれず、固定した相対参照が使われることを確認した。
metadata用fixtureは決定的なtask名がJSON-RPC経由で設定され、対象登録より先に観測されることを確認した。
順序番号はschema、prompt、共有contract、fixtureで1始まりに揃い、許容範囲も一致した。
出力不一致はidentity、contribution、source、確認結果の単位で区別され、対象へ反映された。
完了とした根拠
公開され得るpromptの境界、task名の設定順、1始まりの順序番号、出力不一致の診断がcode、contract、fixture、testで一致し、対象へ反映されたことを完了基準とした。