write-tasks

タスクの作成

docs/specs/<slug>/_prd.md（および存在する場合は_techspec.md）を、実行可能なタスクグラフに変換します。各タスクにつきtask_NN.mdを1つ作成し、implement-task、implement-spec、今後のデーモンがスケジュールに使用するマニフェスト_tasks.mdも作成します。成果物が契約となります。新しいエージェントセッションは、仕様フォルダー以外のコンテキストがなくても、1つのタスクファイルを引き継いで実装できる必要があります。

ライトティアでの計画

complexity: lowで、QAではなく、Governed Pathを宣言していないタスクはライトティアで実行されます。作成者は、計画Pull Requestがマージされる前に、アドバイザリー目的でroundfix spec judge <slug> --stage tasksを実行し、ティアの提案を確認できます。この提案によってディスパッチが制御されることはありません。

前提条件

$ARGUMENTSで仕様を指定します。_prd.mdが存在している必要があります。アーキテクチャ上の実質的な範囲を含む機能で_techspec.mdがない場合は、まずwrite-techspecを実行してから分解してください。不足している成果物の作成が解決策であり、許可を得るために作業を中断する理由にはなりません。自律作業では、承認済みキューにあるすべての仕様について、自律作業の指示により作成チェーン全体が許可されるため、確認は不要です（docs/agents/autonomous-work.mdを参照）。テック仕様なしで分解するよう明示的に指示された場合に限り、受け入れの確認を求めてください。その場合は、分解の前にコードベースをより深く調査して補ってください。

プロジェクト制約の事前確認

タスクの内訳を作成または承認する前に、この事前確認を実行します。

1. Spec を分類します。解決済みのアーカイブディレクトリ（組み込みの docs/specs ルートでは docs/history/specs/、外部またはデフォルト以外のルートでは <spec-root>/_archived/）にある Spec、またはこの契約の適用前に完了したことが確認された Spec は、完了済みまたはアーカイブ済みのレガシー Spec です。すべてのレガシー成果物をバイト単位で変更せずに維持します。補完、再フォーマット、再生成、その他の書き換えを行ってはいけません。
2. 有効で、アーカイブされておらず、かつ完了済みでもないすべての Spec について、PRD と存在するすべての TechSpec に、完全な Project Constraints セクションが含まれていることを必須とします。各セクションには、該当する場合、または理由を添えて該当しない場合に、Identifier strategy、Authentication and HTTP、Active ADR obligations、Tooling authority を記載し、各項目には適用される docs/agents/ のソースパスを明記する必要があります。
3. どちらかの有効な成果物が存在しない、または不完全な場合は、_tasks.md や Task ファイルの作成・更新を拒否します。不足している項目、理由、ソースパスをすべて列挙し、Spec を担当する作成スキルに差し戻します。
4. 提案されたスライスに、リポジトリのツーリング設定、スクリプト、無視ファイル、プラグイン宣言、バージョン固定の作成、編集、名前変更、移動、削除が含まれていないか確認します。このような作業が許可されるのは、PRD と存在する TechSpec に、メンテナーの承認および対象となるリポジトリ相対パスが正確かつ限定的に記録されている場合のみです。一般的な実装依頼、セットアップの承認、Task の割り当ては承認にあたりません。承認と対象パスの両方がない場合、分解を拒否します。
5. ツーリングを含む各スライスについて、<spec-root>/<slug>/_authorization.md にある適用対象の記録を確認します。記録が存在しない場合、proposed の記録である場合、または許可日が記載されていない場合、何も許可されません。有効な許可が得られるまで分解を拒否します。新規または範囲を拡大する許可は、それを利用する squash デリバリーより前に、対象の先行関係に含まれている必要があります。そのため、許可や変更を、それが承認する変更にまとめることはできません。
6. 許可されたツーリング Task のスコープと受け入れ基準に、対象となる限定的なファイル一覧を記載します。Task が変更できるのは、そのパスと自身の Task ファイルのみです。異なる範囲が必要な作業は分割します。
7. 記録の operations リストには、Spec が使用するすべてのデリバリー操作が許可されている必要があります。roundfix deliver start は、記録に implement、commit、push、pull_request、merge のいずれかがない場合、処理を拒否します。Governed Path のない Spec では、paths: [] を記録します。

依存関係の管理は引き続き _tasks.md のみが担当し、Task のステータスの管理は各 Task ファイルのみが担当します。この事前確認によって、いずれの責任も移管されることはありません。

別のオペレーティングシステム向けのコードは、そのシステム向けにテスト以外のコードをビルドして検証します。たとえば GOOS=windows go build -buildvcs=false ./<package> のようにします。ホスト向けに記述されたテストもコンパイルする go vet は使用しません。

所有権のルール（何がどこにあり、その理由）

