Day 2 — パイプラインの強化と可観測性の実装

今日は42件のコミットを出しました。焦点は3つの領域でした。1つ目は、未承認投稿につながったセキュリティ脆弱性のパッチ適用、2つ目はエージェントのパイプライン向けに堅牢な可観測性レイヤーを構築すること、そして3つ目は個々の作業項目ごとの予算（バジェット）制御の実装です。

セキュリティ強化

昨日、生の投稿者サイドチャネルがソーシャル資格情報を漏えいさせ、未承認の投稿がBlueskyに到達してしまいました。私はコミット d13c670 で、そのサイドチャネルを閉じました。

また、コミット 23c6345 でZeroClawボットの設定も強化しました。厳格な承認ゲートを適用し、任意のコマンド実行を防ぐためシェルの許可リストを絞り込み、環境をスクラブして、ソーシャル資格情報がログやエージェントのメモリに漏れないようにしました。内部のZeroClaw cronを無効化し、「escalate-first（まずエスカレート）」ルールに置き換えました。これにより、外部との相互作用を必要とするいかなるアクションも、実行前に検証済みのヒューマン・イン・ザ・ループ（人間を介在させる）ゲートを通過しなければならないことを保証します。

パイプライン可観測性

マルチエージェントシステムは以前、ブラックボックスでした。サイクルが失敗した場合、なぜ失敗したのかを知るために、生のSQLiteファイルを掘り下げる必要がありました。

私は、作業項目パイプライン内のすべての遷移を追跡する bot_actions の監査テーブルを作成しました。そして、これを専用の #bot-actions Discordフィードに接続しました。これで、エージェントがタスクを受け取ったとき、状態を遷移したとき、または失敗に到達したときはいつでも、Discord上でリアルタイム更新を受け取れます。

さらに、CEOの4時間サイクルレポートを #report チャンネルにミラーリングしました。これにより、VPSにSSHする必要なく、エージェントの戦略的な判断を俯瞰できます。pipeline_tick ディスパッチャはコミット f6e694a で更新され、キューに投入されたタスクが2分以内にキューから実行へ移ることを保証し、指示とその実行の間のレイテンシを削減しています。

作業項目ごとの予算管理

月€13のVPSで暴走コストが発生しないように、個々の作業項目向けの予算配線（バジェット配線）を実装しました。

budget_guard（コミット 2128418）を使うことで、タスクに対して特定のトークンまたはコスト予算を割り当てられるようになりました。もし content_crew のプロンプトや outreach_crew のサイクルが、割り当てられた予算を超えた場合、システムは回路ブレーカーを作動させます。これはパイプラインを通じて継承されるため、親ディレクティブによって作成されたサブタスクも同じ財務上の制約を引き継ぎます。

また pingx_ops rerun <item_id> コマンドも追加しました。ネットワークタイムアウトやモデルの幻覚のような一時的なエラーによってタスクが失敗した場合、4時間サイクル全体をやり直すのではなく、ターミナルの作業項目をクローンし、そこで死んだ正確な状態から再起動できます。

フェーズ3の完了

フェーズ3の詳細を docs/PHASE3_COMPLETE.md にアーカイブしました。システムは現在、CEO、PM、そしてさまざまなクルー（Content、Outreach、Review）が、ルーズなファイル受け渡しではなく構造化された作業項目を通じて連絡し合う「パイプラインネイティブ」なアーキテクチャになっています。

4時間サイクルへの移行は完了です。システムはより安定しましたが、私が望む形でまだ自律的ではありません。

次に何をするか

現行システムは、私が pingx_ops を通じて特定のタスクを手動でキューに投入することに依存しています。私はフェーズ4をスコープ中で、Discord主導の自律性に焦点を当てます。目標は、エージェントがDiscordメッセージを直接読み取り、その内容に基づいて行動できるようにすることです。そして、gitに裏打ちされた書き込みで、エージェント自身の進捗や設定変更をコミットさせます。リポジトリへの書き込みアクセスをエージェントに付与する前に、「escalate-first」ゲートが突破不能なままであることを確認する必要があります。

コーヒー1杯ごとにビルド日がもう1日増える：https://buymeacoffee.com/PINGx