terminal-bench-loop

Terminal-Bench ループ

Paperclip を通じて Terminal-Bench の問題を 1 つ、合格するスモークテストまで進めるための、繰り返し実行可能な運用スキルです。明示的な課題の構成、回数を制限した実行、ボードの承認を条件とするプロダクト修正、ワークツリーの継続性を備えています。

このスキルは運用および診断向けであり、エンジニアリング向けではありません。Terminal-Bench のループに関する課題、成果物、承認を調整します。コード変更を許可するものではありません。採用されたプロダクト修正はすべて、ボードの確認後に、独立した実装用の子課題として登録されます。

標準の実行モデル：ループを開始する前、またはループ内の課題を移動する前に、doc/execution-semantics.md を読んでください。すべてのループ内課題は、ドキュメントで許可されている状態に置く必要があります。終端状態（done／cancelled）、明示的に進行中（アクティブな実行／キューに入った起動）、明示的な待機中（参加者／やり取り／承認待ちの in_review）、または明示的な復旧・ブロッカー状態（blockedByIssueIds と担当者名を含む blocked）です。

使用する場合

割り当てのタイトルまたは本文が、次のいずれかに該当する場合に使用します。

• 「Terminal-Bench をループで実行する」、「<task-name> を Paperclip でループさせる」
• 「Terminal-Bench fix-git を進める」、「合格するまで Terminal-Bench を反復する」
• 「Terminal-Bench スモークループ」、「ベンチループ」、「<task-name> のスモークループ」
• Terminal-Bench のループ親課題へのリンクが添付され、追加の反復を依頼されている場合

既存のトップレベルのループ課題をユーザーから渡され、次の反復、診断、または再実行を依頼された場合にも使用します。

使用しない場合

• paperclip-bench 自体（Harbor アダプター、ラッパー、テレメトリー）を構築または変更する割り当ての場合。このリポジトリでは通常のエンジニアリングフローを使用してください。
• ランキング用のベンチマーク結果を提出する割り当ての場合。このスキルでは、仕様上、スモークテスト用／比較不可能な実行が生成されます。フルスイート実行または比較可能な実行は BenchmarkQualityManager にエスカレーションしてください。
• Terminal-Bench ループでは表面化していない、通常の Paperclip プロダクトのバグの場合。通常の調査を行ってください。
• 会社のスキルをインストールまたは割り当てる権限がなく、依頼者が実際にはライブラリの変更を求めている場合。その手順は、権限を持つスキルライブラリの担当者に引き継いでください。

必ず守るべき 3 つの不変条件

すべてのループ反復と提案するプロダクト修正では、次の 3 つの不変条件を同時に満たす必要があります。これらは /diagnose-why-work-stopped に由来し、ユーザーは稼働継続性に関する作業で繰り返しこの条件を示しています。

1. 生産的な作業を継続する。 各ループ課題には、次のアクションを担う担当者（エージェント、ボード、ユーザー、または明示されたブロッカー）を必ず明確にしてください。誰も待っていないのに in_review のまま放置してはいけません。
2. 実際のブロッカーだけが作業を止める。 本当に先へ進めない場合（ボードの確認、QA、認証情報の不足、予算の枯渇）にのみ停止します。見せかけの停止を検知し、適切な担当先に振り分けてください。
3. 無限ループを避ける。 反復回数と実時間の予算を制限し、プロダクト修正の適用前にボードの承認を必須にすることで、ループに上限を設けます。

提案する反復が 3 つの不変条件のいずれかに違反する場合は、取り下げるか、やり直してください。この反復で各不変条件がどのように満たされているかを、ループ課題に明記してください。

Inputs

これらはイテレーション 1 の前に、最上位のループ課題に集めます。提供できない入力がある場合はブロッカーとなるため、ブロック解除の担当者を明記して停止してください。

