評価資料¶

English | 日本語

evaluations/ は、現在の利用先が必要とするレビュー済みの入力と選別した証拠を保持します。モデル別・実行別の履歴倉庫にはしません。この方針の所有者はリポジトリの source maintainer です。 Issue #1011 に選択肢と初回のファイル別判断を記録しています。

Ownership and lifecycle¶

evaluations/lifecycle.json が、評価分野（family）ごとの所有関係をまとめる唯一のカタログです。保持する資料は、それぞれ一つの family と lifecycle に属します。family は目的、所有者、更新契機、廃止条件を記録し、各資料は実際の利用先を記録します。利用先は既存のテスト、スクリプト、fixture の入力・ツール、または明示した手動評価・履歴レビューの担当契約です。カタログや source inventory に掲載されるだけでは利用先になりません。

Lifecycle	目的と正本	更新・廃止
`forward-fixture`	現在の評価契約を検証するシナリオ。評価者の期待値を agent input から分離し、自動テストがなければ手動評価を明示します。	契約や失敗シナリオの変更時に既存 family を拡張します。利用先と固有シナリオを確認してから廃止します。
`regression-fixture`	現行テストが使う代表入力や固定版の互換性ツール。lockfile は package 宣言から生成され、独立した手書きの結果ではありません。	利用する動作や明示的に選択した互換性バージョンと同時に更新し、入力・ツール・lock の関係を維持します。
`current-baseline`	report や比較が現在選択する family ごとに一つの baseline。取得日と不明値は過去の事実であり、新しい測定値ではありません。	比較可能な証拠をレビューし、利用先と同時に置換します。必要な固有の過去資料は別に保護します。
`immutable-history`	元の来歴・歴史的意味を必要とする明示的な利用先がある、選別済みの観測や廃止済みシナリオ。各ファイルに個別の保持理由が必要です。	現在の動作に合わせて観測を書き換えません。全利用先と固有の証拠の扱いを確認してから廃止し、現行 benchmark 入力やモデル選択表には使いません。

カタログは証拠を分類し、元の資料が観測内容と schema の正本を持ちます。既存資料内の履歴宣言とも一致させます。ハッシュ付き source inventory が source の完全性・ハッシュ・package identity を引き続き所有し、カタログにハッシュを重複保存したり配布権限を与えたりしません。評価用ツールと依存関係は配布 Plugin の外に置きます。

生成された比較結果は、current baseline または immutable history として明示的に選択するまで一時出力です。既存の一時・Git 対象外の出力先、または CI が所有する artifact store を使います。生の transcript、provider payload、全試行、別のモデル一覧をこのディレクトリへ蓄積しません。

Extend a family before adding a file¶

新しいシナリオは既存 family の入力へ追加します。モデルやバージョンを繰り返し比較する場合も、一つの family の比較にまとめ、選択した観測の元の identity と限界を維持します。履歴ファイルを別に増やす理由は、独立した利用先と来歴を守る具体的な必要性です。モデル名、日付、追加実行だけでは理由になりません。historical_fidelity にその理由を記録します。

既存の execution-economics のモデル観測二件は一つの family にまとめますが、元の名前と内容を維持します。一方は利用不能なモデルの無断置換をしなかった証拠、もう一方は実効 identity と費用が不明な二件の bounded-inference 観測です。schema、来歴、既存の回帰テスト用途が異なるため、内容の統合は runtime dependency を減らさず証拠を書き換えてしまいます。日付付きの calibrated-delegation 比較と DESIGN.md research snapshot も同じ基準で保護します。

measurement-cases.json は、廃止した #79 の仕組みと PR #649 での除去を検討する maintainer の履歴レビューだけに保持します。現在の自動テストや benchmark の利用先はありません。次にこの family を変更するとき、元の五つのシナリオを Git・Issue の保存済み履歴と比較してから削除を提案します。定期実行や測定収集を再導入する権限を与えるものではありません。

Growth review¶

数値のレビュー閾値はカタログが所有し、検証器が現在の資料数、byte 数、family 数、lifecycle 別件数を報告します。どちらかの閾値を超えた candidate は、受け入れる前に family と利用先をレビューします。初期閾値には確認済み baseline に対して四ファイルと、既存の最大 fixture 約一件分の byte 増加を許容しています。これはこのリポジトリのレビュー契機であり、普遍的なサイズ制限、実行ごとの保持枠、自動削除の許可ではありません。

影響する family だけを確認し、来歴を損なわず統合できる入力をまとめるか、追加証拠が必要な理由を説明します。レビュー済み変更で閾値を更新する場合は、実測 inventory と根拠を Issue/PR に残します。検証器は閾値を自動更新しません。既存ファイル内の増加も確認対象です。閾値未満でも、履歴を分割して追加する場合は個別の保持理由が必要です。

Lifecycle validation¶

目的は、不完全な所有関係や履歴の誤った現行入力化を拒否し、既存の証拠を保持することです。実装は scripts/evaluation_lifecycle.py です。source inventory の Git path projection と安全なファイル解決を再利用し、別の hash index を作ったり、宣言された利用先を実行したりしません。

