loop-engineering

ループエンジニアリング

1つの変更について、計画 → 承認 → 実行 → 検証 → 独立レビュー → 対応 → 完了の各段階を経て、受付から完了可能な状態まで進めます。このスキルでは、各段階の意味と、段階間で引き継がれる証拠を定義します。ツールの使用、公開、スケジュール設定、委任を許可するものではなく、永続的な状態をどこに保存するかも規定しません。

どの変更提供ゲートを適用するか、外部コードレビューの独立性、ブランチと提供に関するルール、保存形式は、プロジェクトポリシーで定めます。ポリシーに明記されていない場合は、このスキルの既定値を適用します。つまり、編集前に人間が計画を承認すること、検証を必須とすること、独立レビューを必須とすること、復旧時は追記のみとすること、収束した後にのみ完了状態とすることです。

このスキルは、実行時に注入される指示とプロジェクトの必須要件のどちらを優先するかを定めません。ホストの導入ガイダンスでは、現在のホストで実際に適用される指示の優先順位に従う方法を説明しますが、その優先順位を再定義することはできません。各指示の実際の出所と優先度に基づいて競合を解決し、ツール使用条件を遵守したうえで、その範囲内では満たせないプロジェクトのゲートがあれば報告してください。

ループドライバーとは、承認済みの計画と必須の証拠に照らして変更を進める責任を現在負う担当者です。ドライバーが作業の一部を委任した場合、その委任先に対する親となります。別の担当者が所有する変更を開始しても、開始者がその変更のドライバーになるわけではありません。結果を受け取っただけでは、ループ、人間の意思決定権限、または操作権限は移転しません。

何も変更しない読み取り専用の作業には、変更ゲートは適用されません。実装の委任、段階成果物のレビュー、実装前チェックには、それぞれ独立した、現時点で有効な適格性が必要です。ある経路が以前に利用可能だったか、利用できなかったかによって、他の経路が決まることはありません。適用されるホストガイダンスでは、担当者と読み取り経路を定めます。このスキルでは、チェックポイントの証拠と進行を維持します。ドライバーが実行を担っても、ドライバー自身が独立レビュー担当者になることはありません。

この文書における「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、「OPTIONAL」は、RFC 2119で説明されている意味に従って解釈してください。

フェーズの進行

すべての変更は、前のフェーズから引き継いだ主張ではなく、現時点の証拠に基づいて進めます。

以下の4つのルールは、変更作業全体を通じて適用され、参照先を選ぶ前に確認する必要があります。これは変更作業か、誰が責任を担うか、チェックポイントの適格性が現時点で有効か、どの承認が認可となるか、です。これらは無条件適用範囲の例外に基づき、ここに記載しています。チェックポイント固有の証拠と手順は、それぞれの参照先に記載しています。

その他のすべてのフェーズルールは、計画のゲートと、リビジョン変更後に発生する古さの扱いも含め、それを規定する参照先に記載しています。書き込み、承認、改訂、比較に関する両方の規定については、plan-document.md を参照してください。

ガイドライン：

• MUST 読み取り専用の作業は、プロジェクトの変更を生じさせない限り、変更ゲートの対象外として扱う。
• MUST ループの推進役と貢献に関する責任を、実行の系譜ではなく、割り当てられた作業と確立された引き継ぎに基づいて特定する。
• MUST 実装の委任、フェーズ成果物のレビュー、実装前の確認について、それぞれのチェックポイントで、現時点のホスト条件に基づいて個別に適格性を判断する。直接実装することや、以前の役割が利用可能または利用不可能だったことを理由に、別のチェックポイントを省略したり、その適格性を満たしたりすることはできず、いずれのゲートも緩和しない。
• MUST 計画の承認、操作の認可、実行能力、許可されたツールの使用を区別する。本来の範囲内で有効な認可を引き継ぐこと。これには、人間がプロジェクトのガイダンスに取り入れた、検証済みの恒常的な許可も含まれ、これは実際の認可です。ただし、ツールが利用可能であること、許可が記載されていないプロジェクトポリシー、計画の承認、以前の操作を根拠に、許可の存在や、より広い許可を推測してはなりません。

以下については、phase-progression.md を参照してください。

• インテークとデフォルトゲートのもとで、新しい変更を追跡対象に結び付け、最初の編集またはブランチ操作を行うこと
• プロジェクトポリシーと独立レビューのもとで、変更された範囲の検証を実行し、デリバリー対象を作成または対応すること
• 検証に失敗した場合や、レビュー／CI が保留中の場合に、利用可能なアクションを選択し、具体的な依存関係と範囲を限定した機械的な待機を特定すること
• 現時点の機械的な結果を受けて、ソースを編集せずに準備が整った場合も含め、残りのゲートを再評価すること

以下については、plan-document.md を参照してください。

• 計画の作成、承認、改訂、比較
• 計画の標準セクションと承認対象
• 計画中に、必要なリポジトリ外での検証とその証拠の保存先について合意すること
• リビジョンの識別、改訂の承認、ビジュアル上の選択

以下については、reviewing-phase-deliverables.md を参照してください。