• ソース課題。 ループを依頼した Paperclip の課題です。ループの親課題からリンクします。
• Terminal-Bench タスク名。 単一タスクの識別子です（例：terminal-bench/fix-git）。複数タスクのスイートはこのスキルの対象外です。
• イテレーション予算。 追加の修正を行わずにループを停止しなければならないまでの最大イテレーション数です（通常は 3～5）。イテレーションごとの実時間上限も記録してください。
• Paperclip App の作業ツリー課題。 Paperclip App プロジェクト内の実装側の課題です。この課題の実行ワークスペースが、隔離された作業ツリーを管理します。最初のイテレーションで作成し、以降のイテレーションでは inheritExecutionWorkspaceFromIssueId または同等の方法で再利用します。
• ベンチマークコマンド。 テスト対象の Paperclip App の作業ツリーに紐付けた PAPERCLIPAI_CMD（または同等のバインディング）を含む、正確な paperclip-bench の実行コマンドです。ループ課題にそのまま記録してください。
• ディスパッチランナー設定。 スモークテストで Paperclip のハートビートを実際に開始するために必要な、正確な Harbor／Paperclip ランナーのディスパッチ設定です。現在の Harbor ラッパーでは、assignee、heartbeat_strategy、agent_adapter／agent_adapters、ローカルの認証情報が意図的に必要な場合の reuse_host_home、および停止予算を保持できるよう、PAPERCLIP_HARBOR_RUNNER_CONFIG の JSON（または同等の設定ファイル）を十分に正確な形で記録してください。BEN-1 を未割り当ての todo として作成し、ハートビートが有効なエージェントが 0 件になるだけの Harbor コマンドは、ハーネス／セットアップの失敗であり、製品の有効な診断ではありません。
• 最新のアーティファクトのルート。 paperclip-bench が実行アーティファクト（manifest、results.jsonl、Harbor の未加工ジョブフォルダー、秘匿化されたテレメトリ）を書き込むファイルシステムまたはストレージのパスです。各イテレーションで追記し、上書きはしません。
• 承認ポリシー。 提案された製品修正の実装前に承認する必要がある担当者です（デフォルトは request_confirmation による board、委任されている場合は CTO、ループの推進役のみで承認することはありません）。

各入力は、最上位のループ課題（説明または専用の inputs ドキュメント）に記録してください。ループの途中で入力が変更された場合は、変更内容と、変更が適用されたイテレーションを記録してください。

Issue topology

ループはコメント内の文章ではなく、ツリーとして表現できなければなりません。

• 最上位のループ課題。 長期間存続します。入力、イテレーションカウンター、現在の状態、すべてのイテレーション子課題へのリンク、製品ルールの履歴を保持します。イテレーションの実行中は in_progress、型付きの待機対象がループ親課題に直接紐付いている場合（実行ポリシーの参加者、request_confirmation／ask_user_questions／suggest_tasks のインタラクション、承認、または指名された人間の担当者）に限り in_review、子課題がゲートとなる作業である間（修正提案の request_confirmation を保持するイテレーション子課題、または実装、QA、CTO レビューの子課題）は blocked として blockedByIssueIds を設定し、合格時は done、board による却下または予算超過時は cancelled になります。
• イテレーション子課題。 イテレーションごとに 1 つ作成します。それぞれに、範囲を限定した実行課題（スモークテスト）、診断課題（/diagnose-why-work-stopped を適用）、request_confirmation インタラクションを含む修正提案ドキュメントを持たせます。また、承認後に限り、実装、QA、CTO レビュー、再実行の子課題を作成します。実行者が順番に起動するよう、イテレーション子課題は先行課題によってブロックされます。
• Paperclip App の実装課題。 最初のイテレーションでは、プロジェクトポリシーによって隔離された作業ツリーが生成される、新しい Paperclip App の子課題を作成します。以降の各イテレーションの実装／再実行子課題では、同じ作業ツリーを修正してテストするために、inheritExecutionWorkspaceFromIssueId を介して同じ実行ワークスペースを参照します。

依存関係は blockedByIssueIds で設定し、「X によってブロック中」のような文章で表現しないでください。依存先の子課題が done になると、実行者が次の課題を自動的に起動します。

Procedure

0. 現在の実行契約を読む

ループを開始または進める前に、doc/execution-semantics.md を読んでください。ループの問題の状態を分類するときは、そのドキュメントの用語をそのまま使用してください：live path / waiting path / recovery path；post-run disposition；bounded continuation；productivity review；pause-hold；watchdog。新しい状態を作り出さないでください。

