mlb-decision-logger

MLB Decision Logger

目次

• 例
• ワークフロー
• 一般的なパターン
• ガードレール
• クイックリファレンス

例

シナリオ：2026-04-17 の朝のブリーフィングで、3 つのエージェントが一斉に動作します。各エージェントは判断ペイロードをこのスキルに渡します。2026-04-21（月曜日）、コーチは金曜日のラインアップ判断についてキャリブレーションを実行します。

手順：

1. mlb-lineup-optimizer が Junior Caminero の先発／ベンチ判断を送信します。
2. mlb-waiver-analyst が先発 2 回のストリーマーに対する FAAB の入札を送信します。
3. mlb-streaming-strategist がストリーミング獲得選手を送信します。

スキルの動作：

• tracker/decisions-log.md の現在の末尾を読み込みます。
• 同じ日付、同じ種類のエントリーを数えて増分し、decision_id を自動で割り当てます（2026-04-17-lineup-01、2026-04-17-waiver-01、2026-04-17-stream-01）。
• 各ペイロードを context/frameworks/decision-log-format.md のスキーマに照らして検証します。
• タイムスタンプ順に、1 件ずつエントリーを追記し、書き込みのたびに末尾を再読み込みします。
• 呼び出し元のエージェントに割り当てた decision_id を返します。

月曜日のキャリブレーション（2026-04-21）：

• will_verify_on <= 2026-04-21 で、outcome_recorded_on が空のすべてのエントリーを読み込みます。
• 各エントリーについて、エージェントがウェブ検索で結果を調べ、その結果をこのスキルに渡します。
• スキルは対象エントリーをその場で編集し（3 つの結果フィールドのみ）、tracker/variant-scoreboard.md の該当行を増分します。
• 直近の検証済み判断 20 件について、支持／批判の件数を用いて、エージェントごとに tilt を再計算します。

手順 1 で追記された記入例：

### 2026-04-17T08:30:00Z | lineup | mlb-lineup-optimizer
- **decision_id:** 2026-04-17-lineup-01
- **recommendation:** START Caminero at 3B
- **signals_in:** caminero.daily_quality=78 (matchup=85, form=72, opportunity=80)
- **variants:**
    - advocate -> "Start: strong matchup vs RHP, hitter-friendly park, batting 3rd"
    - critic -> "Sit: 0-for-12 last 3 games, BABIP-driven regression due"
- **dialectical_synthesis:** Advocate wins -- matchup+opportunity outweigh slump. Confidence 0.72.
- **red_team_findings:**
    - severity: 2, likelihood: 3, score: 6, note: "MIA rain watch", mitigation: "Check 1pm forecast"
- **confidence:** 0.72
- **will_verify_on:** 2026-04-18
- **outcome_recorded_on:**
- **outcome:**
- **variant_that_was_right:**

月曜日のキャリブレーション後、最後の 3 つのフィールドが入力されます。mlb-lineup-optimizer のスコアボード行では、Total decisions、Advocate correct（1 打数 4 安打で RBI も記録した場合に成功としてカウント）、Synthesis correct が増分され、Tilt が再計算されます。

ワークフロー

このチェックリストをコピーし、呼び出しごとに進捗を記録してください。

Decision Logger Progress:
- [ ] Step 1: Determine mode (append vs calibrate)
- [ ] Step 2: Read current log tail
- [ ] Step 3: Validate payload against schema
- [ ] Step 4: Serialize write (append or in-place edit)
- [ ] Step 5: Update scoreboard (calibration mode only)
- [ ] Step 6: Return decision_id and confirmation

ステップ 1：モードを判定する

サポートされているモードは 2 つです。呼び出しごとに、実行されるのは必ずどちらか 1 つです。

• append -- 呼び出し元のエージェントが完全な判断ペイロードを渡します。スキルは新しいエントリーを作成します。
• calibrate -- 呼び出し元のエージェントが既存の decision_id と結果フィールドを渡します。スキルはそのエントリーを直接編集し、スコアボードを更新します。

完全な判断フローについては、resources/methodology.md を参照してください。

ステップ 2：現在のログ末尾を読む

書き込みの直前には、必ずログを再度読み込んでください。これにより、実際のファイルロックを使わずに、並列エージェントによる同時書き込みを直列化できます。

• tracker/decisions-log.md の末尾約 80 行を読みます。
• 最後のエントリーのタイムスタンプと decision_id を解析します。
• この呼び出しが開始されてから別のエージェントが書き込んでいる場合は、今日使用された新しい decision_id 番号を記録します。

完全な直列化プロトコルについては、resources/methodology.md を参照してください。

