dagr-producer

dagr producer — 実行を記述し、実行を証明する

あなたはプロデューサーです。dagr view がライブで描画する実行ファイルの唯一の書き手です。dagr は表現カーネルです。タスクの事実を記述すると、そこから定義済みのビューシグナルのみを導出します。事実が欠けていたり誤っていたりすれば、グラフも欠落したり誤ったりします。それを修正するワークフローエンジンはありません。

コントラクトバージョン："dagr": 3（v1/v2 のファイルも引き続き読み取れます。新しい実行には v3 を書き込んでください）。

書き込む前にバリデーターを見つける

以下のチェックループから得られるフィードバックはこれだけなので、まず dagr バイナリを特定してください。見つからない場合は作業を中止してください。

1. $DAGR_BIN が設定されている場合はそれを使用します。
2. command -v dagr（PATH 上）を実行します。
3. プラグイン／リポジトリのビルド：<dagr repo>/target/release/dagr — herdr ペイン内では、ランタイムが $HERDR_PLUGIN_ROOT を注入します。これは dagr リポジトリのルートです。
4. フォールバック：cargo run --manifest-path <dagr repo>/Cargo.toml -- check …。

バリデーターが見つからない場合は、実行ファイルの書き込みを開始せず、その旨を伝えて終了してください。未検証の実行ファイルは、このシステムが防ごうとしている「気付かれない誤り」そのものです。

ループ（必須）

write run.json.tmp → dagr check run.json.tmp --strict --json → fix → repeat until []
                                                             → THEN rename over run.json

候補を検証してから公開してください。決して順序を逆にしないでください。 ペインは run.json の内容を即座に描画します。無効な候補をそのファイルに名前変更すると、作業中にすべての閲覧者へエラー状態が表示されます。安全なトランザクションは次のとおりです。

1. 次のドキュメント全体を run.json.tmp に書き込みます（同じディレクトリに置いてください。名前変更をアトミックにするには、同じファイルシステム上である必要があります）。
2. dagr check run.json.tmp --strict --json を実行します。終了コード 0 で出力が [] なら問題ありません。終了コード 1 は検出事項があることを意味します（E コードはエラー、W コードは表現可能だが疑わしい状態です。理由を説明できない限り修正してください。--strict はこれらを失敗として扱うため、優先して使用してください）。終了コード 2 は、バリデーターがファイルをまったく読み取れなかったことを意味します。これはパスまたはツールの問題であり、ドキュメントの問題ではありません。この場合、標準出力は空なので、空の出力を問題なしと見なさないでください。作業を止めて事前確認をやり直し、終了コードが 0 以外の場合は決して公開しないでください。
3. 問題がない場合に限り、mv run.json.tmp run.json を実行します（アトミックな名前変更です。ペインは mtime の変更を検知して再読み込みするため、書き込み途中や無効なファイルを表示しません）。
4. 失敗した場合は、一時ファイルを修正して再チェックします。以前のライブファイルには手を加えず、run.json 自体をエラー状態のままにしないでください。

書き込み先：ペインはまず $DAGR_RUN を探し、次にワークスペースの cwd 配下の .dagr/run.json、続いて run.json を探します。まだ存在しない場合は .dagr/run.json を待ち受けます。ワークスペースのルートにある .dagr/run.json を既定の保存先にし（gitignore に追加してください）、ファイルごとに実行を 1 つだけ保存します。実行内の並列レーンは deps が重複しないタスクとして表現できますが、別のワークフローには専用の実行ファイルとペインを用意してください。

オブジェクトモデルを一息で