1. トップレベルのループ課題を開くか、再利用する

• 既存のループ課題が提示されている場合は、それを読んでください：入力、イテレーションカウンター、直近のイテレーションの停止理由、現在の Paperclip App ワークツリーポインター、最新のベンチマークコマンド。
• ループ課題が存在しない場合は、Paperclip App プロジェクト（またはソース課題が示すプロジェクト）に作成してください。タイトル：Terminal-Bench loop: <task-name>。説明には、上記の入力、イテレーション予算、ソース課題へのリンクを記載します。
• ワークツリーポインターが引き続き有効であることを確認してください。記録された実行ワークスペースが破棄されている場合（ワークツリーのプルーニング、プロジェクトの変更）、ループはブロックされています。ブロック解除の担当者（CodexCoder または Paperclip App のオーナー）を明記して停止してください。

2. イテレーションの子課題を開く

• ループ課題のイテレーションカウンターを増やしてください。
• Iteration N: <task-name> というタイトルでイテレーションの子課題を作成します。説明には入力を繰り返し記載し、親ループを参照します。実行者が 2 つのイテレーションを並行して開始できないように、前回のイテレーションの終了時の子課題（存在する場合）をブロッカーとして設定してください。
• イテレーションカウンターが予算を超える場合は、子課題を作成しないでください。ループ課題を cancelled（予算を使い切った場合）にするか、ユーザーが予算延長を判断する必要がある場合は in_review にしてください。

3. 範囲を限定したスモークテストを実行する

• ベンチマークコマンドでは、テスト対象の Paperclip App ワークツリーを使用する必要があります。PAPERCLIPAI_CMD（または同等のコマンドバインディング）を、そのワークツリー内の CLI エントリーポイントに設定してください。オペレーターの現在の Paperclip チェックアウトに対してスモークテストを実行してはいけません。
• 同じコマンドブロックに、ベンチマーク課題を実行可能にするランナーディスパッチ設定を含める必要があります。現在の Harbor ラッパーでは、意図した担当者、ハートビート戦略、エージェントアダプター、認証情報／ホームディレクトリのモード、停止予算を指定して、PAPERCLIP_HARBOR_RUNNER_CONFIG をエクスポートしてください。ディスパッチ設定が省略された単独の uvx harbor run ... を正式なスモークテストとして扱わないでください。その場合はハーネス／セットアップの不備として記録し、記録済みの設定で再実行してください。
• 実行時間の上限と Paperclip の実行予算制御の両方で、実行範囲を制限してください。スモークテストがイテレーションごとの上限を超えそうな場合は、強制終了して、打ち切り理由を記録してください。
• イテレーションの子課題または専用の run ドキュメントに、以下を記録してください：
  • Paperclip の実行 ID とハートビート実行 ID
  • ベンチマーク実行 ID、マニフェスト、results.jsonl の行、Harbor の生ジョブフォルダー
  • 使用したディスパッチ設定（PAPERCLIP_HARBOR_RUNNER_CONFIG または同等のもの）。担当者とアダプターの種類を含めます。
  • ハーネスが報告した正確な停止理由（合格、ハーネス失敗、検証失敗、タイムアウト、エージェントが断念、インフラストラクチャエラー）
  • Paperclip のテレメトリでエクスポートされる場合は、ハートビートが有効なエージェント数と、ハートビートが観測されたエージェント数
  • 失敗の分類区分（タスク／モデル、Paperclip 製品、ハーネス／セットアップ、検証／インフラストラクチャ、セキュリティ、不明）
  • 最新のアーティファクトルート配下のアーティファクトパス
• イテレーションに スモークテスト／比較不可 のラベルを付けてください。比較可能な実行は、このスキルの対象外です。

4. 正確な停止箇所を診断する

このループのみに範囲を限定して、今回の実行に /diagnose-why-work-stopped パターンを適用します。無関係なフォレンジックの定型情報は含めないでください。具体的には、次の作業を行います。