不変条件: カタログ自身を除く全 tracked 評価資料に、一意の family/lifecycle、役割が一致する解決可能な tracked 利用先、完全な所有者情報が必要です。未追跡の評価 source、競合する current baseline、履歴と現行の宣言不一致、安全でないパスを拒否します。履歴の利用先は回帰テストまたは履歴レビューに限定し、 runtime routing は許可する役割に含めません。ただし、宣言した利用先が実際に証拠を使うこと、未宣言の動的 loader が履歴を現行入力化しないことは semantic review でも確認します。存在と役割だけの検査でそれらを実証したとは扱いません。

数値境界: カタログは最大 128 KiB、64 family、512 artifact、資料ごとに32 consumer、説明値はそれぞれ最大2,000文字です。一回の呼び出しは既存の上限付き Git inventory 読取と一回のカタログ走査を使い、 model/provider API 呼び出し、インストール、削除、資料の書換え、自動再試行、背景処理はゼロです。入力サイズ境界とカタログの増加レビュー閾値は別のものです。

失敗時の封じ込めと証拠: 不正・未知の入力、identity 重複、利用先やファイルの欠落、曖昧な lifecycle、 symlink パスは非ゼロ終了と短い診断を返します。増加時は実測値と契機名を含む review_required、成功時は同じ集計値を含む valid を返します。benchmark 成功、モデル選択、削除許可、長期的な増加抑制の実証を意味しません。

権限と復旧: 検証は読取専用です。該当宣言を修正するか、Git から欠けた証拠を復元するか、通常のレビュー済み移行を行って再実行します。固有の証拠や利用先の扱いが未確定なら廃止を止めます。削除コマンドや経過日数による自動失効はありません。追加したカタログ・検査・方針を revert すれば、過去の内容や provider state を変えず元の source layout に戻せます。

互換性と移行: 初回は既存の全資料を byte 単位で維持します。正確な保持パスはカタログの各 entry、集約する情報は family metadata、移動・廃止・削除するパスは空です。後の移行は保持・集約・廃止する正確なファイルを Issue/PR に列挙し、全利用先と固有観測を扱って source inventory とテストを同時に更新します。来歴不明は削除を止めます。glob で削除対象を選んだり、カタログ entry がないことを使い捨て可能の根拠にしたりしません。

受け入れテストは実際の一時ファイルと Git inventory を使い、有効な分類、未分類・欠落した証拠、欠落・危険な利用先、所有重複、履歴の現行入力化、増加契機を検証します。リポジトリ全体のカタログも通常の test discovery で検証するため、required と CI で model や external API を呼ばず実行できます。既存 consumer test が動作の検証を引き続き所有し、カタログ検証で置き換えません。

python3 scripts/evaluation_lifecycle.py

source inventory の生成と最終カタログ検証の前に、正確な新規 source path を stage します。どちらも未追跡 source の漏れを意図的に拒否します。レビューは documentation の公開、Plugin のインストール、release authority の変更を伴いません。

Historical candidate classification¶

目的と権限: source maintainer は scripts/quality_pr_preflight.py で限定的な履歴資料の設計分類を行います。local pre-push と hosted design step は同じ判定を使います。portable Plugin validator は任意の material negative 宣言を引き続き拒否します。既存 evaluation lifecycle owner がこの repository の catalog 変換を検証するもので、手動 review の迂回や新しい Plugin capability ではありません。

不変条件: exact base/head diff が追加できるのは Markdown の immutable-history 資料と catalog 登録、それに伴う documentation と正確な generated source inventory だけです。既存 family の field と artifact entry、schema、growth limit、owner、 consumer authority は変更できません。新 family は既存 owner を使い、追加資料は登録済み historical-review consumer を使います。既存評価資料の内容は変更できません。通常の catalog completeness/growth 検証と source inventory の path/hash 検証を通過する必要があります。正確な generated projection だけの有効な変更も対象です。

検証対象の tracked working file の内容は要求された head と一致しなければなりません。異なる merge checkout はこの例外の証拠にならず、candidate の更新か一致する checkout が必要です。unknown、malformed、untracked、rename/delete、非履歴、wrong-path、実行コードや configuration の混在は review_required を保持します。positive 分類は従来の source/reference/failure-test chain を使います。

上限と観測証拠: 1 request が調べるのは 1 base/head pair、最大 512 changed paths です。catalog の既存 byte/family/artifact 上限を維持し、provider effect、retry、 source write、自動承認はすべてゼロです。受理した negative は revision/diff identity を保持し、理由 historical_evaluation_addition または generated_source_projection を返します。履歴資料は実行権限、product success、release acceptance ではなく、通常の semantic review と exact-head hosted gate は引き続き必要です。

復旧と互換性: exact evidence を修正し、同じ source-owned gate を再実行します。 input schema、永続状態、Plugin runtime の移行はありません。rollback はこの source composition を除き review に戻すもので、証拠の書換えや portable gate の迂回は行いません。実際の Git candidate test が履歴追加、projection-only、owner/retention/ 既存 entry の変更、stale/malformed evidence、configuration 混在、従来の positive 分類を検証します。local/hosted entry point は同じ classifier を使います。

薄い信頼性レイヤの比較¶

#1122 を再検討する保守担当者は、選択された過去の比較記録で7案の違い、実ソース・仮想ケースでの判断結果、新しいPluginレイヤを採用しなかった理由を確認します。各案8件の結果は実運用の成果ではありません。コマンド回数はエージェントの自己申告であり、所要時間とホストを含む全コンテキスト量は未計測です。構造情報、判断原則、フック、反例生成を再検討するときも、この限界を保持してください。実験用ランタイムや新しいSkillの必須規範は残していません。