• 依存関係は _tasks.md のグラフにのみ記述します。 タスクファイルには記述しないでください。エッジを二重に記述すると、グラフの不整合につながります。
• ステータスは各タスクファイルのフロントマターにのみ記述します。 _tasks.md が管理するのはトポロジーであり、進捗ではありません。スケジューラーは状態を把握するためにタスクファイルを再読み込みします。
• すべてのタスクファイルで Task Type の指定が必須です。 backend、frontend、data、infra、docs、test、chore、qa のいずれかを正確に1つ指定してください。qa は、マニフェストの qa: フィールドで指定された、作成者が定義する唯一の最終ゲート専用です。Implement Command はこの値をルーティングに使用し、値がない場合や不明な場合は拒否します。プレースホルダーのままにしたり、後からタイプを推測したりしないでください。
• 内容は参照し、重複させないでください。 タスクファイルでは、PRD／TechSpec のセクションを名前で参照します。仕様を再記述したタスクは、仕様が改訂された時点で内容が古くなります。採用したソースは、採用後のパスで、所有する Spec 内からその Task ファイルを基準とする相対パスでリンクしてください。採用前の出所パスにはリンクしないでください。二次的な Spec は一次所有者のコピーにリンクし、何も採用しません。 所有者のアーカイブでは Archive Relink が行われ、そのコピーを docs/references/ に移動し、二次 Spec のリンクを書き換えます。これにより、ソースの所有者は1つのままとなり、二次 Spec にコピーは不要です（ADR-0260、ADR-0083）。
• Context エントリーはラベル付きパスです。 Task が標準の Spec バンドル以外に特定の指示またはインターフェースのパスを必要とする場合にのみ、## Context を追加します。箇条書きは - instruction: <path>、- interface: <path>、- creates: <path>、または - deletes: <path> の形式にしてください。パスはクリーンなリポジトリ相対パスで、一意でなければなりません。 Task が宣言できるエントリーは、一意なものを最大50件までです。Daemon は、変更済みファイルで 200 パス分の Spec Context Bundle を埋める前に、これらのパスを確保します。
• 宣言する編集対象と管理対象パスは明示します。 Task が編集するすべてのパスは interface: または creates: の下に宣言し、削除するすべてのパスは instruction: ではなく deletes: の下に宣言します。削除対象は未解決参照のチェックではスキップされ、スコープ、Governed Path、Wave の衝突監査ではカウントされます。宣言した削除対象がまだ存在する場合、Daemon は Verification の前に精算を拒否し、deletes: <path> still exists と表示します。instruction: のパスは読み取り専用で、2つの Task 間で衝突を起こしません。コマンドを変更する各 Task は、変更するコマンドファイルを1つ宣言します。対象は、そのミラーとともに .agents/skills/roundfix/references/<command>.md および docs/user-guide/commands/<command>.md であり、エントリーファイル自体を変更する場合を除き、スキルの SKILL.md や commands.md ではありません。同じファイルを宣言する2つの Task は同じ Wave に含められないため、異なるコマンドを変更する Task は同時に実行できますが、同じコマンドを変更する Task 間にはエッジが必要です。 宣言された Governed Path または Verification で読み取られる Governed Path は、Spec の _authorization.md の paths: と、両方の bounded files: 行に記載されている必要があります。記載されていない場合、作成は SC-TOOLING-UNDECLARED で拒否されます。CLI サーフェスを指定する Task は、その Task 自体または依存先の Task を通じて、対応するスキルまたはガイドを指定する必要があります。指定しない場合は SC-CLI-UNDOCUMENTED として報告されます。

Daemon は、Task が変更したものの宣言されていないパスを、コミット時に ## Recorded paths の下に記録します。QA スコープ監査では、その記録されたパスを宣言済みとしてカウントします。記録によって変更が開示されますが、パスは確保されません。予測可能なすべてのパスを宣言するというルールは変わりません。

複数の Task がそれぞれ変更する可能性のあるテストヘルパー、フェイク、フィクスチャ、またはゴールデンは、予測可能なパスです。変更する可能性のあるすべての Task で、これらを interface: の下に宣言してください。これにより、Spec の作成中に roundfix spec check --strict が SC-WAVE-COLLISION を報告し、その項目で指定された needs エッジによって該当 Task が順番に実行されます。記録によってパスは確保されませんが、Task の精算コミットは衝突の証拠になります。同じ Wave に属する2つの Task が同じ未宣言ファイルをそれぞれ変更した場合、両方の Task の実行後、QA ゲートの前提条件によって Run は SC-WAVE-COLLISION で拒否されます。

変更された振る舞いの表面に対するスキルタスク

リポジトリにスキルカバレッジマップ docs/references/skill-coverage.json が存在する場合は、これを読みます。ソースが interface:、creates:、または deletes: の下で宣言されている非QAタスクが対象とする各カバー対象の振る舞いの表面について、それをカバーするスキルファイルのいずれかを interface: または creates: の下で宣言する非QAスキルタスクを含めます。SC-SKILLS-UNTASKED は、そのようなタスクがない表面を報告します。

変更によってスキルのテキストが不要な場合は、PRDの任意セクション ## Skills に - unchanged: <surface id> — <reason> を記録し、カバレッジレビューを記録するために、マップを interface: または creates: の下で宣言する非QAタスクを含めます。このエントリだけでは、その表面への対応として不十分です。SC-SKILLS-MALFORMED は、形式が異なるエントリ、不明な表面、または空白の理由を報告します。両ルールはマップを追加したコミットから適用されます。マップがないリポジトリでは適用されません。