• Project = 再帰的な視覚上のスコープです。実行は暗黙のルートです。 サブプロジェクトは、単に parent を持つプロジェクトです。フェーズや ワークストリームも別のエンティティではなく、プロジェクトです。各タスクは 任意で一つの project を所属先に持ちますが、依存関係のエッジは どのプロジェクト境界も越えることができます。
• Task = 作業項目です。安定した id は自分で選びます（ペイン ID は 使用しません）。kind は固定されていません — impl · review · test · gate · question · docs · ship · … — 実態に合うものを選びます （人間が回答するために存在するタスクには question、合流点には gate を 使用します。どちらも dagr の描画方法を変えます）。 状態：queued · working · review · blocked · done · failed · rejected · canceled · settled_unverified。
• Attempt = タスクへの一回の試行です。id は T·aN 形式で、 n は 1 から始まります。状態：queued · working · done · failed · rejected · settled_unverified · lost。**再試行で試行を書き換えることはありません — cause を付けた新しい試行を追加します。**タスクの履歴が 後戻りすることはありません — 試行を書き換えたり削除したりすることは ありません。タスクの状態は最新の試行に従うため、新しい試行が始まると、 差し戻された done タスクは working に戻ります。
• Event = 追記のみの来歴情報です：attempt_started · attempt_settled · promoted · directive · message_resolved · note。at のタイムスタンプは 昇順です。イベントを書き換えたり、並べ替えたりしてはいけません。
• Evidence tier = すべての終端結果に付く証拠レベルです：verified（機械的に 検証済み — テスト実行、コミットの受領記録） · reported（アクターからの 型付きエンベロープ） · heuristic（推定） · asserted（根拠のない主張）。 「エージェントが完了したと言った」は、よくても reported です。 エンベロープがない場合は settled_unverified です — 実際の終端状態であり、 暫定的な done ではありません。

dagr checkで検証される不変条件

1. タスクの状態は試行の投影です：workingには作業中の試行が必要です。done／rejected／settled_unverifiedでは、最新の試行がその状態と一致する必要があります。failedでは、最新の試行がfailedまたはlostであれば有効です。queuedでは、作業中の試行があってはならず、最新の試行がdoneまたはsettled_unverifiedであってもいけません。failedまたはrejectedの試行後にタスクを再キューするのは正しく、想定された動作です。reviewには少なくとも1回の試行が必要です。canceledはタスク専用です。計画された作業を取り下げますが、試行を書き換えたり、新たに作成したりすることはありません。
2. 原因は時間的に前を指します：2回目以降の試行にはcause（sent_back · gate_failed · followup · superseded）が含まれ、そのrefはそれより前の試行を指します。initialは1回目の試行にのみ使います。
3. 実行はDAGです：depsまたはゲートのinputsを通じて、循環があってはなりません。ゲートのファンインはdepsそのものです。inputsは、ファンインの集合が依存関係の集合と異なる場合にのみ上書きするために使います。真の逐次作業は依存関係として記述してください。タスクの宣言順序は、試行のない兄弟タスクのタイブレーカーとしてのみ使われます。
4. 終了した試行にはoutcomeが必要です。resultはstateと一致し、証拠の段階は実際に存在するものを指定してください。タイムスタンプは実際のISO-8601形式とし、試行の終了時刻は開始時刻より後でなければなりません。
5. IDは自分で決め、一意にします：タスクIDを試行IDと重複させてはいけません。herdrのペインIDはidではなくlocatorに指定してください。
6. 進行中の試行は場所を特定でき、稼働中でなければなりません：作業中の試行にはlocator（{"pane": "wX:pN"}）と、値が設定されたlivenessが必要です。livenessには、prompt_acknowledged（ブール値）、last_output_at（タイムスタンプ文字列）、queued_input（入力済みで未送信のコンポーザー行の数。何もなければ0。ブール値ではありません。ブール値を指定するとドキュメント全体が拒否されます）が含まれます。エージェントが出力を生成したら、last_output_atを更新してください。古さは表示されますが、無反応こそが問題です。
7. ブロックされている場合は、ブロックを解除するものを明示します。昇格はイベントであり、推測するものではありません。ファンインが完了したら、{"type": "promoted", "task": ...}を出力してください。
8. **プロジェクトへの所属は依存関係ではありません。**各タスクに正確な視覚上の配置先を1つ与え、プロジェクトをまたぐものも含め、すべてのブロッカーをdepsに記載してください。影響を両方から見せるために、タスクを2つのプロジェクトに重複して配置してはいけません。
9. **オペレーターのメッセージでは、その権限とIDを保持します。**ペインから[DAGR OPERATOR MESSAGE]エンベロープが届きます。recommend_and_returnとmay_decide_and_continueの違いを尊重し、解決イベントにmessage_idを保持してください。dagrはリクエストを転送しますが、代わりに対応することはありません。

レシピ

以下の各レシピには、このスキルディレクトリのexamples/に、完全で厳密な検証に合格する対応ドキュメントがあります。dagrのテストスイートで適切な状態に保たれています。ここにある断片は構成の形を示しています。実際のファイルを作成するときは、例を参考にしてください。断片だけでは、dagr checkで検証される相互参照（cause.refには参照先の宣言が必要であり、作業中の試行にはlocatorとlivenessが必要です）が省略されています。