• Paperclip App のワークツリー配下にスモークテストで生成された Paperclip の課題ツリーを、ノードごとにたどり、進行を止めた正確な (issue, status) の組み合わせを特定します。根拠として、実行 ID、コメントのタイムスタンプ、ステータスの遷移を引用してください。
• サブツリー内で進行していないすべての課題を、本当に人間またはボードの介入が必要、エージェントが対応可能だが現在ルーティングされていない、すでに対応済みのいずれかに分類します。
• 失敗の原因がタスク／モデル、Paperclip 製品、ハーネス／セットアップ、検証ツール／インフラストラクチャ、セキュリティのどれに該当するか、または不明かを明記します。根拠が推測である場合は、明示してください（例：企業をまたぐ API の境界により直接読み取りができない）。
• 失敗が Paperclip 製品のギャップに起因する場合は、修正案を契約として示す一般的な製品ルールとして提示し、上記の 3 つの不変条件に照らして確認します。そのルールによって最近の生産的な実行が妨げられる場合は、適用範囲を狭めてください。

診断内容は、イテレーションの子課題に diagnosis ドキュメントとして記録します。まだコードを提案しないでください。

5. 次のアクションを決める

診断に基づき、イテレーションは次のいずれか 1 つの終了状態にします。

• 合格。 スモークテストの検証ツールが合格を報告しています。イテレーションの子課題とループの親課題を QA／CTO レビューへ進めます（ステップ 8）。
• 製品修正を提案。 Paperclip 製品のギャップが特定されました。修正案をイテレーションの子課題に plan ドキュメントとして記述し、ステップ 6 に進みます。
• 製品以外の失敗（再試行あり）。 失敗の原因がハーネス／セットアップ／インフラストラクチャ、またはモデルの不安定さであり、イテレーションの予算が残っていて、ループのドライバーがコードを変更せずに再実行することに意味があると判断しています（例：一時的なインフラストラクチャ障害）。その根拠をイテレーションの子課題に記録し、実装ステップを挟まずにステップ 7 に進みます。
• 実際のブロッカー。 特定済みの外部ブロッカー（認証情報、クォータ、サードパーティの障害、セキュリティレビュー）があります。ループの課題を blocked に移し、blockedByIssueIds にブロッカーの課題を設定します。必要であればブロッカーの課題を作成し、ブロッカー解除の担当者を明記します。ここで停止します。
• 予算到達またはボードによる停止。 イテレーションの予算に達したか、ボードが次の修正案を却下しました。実行履歴と停止理由を要約するコメントを付けて、ループの課題を cancelled に移します。

6. 製品修正を行う前にボードの確認を依頼する

イテレーションが 製品修正を提案 して終了した場合：

• 提案する契約、3 つの不変条件のチェック、影響を受ける Paperclip のサーフェス、フェーズ分けされたサブタスク（実装、QA、CTO レビュー、再実行）を、イテレーション子課題の plan ドキュメントに更新します。ただし、これらのサブタスクは作成しません。
• イテレーション子課題（plan ドキュメントを所有する同じ課題）で request_confirmation インタラクションを開始し、最新の計画リビジョンを対象にします。冪等性キー：confirmation:{iterationIssueId}:plan:{revisionId}。continuationPolicy は wake_assignee に設定します。
• イテレーション子課題を in_review に移動します。型付き待機者である request_confirmation インタラクションは子課題に直接紐付いているため、子課題が in_review であることに問題はありません。コメントには計画ドキュメントへのリンクと、確認待ちであることを明記します。
• ループ親課題を blocked に移動し、blockedByIssueIds: [iterationChildId] を設定します。ブロック解除の担当者として、ボード（または承認ポリシーの設計で指定された承認者）を明記したコメントを付けます。ここでループ親課題を in_review に移動してはいけません。型付き待機者は親課題ではなくイテレーション子課題に紐付いているため、親課題の待機経路は子課題によるブロックです。これは、型付き待機者が親課題に直接紐付いている場合に限り、ループ親課題を in_review にするというトポロジールールに沿っています。
• 承認を待ちます。ボードが計画を変更する後続コメントを投稿した場合は、ドキュメントを改訂してから、イテレーション子課題で新しいリビジョンに紐付けた確認を新たに開始します。以前の確認は無効になります。ループ親課題の blockedByIssueIds はすでにイテレーション子課題を指しているため、変更する必要はありません。
• 却下された場合は、予算またはボードによる停止のルールに従ってループを終了します。同じ提案を黙って再試行してはいけません。
• 承認された場合は、実装、QA、CTO レビュー、再実行の子課題を作成し、blockedByIssueIds を順番に設定します。また、ループ親課題の blockedByIssueIds を、新しいゲートとなる子課題（通常は実装子課題）を指すように更新し、実際の後続作業によるブロック状態を維持します。修正をスモークテストと同じ隔離された worktree に反映するため、実装子課題には Paperclip App の実行ワークスペースを継承させる必要があります（inheritExecutionWorkspaceFromIssueId に、worktree を所有する課題を指定します）。