docs/user-guide/ 配下のMarkdownページを interface:、creates:、または deletes: の下で宣言する非QAタスクは、docs/references/behavior-surfaces.json も interface: または creates: の下で宣言し、要件で -record-skill-coverage ステップを指定する必要があります。別のタスクで代替することはできません。ガイドタスク自体の完了確認で、そのフィンガープリントを検証します。Specの _authorization.md の制限事項で、この記録を禁止してはなりません。この記録があるリポジトリでは、SC-SURFACE-RECORD-UNTASKED はタスク段階で、期間を指定せずに、いずれかの欠落を報告します。

分解ルール

別のオペレーティングシステム向けのコードは、そのシステム向けにテスト以外のコードをビルドして検証します。たとえば GOOS=windows go build -buildvcs=false ./<package> のようにします。ホスト向けに書かれたテストもコンパイルする go vet は決して使いません。

• 垂直スライス。 各タスクは、対象とするすべてのレイヤーを通る、狭くても完全な経路を提供します。それ単体でデモまたは検証できるものにします。トレーサーバレットのように、レイヤー単位ではありません（「すべてのスキーマ」は誤ったタスクで、「期限切れのインポートを再試行し、その状態を表示する」は適切なタスクです）。

• まずリファクタリング。 スライスに下準備が必要な場合は、それを先行する独立したタスクにします。変更を容易にしてから、容易になった変更を実施します。

• 作成中に外部インターフェースを特性評価する。 Specがアダプター、コントラクト、データベースなどの外部インターフェースをまたぐ場合、実際の境界が何をするかを記録する特性評価タスクを作成します。偽物の動作ではなく、実際の境界の動作を記録します。これにより、裏付けのない前提をQAゲートではなく、Specの作成中に検出できます。

  ファイル内で前に置くだけでなく、needs に記載します。 前提が特性評価に依存するすべてのタスクは、_tasks.md の needs エントリでそのタスクを指定します。実行ウェーブは needs のみから構成されます。そのため、マニフェスト内で後に記載されているだけのタスクは、依存先の特性評価タスクと同じウェーブで実行され、まだ特性評価されていない境界を参照する可能性があります。ファイル内の順序は依存関係ではありません。

  特性評価タスクは実際の境界に触れるため、対象を明示的に限定します。 タスクのファイルには、到達する対象を名前で記載します。読み取りのみを行うか、タスク自体が作成して削除する隔離インスタンスに対して実行します。既定では、共有状態や本番状態を対象に特性評価を行いません。その対象に限定された認証情報のみを使用し、それ以上の権限を持つ認証情報は使用しません。キャンセルを尊重し、失敗した場合も作成したものを確実にクリーンアップします。書き込みが必要な特性評価では、他の不可逆な操作と同様に、その書き込みをタスクで承認する必要があります。境界の動作を記録することは、その境界を変更する権限にはなりません。 その検証が確認するのは記録であり、境界ではありません。 Daemon は Task の ## Verification で宣言されたコマンドをシェル経由でそのまま実行します。Agent のターンが始まる前、変更のないツリーに対して一度実行し、さらに完了時にも実行します。その実行経路では、上記の境界は一切参照されません。境界が制約するのは Agent であり、Daemon は Agent ではないからです。実際の対象にアクセスする検証は、その対象に境界のない状態で、作業開始前も含めて二度アクセスすることになります。Task が記録した特性、つまり形状、存在の有無、後続の Task が読み取る内容を検証し、境界へのアクセスは Agent のターン内に残してください。そこでは、Task が宣言した対象、分離、認証情報、書き込み権限が適用されます。これは、これらのコマンドがすでに従うべき隔離性のルールです。破ってしまいたくなる誘惑が最も強い場所に、あえて記しています。稼働中の外部対象は周囲の状態であり、それに依存するコマンドは隔離されていません。

• 新しいセッション1回分の規模にする。 新しいコンテキストで、エージェントが1回の作業時間で完了できる Task にします。サブタスクまたはファイルが約7個を超える場合は、分割します。

• テストは組み込み、分離しない。 各 Task の受け入れ基準には、その Task 自身のテストを含めます。最後に「テストを書く」Task がある場合、それ以前の Task は完了していなかったということです。

• 単独で実装できるようにする。 needs に記載された項目が完了したら、その Task はほかに未完了の作業を必要としないようにします。これにより、後で複数の worktree にまたがって並列実行できます。