実行を初期化する

{
  "dagr": 3,
  "run": {
    "id": "run-myjob-v01", "title": "what this run is",
    "started_at": "2026-02-01T09:00:00Z",
    "orchestrator": {"pane": "wX:p1"}
  },
  "generated_at": "2026-02-01T09:00:00Z",
  "projects": [],
  "tasks": [],
  "events": []
}

書き込むたびにgenerated_atを更新してください。画面上のすべての「Nm ago」の基準となり、値が古い場合は古さを示すバナーが表示されます。

利用可能な場合は、独自の$HERDR_PANE_IDからrun.orchestratorを自動設定してください。利用できない場合は、安定したHerdrエージェントのターゲットを指定します。ここにmがオペレーターメッセージをキューイングします。ワーカーを指定してはいけません。ユーザーのオンボーディング手順や追加のコントローラーは不要です。

タスクを始める前にプロジェクトとサブプロジェクトを構成する

視覚的に適切な所属先を用意できる、最小限の階層にします。個別の phases 配列や workstreams 配列は作成しないでください。

"projects": [
  {"id": "APP", "title": "Application"},
  {"id": "API", "title": "API stream", "parent": "APP", "owner": "api-lead"},
  {"id": "UI", "title": "UI stream", "parent": "APP", "owner": "ui-lead"}
]

API のタスクには "project": "API" を指定します。UI タスクがそのタスクに依存する場合は、UI タスクを UI に置いたまま、deps に API タスクの ID を指定します。レンダラーがプロジェクト間の依存関係を表示します。タスクを複製したり、共通の親プロジェクトに無理に配置したりしないでください。本当に実行レベルの作業に限り、project を省略します。

まずは大まかに始め、役立つプロジェクトの骨格、直近の作業、意味のあるゲートを宣言します。見つかったタスクは、関連するようになった時点で追加します。公開するのはオペレーターが確認できる作業であり、内部のエージェント、ツール、ランタイムの手順をすべて公開するわけではありません。Dagr は deps、owner／actor、kind から、待機中の行の waits、ready、unassigned、needs answer を導出します。これらを追加フィールドとして記述しないでください。

タスクを開き、最初の試行を開始する

{
  "id": "L1", "title": "impl: core lane", "kind": "impl",
  "owner": "l1-dev", "state": "working", "deps": [],
  "attempts": [{
    "id": "L1·a1", "n": 1, "cause": {"type": "initial"},
    "actor": "l1-dev", "model": "fable",
    "locator": {"pane": "wX:p3"},
    "state": "working", "started_at": "2026-02-01T09:05:00Z",
    "liveness": {"prompt_acknowledged": true, "last_output_at": "2026-02-01T09:05:00Z"}
  }]
}

{"at": ..., "type": "attempt_started", "task": "L1", "attempt": "L1·a1", "actor": "l1-dev"} を events に追加します。

model は任意の文字列で、そのまま表示されます。dagr が書き換えることはないため、表示形式は自分で選んでください。短い model·effort チップを使います。例：fable·xhigh、sol5.6·max、luna5.6·max、terra5.6·max。ペインのこの列には 12 セルが割り当てられています（terra5.6·max でちょうど埋まります）。文字列がそれより長い場合は省略記号で切り詰められます。また、狭いレイアウトではタイトルが切り詰められる前にチップが非表示になります。

試行を確定する（証拠を添えて）

試行の state、ended_at、outcome を設定します（result は state と一致させます）。タスクの state も同じ状態にし、attempt_settled イベントを追加します。 （ended_at は作業が停止した時刻、確定イベントの at は判定が下された時刻です。両者が異なる場合もあり、その差は実際の情報です。09:50 に停止したペインの却下が 10:12 に下された場合、両方の時刻を記録します。）入手できる最も強い証拠を優先してください。

判定ルール：ティアは、確定の主張を裏付ける証拠の強さを示します。done に必要なのは、誰かが完了を主張したことだけです。主張がどれほど弱いかは、ティアが評価します。誰も何も主張しておらず、ランタイムのシグナル（ペインの終了、応答がないこと、緑色のプロンプト）から推測している場合、状態は settled_unverified です。この状態は、そのためにあります。4 つの適切な確定方法の全容は examples/06-evidence-tiers.json に記載されています。

