preservation-verifier

Preservation Verifier

リライトまたはファイル編集によって、元の ../avoid-ai-writing/SKILL.md が保護するよう指定している内容が維持されたかを検証します。

Skill をまたぐ作業では、../avoid-ai-writing-router/references/handoff-contract.md と ../avoid-ai-writing-router/references/skill-graph.json に従ってください。

接続契約

入力

次の経路から、変更前と変更後の検証を受け付けます。

• ユーザーが変更前と変更後の内容を直接提供する場合は、ROUTE を通じて avoid-ai-writing-router から受け取ります。
• 返却されたテキストのリライト後は、VERIFY を通じて voice-preserving-rewriter から受け取ります。
• 許可された指定ファイルの変更後は、VERIFY を通じて file-edit-in-place から受け取ります。

元のバージョンと現在のバージョンの両方が必要です。どちらかが利用できない場合は、比較を捏造せず、ルーターに制御を戻してください。

出力

引き継ぎエンベロープを次の内容で更新します。

• execution_evidence.verifier：同梱のバリデーターを実行した場合に限り executed、それ以外は model_only。
• verification_summary.status：PASS、REVIEW、または FAIL。
• ブロッキングエラーと警告。
• 修復可能な場合は、修復対象を正確に指定します。

FAIL はワークフローをブロックする結果です。テキストが生成された、またはファイルへの書き込みが成功しただけでは、リライト／編集の段階は完了していません。

出力先

• 返却テキストが保持に失敗し、共有編集予算に余裕がある場合は、REPAIR を voice-preserving-rewriter に送ります。
• 指定ファイルが保持に失敗し、共有編集予算に余裕がある場合は、REPAIR を file-edit-in-place に送ります。
• 収束確認または残存要素の監査がユーザーの依頼に含まれている場合に限り、RECHECK を ai-writing-detector に送ります。
• PASS で、ユーザーが依頼した後続段階がない場合は終了します。
• 2 回目の検証にも失敗した場合は、終了して報告します。修復ループを再度開始してはいけません。

アーキテクチャと実装の観点

../avoid-ai-writing-router/references/agency-role-lenses.md に記載された両方の観点を適用してください。

• agency-software-architect：検証は、明確な責任分担と上限のある修復サイクルを備えた境界ゲートです。
• agency-senior-developer：実行の主張には実際のコマンド実行の証拠が必要です。エラーは伝播させ、変更前後の状態が正しい対象に帰属するようにします。

検証担当者は、自らコンテンツを書き換えません。

推奨する決定論的な方法

同梱の scripts/validate.js は、ソースリポジトリの保持バリデーターと完全に同一です。Node を実行できる場合は、次を実行してください。

node scripts/validate.js --residual-policy warn before.md after.md

プログラムから使用する場合：

const { validate } = require("./scripts/validate.js");
const result = validate(original, rewritten, { residualPolicy: "warn" });

編集内容の検証には、明示的な warn 残存要素ポリシーを使用します。バリデーターは、機械的な preservation の結果と quality の診断を分けて提示しつつ、トップレベルのエラー、警告、統計情報も保持します。残存要素の増加は警告として見える状態にします。これはコンテンツが損なわれた証拠ではなく、それだけで修復を許可するものでもありません。品質チェックがスキップされた場合、利用できない場合、またはスコアが付けられていない場合は、残存要素の監査が問題なく完了したことにはなりません。このバリデーターは、意味の変更がユーザーの明示的な修正指示に基づくものか、通常は保護される範囲の編集をユーザーが特別に許可したかを判断しません。現在のホストで実行していない限り、実行したと主張してはいけません。

実行できない場合は、同じ保持契約に基づいて元の内容とリライト後の内容を手作業で比較し、結果に model_only とラベル付けしてください。

追加の保護対象制約

正規バリデーターによる構造チェックに加えて、正規編集契約に基づくセマンティックレビューを別途実施してください。意味、帰属、数量と単位、否定、条件、因果関係、不確実性、話者の経験が維持されているか確認してください。明示的なユーザー修正は、創作ではなく意図された変更として扱ってください。ユーザーが通常は保護対象となる範囲を明示的に変更対象にした場合は、要求された変更を確認しつつ、そのデータと帰属は引き続き保護してください。一般的な整理、文体、または語調の変更要求から、変更の許可を推測してはいけません。このレビューはモデルのみで実施したものとして報告し、決定論的バリデーターが実施したと主張しないでください。

human_representation_sensitive: true の場合は、agency-inclusive-visuals-specialist の観点から、保護対象となるアイデンティティと表現の詳細を確認してください。構造的に有効な書き換えでも、文化、地理、障害、服装、肌の色・照明、身体的現実、反ステレオタイプに関する重要な制約が消去または一般化されている場合、REVIEW または FAIL が必要になることがあります。

決定論的バリデーターが実装していないセマンティック表現の詳細を確認したと主張してはいけません。その部分は、モデルのみで実施したセマンティックレビューとして別途報告してください。

結果の扱い

PASS

ブロック対象となる機械的な保持エラーが見つからず、未解決の警告やセマンティック上の懸念も残っていません。ユーザーが残存分析を要求した場合、PASS には quality.status: checked も必要です。数値表記に関する警告を解決済みでも、skipped、unavailable、または unscored であれば REVIEW が必要です。これはセマンティックな忠実性を証明するものではありません。別途要求された段階が残っている場合に限り、続行してください。

REVIEW

警告またはセマンティックな変更について判断が必要ですが、自動的にブロック対象となるわけではありません。number-added、number-missing、residual-grew を、ソースと文脈に照らして確認してください。数値表記の変更は正当な場合があります。必須の監査で残存分析が利用できない、または未採点の場合は、不完全であると報告してください。通常は保護対象となる内容について、明示的に要求された編集に対応するバリデーター上の差異も含まれます。これを自動的に元に戻すのではなく、要求範囲と、引き続き適用されるデータおよび帰属の制約に照らして確認してください。具体的な不確実性を説明してください。

FAIL

保護対象の内容が変更または削除されています。ソースの種類に応じて、適切な修復担当を特定してください。

• 返却されたテキスト -> voice-preserving-rewriter
• 名前が指定されたファイル -> file-edit-in-place

ブロック対象の修復範囲と既存のエンベロープのみを渡してください。問題のない部分までやり直すよう修復担当に依頼してはいけません。pass.index が pass.max に達している場合は、追加の変更を要求せず、未解決の失敗として報告してください。

修復ループの上限

修復による再実行は最大 1 回のみ許可され、要求された編集予算に余裕がある場合に限ります。修復には次の編集パスを使用します。検証自体はパスを消費しません。修復後はもう一度だけ検証してください。その確認でも失敗する場合は、停止して未解決のエラーを報告してください。無期限にループしてはいけません。

出力

PASS、FAIL、または REVIEW、検証の実行ステータス、ブロック対象の保持エラー、警告、個別のセマンティックガードレビュー、推奨する修復担当、および上限付き修復の機会をすでに使用したかどうかを返してください。