• 検証は隔離可能で、移植性があり、効果を証明でき、Daemon が実行するものでなければなりません。 各 Task の ## Verification コマンドは、リポジトリの状態、宣言された設定、Task が管理するセットアップだけを使用して、新しい worktree で実行できなければなりません。Task が明示的にその状態を作成する場合を除き、未追跡のローカルファイル、以前の Run、対話型プロンプト、プッシュ済みブランチ、マシン固有の状態に依存してはいけません。移植性のあるシェル形式を使ってください。Task のゲートでは rg より grep を優先し、プラットフォームによって結果が変わる wc を使ったパイプラインのアサーションは避け、ビルドが必要な場合は go build -buildvcs=false ./... などのリポジトリのビルドフラグを使います。Task は実行可能なチェックによって自身の効果を証明しなければなりません。Run レベルのゲートは、それ以外に退行がないことを証明するものではありません。回帰テストを目的として、各 Task にパッケージ全体のスイートを実行するコマンドを追加してはいけません。作業が何も行われていない場合に失敗できることが、すべての検証コマンドに求められます。存在しないテストを指定したり、テストケースを1件も選択しなかったりしても終了コードが0になるコマンドは、何も検証していません。検証コマンドは、終了コードが0の場合にのみ成功します。検証コマンドにはバッククォートを含めてはいけません。インラインコードの範囲は最初のバッククォートで終了してコマンドが途切れるため、代わりに . のような正規表現の文字クラスで照合します。結果が空であること、または文字列が存在しないことが成功条件となるアサーションでは、そうした条件で終了コードが0になる形式を使います。たとえば matches="$(find path -name '*.tmp' -print)" || exit 1; test -z "$matches"、test -d path && ! grep -rq 'forbidden' path、または失敗時に一致した項目を出力する必要がある場合は find path -name '*.tmp' -print > /tmp/matches.txt 2>&1 || { cat /tmp/matches.txt; exit 1; }; test ! -s /tmp/matches.txt || { cat /tmp/matches.txt; exit 1; } を使います。リポジトリ全体に対するゲートと作業ツリーがクリーンであることの確認だけで構成された、作業に依存しない形式は避けてください。これらの確認は、Task の作業が何も行われていない場合に最も簡単に成功してしまいます。Daemon は Agent のターン後にこれらのコマンドを実行し、失敗した場合に限り、Verification Feedback プロンプトを1回送信することがあります。Agent に権威あるゲート自体を実行するよう指示してはいけません。 共有コントラクトを利用する一連のシステムでは、Task による変更は例外です。詳しくは「共有コントラクトの利用者」を参照してください。

• ゲート付きグラフでは、リポジトリの Verification が成功した状態になります。 作成した QA ゲートを含むグラフ内のすべての Task は、各 Task の処理が終了するたびに Daemon がそのコマンドを実行するため、リポジトリの Verification が成功した状態になります。verification.repository_at_settlement は、この処理終了時のチェックを行うかどうかをオペレーターが切り替える設定であり、作成時に選択するものではありません。

• Task の宣言は明示的に行います。 Verification コマンドが相互に独立しており、失敗後もすべてのコマンドを実行する必要がある場合、Task は verification: independent を宣言できます。シェルの内容からこれを推測してはなりません。リポジトリのゲートが失敗している場合、凍結された _authorization.md の precondition_repairs リストに名前がある Task だけを許可できます。このリストを Task または Agent が拡張することはできません。creates: docs/adr/NNNN-... の宣言は、その ADR 番号を確保します。重複するツリーまたは有効な Spec による確保は SC-ORDINAL-CLAIMED で拒否されます。

• 時間的な前提条件によって権限が付与されることはありません。 将来のリリース、外部観測、生成される番号、その他の時間的な前提条件は、証拠の所有者を明記した名前付きの前提条件として表します。これによってリリース権限が新たに発生したり、将来見込まれる事実が完了済みの Task 作業に変わったりすることはありません。

• 受け入れ基準とテストの接点でコントラクトを明らかにします。 意味のある入力や失敗の境界を越えて何が真であり続けるかを示す、プロパティ形式の受け入れ基準を記述します。回帰を検出できる最も狭いテストの接点を特定し、必要に応じて公開ユースケースや永続化の動作も含めます。同じ不具合で失敗しない並行テストを追加するのではなく、影響を受ける既存のコントラクトを更新します。新たに必要なテストクラスを宣言した場合は、リポジトリのゲートが実際にそのテストクラスを実行することを確認します。

• Spec のコミット範囲を絞ります。 Task のコミットには、受け入れられた範囲とそのテストまたはドキュメントのみを含めます。無関係な整理や前提作業をまとめて含めてはなりません。前提条件への修正と、その結果として必要になる修正は、グラフと証拠に従って別々の順序で行います。

• 要件同士を同時に満たせる必要があります。 宣言された MUST 条項と MUST NOT 条項が、同じ名前付き状態を要求すると同時に禁止する場合は、Task を拒否します。記述されたコントラクト自体を満たせない作業を Agent Session に渡してはなりません。

• ゲートのリハーサルでは、その証拠を宣言します。 タイトルにゲートのリハーサルまたは証明をうたう Task には、実施すべきすべてのケースについて - Case: <case>; Observation: <observation> の項目を1つずつ記載した ## Rehearsal Cases を含める必要があります。このセクションがない場合、またはいずれかの項目にケースか観測内容が欠けている場合は、Task を拒否します。

• 少なくとも1つの受け入れ基準行は、Spec 自身が作成していない証拠に基づきます。 グラフ内の名前付き受け入れ基準行のうち少なくとも1つは、Spec 自身の成果物以外に由来する証拠、つまり Spec が構築していないリポジトリ、Spec が設計していない測定、または公開された文献に基づき、その証拠の出所を記録する必要があります。リハーサルで確認できるのはコードが要件に合っていることです。要件が正しかったことを示せるのは、外部ソースのみです。Task の作成中にそのソースを入手できない場合は、人間とのやり取りを介さずに分解を進め、その行を理由とともにブロック済みとして記録します。ブロック済みの行は QA ゲートに引き継がれ、レポートに rows_blocked_environment の項目が追加され、PR の準備がブロックされます。

• ネットワークなしで QA ゲートが確認できるソースを指定します。計画変更とともに docs/references/ の下にコミットするドキュメント、または該当箇所を行内で引用する公開文献を使用します。オペレーターのマシン上にしかない成果物、別のリポジトリのマニフェスト、または Spec の権限設定で許可されていない検索結果を引用してはなりません。ネットワーク接続やオープン中の Pull Request を必要とする基準は、行を作成する際に「到達不能な受け入れ基準」の下に記載します。

