simmer-reflect

Simmer Reflect

完全なスコア履歴を確認できる唯一のサブスキルです。反復を記録し、最良の候補を追跡して、ASI を次に引き継ぐのが役割です。

受け取るコンテキスト

• 完全なスコア履歴：これまでのすべての反復（スコア、複合スコア、主な変更点）
• 現在の反復番号と最大反復回数
• 最新の評価者出力：このラウンドのスコアと ASI
• ジェネレーターのレポート：このラウンドでの変更内容（2〜3 文）
• 成果物の種類：単一ファイルまたはワークスペース

作業内容

1. Trajectory に記録する

{OUTPUT_DIR}/trajectory.md を更新して、スコア表を記録します。

評価モード（評価者のみ、実行可能、ハイブリッド）にかかわらず、Trajectory の表は同じ形式を使います。 評価者の生出力、テストケースごとの内訳、表内の分析は記載しないでください。表にはスコアの記録のみを簡潔に記載します。

必須形式（以下に記載した列以外は追加しないでください）：

単一ファイルモード：

• 列：Iteration、[ルーブリックの評価基準名]、Composite、Key Change
• 表の下：Best candidate: iteration [N] (composite: [N.N]/10)

# Simmer Trajectory

| Iteration | [criterion 1] | [criterion 2] | [criterion 3] | Composite | Key Change |
|-----------|---------------|---------------|---------------|-----------|------------|
| 0         | 4             | 5             | 3             | 4.0       | seed       |
| 1         | 7             | 5             | 4             | 5.3       | [summary]  |
| 2         | 7             | 6             | 7             | 6.7       | [summary]  |

Best candidate: iteration 2 (composite: 6.7/10)

ワークスペースモード：

• 列：Iteration、[ルーブリックの評価基準名]、Composite、Config、Key Change
• 「Config」列には、ワークスペースの主要な状態（モデル名、トポロジーなど）を数語で記載します
• 表の下：Best candidate: iteration [N] (composite: [N.N]/10)

# Simmer Trajectory

| Iteration | Coverage | Efficiency | Noise | Composite | Config | Key Change |
|-----------|----------|------------|-------|-----------|--------|------------|
| 0         | 2        | 6          | 2     | 3.3       | qwen3.5:4b, single-call | seed |
| 1         | 4        | 4          | 4     | 4.0       | qwen3.5:27b, single-call | model swap + rich prompt |
| 2         | 3        | 5          | 3     | 3.3       | qwen3.5:9b, single-call | REGRESSION — 9b too weak |

Best candidate: iteration 1 (composite: 4.0/10)

評価者の詳細がコンテキストとして重要な場合は、表の下に別のセクションを追加します。

## Evaluator Details

### Iteration 1
- Video ozXhzdjT8tU: 54% coverage (23/43 matched)
- Video DRqUWtnXEXA: 48% coverage (15/31 matched)
- Missed: [list of key misses]

表自体は簡潔に保ちます。評価者の詳細は補足情報であり、Trajectory の記録には含めません。

「Key Change」列には、ジェネレーターの 2〜3 文のレポートを数語（60 文字未満）に要約して記載します。反復 0（シード）の Key Change は必ず「seed」とします。

2. 最良の候補を追跡する

今回の反復のスコアを、これまでの最良スコアと比較します。Trajectory の末尾にある「Best candidate」の行を更新します。

セットアップブリーフで PRIMARY 評価基準が指定されている場合： まず主要評価基準のスコアで最良候補を決め、同点の場合は複合スコアで比較します。例：「coverage」が主要評価基準で、反復 2 の coverage が 6（複合スコア 5.3）、反復 4 の coverage が 5（複合スコア 6.0）の場合、最良候補は反復 2 です。

主要評価基準が指定されていない場合： 複合スコアで最良候補を決めます（デフォルト）。

最良の候補が最新の反復とは限りません。 反復 3 のスコアが反復 2 より低い場合、最良候補は引き続き反復 2 です。

2b. 回帰に対処する

今回の反復の複合スコアがこれまでの最良スコアを下回る場合：

• Trajectory の Key Change 列に回帰を記載します（例：「REGRESSION — 9b が弱すぎる」や「回帰 — プロンプトの圧縮で型の表が失われた」）
• 次のジェネレーターには最新の候補ではなく、最良の候補と現在の ASI を渡すよう、オーケストレーターに指示します
• 出力に次を含めます：REGRESSION: true — use iteration [N] as input to next generator

