sohan-gupthak/skills

証拠ゲート付きエージェント

影響の大きいリポジトリ変更や完了主張については、以下のシーケンスを使用してください。

1. 要求されたアクションと、実際の作業に伴う前提を分離します。もし曖昧さが動作、スコープ、安全性、または解決策を変える可能性がある場合は、BLOCKED_CLARIFICATION を発行します。これは、その曖昧さを解決する、最小の信頼できる明確化によって解除されます。

2. 発見されたコンテキストにおいて、そのアクションを低リスク、中リスク、高リスクに分類します。パブリック/共有サーフェス、動作、データ、セキュリティ、財務、および本番環境への影響、可逆性、依存関係、観測可能性を考慮します。

3. 主張固有の証拠契約を作成します。現在のスコープ、意思決定に関連する主張、各主張に必要な証拠、および主張が裏付けられない場合の結果を含めます。公開API、認証/認可、支払い、移行、または破壊的操作については、高リスクドメインを参照して契約を構築します。すべての必須検証について、証拠を静的（ソースインスペクション、grep、型チェック、設定インスペクション）またはランタイム（実際にアプリケーションを実行し動作を観察）に分類します。ソースレベルのチェックはランタイム動作の証明にはなりません。ランタイムの主張は、実際に実行された観察によって裏付けられる必要があります。references/evidence-ledger.mdのリスク階層化ポリシーに基づき、エビデンス台帳で追跡することが必須または選択された場合、アクティブな台帳に契約を記録し、コンテキストが失われても持続するようにします。

4. 比例した証拠を収集します。リポジトリの成果物と実行可能な観察を優先し、適切な場合は決定論的分析を使用します。出所を主張 -> 観察された事実 -> 成果物またはコマンド結果 -> 方法 -> 制限として記録します。必須検証については、変更前にベースライン実行をキャプチャし、後で既存の障害が想定されるのではなく、比較できるようにします。この変更に台帳が使用されている場合、ベースラインと証拠の記録はアクティブなエビデンス台帳に保存されます。

5. 変更前の状態を解決します。

   • BLOCKED_EVIDENCE: 必要な事実上の証拠が欠落、矛盾、または利用不可能な場合。必要な事実証拠、矛盾を解決する調査/是正、または承認されたより狭いアクションによって解除されます。必須のゲートが、スコープ外の変更なしには通過不可能であることが既にわかっている場合、そのゲートを必須と宣言したまま先に進まないでください。スコープを拡大して再分類する承認を得るか、制限を記録した上で、ゲートが必須でなくなるように検証契約を明示的に再定義します。
   • ALLOW: 裏付けられた低リスクアクションが進行可能な場合。
   • ALLOW_WITH_VERIFICATION: 裏付けられた中リスクアクションが、完了前に規定された検証を条件として進行可能な場合。
   • CHECKPOINT: 裏付けられた高リスクアクションが、計画されたアクション、証拠、制限、および検証計画について明示的な人間の承認を必要とする場合。CHECKPOINT は行動の許可ではありません。明示的な承認が必要です。すべての CHECKPOINT について、人間が署名する書面による承認記録としてアクションを提示します。承認の範囲、不可逆的な結果、必要な検証 というセクションラベルを正確に使用し、いずれも省略しないでください。この記録と一字一句一致しない「承認します」や「お任せします」という回答は、そのアクションに対する承認ではありません。記録を再提示するか、BLOCKED_CLARIFICATION を返します。承認は、記載されたスコープの実行を承認します。スコープの変更、証拠要件の緩和、または裏付けのない変更後の主張の受け入れを承認するものではありません。

   チェックポイント承認必須
   
   承認範囲:
   - <具体的なアクション1>
   - <具体的なアクション2>
   - ...
   
   不可逆的な結果:
   - <元に戻せない具体的な結果>
   - <元に戻せない具体的な結果>
   - ...
   
   必要な検証:
   - <完了前に成立すべき観察またはコマンド結果>
   - <完了前に成立すべき観察またはコマンド結果>
   - ...
   
   承認するには「承認します」と返信してください。
   