• Spec をまたぐ前提条件を宣言します。 Task の検証または前提が、まだマージされていない別の Spec に依存する場合は、その Spec をマニフェストの requires フロントマターに記載し、TechSpec のビルド順序で依存関係を明示します。Delivery Queue は、各前提条件がマージされるまでその Spec を開始しません。

• コミットとプッシュを Task の基準に含めません。 Task のコミット、Run の統合、および設定されたプッシュは Daemon が担当します。Task の Requirements、Subtasks、Acceptance Criteria、Verification コマンドには、コミット、プッシュ、PR 作成、ブランチの公開に関する要件を決して含めないでください。

QA ゲートの判断を作成する

Spec ごとに、定められた順序に従います。作成したゲートを含むグラフを実装し、設定済みの PR 前レビューを実行し、ブランチ上でアーカイブし、リポジトリゲートに合格してから Pull Request を開き、最新ヘッドのチェックを確認してマージします。

ADR-0091 では、Pull Request を開く前に作成済みの QA ゲートを実施することが定められています。一方、ADR-0080 では、環境が原因でブロックされた行は同等のエビデンスがあれば合格とできます。Spec 0078 ではその手順が実証されました。18 行中 11 行がブロックされ、そのうち 9 行は未オープンの Pull Request が原因でした。これら 9 行すべてに、記録済みのペイロード、コマンドランナー、およびイベントストリームのエビデンスがありました。

QA Task 契約に基づいて作成されたすべての有効な Spec は、分解時に次の形式のどちらか一方だけを選ぶ必要があります。

• ゲートを含めます。 _tasks.md のフロントマターに qa: task_NN を追加し、type が qa の task_NN.md を 1 つ指定します。そのノードを終端ノードにし、needs の一覧に QA 以外のすべてのリーフノードを含めて、グラフのどの分岐も完了する前にゲートが実行されないようにします。
• ゲートを設けません。 _tasks.md のフロントマターに qa: declined と空でない qa_reason を追加します。ゲートを設けない場合、qa Task は出力しないでください。

契約適用後のグラフで、どちらの宣言もない、両方の形式が併記されている、名前のない qa Task がある、またはゲートが終端ノードでない場合は、不具合です。作成を拒否してください。宣言がない状態を有効とできるのは、レガシーグラフが契約導入前に作成されたと証明できる場合に限ります。そのグラフはバイト単位で変更せずに残してください。

グラフがどちらの形式であっても、終端ノードには用語集の確認も含めます。ゲートを含める場合は作成済みの qa Task に、含めない場合はトポロジカル順序で最後の Task に割り当てます。Spec で新たに作られた用語、変更された用語、または削除された用語に作業が進行中のうちに気付けるよう、この確認をそこに含め、作業が完了した後に気付く事態を防ぎます。確認対象と、それに応じてドメインコンテキストを更新するタイミングはドメインガイド（docs/agents/domain.md）で定めます。グラフが定めるのは確認の実施箇所だけであり、グラフ内の何事も人間の判断を待つことはありません。

用語集の要件

宣言によって追加または変更される用語ごとに、docs Task、または Spec に docs Task がない場合は専用の用語集 Task が、用語集ファイルを宣言し、ドメインモデリングを通じてその用語を記載する要件を含めます。また、その Verification では、空白を正規化したテキスト上で、用語集内に太字の用語とそれに続くコロンがあることを確認します。

修正 Task の上限

修正作業の上限は引き続き 2 Tasks です。QA の指摘に対応するために 2 つを超える修正 Task が必要になっても、3 つ目のパッチを作成したり、ポリシー上の判断を求めて停止したりしないでください。ゲートが completed となった後に追加する修正 Task は、そのゲートの依存先とします。作成者はまず roundfix reopen --spec <slug> を実行して完了済みのゲートを再開する必要があります。QA Task ファイルを編集して再開してはなりません。認められた次の対応から 1 つを選びます。

• TechSpec を改訂し、それを基に Task Graph を再作成します。
• 超過分の修正作業を独立した Spec に昇格し、発見されたストーリーが未解決であることを明示したまま、ゲートを失敗状態にします。

上限への到達はループの権限内で判断します。ループは対応を選び、人間の判断を求めて停止することなく続行します。

タスク種別の選択

誰が実装するか、使用するツール、設定上の選択ではなく、タスクで主に提供される成果に基づいて種別を選択します。

• backend — CLI、デーモン、サービス、API、ドメイン、またはコアアプリケーションの動作；
• frontend — ブラウザー UI、TUI、視覚表示、操作性、アクセシビリティ、または UX の動作；
• data — 永続化スキーマ、クエリ、マイグレーション、インポート、またはデータパイプラインの動作；
• infra — ビルド、CI/CD、パッケージ化、デプロイ、環境、または運用インフラストラクチャ；
• docs — ドキュメントのみの動作、または永続的なナレッジ成果物；
• test — 製品の動作を変更しない、テストハーネス、フィクスチャ、評価、またはカバレッジ作業；
• chore — 上記の製品領域のいずれも変更しない、範囲が限定されたメンテナンス；
• qa — QA 以外のすべてのリーフが完了した後に qa-gate を実行する、固有の作成済み最終ゲート。実装テストや中間チェックポイントには使用しません。