ステップ 3：スキーマに照らしてペイロードを検証する

すべての必須フィールドを確認します。欠落または形式不正のフィールドがある場合は、拒否し（書き込まず）、処理を中止します。正式なスキーマは context/frameworks/decision-log-format.md にあります。resources/template.md はその内容を一字一句そのまま反映しています。

• timestamp_iso8601 は UTC の ISO 8601 形式（YYYY-MM-DDTHH:MM:SSZ）です。
• decision_type は列挙型のいずれかです：lineup | waiver | stream | trade | category-plan | playoff-push | add-drop | ad-hoc。
• emitted_by は既知のエージェント名です。
• recommendation は動作を表す動詞で始まります（START、SIT、ADD、DROP、BID $X、ACCEPT、COUNTER、REJECT、STREAM、HOLD）。
• signals_in は、少なくとも 1 つのシグナルを名前で参照しています。
• variants には advocate と critic の両方のエントリーがあります（または、ブートストラップ用に明示的に n/a と記載されています）。
• confidence は [0.00, 1.00] の範囲です。
• will_verify_on は日付、end of week N、または end of season です。
• calibrate モードの場合：outcome は {happened, did not happen, partial} のいずれかで、variant_that_was_right は {advocate, critic, both, neither} のいずれかです。

ステップ 4：書き込みを直列化する

• append：{YYYY-MM-DD}-{decision_type}-{NN} の形式を使って decision_id を割り当てます。NN は同じ日の同じタイプの最後のインデックス + 1 とし、2 桁になるようゼロ埋めします。書式化したエントリーと末尾の区切り行を追加します。
• calibrate：decision_id で対象エントリーを特定し、3 つの結果フィールドのみを置き換え、それ以外はバイト単位で完全に保持します。
• ファイル全体を上書きしないでください。エントリーを並べ替えないでください。3 つの結果フィールド以外のフィールドを編集しないでください。

書き込みプロトコルについては、resources/methodology.md を参照してください。

ステップ 5：スコアボードを更新する（キャリブレーションモードのみ）

• tracker/variant-scoreboard.md を読みます。
• エントリーの emitted_by エージェントに該当する行を探します。
• Total decisions を 1 増やします。
• Advocate correct、Critic correct、またはその両方を（variant_that_was_right = both の場合）1 増やします。合成された推奨が実際の結果と一致した場合は、Synthesis correct を増やします。
• resources/methodology.md のルールに従って Tilt を再計算します。
• 更新した表を書き戻します。ほかのテキストはすべて変更しないでください。

ステップ 6：decision_id と確認を返す

• 割り当てた decision_id（append）またはキャリブレーションしたフィールドの確認（calibrate）を返します。
• 検証に失敗した場合は、フィールド名と理由を含む構造化エラーを返し、書き込みは行いません。
• resources/evaluators/rubric_mlb_decision_logger.json を使って最終出力を検証します。最低基準：平均スコア 3.5 以上、各評価項目は 2 未満にならないこと。

共通パターン

パターン 1：エージェントによる並列追記（朝のブリーフィング）

コーチは、lineup-optimizer、waiver-analyst、streaming-strategist を 1 回の実行で起動します。それぞれがバリアントのペアを完成させ、統合したうえで、このスキルを呼び出します。スキルは到着順に処理し、書き込みのたびにログの末尾を読み直して、タイプごとに一意の decision_id を割り当てます。

パターン 2：月曜日のキャリブレーション

コーチはログを開き、will_verify_on <= today かつ outcome_recorded_on が空のエントリーを絞り込み、それぞれについて結果をウェブ検索し、キャリブレーション用ペイロードを作成して、このスキルを calibrate モードで呼び出します。呼び出しごとに 1 つのエントリーを編集し、スコアボードの 1 行を更新します。

パターン 3：トレードの判断（オンデマンド、検証は後日）

トレードのオファーが届くと、mlb-trade-analyzer が起動します。判断は REJECT、ACCEPT、または COUNTER です。トレード価値は数週間かけて明らかになるため、will_verify_on は通常、end of week N または end of season です。スキルは通常どおりログに記録し、検証日が来るまではキャリブレーションキュー上でトレードを「オープン」のままにします。

パターン 4：初期設定／アドホックなエントリー

チームの初期設定やメタ判断（重み付けの変更、フレームワークの修正）では、decision_type = ad-hoc または bootstrap、variants = n/a、variant_that_was_right = neither とします。スキルはこれを特殊な形式として受け付けます。

ガードレール

