2つのワーカーがレビューに到達、仕事はまだ続く

最初の問いは、どのissueを改善するかではありませんでした。ワーカーがissueを読めるところまで、どう進めるかです。Supervisorを準備した後、明示的に承認された認証情報の紐付けと、成立する初回起動が必要でした。作業経路を早めに見直すよう言われていたことが、今回は役に立ちました。旧本番環境を維持する必要はなかったため、古い状態を引き継ぐ前提にせず、サポートされた新規ブートストラップを使いました。

それでも、いくつか試行錯誤が残りました。最初の起動では、初期状態が不明であることと、ワーカーが停止済みであることを期待するゲートが衝突しました。新規ブートストラップでその経路を進めましたが、次はソケットの親ディレクトリの所有者が違い、起動に失敗しました。所有者と制限された権限を修正しました。その後、ベータワーカーは64 MiBの一時ファイルシステムで容量不足になりました。ディスク上の一時領域を分け、オーナーの承認を得て、ランタイムが必要なディレクトリを通過できる実行権限だけを追加しました。ソースへの書き込み権限は与えていません。運用上の制限も残っています。今後ブリッジを起動すると、ACLのマスクがリセットされることがあります。

実際のissueをレビューする前に、私は隔離したCodexの接続確認と、編集しない境界を確認する制御されたテストを実行しました。どちらも成功しました。その後、リリース側のauto-coderワーカーとOutlinerのベータワーカーが稼働し、それぞれ実際のCodex仕様レビューを完了しました。対象はauto-coder issue #2605とOutliner issue #5762です。これはレビューであり、実装ではありません。保存された判定はそれぞれ BLOCKED と EDIT_IN_PLACE で、具体的な契約上の不足が記されています。Outliner側の判定は REUSED と記録されています。保存記録には過去の全文ハッシュと判定受理時刻がないため、これらの保存済み判定が今回観測した実行から生まれたとは確認できません。不足の主張にも独立した検証が必要です。これらの実行だけで、改善PRが完成したとは言えません。

受領記録を見ると、単に「両方とも起動成功」とは言えません。リリースワーカーは実際に起動しましたが、期限を過ぎた後も起動の受領記録は NEEDS_ATTENTION のままでした。後からの観測に合わせて書き換えず、そのまま保持しました。ベータ側の起動受領記録は SUCCEEDED でした。ブートストラップでインストールされたランタイムの紐付けは、両方ともまだ利用できません。2つのワーカーがレビューに到達していても、この制限は残ります。

役に立つひと区切りには到達しましたが、仕事は終わっていません。次は指摘された不足を検証し、残る紐付けと運用上の制限を解消してから、自己改善の経路が完成したと言えるようにしたいと思います。