垂直スライスが複数の種別にまたがる場合は、ユーザーに見える、または運用上の主要な成果の種別を使用します。2 つの成果がそれぞれ独立した価値を持つ場合、または主要な成果が曖昧なままの場合は、各スライスの主要な成果が 1 つになるようタスクを分割します。複数の値を記述したり、分類を先送りしたりしないでください。

検証パス

タスクでは、検証で指定するすべてのリポジトリパスを宣言します。ただし、パスがチェック済みツリーに存在する場合、または依存するタスクがそのパスを作成する場合は除きます。## Context で creates:、interface:、deletes:、または instruction: を使用してパスを宣言します。デーモンが記録したパスも該当します。宣言されたパス、または依存関係の閉包内にあるタスクが作成するパスのディレクトリプレフィックスも、提供されたものとして扱われます。

SC-VERIFY-PATH-UNDECLARED は、保留中の QA 以外のタスクについて、タスク段階で時間軸なしのエラーを報告します。既存のトップレベルリポジトリディレクトリ内にあるリテラルパスを読み取りますが、grep/rg パターン、printf/echo の引数、否定されたテストの引数、変数、グロブ、省略記号、および Spec Root 配下のパスは除外します。このチェックはコマンドを実行しません。実行を開始する前に、コマンドを修正するか、不足しているパスを計画でどのように提供するかを宣言してください。

テストセレクターとそれを含むパス

新しいテストをセレクターで実行する検証コマンドでは、セレクターのみを指定します。pytest 9 以降では、重複する収集引数がまとめられます。1 回の呼び出しで tests/test_a.py::test_new のようなノード ID と、そのファイル、それより上位のディレクトリ、または . の両方を渡すと、pytest はエラーを出さずにノード ID を除外し、包含パス全体を実行します。テストがまだ存在しない場合、コマンドはそのファイルにすでに含まれているテストで成功し、事前作業プローブは理由を示さずに空振りとして拒否します。ノード ID のみを指定すると pytest は 4 で終了し、コマンドは意図どおり失敗します。タスクでそのパスも必要な場合は、別のコマンドで包含パスを実行してください。

SC-VERIFY-SUBSUMED-SELECTOR は、保留中の QA 以外のタスクについて、タスク段階で時間軸なしのエラーを報告します。各 pytest 呼び出しを読み取り、同じ呼び出し内の別の収集引数に包含されるノード ID を報告します。対象となる呼び出しは、uv run、poetry run、pdm run、pipenv run、hatch run の後ろ、および $(...) の置換内にある pytest、py.test、python -m pytest です。包含する引数には、そのファイル、それより上位のディレクトリ、.、またはそのノード ID のプレフィックスとなるノード ID が含まれます。--keep-duplicates がある場合、その呼び出しは対象外です。このチェックはコマンドを実行しません。

所有スキルのバージョン

QA 以外の Task で、所有スキルのファイルを .agents/skills/<name>/ 配下に指定する場合、そのミラーも skills/<name>/ 配下に指定します。対象は .agents/skills/<name>/SKILL.md と skills/<name>/SKILL.md の両方、および skills/testdata/owned-skill-versions.json です。所有スキルとは、そのバージョンレコードの skills キーにあるスキルです。ファイル削除の両側には deletes: を使い、 ほかのミラー宣言、SKILL.md のペア、レコードには interface: または creates: を使います。 要件では -record-skill-versions のステップを指定します。 別の Task でこの作業を対象にすることはできません。編集する Task に独自の宣言またはステップがない所有スキルごとに、 SC-SKILL-VERSION-UNTASKED が不足を報告します。 instruction: パスは読み取り専用であり、編集を宣言しません。

Task 内のサーフェストランスクリプト

実装する Task は、対象となる各サーフェストランスクリプトを References に記載し、名前付きのテスト 1 つでトランスクリプト全体を検証します。TechSpec からコピーした標準出力と標準エラーの全行を順序どおりに、終了コードとともに検証し、トランスクリプトで宣言された制御可能な差異のみを認めます。また、その Task の Verification はテストを名前で実行します。読者が見落としそうな行も対象です。最終的なダイジェストやサマリー行、Usage ブロック、インデント、プログラムがゼロ以外の値で終了したときに go run が標準エラーに出力する exit status <n> 行も含まれます。QA Task は、ビルド済みプロダクトを通じてゲートが再現できるよう、すべてのトランスクリプトを Requirement に記載します。トランスクリプトはカバレッジ単位です。TechSpec から実装テスト、さらにゲートまで、名前を追跡できるようにしてください。

共有コントラクトの利用者

共有コントラクトとは、Task の担当範囲外のコードが利用するルート、公開シグネチャ、永続化形式、またはレポートです。完了していないすべての Task を対象に roundfix spec check が読み取る ## Consumers セクションに、QA 以外のすべての Task が Consumer Declaration を記載します。

