Write Tasks
docs/specs/<slug>/_prd.md（および存在すれば _techspec.md）を実行可能なタスクグラフに変換します。タスクごとに task_NN.md ファイルと、マニフェストである _tasks.md を生成します。_tasks.md は implement-task と Roundfix Daemon がスケジュールを組むための元となります。成果物は契約です。つまり、新しいエージェントセッションが、タスクファイル1つと仕様フォルダだけをコンテキストとして、そのタスクをビルドできなければなりません。
軽量プランの計画
complexity: low であり、QAではなく、管理対象パスを宣言していないタスクは、軽量プランで実行されます。作成者は、計画用プルリクエストがマージされる前に roundfix spec judge <slug> --stage tasks を実行して、アドバイザリ的なプラン提案を得ることができます。この提案がディスパッチを制御することはありません。
事前条件
$ARGUMENTS が仕様を指定します。_prd.md が存在しなければなりません。実際のアーキテクチャ上の表面を持つ機能で _techspec.md が欠落している場合は、まず write-techspec を実行してから分解します。存在しない成果物を作成することが解決策であり、許可を求めて停止する理由にはなりません。自律作業中は、これを確認する必要はありません。自律作業の指示は、承認済みキュー内のすべての仕様に対して、作成チェーン全体を承認するものです（docs/agents/autonomous-work.md に従う）。テクニカルスペックなしで分解するよう明示的に指示された場合のみ受け入れを求め、その場合は分解前にコードベースをより深く探索することで補償します。
プロジェクト制約の事前チェック
分解の導出または承認の前に、以下の事前チェックを実行します。
- 仕様を分類します。解決済みのアーカイブディレクトリ（ビルトインの
docs/specsルートの場合はdocs/history/specs/、外部または非デフォルトルートの場合は<spec-root>/_archived/）配下の仕様、またはこの契約が適用される前に完了したことが証明された仕様は、完了済みまたはアーカイブ済みのレガシー仕様です。すべてのレガシー成果物をバイト単位で同一に保ちます。バックフィル、再フォーマット、再生成、書き直しは行いません。 - アクティブでアーカイブされておらず、まだ完了していないすべての仕様について、PRDおよび存在するすべてのTechSpecに完全な
Project Constraintsセクションが含まれていることを要求します。各セクションには、Identifier strategy、Authentication and HTTP、Active ADR obligations、Tooling authorityが、該当する場合は理由付きで、該当しない場合も理由付きで記録されていなければならず、各行はその運用元であるdocs/agents/のソースパスを引用しなければなりません。 - いずれかのアクティブな成果物が欠落または不完全な場合、
_tasks.mdまたはタスクファイルの作成または更新を拒否します。欠落している行、理由、またはソースパスをすべて指定し、仕様を所有する作成スキルに差し戻します。 - 提案されたスライスが、リポジトリツールの設定、スクリプト、無視ファイル、プラグイン宣言、またはバージョン固定の作成、編集、名前変更、移動、または削除を含むかどうかを検査します。このような作業は、PRDおよび存在するTechSpecのレコードがメンテナの承認と、それがカバーする正確で境界のあるリポジトリ相対ファイルを明示している場合にのみ許可されます。一般的な実装リクエスト、セットアップの承認、またはタスクの割り当ては承認ではありません。承認と境界ファイルの両方がない場合、分解を拒否します。
- すべてのツールスライスについて、
<spec-root>/<slug>/_authorization.mdの運用レコードを解決します。レコードがない場合、proposedレコード、または付与日がないレコードは何も承認しません。運用中の付与が存在するまで分解を拒否します。新しい付与または拡大された付与は、それを消費するスカッシュデリバリーの前にターゲットの祖先ブランチにランディングする必要があります。したがって、付与または修正を、それが承認する変更に折り込むことはできません。 - 境界ファイルのリストを、承認された各ツールタスクのスコープと受け入れ基準にコピーします。タスクはこれらのパスと自身のタスクファイルのみを変更できます。異なる境界を必要とする作業は分割します。
- レコードの
operationsリストは、仕様が使用するすべてのデリバリー操作を許可していなければなりません。roundfix deliver startは、implement、commit、push、pull_request、またはmergeが欠落しているレコードを拒否します。管理対象パスがない仕様はpaths: []を記録します。 - タスクコミットは、その正確なパスが仕様の承認レコードの実行可能ファイルリストに記載されている場合にのみ、追跡されていない実行可能ファイルを保持します。それ以外の追跡されていない実行可能ファイルは拒否されます。リストは、Runが読み取る前にデリバリターゲット上になければなりません。QAレポートおよびバッチコミットは、追跡されていない実行可能ファイルを決して保持しません。
core.fileModeがfalseのリポジトリは、ファイルを100644として記録します。
依存関係は _tasks.md のみが所有します。タスクステータスは各タスクファイルのみが所有します。事前チェックは、これらの責任を決して移動しません。
別のオペレーティングシステム用のコードは、そのシステム向けに非テストコードをビルドして検証され、例えば GOOS=windows go build -buildvcs=false ./<package> のように検証され、ホスト用に書かれたテストもコンパイルする go vet は決して使用しません。
所有ルール（何がどこにあるべきか、そしてその理由）
- 依存関係は
_tasks.mdグラフのみに存在します。 タスクファイルには決して記述しません。エッジのコピーが2つあると、グラフが乖離する原因になります。 - ステータスは各タスクファイルのフロントマターのみに存在します。
_tasks.mdはトポロジを所有し、進捗は所有しません。スケジューラは状態を読み取るためにタスクファイルを再読み取りします。 - タスクタイプはすべてのタスクファイルで必須です。
backend、frontend、data、infra、docs、test、chore、qaのうち、正確に1つを使用します。qaは、マニフェストのqa:フィールドで指定された、独自に作成されたターミナルゲートのために予約されています。実装コマンドはこの値をルーティングに使用し、欠落または不明な値は拒否します。プレースホルダーを残したり、後でタイプを推測したりしないでください。 - コンテンツは参照し、複製しません。 タスクファイルはPRD/TechSpecのセクションを名前で参照します。仕様を言い換えるタスクは、仕様が修正されるたびに古くなります。採用元のコピーは、所有する仕様内の採用後のパスでリンクし、そのタスクファイルからの相対パスで宛先を指定し、採用前の来歴パスでは決してリンクしません。二次的な仕様は、プライマリ所有者のコピーをリンクし、何も採用しません。所有者のアーカイブはアーカイブ再リンクを実行します。そのコピーを
docs/references/に昇格させ、二次的な仕様のリンクを書き換えるため、ソースは1つの所有者を維持し、二次的な仕様はコピーを必要としません（ADR-0260、ADR-0083）。 - コンテキストエントリはラベル付きパスです。
## Contextは、タスクが標準の仕様バンドルを超える特定の指示またはインターフェースパスを必要とする場合にのみ追加します。- instruction: <path>、- interface: <path>、- creates: <path>、- deletes: <path>の形式の箇条書きを使用します。パスはクリーンで、リポジトリ相対であり、一意でなければなりません。タスクは最大50の一意なエントリを宣言できます。Daemonは、以前に変更されたファイルを含む200パスの仕様コンテキストバンドルを埋める前に、これらのパスを予約します。 - 宣言された編集と管理対象パスは明示的です。 タスクが編集するすべてのパスは
interface:またはcreates:の下で宣言されます。削除するすべてのパスはdeletes:の下でのみ宣言され、interface:でもinstruction:でもありません。削除する前にファイルを読み取るタスクでも、deletes:の下に1回だけリストします。削除は未解決参照チェックではスキップされ、スコープ、管理対象パス、Wave衝突の監査でカウントされます。Daemonは、宣言された削除がまだ存在する場合、検証前の決済を拒否し、deletes: <path> still existsを報告します。instruction:パスは読み取り専用であり、2つのタスクを衝突させることはありません。コマンドを変更する各タスクは、変更する1つのコマンドファイルを宣言します。.agents/skills/roundfix/references/<command>.mdとそのミラー、およびdocs/user-guide/commands/<command>.mdであり、スキルのSKILL.mdやcommands.mdは、エントリファイル自体を変更する場合を除いては宣言しません。同じファイルを宣言する2つのタスクはWaveを共有できないため、異なるコマンドを変更するタスクは一緒に実行でき、同じコマンドを変更するタスクはそれらの間のエッジを必要とします。宣言された、または検証読み取りの管理対象パスは、仕様の_authorization.mdのpaths:と、bounded files:行の両方に現れなければなりません。そうでない場合、SC-TOOLING-UNDECLAREDで作成が拒否されます。CLIサーフェスを指定するタスクは、自身または依存するタスクを介して、そのスキルまたはガイド自体を指定します。そうでない場合、SC-CLI-UNDOCUMENTEDで報告されます。
Daemonは、タスクが宣言せずに変更したパスを、コミット時に ## Recorded paths に記録します。QAスコープ監査は、その記録されたパスを宣言済みとしてカウントします。記録は変更を開示し、何も予約しません。予見可能なすべてのパスを宣言することがルールであり続けます。
2つのタスクがそれぞれ変更する可能性のあるテストヘルパー、フェイク、フィクスチャ、またはゴールデンファイルは、予見可能なパスです。それを変更する可能性のあるすべてのタスクの interface: で宣言します。これにより、roundfix spec check --strict は、仕様がまだ作成中で、needs エッジが指定するタスクを直列で実行する際に SC-WAVE-COLLISION を報告します。記録は何も予約せず、完了したタスクは決して衝突しません。タスクの決済コミットは、2つのタスクのうち1つが完了していない場合（例えば、タスクが pending に再オープンされた場合）にのみ衝突の証拠となります。したがって、宣言されていない同じファイルを変更した後に両方とも完了した1つのWaveの2つのタスクは決して拒否されません。ファイルを宣言することが唯一の防御策です。
変更された動作サーフェスのためのスキルタスク
リポジトリのスキルカバレッジマップが docs/references/skill-coverage.json に存在する場合は、それを読み取ります。非QAタスクが interface:、creates:、または deletes: の下でソースを宣言する、カバーされているすべての動作サーフェスについて、interface: または creates: の下でそのカバーするスキルファイルの1つを宣言する非QAスキルタスクを含めます。SC-SKILLS-UNTASKED は、そのようなタスクがないサーフェスを報告します。
変更にスキルテキストが必要ない場合、PRDのオプションの ## Skills セクションに - unchanged: <surface id> — <reason> を記録し、interface: または creates: の下でマップを宣言する非QAタスクを含めて、カバレッジレビューを記録します。エントリだけではサーフェスを免責しません。SC-SKILLS-MALFORMED は、別の形状のエントリ、不明なサーフェス、または空の理由を報告します。両方のルールは、マップを追加したコミットから開始されます。マップがないリポジトリはこれらをスキップします。
interface:、creates:、または deletes: の下で docs/user-guide/ の下のMarkdownページを宣言する非QAタスクは、interface: または creates: の下で docs/references/behavior-surfaces.json も宣言し、要件に -record-skill-coverage ステップを指定しなければなりません。別のタスクがそれをカバーすることはできません。ガイドタスク自体の決済がそのフィンガープリントをチェックします。仕様の _authorization.md の制限は、そのレコードを決して禁止してはなりません。SC-SURFACE-RECORD-UNTASKED は、レコードを持つリポジトリにおいて、タスク段階からのギャップを、猶予期間なしで報告します。
分解ルール
-
垂直スライス。 各タスクは、それが触れるすべてのレイヤを通る、狭いながらも完全なパスを提供し、それ自体でデモ可能または検証可能でなければなりません。トレーサーバレットであり、レイヤではありません（「すべてのスキーマ」は間違ったタスクです。「期限切れのインポートを再試行し、そのステータスを表示する」が正しいタスクです）。
-
まず事前リファクタリング。 スライスが準備を必要とする場合、それを独自の先頭タスクにします。変更を容易にしてから、容易な変更を行います。
-
作成中に外部サーフェスを特性評価します。 仕様がアダプター、コントラクト、データベースなどの外部サーフェスを横断する場合、特性評価タスクを作成します。このタスクは、フェイクが行うことではなく、実際の境界が行うことを記録します。これにより、サポートされていない前提が、QAゲートではなく、仕様の作成中に失敗します。
依存関係を
needsにリストし、単にファイル内で前に配置するだけではありません。 前提が特性評価に依存するすべてのタスクは、_tasks.mdのneedsエントリにそのタスクを指定します。実行のWaveはneedsのみから構築されるため、マニフェストで単に後ろに現れるタスクは、依存する特性評価と同じWaveで実行でき、まだ特性評価されていない境界を読み取る可能性があります。ファイルの順序は依存関係ではありません。特性評価タスクは実際の境界に触れるため、明示的にバインドします。 そのファイルは、到達するターゲットを名前で示します。読み取り専用で動作するか、タスク自体が作成および削除する分離されたインスタンスに対して実行します。デフォルトでは、共有または本番状態に対して特性評価を行いません。そのターゲットにスコープされ、それより広くない認証情報を使用し、キャンセルを尊重し、失敗した場合でも作成したものをクリーンアップします。書き込みを必要とする特性評価は、その書き込みが他の不可逆アクションと同じようにタスクで承認されることを要求します。境界が何を行うかを記録することは、それを変更する権限ではありません。
その検証はレコードをアサートし、境界はアサートしません。 Daemonは、タスクの宣言された
## Verificationコマンドをシェルを介して逐語的に実行します。エージェントターンが存在する前に、変更されていないツリーに対して1回、決済時に再度1回実行します。そのパスの何も、上記の境界を読み取りません。それらはエージェントを制約し、Daemonはエージェントではありません。したがって、実際のサーフェスに到達する検証は、作業が行われる前を含め、境界なしで2回到達します。タスクが記録した特性評価（その形状、存在、下流タスクが読み取るもの）を検証し、境界呼び出しはエージェントターンに残します。そこでは、タスクの宣言されたターゲット、分離、認証情報、および書き込み承認が適用されます。これが、これらのコマンドがすでに持っている密閉性ルールであり、それを破る誘惑が最も強い場所で述べられています。ライブな外部サーフェスはアンビエントな状態であり、それに依存するコマンドは密閉的ではありません。 -
1つの新しいセッションに適したサイズ。 エージェントが新しいコンテキストで1回のセッションで完了できるタスク。約7つのサブタスクまたはファイルを超える場合は分割します。
-
テストは埋め込み、分離しない。 すべてのタスクの受け入れ基準には、独自のテストが含まれます。後続の「テストを書く」タスクは、以前のタスクが決して完了していなかったことを意味します。
-
独立して実装可能。
needsが完了すると、タスクは他の未完了の作業を必要としてはいけません。これにより、後でワークツリー間での並列実行が可能になります。 -
検証は密閉的で、ポータブルで、効果を証明し、Daemonが所有するものでなければなりません。 すべてのタスクの
## Verificationコマンドは、onを使用して新しいワークツリーで満たせなければなりません。
…
（翻訳のため省略）