1. 追記のみです。 ログを書き換えてはいけません。エントリーの順序を入れ替えてはいけません。既存のエントリーに対して許可されている編集は、キャリブレーション時に 3 つの結果フィールドを埋めることだけです。それ以外の変更はバグです。

2. 書き込みの前に必ず読み直します。 並列エージェントは 1 つのファイルを共有します。書き込み直前に末尾を読むことで、書き込みを直列化します。実行中の以前の時点で読んだ末尾をキャッシュしてはいけません。

3. 書き込み前に検証します。 形式の不正なエントリーは、後続のキャリブレーションに悪影響を及ぼします。構造化エラーを返して拒否し、不完全な書き込みや不足フィールドの自動修正を試みてはいけません。

4. decision_id は決定的です。 同じ日、同じタイプの場合は、連番の NN を使います。別のエージェントがすでに 2026-04-17-lineup-01 を使っている場合、このエージェントには 02 を割り当てます。ID を再利用してはいけません。

5. 結果フィールドの編集は最小限にします。 結果フィールドを埋める際は、対象となる 3 行のみを置き換えます。タイムスタンプ、decision_id、推奨事項、バリアント、統合内容、レッドチーム、信頼度、will_verify_on は 1 バイトも変更せず保持します。書き込みのために再フォーマットが必要なら、手順を誤っています。

6. スコアボードの更新は、判断ごとに冪等です。 各 decision_id が加算する行数は、必ず 1 行です。キャリブレーションの呼び出しが再試行された場合は、エントリーにすでに outcome_recorded_on が入力されているかを再確認し、入力済みなら二重にカウントしてはいけません。

7. 傾向の判定にはサンプル数が必要です。 エージェントの Total decisions < 10 の場合は neutral と報告します。サンプル数とマージンの両方が基準を満たした場合に限り、advocate+／critic+ に切り替えます。正確なしきい値については、resources/methodology.md を参照してください。

8. エージェントがログに直接書き込むことはありません。 MLB の各エージェントは、必ずこのスキルを経由します。コーチがこのスキルによって作成されていない形式不正のエントリーを見つけた場合は、バグとして扱い、tracker/calibration-review.md に記録します。

クイックリファレンス

モードの入力：

• append で必要：timestamp_iso8601、decision_type、emitted_by、recommendation、signals_in、variants (advocate + critic)、dialectical_synthesis、red_team_findings、confidence、will_verify_on。
• calibrate で必要：decision_id、outcome_recorded_on、outcome、variant_that_was_right。

decision_id の形式：

{YYYY-MM-DD}-{decision_type}-{NN}
e.g., 2026-04-17-lineup-01

傾向の閾値（エージェントごとの、直近20件の検証済み判断）：

条件	傾向
検証済みの合計が10未満	neutral
Advocateの正解率がCriticを10～20パーセントポイント上回る	advocate+
Advocateの正解率がCriticを20パーセントポイント以上上回る	advocate++
Criticの正解率がAdvocateを10～20パーセントポイント上回る	critic+
Criticの正解率がAdvocateを20パーセントポイント以上上回る	critic++
差が10パーセントポイント以内	neutral

変更対象ファイル：

• yahoo-mlb/tracker/decisions-log.md（追記、または結果フィールドの必要最小限の編集）
• yahoo-mlb/tracker/variant-scoreboard.md（行の更新、傾向の再計算）
• yahoo-mlb/tracker/calibration-review.md（高い確信度の判断が誤っていた場合にのみ記録）

読み取り対象ファイル：

• yahoo-mlb/context/frameworks/decision-log-format.md（記録のスキーマ）
• yahoo-mlb/tracker/decisions-log.md（末尾部分。シリアライズとIDの割り当てに使用）
• yahoo-mlb/tracker/variant-scoreboard.md（較正の更新に使用）

主なリソース：

• resources/template.md：decision-log-format.md に準拠した正確なエントリー形式。
• resources/methodology.md：追記プロトコル、較正プロトコル、同時実行の処理、傾向の再計算、作業例のログシーケンス。
• resources/evaluators/rubric_mlb_decision_logger.json：8項目の品質評価基準。

必須入力：

• 呼び出し元のエージェントから（追記）：上記の完全な判断ペイロード。
• 呼び出し元のエージェントから（較正）：decision_id と検証済みの結果フィールド。

生成される出力：

• 追記モード：割り当てられた decision_id と、エントリーがログに記録されたことの確認。
• 較正モード：更新されたエントリーと、変更されたスコアボードの行の確認。
• 検証に失敗した場合：構造化されたエラー（フィールド名、理由、不正な値）。書き込みは行われません。