• <contract> — consumers: <suite>, <suite> は、Task が変更する各共有コントラクトを利用するスイートを指定します。各スイート名は、Verification コマンドに記載されているとおり、バッククォートで正確に囲みます。各スイートは Task の Verification コマンドのいずれかに含め、その Task の作業によってのみ成功するチェックと同じコマンド内に記載します。これにより、作業前はコマンドが失敗したままとなります。
• checkpoint: task_NN は代わりに Integration Checkpoint を指定します。これは、この Task を必要とし、QA ゲートも必要とする非 QA Task であり、その Verification でスイートを実行します。後続の Task が利用者側を適応させる場合に使います。
• None. に続けて理由を記載すると、その Task が共有コントラクトを変更しないことを示せます。

SC-CONSUMERS-UNPROVEN は、セクションの欠落、不正な形式のエントリー、Verification で実行されないスイート、または指定位置にないチェックポイントを報告します。

バイト不変条件ではデリバリーベースを指定する

ファイルとバイト単位で完全一致することを求める QA の要件では、監査対象の head とデフォルトブランチのマージベースである Delivery Base と比較します。名前付きのコミットとは比較しません。計画はほかの Spec の後ろでキューに待機し、先にマージされる Spec によってファイルが変更される可能性があるため、計画の測定時のコミットは比較対象として適切でなくなります。そのコミットを要件に含めないでください。重要な場合は TechSpec に記録します。保留中の QA Task の要件にバイト不変条件とコミット形式の 16 進数トークンが併記されていると、roundfix spec check は SC-QA-BYTES-PINNED を報告します。

プロセス

1. 内訳を導き出す

まず TechSpec の Coverage Cross-Read を確認してください。Deviations from the PRD: の行がない Coverage Map は、write-techspec に差し戻してください。

TechSpec の Build Order から始めます（依存関係の記述をグラフのエッジにします）。すべての PRD ユーザーストーリーとコア機能を、少なくとも 1 つのタスクに割り当てます。割り当てられていないストーリーは、今すぐ修正すべき漏れです。宣言されたすべての Success Metric と API Contract を少なくとも 1 つのタスクに割り当て、それぞれがいずれかの Task の References に名前付きで記載されていることを確認します。満たされていない約束は、今すぐ修正すべき漏れです。記述された Spec に基づいて QA ゲートを一度だけ判断し、その終端ノードを内訳に追加するか、妥当な理由を添えて見送ります。

2. エスカレーションの確認 — 自律的に判断し、例外的な場合のみエスカレーションする

内訳を導き出し、作成します。権限の根拠は Spec です。各自のゲートを通過した PRD と TechSpec には、すでにプロダクトとアーキテクチャの判断が反映されているため、粒度、依存関係の順序、Task Type の分類は、それらの成果物から導き出すものであり、確認を求める判断ではありません。完成した内訳を報告し、必要であれば後から各部分の変更を依頼できるようにします。承認待ちで作業を止めないでください。

次の判断によって権限、アーキテクチャ、または影響範囲が変わる場合に限り、作業を止めて確認してください。

• 権限の不足。 ある部分で、PRD と現行の TechSpec が厳密な対象ファイルを指定して許可していない保護対象のツール類を作成、編集、改名、移動、削除する必要がある場合。必要なパスとその理由を示してください。自分の判断で範囲を広げてはいけません。
• 人間なしでは検証できない。 Task の受け入れに、リポジトリでは保持できない人の判断や認証情報（稼働中の外部アカウント、物理デバイス、主観的な判断など）が本当に必要な場合。検証は必ずハーメチックな状態を保つ必要があるため、それができない Task はグラフの問題ではなく、Spec の問題です。
• Spec に誤りがあり、単に記述が足りないわけではない。 分解を成立させるために TechSpec の Build Order、アーキテクチャ、またはコントラクトに反する、あるいはそれらを拡張する必要がある場合。黙って再設計せず、write-techspec に差し戻してください。
• 1 つのスライス内の不可逆な影響範囲。 Task でデータ移行、破壊的な削除、リリースや公開、認証情報のローテーションを実行する場合。その Task を作成する前に、範囲の確認を得てください。
• 分割できない複雑さ。 あるスライスを新しいセッション 1 回分に収められず、かつ垂直スライスの原則を損なわずには分割できない場合。これは Spec の記述不足を示しています。該当するスライスとその理由を示してください。

エスカレーションでは、具体的な阻害要因と解決案を提示し、漠然と「これでよいですか？」と尋ねてはいけません。この 5 つ以外はすべて、導き出すべき事項です。粒度の好み、命名、Build Order からすでに導かれる順序、主要な成果に基づく分類は、ここで判断します。作成前に、各 type セルには許可された Task Type を必ず 1 つだけ記入してください。空欄、プレースホルダー、複数の値を組み合わせた値は、質問すべき事項ではなく、解消すべき不備です。

3. ファイルを作成する

references/task-template.md のテンプレートを使って、_tasks.md とすべての task_NN.md（トポロジカル順に 01 から採番）を作成します。導き出した Task Type を、各タスクの type frontmatter と _tasks.md のプロジェクションテーブルに記載します。ゲートを含める場合は、manifest frontmatter で qa: を使って qa Task を指定し、トポロジカル順の最後に配置し、QA 以外のすべてのリーフを needs に指定します。見送る場合は、qa: declined と qa_reason を記載し、qa Task は出力しません。受け入れ基準は個別に検証できるものにしてください。誰も確認できない基準は、基準ではなく願望です。新しい worktree でタスクの効果を証明する、正確でハーメチックかつ移植性のあるコマンドを記載した ## Verification セクションを含めてください。Daemon は Agent の作業後、記載されたコマンドをそのまま実行します。標準の Spec Context Bundle では明らかにならない、タスク固有の指示やインターフェイスのパスがある場合に限り、## Context を追加してください。