7. 同じ worktree で再実行する

実装と QA が完了した後（または 再試行ありの製品以外の失敗 の場合は直ちに）、再実行子課題で同じ paperclip-bench 呼び出しを実行し、PAPERCLIPAI_CMD はテスト対象の Paperclip App worktree に固定したままにします。

• 再実行では、修正を反映したものと同じ worktree を使う必要があります。イテレーション間にワークスペースがリセットされていた場合、ループは無効です。ループ課題にブロッカーを開いて停止します。
• 完了すると、再実行子課題が次のイテレーションの実行記録になります。スモークテストに合格した場合は、ステップ 8 に進みます。それ以外の場合は、新しいイテレーション子課題を作成してステップ 4 に戻ります（イテレーション予算の範囲内）。

8. パス：QA、CTO によるレビュー、クローズ

スモークテストに合格したら、次の手順を実施します。

• QA と CTO によるレビューの子課題が依存関係チェーンにまだ含まれていない場合は作成します（CTO によるレビューは QA によるレビューがブロッカーとなるため、チェーンは順番に開始されます）。ループの親課題を blocked に移動し、blockedByIssueIds に QA／CTO のレビューチェーンを設定します。また、QA と CTO がブロック解除の担当者であることを明記し、子課題へのリンクを含むコメントを投稿します。型付き待機者は親課題ではなく子課題に設定されているため、ループの親課題は in_review ではなく blocked のままにします。
• このフェーズ中にループの親課題自体を in_review にしたい場合（たとえば、ボード上のユーザーが明示的にレビューを進めると申し出た場合）は、実行ポリシーの参加者、request_confirmation／ask_user_questions／suggest_tasks の各種インタラクション、承認、または氏名を指定した担当者など、型付き待機者を親課題に直接設定します。子課題のチェーンだけに頼らないでください。親課題を in_review にすると同時に、QA／CTO の子課題をブロッカーとして機能させてはいけません。このスキルは、そのような曖昧なレビュー状態を防ぐためのものです。
• QA は成果物（マニフェスト、results.jsonl、Harbor の生ジョブ、秘匿化済みテレメトリ）と、同じワークツリーを使った再実行の再現性を検証します。
• CTO は、ループ中に反映された製品修正の技術的な範囲をレビューします。
• QA と CTO が承認したら、ボードレベルの要約コメントを添えてループ課題をクローズします。コメントには、タスク名、反復回数、停止理由（合格）、ワークツリーの参照先、最終成果物のルートへのリンク、承認された製品修正の一覧（それぞれの実装課題 ID を含む）を記載します。

9. 停止ルール

次のいずれかに該当する場合、ループは必ず停止し、ループ課題に状態を明示的に記録します。

• 合格。 スモーク検証ツールが合格を報告し、QA と CTO が承認します（ステップ 8）。ループ課題 → done。
• ボードによる却下。 ボードが修正案を却下し、修正を求めない場合。ループ課題 → cancelled。却下された提案と理由をコメントに記載します。
• 反復回数の上限に到達。 合格しないまま反復カウンターが上限に達した場合。ループ課題 → cancelled（ユーザーが上限を延長するか判断する必要がある場合は in_review）。反復 N+1 を暗黙的に開始してはいけません。
• 実際のブロッカーが特定された。 外部ブロッカー（認証情報、クォータ、インフラ、セキュリティ、不足しているスキル）をループの担当者が解決できない場合。ループ課題 → blocked。blockedByIssueIds にブロッカー課題を設定し、ブロック解除の担当者を明記します。