ワークスペースモードでの回帰： オーケストレーターは、最良の反復のコミットからワークスペース内のファイルを選択して復元します（git checkout <commit> -- <files>）。Trajectory.md やその他の追跡用ファイルは復元されません。オーケストレーターが復元するスナップショットを特定できるよう、反復番号を含めてください。

3. 探索状況を追跡する（ワークスペースモード）

セットアップブリーフに SEARCH_SPACE が含まれている場合、Trajectory を確認して、探索済みの項目と未探索の項目を特定します。Config 列と Key Change 列から、以下を確認します。

• 試したモデル
• 試したトポロジー
• その他、探索済みの探索空間の要素

簡潔な探索状況の要約を作成します。例：

Models tried: qwen3.5:4b (iter 0), qwen3.5:27b (iter 1-3). Untried: qwen3.5:9b.
Topologies tried: single-call (all iterations). Untried: multi-call.
Prompt changes: 4 variations tried.

テキスト／クリエイティブモードの場合、または探索空間が指定されていない場合は省略します。

4. 安定して効果を発揮している要素を追跡する

推移を確認して、一貫して機能しているもの、つまり以前の反復で追加されて以来、後退との関連が見られない要素を特定します。

反復ごとの変更点列を確認します。ある要素が反復 N で導入され、反復 N+1、N+2 などを通じてスコアが維持または向上している場合、それは安定して効果を発揮している要素です。その要素を削除または変更した反復で後退が起きた場合、それが重要な役割を果たしている強力な証拠になります。

簡潔なリストを作成します。例：

STABLE WINS (do not remove):
- Correction lookup table (added iter 1, held through iters 2-4)
- Worked examples format (added iter 3, improved coverage each iteration since)

NOT WORKING:
- Verbose rule lists (tried iter 2, regressed)
- Multi-step prompt structure (tried iter 1, skipped by executor)

これは審査ボードの審議サマリーに渡され、審査員とジェネレーターが何を維持し、何を避けるべきかを把握できるようにします。

5. ASI を引き継ぐ

オーケストレーターに以下を返します。

• 今回のラウンドの審査員による ASI（変更せずに次のジェネレーターへ渡すもの）
• 現時点で最良の候補が含まれる反復
• 残りの反復があるかどうか
• 後退が発生したかどうか（発生した場合は、入力として使用する候補）
• 探索状況（検索空間のみを使うワークスペースモード）
• 安定して効果を発揮している要素（機能しているもの、機能していないもの）

オーケストレーターへの出力

ITERATION [N] RECORDED
BEST SO FAR: iteration [N] (composite: [N.N]/10)
REGRESSION: [true/false] — [if true: use iteration N as input to next generator]
ITERATIONS REMAINING: [N]
ASI FOR NEXT ROUND: [the judge's ASI, unchanged]
EXPLORATION STATUS: [what's been tried vs untried — omit for text/creative or no search space]
STABLE WINS: [what's working — do not remove]
NOT WORKING: [what's been tried and failed — do not retry same approach]

よくある間違い

評価器の出力を推移テーブルに書き込む

• 問題：テーブルが読みにくくなり、標準形式から外れ、実行間の比較ができなくなります。
• 対処：テーブルには標準の列形式を使用します。評価器の詳細はテーブルの下に別のセクションとして記載します。

ASI を変更する

• 問題：審査員の ASI を渡す前に編集を反映したり、要約したりします。
• 対処：ASI は変更せずにそのまま渡します。審査員はジェネレーター向けに記述しています。

これまでの最良候補を別に追跡しない

• 問題：最後の反復が最良だと思い込んでしまいます。
• 対処：常に合成スコアをこれまでの最良スコアと比較し、上回った場合は更新します。

候補の内容を推移に書き込む

• 問題：推移ファイルが膨大になり、コンテキストが煩雑になります。
• 対処：推移にはスコア、合成スコア、簡潔な変更点の要約のみを記載します。

テーブルではなく文章形式を使う

• 問題：段落や箇条書きで書かれた推移は、すばやく確認できません。
• 対処：評価器を使うワークスペースモードでも、必ず上記の Markdown テーブル形式を使用します。