• verified — 機械的な確認結果： {"result": "done", "evidence": "verified", "receipt": "cargo test 40/40 ✓ @ a1b2c3d"}
• reported — アクターからの型付きエンベロープ（構造化された結果データであり、チャットの文章ではありません）： {"result": "done", "evidence": "reported", "receipt": "result envelope: {files: 4, status: complete}"}
• asserted — アクターは完了を主張しましたが、文章での主張にとどまります： {"result": "done", "evidence": "asserted", "reason": "actor asserted completion in chat; no typed envelope to verify against"}
• 誰も何も主張していない — これは確度の低い done ではありません。別個の終端状態 settled_unverified であり、ended_at と、それに一致する outcome が引き続き必要です： "state": "settled_unverified", "ended_at": ..., "outcome": {"result": "settled_unverified", "evidence": "heuristic", "reason": "no claim of completion from the actor; inferring from clean pane exit"}。 証明されていない作業が成功に格上げされることはありません。

差し戻して再開する

レビュー担当者が作業を却下した場合、3 つのレコードを更新します。レビューの試行は done（レビュー自体は成功）、レビュー対象の試行は rejected として確定し、修正ラウンドは、レビュー試行を指す cause を持つ新しい試行にします。

{"id": "L1·a2", "n": 2,
 "cause": {"type": "sent_back", "by": "rev-1", "ref": "R1·a1", "reason": "error paths untested"},
 "locator": {"pane": "wX:p3"}, "state": "working", "started_at": "...",
 "liveness": {"prompt_acknowledged": true, "last_output_at": "..."}}

cause.ref には、宣言済みで、より前にある試行を指定する必要があります。R1·a1 がファイルにない場合、チェックは失敗します。正常に機能する再試行にも、ロケーターと稼働状態が必要です。タスクの状態を state: "working" に戻します。dagr は、この cause から再開を示す ↩ を描画します。完全なドキュメント： examples/03-send-back.json。

ファンインゲート

ゲートのファンインは**depsです**。これにより、すべてのゲートエッジが循環チェックの対象に含まれます。ファンインの集合が依存関係の集合と実際に異なる場合に限り、inputsを使用してください。

{"id": "G1", "title": "gate: merge lanes", "kind": "gate", "owner": "orchestrator",
 "project": "APP", "criteria": "API and UI reviews are clean",
 "state": "queued", "deps": ["L1", "L2", "L3"], "attempts": []}

ゲートの入力は、人が読む順序を意図して宣言し、tasks配列全体も意図した順序に保ってください。dagrは、試行のない兄弟タスクと、状態を持つゲートの結合ストリップについて、宣言順を維持します。並べ替えのためにIDを変更したり、レイアウト上の回避策としてゲートを1つのレーンに紐付けたり、合成的な「結合」タスクを追加したりしないでください。実際のファンインを宣言してください。projectを持つゲートはそのプロジェクトのマイルストーンです。projectがない場合、dagrはすべての入力に共通する最も近いプロジェクトに配置します。したがって、API内のゲートはAPI内にとどまり、APIとUIを結合するゲートは親のAPPに配置され、無関係なトップレベルプロジェクトを結合するゲートは実行レベルのマイルストーンになります。入力の試行タイムスタンプによって親が決まることはありません。各直接入力は、待機中を○、作業中を◎、充足済みを●で表示します（通常のブロック／レビュー／失敗マークも表示されます）。狭いペインではこれらのマークが集約されますが、ゲートを選択すると正確な入力IDが表示されます。

組織上の所有者が明確な場合は、明示的なprojectを指定してください。入力の所属先からの推定が実態を正確に表す場合は、省略してください。画面上の位置を変えるためだけに、偽の依存関係を追加してはいけません。

最後の入力が到着したら、すべてのイベントと同様に、atタイムスタンプを含むpromotedイベントを追加してください。

{"at": "...", "type": "promoted", "task": "G1", "detail": "fan-in complete: L1 ✓, L2 ✓"}

「ゲートを先に進める」とは、引き続き投影ルールが適用されるという意味です。working／doneのゲートには、その状態にある独自の試行が必要です。ゲートの作業開始時にロケーターと、ライブの場合はライブ状態を付けてG1·a1を開き、ほかの試行と同様に証拠を添えて完了させてください。attempts: []のゲートはqueuedにできます。また、ゲートが取り下げられた場合はcanceledにできます。完全なドキュメント： examples/04-gate-promotion.json。