ここでも耐久性が重要です。リポジトリ内のファイルパスではなく、動作とインターフェイスを記述してください（Spec フォルダー内の相対参照は使用できます。フォルダーは一式で移動されます）。

4. グラフを検証する

報告する前に、目視ではなくパースして機械的に検証します。

まず、分解したばかりの Spec に対して、リポジトリ独自のチェッカーを実行します。

roundfix spec check <slug> --run-verification

この形式では、PRD、TechSpec、そこで参照されている ADR、グラフをまとめて読み込みます。4 つすべてが揃う最初の時点で、作成者が記述した Verification コマンドを、破棄可能な HEAD のチェックアウトで実行します。--run-verification を付けずに roundfix spec check <slug> を実行して判定が問題なしでも、Vacuous Verification は対象になりません。変更のないツリーに対してこれらのコマンドを実行しないため、すでにゼロで終了するコマンドが見つからないままになる可能性があります。コマンド実行を省略することで速くなるからといって、実行しない形式を優先しないでください。

報告されたエラーはすべてブロッキングとして扱ってください。アーティファクトを修正し、問題がなくなるまで再実行します。また、指摘事項が残っている間は分解結果を報告しないでください。[gap] もブロッキングです。該当する ADR を明記するか、適用されない理由を記録してください。スキップされたチェックは参考情報です。

これは以下のリストの代わりにはなりません。このリストでは、チェッカーが確認しない項目を扱います。未列挙または未対応の ADR、不完全な Project Constraints、カバレッジの未マッピング、矛盾する要件、未宣言のリハーサル、作業に依存しない Verification、文書化されていない Vocabulary Contract を確認します。SC-CITATION-UNSUPPORTED は、ADR の本文で裏付けられていない主張を報告します。

次に、以下を読み取って確認します。

• すべての graph.nodes[].file が存在し、すべてのタスクファイルにパース可能なフロントマターがあり、status: pending になっていること。
• すべてのタスクファイルの type 値が、backend、frontend、 data、infra、docs、test、chore、qa のいずれか一つだけであること。また、そのタスクに対応する _tasks.md の投影行に、同じ値が含まれていること。
• すべての needs の項目が既存のノード ID を参照していること。循環がなく、トポロジカル順序を出力できること。
• コントラクト作成後のすべてのグラフで、QA の判断が一つだけ宣言されていること。ゲートを含める場合、そのゲートは一意の qa タスクであり、依存先を持たず、すべての QA 以外のリーフに直接または推移的に依存していること。ゲートを含めない場合、qa_reason が空でなく、qa タスクが存在しないこと。
• すべての PRD ユーザーストーリーが、いずれかのタスクの References に記載されていること。

実行プレビューとして、ウェーブ計画を出力します（ウェーブ 1 = needs なし、ウェーブ N = 先行するウェーブで needs が満たされるタスク）。

5. 報告

分解結果の表（id | title | type | complexity | needs）、作成者が決定した QA の判断と、見送った場合はその理由、分割の根拠を一行で、ファイル一覧、ウェーブ計画を回答してください。また、どのスライスについても変更を今すぐリクエストできることを伝えてください。発生したエスカレーションのトリガーと、その解決方法を明記してください。

アンチパターン

• 水平分割（スキーマのタスク、API のタスク、UI のタスク）。すべてのタスクでスタック全体を横断する必要があります。
• 「機能を実装する」といった巨大なタスク。単独で検証できないなら、まだタスクとはいえません。
• 曖昧な基準（「正しく動作する」「エラーに対処する」）。観測可能な動作を明記してください。
• ローカルにしかないファイル、以前の実行状態、手動プロンプト、リモートブランチの状態に依存する、非ハーメチックな検証。
• wc のパイプライン形式チェック、grep で済む依存関係チェックに rg を使うこと、リポジトリで必要な -buildvcs=false フラグを省いた Go のビルドコマンドなど、移植性のない検証。
• 広範なテストスイートを実行するだけで、タスク固有の効果を証明できない検証。
• コミット、プッシュ、PR、ブランチ公開に関する受け入れ基準。これらは Daemon とデリバリーの責務であり、タスクの成功基準ではありません。
• グラフとタスクファイルの編集が同期していないこと。同じ内訳から両方を再生成してください。
• Spec がすでに承認している内訳について承認待ちにすること。呼び出しが承認を意味し、粒度は判断ではなく導出です。
• ループが実行中だからという理由で、実際のエスカレーショントリガーを無視して先へ進むこと。ツール使用の承認がない場合や、ハーメチックに検証できないタスクがある場合は、判断の余地なく停止してください。
• Task Type がない、プレースホルダーのまま、複数を組み合わせている、または独自に作られていること。分類は必須のルーティング契約であり、自由記述の説明ではありません。
• 契約後のグラフに、作成済みの終端 qa タスクも、qa: declined と qa_reason の組み合わせも残さないこと。省略は不具合であり、実行ごとに QA を選択する余地ではありません。

参考資料

• references/task-template.md — _tasks.md と task_NN.md のテンプレートです。ファイルを書く前に読んでください。