6. 承認された範囲の変更のみを行います。スコープが拡大した場合は、リスクを再分類し、証拠契約を修正し、変更前の状態に戻ります。ユーザーが承認済みまたはチェックポイント済みの計画を変更した場合、単に計画を更新するだけでは不十分です。変更によって影響を受けるすべての依存する主張、証拠、リスク、破壊的な結果、および検証要件を再評価します。削除がないことを、保持されたデータが使用可能または読み取り可能であるという主張に変換しないでください。バイトの保存はセマンティクスの保存ではありません。

   コンポーネント、トランスポート、依存関係、またはサブシステムが変更された動作に関連しているという理由だけで、要求されたスコープを拡大しないでください。削除が明示的に要求された機能、削除された機能に技術的に必要な機能、削除された機能に単に隣接しているか歴史的に関連している機能を区別します。隣接する機能が、未使用である、承認された変更と互換性がない、または要求されたスコープに明示的に含まれているというリポジトリの証拠が確立された場合にのみ、その機能を削除します。機能が削除された機能なしでも動作可能な場合は、ユーザーが削除を承認しない限り、それを維持します。

   無関係な既存のコンパイル/テスト/ビルドの失敗により検証が妨げられている場合、検証を通過させるためだけに無関係なコードを変更しないでください。代わりに、無関係な失敗、それが既存の問題である理由、それを修正するとスコープが拡大する理由、およびそれを修正せずにどのような検証が可能かを報告します。

7. アクションと観察された動作に比例して主張を検証します。変更後の証拠ゲートを実行します。COMPLETE は、必須検証が合格し、必要な変更後の主張が裏付けられた場合にのみ続きます。 既存の失敗はスコープから除外される可能性がありますが、合格した検証として表現することはできません。検証を UNVERIFIABLE / BLOCKED_EVIDENCE として報告し、対象を絞ったチェックとリポジトリ全体の検証を区別します。

必要な事実上の証拠が欠落している場合は、BLOCKED_EVIDENCE のままです。必要な検証を実行できないことも、COMPLETE に対する十分な証拠ではありません。その検証が必須である場合、検証を UNVERIFIED または FAILED として報告し、全体的な処分を BLOCKED_EVIDENCE のままにします。 「先に進んでください」、「お任せします」、「最善を尽くしてください」、「ご判断にお任せします」などの一般的な承認フレーズは、CHECKPOINT アクションの承認にはなりません。明示的な承認は、特定のアクション、証拠、制限、および検証計画を指定する必要があります。承認が不明確なままの場合は、それを解決する最小の信頼できる質問を含む BLOCKED_CLARIFICATION を返します。 該当するポリシーが欠落しているプロパティを必要としない場合、人間はより狭いアクションを選択するか、確立された不利なリスクを受け入れることができます。承認によって、裏付けのない事実上の主張が真実になることは決してありません。検証の矛盾、または検証されていない必要な変更後の主張は、調査/是正のために BLOCKED_EVIDENCE に戻ります。

永続状態のためのエビデンス台帳

中リスクおよび高リスクの作業の場合、アクティブな変更の運用状態は会話のコンテキストを超えて持続する必要があります。エビデンス台帳は永続的な記録です。これは、このスキルの残りの部分と同じMarkdownリファレンス、同じステータスタクソノミー、同じ出所チェーン、同じ完了ゲートであり、変更ごとのドキュメントに適用されます。

台帳は記録であり、証拠ではない

台帳に主張を書いても、それが真実になるわけではありません。台帳エントリは、このスキルの残りの部分とまったく同じように、出所を保持する必要があります。台帳内の PASS は、それ自体としては主張を裏付ける記録された観察を意味します。記録は観察よりも強力ではありません。観察、成果物、方法、または制限のない単なる主張は、それがどこに書かれていても UNVERIFIED です。

台帳が必要な場合

既存のリスク分類を使用します。

• 低リスク: 台帳はオプションです。ローカル変数の名前変更、単独のタイプミスの修正、または重要ではないドキュメントの修正には必要ありません。
• 中リスク: 変更に意味のある証拠の追跡、複数の検証手順、または複数の調査または実行フェーズにまたがる可能性のある作業が含まれる場合、台帳が推奨されます。
• 高リスク: 台帳は必須です。公開APIまたは契約の変更、認証、認可、支払い、金融業務、スキーマ移行、破壊的操作、不可逆的なアクション、および重大な本番環境への影響にはすべて台帳が必要です。

台帳の保存場所

デフォルトの場所: .evidence-gated/active/<change-id>.md。完了した台帳は .evidence-gated/archive/<change-id>.md に移動します。デフォルトは作業状態のディレクトリであり、公開されたリポジトリの一部ではありません。特にユーザーまたはリポジトリの規則が別途指示しない限り、新しいプロジェクトの .gitignore に .evidence-gated/active/ を追加します。リポジトリの規則と明示的なユーザー指示が優先されます。エージェントは、スキルが台帳を使用しているからといって、黙って .gitignore を変更してはならず、許可なくアクティブな台帳をコミットしてはなりません。 変更が特に高リスクである場合、ユーザーが明示的に監査証跡を要求する場合、またはリポジトリの規則が永続的なドキュメントを必要とする場合、台帳は意図的にコミットされ、それに応じて名前が付けられることがあります（例：docs/evidence-gated/<change-id>.md）。

台帳のライフサイクル

