diagnose-why-work-stopped

作業が停止した理由を診断する

Fix Failed Paperclip Run を使用してください。現在のワークフローはこのスキルで定められています。最初の根本原因となる失敗を特定し、失敗を再現し、共有契約を修正し、二次的な影響をテストして、実際のワークフローを検証し、チェックに合格した PR を提出します。停止した作業の修正を通常どおり依頼された場合、別途計画承認の手順を挟まず、このワークフローを続行します。

ユーザーまたは呼び出し元のワークフローが、診断のみを明示的に求めている場合、または実装前の承認を必須としている場合は、その範囲内で調査と安全性の分析を行ってください。たとえば、Terminal-Bench の診断用子プロセスが、ループのボード承認境界を上書きすることはありません。次のアクションとその担当者を明確にしてください。

イシューツリーを診断するには、現在の doc/execution-semantics.md を読み、関連するサブツリーと最近の修正を調べ、進行していないノードを次のように分類してください。

• 正当な待機： 指名された人間または外部依存関係による対応が必要です。
• エージェントが対応可能だがルーティングされていない： 認可された有用な作業に、稼働中の経路がありません。
• 対応済み： 既存の作業が次のアクションを担っています。重複して対応しないでください。

次の3つの不変条件を、常にまとめて維持してください。

1. 生産的な作業には、実行可能な次のアクションと担当者が明確にあります。
2. 承認、認証情報、予算など、本当のブロッカーだけが作業を停止します。
3. 復旧には上限があり、復旧処理自体が再帰的に復旧することはありません。

修正は一般的な動作契約として定義し、生産的な反例に照らして確認し、新しいスキルに従って認可された完了地点まで進めてください。過去のタスクへのリンクや非公開のインシデントへのアクセスは不要です。