• 計画前の調査結果、承認前の計画、人間による選択または依存する作業の前に行う、低忠実度と高忠実度の各ビジュアル案のラウンド
• 現在の成果物と必要な資料の識別、変更のないレビューの再利用、既存の引き継ぎ状態を利用した消費済みラウンドの復旧
• コンダクトが責任を担う完了境界、インストール済みの古いコンダクトスキルにもそのレビュー慣行がない場合の代替策、実装前の確認および外部コードレビューとの切り分け

実行の引き継ぎ

以下については、implementation-package.mdを参照してください。

• 5つの自然言語対応コントラクトを通じて、作業を割り当てる、または実行結果やレビュー結果を受け入れる方法
• リポジトリの識別情報、成果物の忠実性、認可、結果の状態

以下については、subagent-delegation.mdを参照してください。

• 実装の割り当て、または選択したレビューのチェックポイントを適格とする方法（直接実行や、以前は利用できなかった経路を含む）
• 割り当て固有の根拠、再適格化に関連する変更、条件付きのホストガイダンスのデフォルト
• 成果物アクセスの事前確認と、変更全体への責任を移転せずに返却された証拠を統合する方法

以下については、writer-ownership-and-recovery.mdを参照してください。

• 同時並行の書き込みの調整、効果の再試行、中断した実行からの復旧（計画変更による中断や、結果不明の状態からの復旧を含む）
• 追記専用の履歴と完了証拠の比較

レビューと準備状況

以下については、finding-response.mdを参照してください。

• フィードバックの判断と原因に基づく修正の選択を通じて、助言的な事前レビューまたは独立レビューの指摘に対する作成者側の対応を選ぶ方法
• 行動や開発の能力がない場合に限定された対応方法
• 指摘への対応理由と、指摘の処置および新たなレビューへの入力との区別

以下については、pre-flight-review.mdを参照してください。

• 助言的な事前レビューの実行または復旧
• 助言的なレビューの指摘、終端状態、延期された人間への引き継ぎ、却下の権限、永続的な保留
• 初回の実装に続く、自律的なレビューと修正の3ラウンド

以下については、independent-review.mdを参照してください。

• 独立レビューの依頼、指摘への対応、評価、または準備完了への移行の公開
• 必須の外部独立性、新たなレビューラウンド、4ラウンドの対応上限
• プロジェクトで採用された提示および報告の範囲において、識別可能な形で公開された完了（個別の確認項目について肯定的な主張を行わないもの）。明示的な制限事項やコントリビューターの証拠とは区別されます
• レビュアーの履歴を書き換えない、外部による修正済み、人間による却下、未対応の各処置
• 会話の終了とは異なる収束（実質的なメタデータの変更を含む）
• 競合への対処、影響を受ける検証、タイムアウト、準備完了の条件

再開と報告

以下については、resuming-and-handoff.md を参照してください。

• 実際の状態を再構築して保留中のフェーズを1つ再開することで、実行を再開または引き継ぐ
• 古い結果、一部のみの結果、不明な結果に対処する

以下については、run-state-and-reporting.md を参照してください。

• 保存形式に依存しない、復旧可能な意味的実行状態を永続化する。これには、独立したチェックポイントの適格性、実際のレビュー範囲、およびそれらの根拠が含まれます
• 復旧した、または継続中の操作許可を、フェーズやセッションをまたいで、提案された効果に照らして評価する
• 根拠に裏付けられたマージ準備完了の概要を作成し、起動された役割のモデルと作業量を verified、declared、または unknown として報告する

ここからは、さらに読むべき内容ではなく、ルールそのものです。このループが行うすべてのターンを拘束し、より限定的な状況だけに適用されるものではありません。そのため、Phase Progression が適用範囲を無条件とする例外を設けているのと同じ扱いでここに記載しており、エージェントがまだ開いていないかもしれない参照先の後ろには置いていません。ある観察と、それによって正当化されるアクションは、同じターンに属します。テキストを出力してツールを呼び出さないターンは、作業を続けている間に行われたターンとは言えません。実行は停止していないため、先に報告し、次にアクションを行うのは、すでに作業に充てられていたターンで実行する代わりに、1ターン分のコストを2ターンに分割するだけです。

ガイドライン：

• 実行を続けている間に次のステップがある観察については、必ず同じターン内で対応してください。まだ続きがあるのに、報告だけを行い、ツールを呼び出さないターンを終えてはいけません。
• このルールの違反ではなく例外として扱うケースは、正確に3つに限ってください。必須の人間によるゲートでターンを終える場合（機械イベントをエスカレーションしてゲートに進む場合も含む）、待機上限に達して停止する前に状態を記録する場合、そして実行を終了する完了報告です。
• 必須の確認、独立したレビュー、または委任された実行者の実行など、非同期の機械イベントがまだ保留中で、独立して実行できる次のアクションがない場合に投稿する進捗メモには、このルールを適用しないでください。イベントが保留中であることだけでは、その条件を満たしません。
• このルールを、ツール呼び出しと同時に推論することを禁じるものとして解釈しないでください。禁じているのは、テキストだけのターンと、それに続くアクションを行うターンに分けることであり、ツールも呼び出す同じターンに文章を書くことではありません。