1. 上記のリスク分類に基づいて、台帳が必要かどうかを判断します。
2. 新しい台帳を作成する前に、既存のアクティブな台帳を検索します。同じアクティブな変更に対して複数の台帳を作成しないでください。
3. 続行する前にアクティブな台帳を読み取ります。新しい調査フェーズ、重要な変更の実行、チェックポイント承認の要求、承認に基づく行動、スコープの変更、検証要件の変更、および完了の主張の前に、再度読み取ります。再読み取りでは、現在の要求されたアクション、承認されたスコープ、リスク、アクティブな前提、必須の主張、必須の検証、チェックポイント状態、承認状態、既知の制限、および現在の処分を確認する必要があります。これらのいずれについてもメモリに依存しないでください。
4. リスク、スコープ、前提、証拠、検証要件、ベースライン、チェックポイント状態、承認状態、実行状態、検証結果、最終処分など、重要な事実が変更された場合、台帳を更新します。
5. 台帳を終端の処分で確定します。COMPLETE、BLOCKED_EVIDENCE、または BLOCKED_CLARIFICATION。必須の主張が未解決のまま COMPLETE を意味する台帳は無効であり、書き直すか、適切なブロック解除条件に戻す必要があります。

必要なコンテンツ

アクティブな台帳には少なくとも以下を含める必要があります。変更IDと現在のステータス、要求されたアクション、承認されたスコープ、明示的にスコープ外の項目、スコープの制限と未知の事項、理由を含むリスク分類、ステータスとそれを裏付ける証拠または制限を含む重要な前提、証拠契約（意思決定に関連する主張ごとに1エントリ、必要な証拠、証拠の種類、裏付けられない場合の結果、ステータスを含む）、証拠記録（重要な項目ごとに1つ、主張 -> 観察された事実 -> 成果物またはコマンド結果 -> 方法 -> 制限 -> ステータス を保持）、ベースライン検証、チェックポイント状態、重要な状態遷移の実行ログ、すべての必須検証の検証記録、および制限/欠落/矛盾/未解決のセクション。

フェーズと処分

台帳ヘッダーには2つの異なるフィールドがあります。それらを混同しないでください。

運用フェーズ は、エージェントが現在変更に対して何を行っているかを、作業が進む順序で説明します。フェーズは DRAFT（台帳作成、契約未作成）、INVESTIGATING（証拠収集、ベースラインキャプチャ、前提解決）、EXECUTING（承認された範囲の変更進行中）、VERIFYING（変更後の検証と確定）です。フェーズは簿記です。何も承認しません。何もブロックしません。証拠としてカウントされません。対応する処分の変更を伴わないフェーズの移行は、承認の変更ではありません。

処分 は、普遍的なプロトコルからのゲートレベルの決定です。処分は、このスキルの正確に6つの標準状態です。BLOCKED_CLARIFICATION、BLOCKED_EVIDENCE、ALLOW、ALLOW_WITH_VERIFICATION、CHECKPOINT、COMPLETE。処分は、実行を承認し、検証をゲートし、変更を確定するものです。確定時には、台帳の処分はこれらの6つのいずれかでなければなりません。中間フェーズは処分の代わりにはなりません。

同じ変更が同時に EXECUTING フェーズと ALLOW_WITH_VERIFICATION 処分になる可能性があります。同じ変更が同時に INVESTIGATING フェーズと BLOCKED_EVIDENCE 処分になる可能性があります。これらを混同すると、承認が不明確になり、ゲートが隠れてしまいます。行わないでください。

承認とスコープのルールは台帳内でも適用されます

「先に進んでください」、「お任せします」、「最善を尽くしてください」、「ご判断にお任せします」などの一般的な承認フレーズは、会話と同様に台帳に記録された場合でも承認にはなりません。台帳内での承認は、このスキルの残りの部分で使用されるものと同じ チェックポイント承認必須 レコードに結び付けられている必要があります。別のコンポーネントが変更に関連していることを発見しても、新しい承認にはなりません。新しい証拠の発見は、新しいスコープではありません。スコープが実質的に変更された場合、提案された変更を記録し、影響を受ける主張と検証を特定し、リスクを再評価し、新しい承認が必要かどうかを判断し、台帳を更新し、承認されていない拡大スコープを実行しないでください。

真実のソース階層

権限は、何が確立されているかによって異なります。このスキルは、基本的に証拠によってゲートされた事実上の主張に関するものであるため、事実上の問題に関するユーザーの主張は、その証拠の代わりにはなりません。階層は2軸です。

意図、承認、望ましいスコープ、および許容可能なトレードオフの場合:

1. 明示的なユーザー指示または承認。

事実上のリポジトリ状態、ランタイム動作、および検証結果の場合:

1. 直接的なリポジトリおよびランタイムの証拠（実行された検証のコマンド出力を含む）。

…

[翻訳のため省略]