long-task-continuation

長期タスクの継続

概要

長期にわたる作業を、チェックポイントで管理し、中断後に再開でき、ドリフトを把握し、エビデンスを条件として進めます。 このプロトコルは、計画の実行、サブエージェントの派遣、テストの実行を行わず、完了を判断する権限も与えません。

権限の境界

Method Pack が担うのは継続の規律のみです。親計画、ホストの再試行／ウォッチドッグ動作、権威ある GateDecision、エビデンスの十分性、要件の受け入れ、完了の判断は担いません。

使用するタイミング

作業に意味のあるフェーズがある場合、圧縮／再開や引き継ぎの可能性がある場合、サブエージェントを使う場合、または明示的に継続性とドリフト制御が必要な場合に、このスキルを使用します。アーキテクチャ、契約、共有ワークフロー、検証ゲートの変更にも有効です。短い回答や単一コマンドの確認に無理に適用しないでください。

状態を保持する手段は、必ず1つだけ選びます。

• この継続ワークフローでは、中規模／大規模の作業、または複雑さを問わず実際にセッションをまたぐ作業、引き継ぎが必要な作業、再開可能な状態が必要な作業には、永続的な work/ レコードを使用します。
• それ以外の場合は、インラインのチェックポイントを1つだけ使用します。

低複雑度の作業では、それだけを理由に複数ステップ、todo 主導、圧縮の可能性、サブエージェントの使用が永続的なレコードを必要とすることはありません。両方の手段を作成したり、スライスごとにレコードを作成したりしないでください。

必須の成果物

永続的なタスクには、docs/aegis/work/YYYY-MM-DD-<slug>/ に1つのプロセストレイルを置きます。そこには、論理的な意図／ベースライン状態、最新の todo／チェックポイント／再開状態、最終的なエビデンス／ドリフト状態、および必要に応じて完了時の振り返りを保持します。これらは TaskIntentDraft、BaselineReadSetHint、BaselineUsageDraft、ImpactStatementDraft、TodoCheckpointDraft、ResumeStateHint、DriftCheckDraft、EvidenceBundleDraft の各ビューであり、権威あるランタイムレコードでも、別個の計画の所有者でもありません。

durable-work-guidance.md のうち、ライフサイクルに合致するセクションのみを読みます。

• 新しい永続的な作業レコードを作成する場合は、## Required Artifact Layout と ## Create A Durable Work Record。
• 既存のヘルパー対応レコードでサイドカーの更新が必要な場合は、## Update A Slice。
• 再試行／試行の記録には、## Retry Convergence Detail。
• 中断、引き継ぎ、完了バンドルの準備には、## Pause, Handoff, And Completion Bundle。
• 自然な文章によるチェックポイントが曖昧な場合に限り、## Expanded State Fields。

成果物の構成と <aegis-workspace-helper> コマンドの詳細はリファレンスが定めます。このファイルが定めるのは、状態保持手段の選択、再開順序、ドリフトの判断、停止条件です。

中規模／大規模の作業、引き継ぎが発生しやすい作業、長期にわたる作業、サブエージェント主導の作業、アーキテクチャ、契約、互換性、廃止に影響する作業では、Execution Readiness View を意図またはアクティブなチェックポイントに保持できます。これは既存の意図、スコープ、ベースライン、担当者、テスト、レビュー、ドリフトの制約を表示するものであり、新たな JSON 成果物でも、完了判断の権限でもありません。

計画なしのスライスレーン：

• 既存の親計画／仕様が範囲の限定されたタスクを担っている場合は、それと現在のチェックポイントを再利用します。親がなく、新しい永続化も不明瞭な検証境界も必要としない、直接依頼された範囲限定のタスクには、インラインのチェックポイントを使用します。
• 簡潔な Slice Card を1つ記述します。Goal、Parent plan/spec（または none — direct bounded request）、Files、Boundary、Verification、Stop を含めます。
• スライスのゴールが完了させるのは、そのスライスのみです。最終的な完了判断は verification-before-completion を通じて、親計画または直接依頼されたタスクに戻します。
• マイクロスライスに親を持たせることだけを目的に計画／仕様を作成したり、スライスごとに計画／仕様や作業レコードを作成したりしないでください。
• 新しい担当者、契約、スキーマ、パブリック API、アーキテクチャ、移行、永続化、セキュリティ／権限、配布／リリースの対象範囲、不明瞭な検証境界、または親のスコープや受け入れ条件との不一致が見つかった場合は、上位の対応にエスカレーションします。

永続的なアーキテクチャ上の決定が対象に含まれる場合、これらの作業レコードを ADR Auto Backfill の優先ソースとして使用します。決定を示すシグナル、ソース参照、代替案、互換性、廃止、ドリフト、ベースライン同期に関する問いを保持してください。

開始プロトコル

実行前に、次のことを行います。

1. 求められている成果、対象範囲、対象外事項、リスク、親プラン／目標、成功を示す 証拠、および停止状態（done | blocked | needs-verification | scope-exceeded）を記録します。
2. 必要なベースライン参照を特定し、確認済み、引用済み、不足している参照を記録します。 権威ある情報が不足している場合は、needs-baseline-readback で一時停止します。
3. インライン状態または永続状態のどちらかを一度選択し、todo マップ、現在のスライス、 完了したスライス／証拠、ブロッカー、次のステップ、現在のブランチ／HEAD を記録します。
4. Execution Readiness View が存在する場合は、その意図のロック、スコープ境界、 ベースラインのロック、互換性／廃止の境界、テスト、レビュー、証拠、巻き戻しルールを 維持します。
5. 新しいヘルパー対応レコードには、実装前に durable-work-guidance.md を使用して作成し、 構造を確認します。