計画済みの作業をキャンセルする

タスクを"state": "canceled"に設定し、短いnoteを記載してください。それ以前の試行とイベントはすべて変更せずに保持します。キャンセルされた試行結果はありません。キャンセルは成功ではないため、そのタスクに依存するタスクも更新するか、キャンセルしてください。

ループポリシーを宣言する（先の作業）。暗示しない

"policy": {"rounds_max": 3, "futures": [
  {"on": "pass", "ref": "G1"},
  {"on": "fail", "node": {"id": "L1·a2", "title": "fix round", "actor": "l1-dev"}, "loop_back": true},
  {"on": "fail", "streak": 2,
   "node": {"id": "L1x·a1", "title": "escalate: fresh approach", "attribution": "predicted"},
   "after": "L1·a2", "source": "two-strikes rule"}
]}

refは既存のタスクを参照します（»で表示）。nodeはまだ実在しないタスクを宣言します（○、loop_backがある場合は⟲、attributionがpredictedの場合は≈）。afterは同じポリシーの兄弟となる先行タスクに連結します。dagrはこのブロックからのみ、かつ作業中またはブロック中のノードについてのみ、先の作業を表示します。完全なドキュメント： examples/05a-policy-declared.json。

先の作業を実体化する（予測されたラウンドが実際に始まる場合）

policyは現在の意図であり、履歴ではありません。そのまま編集するブロックはこれだけです。履歴はattemptsとeventsにあり、これらは追記専用です。ポリシーは、正確さを保つ予測です。宣言した先の作業が実際のものになったら、1つの候補ドキュメント内で以下をすべて行ってください（その後、チェック → 名前変更）：

1. policy.futuresから、消化された未来ノードを削除します。残しておくと実際の試行のIDと衝突し、チェックで拒否されます。
2. 削除したノードを対象にしていたafterチェーンを修正します。"after": "L1·a2"で連結していた兄弟未来ノードは、タスクに直接連結する（afterを削除する）か、まだ未来のままの別の兄弟に連結します。
3. 未来ノードで予測したIDを持つ実際の試行を追加します。causeはトリガーを指すようにします（ループバックの修正ラウンドでは、失敗した試行を参照するfollowupを指定し、ゲートで差し戻された場合はgate_failedを指定します）。ライブの場合は、ロケーターとライブ状態も指定します。
4. attempt_startedイベントを追加します。それ以前の試行やイベントには決して手を加えないでください。

変更前後のペア。どちらも厳密チェックを通過します： examples/05a-policy-declared.json → examples/05b-policy-materialized.json。

人による判断を記録する

{"at": "...", "type": "directive", "verb": "reject", "by": "operator",
 "task": "L1", "detail": "error paths untested"}

動詞：reject · unblock · answer · rule。指示は判断の記録です。チャットの文章は記録ではありません。

質問に回答する（指示によってタスクを確定する）

依存関係が完了したキュー内の question は、注目キューに needs answer として表示されます。プロデューサーは、これとは別の準備完了フィールドを宣言しません。 指示イベントだけではタスクを確定できません。タスクの状態は試行に基づく射影であるため、人間の回答には、実行者が人間である試行が必要です。両方を同じ候補に記述します。

{"id": "Q1", "title": "question: retry budget?", "kind": "question",
 "owner": "operator", "state": "done", "deps": [],
 "attempts": [{
   "id": "Q1·a1", "n": 1, "cause": {"type": "initial"},
   "actor": "operator", "state": "done",
   "started_at": "2026-02-01T09:40:00Z", "ended_at": "2026-02-01T09:42:00Z",
   "outcome": {"result": "done", "evidence": "reported",
               "receipt": "directive answer: retry budget 2 rounds"}}]}

さらに、次のイベントを追加します。

{"at": "2026-02-01T09:42:00Z", "type": "directive", "verb": "answer",
 "by": "operator", "task": "Q1", "detail": "retry budget 2 rounds"}

レシートには回答を記録し、指示は意思決定ログのエントリーとなります。 同じパターンで、人間が解決したあらゆるタスクを確定できます（question を閉じるブロック解除や、タスクを終了させるルールなど）。完全なドキュメントは次のとおりです。 examples/07-answer-question.json。

オペレーターのメッセージに対応する