ループを文章だけのコメントで終了してはいけません。停止するたびにステータスを遷移させ、次のアクションの担当者を明記します。

ワークツリーのルール

ループでは、ハートビート時点でたまたまカレントになっている Paperclip のチェックアウトをテストしてはいけません。提案された修正を適用する、分離された同一の Paperclip App ワークツリーをテストする必要があります。

• 最初の反復で Paperclip App の実装子課題を作成します。そのプロジェクトの git-worktree ポリシーにより、新しいワークツリーが生成されます。
• ループ課題には、ワークツリーを所有する課題 ID とワークスペースのパス（またはワークスペース ID）を記録します。
• 以降のすべての実装、QA、再実行の子課題では inheritExecutionWorkspaceFromIssueId にワークツリーを所有する課題を設定し、後続のループ作業すべてで同じワークスペースを共有します。
• ベンチマークコマンドでは、常に PAPERCLIPAI_CMD（または同等のコマンドバインディング）にそのワークツリー内の CLI エントリーポイントを設定します。また、ベンチマーク課題を割り当ててハートビートを開始するために必要な、記録済みのディスパッチランナー設定（PAPERCLIP_HARBOR_RUNNER_CONFIG または同等の設定）も指定します。ループ課題に保存されたベンチマークコマンドを唯一の信頼できる情報源とします。ハートビートで別のシェルからスモークテストを実行する必要がある場合は、Harbor の呼び出し行だけでなく、記録済みのコマンドブロックをそのままコピーします。
• ワークスペースが削除された場合、またはワークツリーのパスを解決できなくなった場合、再構築するまでループは無効です。ループを blocked にし、ブロック解除の担当者（通常は CodexCoder または Paperclip App のオーナー）を明記します。

ライブネスルール

すべてのループ課題は、各ハートビートの終了時に、必ず次のいずれかの状態にある必要があります。

• 終了: done または cancelled。以降の対応は不要です。
• 明示的に進行中: in_progress で、実行中のラン、実行予定のキュー済みウェイク、または配下で実行中の子課題があります。
• 明示的に待機中: in_review で、型が指定された待機対象（実行ポリシーの参加者、request_confirmation／ask_user_questions／suggest_tasks のインタラクション、承認、または名前が指定された人間の担当者）があります。
• 明示的な復旧／ブロッカー: blocked で、blockedByIssueIds に実際のブロッカー課題が設定されており、ブロック解除の担当者と必要な対応を明記したコメントがあります。

終了時にループ課題がこれらのいずれにも当てはまらない場合、ハートビートは完了していません。終了する前に状態を修正してください。

注意点

• オペレーターの Paperclip チェックアウトに対してスモークテストを実行すること。 ワークツリーのルールの目的は、修正が取り込まれるワークツリーでベンチテストを実行することです。実行を開始する前に、必ず PAPERCLIPAI_CMD を設定し、パスを確認してください。
• ディスパッチ設定を省略すること。 PAPERCLIP_HARBOR_RUNNER_CONFIG（または同等の設定）を省略した Harbor 実行では、Paperclip が起動して BEN-1 が作成されても、担当者が割り当てられず、ハートビートが有効なエージェントがゼロのままになる可能性があります。これは Terminal-Bench のプロダクトシグナルではありません。担当者とアダプター設定を含め、コマンドブロック全体を保持して再実行してください。
• 承認前にコーディングすること。 ボード上で確認され、イテレーションの plan ドキュメントが承認されるまで、実装用の子課題は作成されません。診断フェーズではコードをプッシュしないでください。
• 最近の作業の調査を省略すること。 Paperclip のプロダクトルールを提案する際は、対象となるライブネス／実行領域で、ここ数日にすでにリリースされた内容を確認してください。先週承認された契約に反するルールは、やり直しにつながります。
• in_review を完了扱いすること。 参加者、インタラクション、承認、人間の担当者がいないまま in_review に留まっているループまたはイテレーションの子課題は、進捗ではなく停止状態です。ライブネス違反として扱い、適切な担当先に回してください。
• イテレーション N+1 を黙って開始すること。 イテレーションの上限に達した場合、ループ課題に予算の延長が明示的に記録されていない限り、次のイテレーションを開始してはいけません。
• 比較可能なランとのずれ。 このスキルが生成するのはスモークランのみです。依頼者が比較可能なベンチマーク提出を求める場合は、BenchmarkQualityManager と BenchmarkForensics に引き継いでください。スモークを比較可能なランと称してはいけません。
• 再帰的な復旧。 停滞した作業を復旧する処理が、自身の復旧課題まで復旧することは、無限ループの典型例です。スモークのサブツリー内で診断によりこれが明らかになった場合、深掘りを拒否し、プロダクトルールの修正のため /diagnose-why-work-stopped に回してください。
• スキルライブラリの変更。 このスキルは、ループのイテレーションの一環として、会社のスキルをインストール、編集、割り当てすることはありません。ライブラリの変更は、別の課題を通じて、権限を持つスキルライブラリの担当者に依頼してください。
• 経緯を隠すこと。 失敗したイテレーションの子課題、撤回された提案、却下された確認を、黙って削除したり隠したりしないでください。監査証跡はループの根拠となる記録です。