リトライ収束プロトコル

検証に失敗しても、新しいスライスではなく、現在のスライスでの再試行として扱います。 失敗した試行のテレメトリは、最終的な証拠や通常のコミットに含めません。 終端状態となるのは、evidence-finalized、blocked、abandoned のみです。 リトライ状態が process-artifact-pressure に達したら、自動リトライを停止し、 systematic-debugging または verification-before-completion に回します。 永続参照を読み込むのは、試行／証拠のコマンドまたはサイドカーのルールが必要な場合に 限ります。

スライスごとのプロトコル

各スライスの前に、現在の目標／todo、予定する編集、明示的に編集しない対象、検証、 および準備状況との整合性を示します。範囲を限定した親プラン内のスライス、または 親プランのないスライスでは、新しいプラン／仕様を作成せず、簡潔な Slice Card を使用します。

各スライスの後に、完了した todo、証拠参照、新たに使用したベースライン参照、 ブロッカー、次のステップ、ドリフトに関する判断を更新します。ヘルパー対応の 作業レコードが有効な場合は、durable-work-guidance.md を読み、同じレコードを更新します。 記録管理のために別の作業ストリームを作成してはなりません。

パッチ形状／波及範囲のトリアージ、H クラスの指摘、または範囲を限定した互換性緩和策が 発生した場合、ローカルでテストが通っても、その方針が確定したことにはなりません。 PatchShape、CanonicalOwner、UpwardDrillSignal、最新の結果、および範囲を限定した 証拠参照を 1 つ保持します。生のログや差分全体をコピーしてはなりません。新たな証拠が ない場合、状態は needs-verification または partial です。修正や最適化では、原因に 関わる範囲、証拠参照、解決策を変え得る未解決の影響要因、および検証範囲を同じ チェックポイントに保持します。情報の圧縮によって、確認された原因を根本原因の全容と して扱ったり、反証を消したりしてはなりません。保持した変更を再開する前に、これらの 不明点を再確認します。並行する原因記録を追加してはなりません。

再開プロトコル

次の順序で再開します。

1. 元の意図、親の計画／目標、最新のチェックポイント、再開ヒントを確認します。 現在のユーザー指示（継続、修正、一時停止、置き換え）と照合します。未完了の成果物を維持し、有効な修正をドリフトとして扱う前に、承認されたスコープを更新します。内部マイルストーンは、ユーザーに届ける成果物の代わりにはなりません。
2. 必須のベースライン参照と、関連する有効な CONTEXT.md の記述を再確認します。
3. Execution Readiness View がある場合は読みます。
4. チェックポイントのブランチ／HEAD、完了済みコミット、証拠の参照先、主張を現在のワークツリーと照合します。 引き継いだ完了の主張は、ワークツリーで確認できるまで未検証として扱います。チェックポイント内の矛盾を修正し、最終報告で開示します。また、古くなった主張を現在のものとして再掲しません。その主張の対象、スコープ、再開時点の状態を保持し、その後の修復や、検証できない過去の実行と区別します。関連する主張は、正確な修正を一つにまとめて対応できます。記録にはその修正を反映し、別の箇所で否定したり、別のスコープに割り当てたりしてはいけません。レビュー担当者の分類には異議を唱えられます。証拠を確認しても重大な見解の相違が解消されない場合は、同意を強制せず needs-verification を維持します。証拠によって解決できる場合は、裏付けのある結論を維持し、通常どおり検証します。
5. 有効な作業範囲を、意図の固定条件、スコープ境界、ベースラインの固定条件、互換性／廃止の境界、テスト、レビュー、非目標と照合します。
6. ドリフト判定を再実施し、次に許可される最小のアクションを明示します。

計画、チェックポイント、ベースライン、コンテキスト、準備状況ビュー、ワークツリーの間に不一致があれば、実行を一時停止します。意味上の競合は establishing-project-context に振り分けます。計画外の修復では、保持された不変条件、責任範囲、パッチ形状、因果関係の構造を再確認してから、比較を systematic-debugging に振り分けます。新しいキャリア名だけでは、新しい方向性の証明にはなりません。記憶だけを頼りに再開してはいけません。

ドリフトチェック

元の意図と停止条件、親スコープ／受け入れ条件、互換性、新たな責任者／フォールバック／アダプター／分岐、廃止、証拠の鮮度、準備状況のロックを確認します。許可される判定は continue、pause-for-user、needs-baseline-readback、needs-verification、blocked です。

gate-passed、completion-granted、authoritatively-safe は決して出力しません。

完了候補プロトコル

完了を主張する前に、次を実施します。

1. aegis:verification-before-completion を使用します。
2. すべての todo にステータスがあること、ブロッカーが解決済みまたは外部要因として明示されていること、証拠が受け入れ条件を満たしていること、ドリフトにブロッキング状態がないことを確認します。
3. 永続的な記録がある場合は、完了バンドルとワークスペースの構造チェックのために durable-work-guidance.md を読み込みます。
4. 永続的なアーキテクチャ作業では、作業記録、証明バンドル、ADR シグナルを検証に渡し、ADR Backfill Check を実施します。

生成されたパックは、将来のランタイムで使用する入力に限られます。Method Pack の出力は、検証済みの証拠および助言的な判断であり、権威ある完了判定ではありません。

最小報告形式

自然な形で報告し、空の構造は省略します。次の意味上の項目を明示します。 Aegis Visibility、現在の todo／進行中／完了済み／次の作業、ベースラインの使用判断、存在する場合は準備状況、最新の証拠、再開した記録が状態を過大に示していた場合の引き継いだ主張の修正、該当する場合は再試行／収束の状態、ドリフト判定、リスク／不明点、次に実施する最小の安全なアクション。