ペインのデフォルト操作は、コンテキストに応じたメッセージ作成フォームです。Herdr は、完成したメッセージを run.orchestrator ロケーターに直接キュー登録するため、別の受信トレイデーモンを作成しないでください。次のようなエンベロープを受け取ります。

[DAGR OPERATOR MESSAGE]
message_id: msg-0123456789abcdef
run: run-myjob-v01
revision: 2026-02-01T09:42:00Z
target: G1
starter: get-guidance
authority: recommend_and_return

Ask sol5.6·max and fable·xhigh independently, then combine their opinions.

次の手順を行います。

1. メッセージを確認します。既存の実行スコープ内で、対象として指定されたものに関する指示として、元の文章を扱います。
2. 文章の内容とは独立して権限に従います。 recommend_and_return は分析を行って選択肢を返すことを意味します。 may_decide_and_continue では、自分で決定して処理を続けられます。「最善の推測」といった表現から、後者の権限があると推測してはいけません。
3. モデル、推論、マルチエージェントに関する依頼は、通常の編集可能な指示として扱い、通常のオーケストレーションツールを使用します。dagr はそれらを実行しません。
4. 後続のやり取りでも message_id を保持します。解決時に、次のイベントを追加します。

{"at":"2026-02-01T09:50:00Z","type":"message_resolved","task":"G1",
 "message_id":"msg-0123456789abcdef",
 "detail":"recommended option B after two independent reviews; awaiting operator"}

1つの決定に複数のメッセージが反映されている場合は、指示／解決イベントに source_messages を設定します。messages.jsonl は編集しないでください。追加専用の配信ジャーナルは dagr が管理します。イベントは、そこへ戻るための永続的なプロジェクトメモリへのリンクとなります。

求められた場合に3つのプロンプトスターターをカスタマイズする

オンボーディングの手順はありません。組み込みの「判断する」「ガイダンスを求める」「スヌーズ」はデフォルトで利用できます。ユーザーから操作の追加や変更を求められた場合は、実行ファイルの隣にある actions.json をアトミックに書き込みます。

{
  "version": 1,
  "include_defaults": true,
  "actions": [
    {"id":"architecture-council", "label":"Architecture council",
     "prompt":"Ask two independent architecture reviewers and synthesize.",
     "authority":"recommend"}
  ]
}

各アクションは、事前入力された編集可能なプロンプトと recommend|decide の権限だけで構成されます。リストは小さく保ち、多数の固定的なボタンより、柔軟に使えるスターターを1つ優先してください。組み込みアクションと同じ ID を指定すると、そのアクションが上書きされます。include_defaults: false を指定すると、組み込みアクションが置き換えられます。サポートされる設定形式はバージョン 1 です。表示されるスターターは最大9個、ラベルは最大80バイト、プロンプトは最大32 KiB です。ペインはこのファイルを自動的に再読み込みし、設定が無効または未サポートの場合はバナーを表示します。

以前のトップレベルの実行 actions 値は読み取り可能ですが、機能しません。追加しないでください。

ランタイムを失う

作業の途中でペインが終了しましたか？試行は lost になります（結果は不要）。タスクは failed または blocked に射影されます。試行を削除しないでください。トレースが記録として残ります。

やってはいけないこと

• 試行やイベントの番号を振り直したり、書き換えたり、削除したりしないでください。追記してください。
• herdr のペイン／エージェント ID をタスク ID や試行 ID に含めないでください。これらは設計上変動する locator データです。
• 機械的なレシートなしに verified と宣言しないでください。後から新しいイベントで理由を説明せずに、エビデンスを格上げしないでください。
• herdr の状況認識に基づいてタスク状態を決めないでください（ペインが稼働中 ≠ 作業完了）。herdr が示すのは 場所 であり、契約が示すのは 真実 です。
• 内部のエージェント／ツールの各ステップをすべて記録しないでください。オペレーターが理解、方向付け、検証に必要とする作業を含めてください。
• 「完了率」を手作業で計算しないでください。試行ごとの progress（{"done": 3, "total": 7, "note": "..."}）とタイムスタンプを記録してください。分析はそれらに対するクエリで行います。

フィールドリファレンス

完全なスキーマは dagr リポジトリ内の CONTRACT.md（Schema v3 セクション）にあります。finding コードも同じ場所に記載されています。dagr check --json が認識できないコードを示した場合は、そのメッセージを読んでください。各 finding には、該当フィールドの JSON パスが含まれています。