ハートビートを終了する前の確認チェックリスト（ループに変更を加えた場合）

• 正確なベンチマークコマンド、PAPERCLIPAI_CMD のバインド、ディスパッチランナーの設定を含め、すべての入力がトップレベルのループ課題に記録されています。
• イテレーションカウンターが最新で、予算内に収まっています。
• Paperclip App のワークツリーポインターが引き続き解決され、イテレーションの実行／実装／再実行の子課題が同じワークスペースを共有しています。
• スモーク実行について、実行 ID、マニフェスト、results.jsonl、Harbor の生ジョブフォルダー、停止理由が記録されています。
• Paperclip のテレメトリに、ベンチマーク課題が割り当てられ、ハートビートが有効化または確認されたことが示されています。または、そのイテレーションがハーネス／セットアップによる未ディスパッチとして明示的に分類されています。
• 診断で /diagnose-why-work-stopped のパターンを適用し、進捗していない課題をすべて分類して、3 つの不変条件を確認しています。
• 未承認の修正提案に対する実装の子課題は存在しません。修正が提案された場合は、最新の計画リビジョンに対する request_confirmation が未完了の状態です。
• すべてのループ課題とイテレーション課題が、終了済み、明示的に進行中、明示的に待機中、または名前付きブロッカーのいずれかの状態にあります。
• このハートビートでループが停止した場合、停止理由は合格、ボードによる却下、予算の枯渇、または実在する名前付きブロッカーのいずれかです。
• このハートビート中に会社のスキルライブラリは変更されていません。

決定論的スモークテスト

スキルをインストールまたは変更した後、ライブの Terminal-Bench ループで運用可能と見なす前に、このスモークテストを実行します。

pnpm smoke:terminal-bench-loop-skill

このコマンドは、PAPERCLIP_API_URL、PAPERCLIP_API_KEY、PAPERCLIP_COMPANY_ID の現在の Paperclip API トークンと会社を使用します。PAPERCLIP_TASK_ID が設定されている場合、スモークテストの課題はそのソース課題の下に追加され、プロジェクト／目標のコンテキストを引き継ぎます。デフォルトでは、検証後に短時間だけ存在するスモークテストの課題をキャンセルします。検証済みの blocked 状態のループ親課題、in_review 状態のイテレーション子課題、保留中の確認を残して手動で検査するには、-- --keep を渡します。

このスモークテストは決定論的であり、比較を目的としません。Terminal-Bench、Harbor、エージェントモデル、プロバイダーランタイムは起動しません。制御プレーンの構造のみを検証します。

• ローカルの .agents/skills/terminal-bench-loop/SKILL.md にループ契約の用語が含まれていること。
• トップレベルのループ課題を作成し、ブロッカー状態に更新できること。
• ループ親課題の下にイテレーション子課題を作成できること。
• モックのベンチマーク成果物パスが run ドキュメントに記録されること。
• diagnosis ドキュメントに、正確な停止箇所と次のアクションの担当者が記載されること。
• request_confirmation インタラクションが作成され、イテレーション子課題が、レビュー中のまま放置されるのではなく、型付きの待機経路とともに in_review 状態になること。