logic-audit

論理監査

成果

主張、要件、証拠、アクション、証明の間にある重大な矛盾や欠落したつながりを見つけて修正します。権威と意図を保ちます。前提を作り出したり、実在する不確実性を消したり、厳密な要件を弱めたりしてはいけません。

適用条件と範囲

ユーザーが、論理的な不整合、欠落、裏付けのない主張、要件の競合、不完全なケース、または目的とその証明の間の隔たりを見つける、説明する、調整する、あるいは修正するよう求めた場合に使用します。

文章、ポリシー、計画、仕様、研究、意思決定、および複数のソースが混在する資料に使用します。コードの不具合については、このスキルで論理上の契約を特定した後、根本原因の調査を systematic-debugging に引き継ぎます。形式的な定理については、利用可能であれば証明支援系またはソルバーを使用し、検証できた範囲に主張を限定します。通常の事実検索だけでは、このスキルの適用対象になりません。

完全な監査の範囲は、指定されたソースセットと成果によって定まります。開かれた世界に潜在的な欠落がないと主張してはいけません。

必須の構成

監査の前に、次の手順を実行します。

1. always-current-datetime を読み込み、時刻の基準を取得します。
2. starting-point を読み込み、非公開の成果マップを作成します。
3. outcome-bounded-work を読み込み、固定要件、証明責務、境界、禁止される成果、必須の手法、候補となる経路、不明点を分類します。
4. 監査全体を通じて同じ as_of 基準を保ちます。新たなユーザーとの直接のやり取りがあった場合、または現地の午前0時を過ぎた場合に限り、再取得します。

これらのスキルは、日付の扱い、成果マップ、および不変条件と手順の分類を引き続き担います。このスキルは、整合性と欠落の分析を担います。

証拠の準備

1. 正確なソースセット、権威の優先順位、バージョン、日付、および除外した資料を明示します。
2. アクセス可能な各ソースを全文確認します。切り詰められた箇所が残る場合は、その範囲を明記し、ソース全体を確認済みとして扱いません。
3. 重要な記述すべてに、ソース内の順序に沿った安定したソース ID を付与します。
4. 各記述を、定義、事実、仮定、要件、境界、例外、証拠、推論、アクション、結論、または不明点に分類します。
5. 2つの記述に矛盾があると判断する前に、用語、実体、参照、量化子、法助動詞、単位、時間枠、バージョン、範囲を正規化します。

ウェブ証拠の取り扱い

利用可能なソース関連のウェブ機能を、明確な目的をもってすべて使用します。調査結果を変え得ない低レベルの操作を実行してはいけません。

1. 現在利用可能な検索、ソース抽出、レンダリングブラウザー、ソーシャルソース、学術、ドメイン固有の各機能を一覧にします。不慣れな機能は、使用前に仕様を確認します。
2. ソース関連機能ごとに1行を設けた機能台帳を作成します。各機能を USED、理由を添えた NOT_APPLICABLE、または確認された失敗内容を記録した UNAVAILABLE のいずれかとして記録します。利用可能な関連機能はすべて使用しなければなりません。
3. 発見とクエリのバリエーションには検索機能を使用します。主張に権威ある管理主体がある場合は、まず公式ドメインまたは当事者のドメインを検索します。
4. 検索結果のスニペットは手掛かりであり、証明ではありません。候補となる場所を証拠として扱う前に、ソース抽出機能を使用します。
5. JavaScript のみで表示される情報、認証が必要な情報、インタラクティブな情報、レイアウトに依存する情報、コンソール情報、ネットワーク情報には、レンダリングブラウザー機能を使用します。ホストで定められたコンピューター操作の担当機能に従います。
6. ソーシャル投稿、プロフィール、スレッドに関する主張には、ソーシャルソース機能を使用します。コーパスによって調査結果が変わり得る場合は、学術、市場、地図、リポジトリ、プラットフォームなど、ソース固有の機能を使用します。
7. ターミナルの HTTP クライアントを使用できるのは、通常のウェブ機能が失敗した場合、または必要な応答内容を取得できない場合の、記録された代替手段としてのみです。取得したソースを確認せずに、代替手段で得た情報を証拠として扱ってはいけません。
8. URL またはソース ID、発行元、入手可能な場合は公開日または更新日、アクセス日、関連する主張 ID、ソースの制約を記録します。

一次ソースを優先します。誤りのコスト、論争の有無、またはソースの利害関係により単一のソースでは不十分な場合は、独立した裏付けを取ります。現在の事実と過去の証拠を区別します。

監査手順

リソースゲート：ここに記載されたパッケージファイルを使用する前に、mise run validate を実行してください。

1. 各結論または必須の成果から、その前提、アクション、担当者、証拠へ遡る依存関係マップを作成します。
2. references/check-catalog.md に記載された該当する一貫性チェックの種類をすべて、各ステートメント、ペア、依存関係の連鎖、権限レイヤーに対して実行します。
3. 同カタログに記載された該当するギャップの種類をすべて、必須の成果、分岐、インターフェース、状態遷移、証明の主張に対して実行します。
4. 普遍的または網羅的な主張を確定する前に、反例と境界事例を探します。
5. 外部から検証可能な前提は、ウェブ証拠の契約に従って検証します。ソース間の一致を、妥当な推論の代わりにしてはいけません。
6. 独立した問題ごとに指摘事項を1件作成します。1つの根本問題を、過剰な重複として分割してはいけません。
7. 各候補を CONFIRMED、PROBABLE、POSSIBLE、NOT_AN_ISSUE、BLOCKED のいずれかに判定します。
8. 表現の強さではなく、受け入れられた成果に基づいて、影響度を critical、high、medium、low に分類します。
9. 整合性のある最小単位を修正します。大幅な書き換えよりも、明確化、適用範囲の修正、前提の明示、ケースの追加、証拠の差し替え、要件の調整を優先します。
10. 依存関係マップを再作成し、修正した成果物に対して監査を再実行します。

指摘事項台帳

各指摘事項には、以下を含める必要があります。

• ID、およびソースの箇所またはステートメント ID。
• 種類、および影響を受ける成果または証明義務。
• 問題となる競合または欠落しているつながり。
• 正規化した解釈と競合する解釈。
• ステータス、影響度、確信度。
• ウェブ機能の行を含む、使用した証拠。
• 最小限の修正と、その副作用。
• 解決状態と残る不確実性。

2つの記述が、関連する対象、時点、適用範囲、意味、権限コンテキスト、様相のすべてにおいて一致しない限り、相違が矛盾となるわけではありません。証拠がないことは、主張が誤りである証拠ではありません。

修正ルール

• 優先度の高い指示と、明示されたユーザー要件を優先します。
• 両立可能な範囲で最も強い契約を維持します。権限の競合がある場合、一方を黙って選んではいけません。
• 方法が必須の場合は、その方法を使用します。別の方法は任意の比較対象として明示し、黙って置き換えてはいけません。
• 新しい前提は前提として明示し、重要なアクションが変わる場合は承認を求めます。
• 証拠によって選択できない場合は、未解決の選択肢を明示したままにします。
• ソースの修正と実装を分けます。正当な編集者を使用し、通常の副作用ゲートに従います。
• 書き換える際は、meaning-preserving-rewrite を読み込み、受け入れられた要件と証明義務をすべて維持します。

証明のしきい値

以下のすべてを満たす場合に限り、PASS を返します。

• 範囲を限定したソースセット全体を読み込んでいるか、アクセスできない範囲をすべて主張の対象外にしています。
• 未解決の重大または高影響度の矛盾が残っていません。
• 必須の成果すべてに、前提、担当者、アクションまたは推論、判断の根拠となる証拠の完全な連鎖があります。
• 重要な外部前提すべてに最新のソース証拠があるか、未解決として明示されています。
• ウェブ機能台帳が、利用可能なソース関連機能をすべて記録しています。
• 修正した成果物が同じチェックに合格し、さらに少なくとも1つの反例または否定的ケースにも耐えます。
• コンポーネントのチェックを、成果全体の証明として提示していません。

有用な指摘事項は証明済みでも、しきい値を満たしていない場合は PARTIAL を使用します。権限、ソースへのアクセス、または証拠の不足によって安全な修正ができない場合は BLOCKED を使用します。

出力

結果と as_of 日付を先頭に示します。続けて、範囲を限定したソースセット、指摘事項台帳、修正後の成果物または正確なパッチ、未解決の項目、ウェブ機能台帳、最終判定の PASS、PARTIAL、または BLOCKED を提示します。主張を裏付けるソース ID と URL は、その主張の近くに記載します。

よくある失敗

• 日付、範囲、定義、モダリティの違いを矛盾として扱う。
• 曖昧さを暗黙の前提に置き換える。
• 無効な推論を無視して、前提の事実確認だけを行う。
• 欠落を列挙するだけで、結果への影響をたどらない。
• 検索スニペット、情報源の件数、モデル間の一致を証拠として扱う。
• 修正した段落を、実行が機能する証明と呼ぶ。
• 範囲を限定した情報源セットの外まで完全性を主張する。

パッケージリソース

ユーザーが永続的な台帳を求めた場合は、assets/finding-ledger-template.md を使用します。記入する前に、インストール済みのスキルの外部へコピーしてください。完全な可視実行例については、examples/direct-contradiction.md、examples/temporal-non-contradiction.md、または examples/blocked-source-access.md を読んでください。パッケージのメンテナーは references/generation-contract.md、mise run test、evals/ を使用し、その後 mise run ci を実行します。通常の監査では、これらのパスを読み込みません。

段階的開示

リソースゲート：ここに記載されたパッケージファイルを使用する前に、mise run validate を実行してください。

PD-101：references/check-catalog.md が、不整合と欠落に関する詳細な分類を定めています。完全な監査を行う場合、または候補が中核クラスに当てはまらない場合は、読み込んでください。このファイルでは、トリガー、手順、相互参照を定めています。

PD-102：references/eval-cases.json が、客観的な負荷ケースと合格基準を定めています。このスキルをテスト、レビュー、変更する前に読み込んでください。このファイルでは、実行時の動作と、その評価の管理元へのリンクを定めています。

PD-201：references/generation-contract.md が、移植可能なパッケージ構造、情報源の系譜、例、評価の証明を定めています。パッケージのメンテナーは、これらの領域を変更する前に読み込みます。このファイルでは、公開手順と相互参照を定めています。

ファクトリー実行契約

受け入れられる結果は、依存関係を考慮した矛盾台帳と、新たな修正証明を通じて、重要な主張の矛盾を発見し、修正することです。矛盾台帳の現在の動作を維持しながら、最小単位の管理元を変更してください。

1. mise run ci で現在のパッケージを凍結し、そのダイジェストを記録します。
2. mise run domain-research-policy を実行し、現在の矛盾台帳の情報源と反証を評価します。
3. 指定された矛盾台帳操作に対して mise run agentic-request を実行します。意味上の選択はモデルに任せてください。
4. mise run decision-policy、mise run ci、行動評価を実行します。失敗した場合は、最も低い階層の管理元に戻ります。
5. mise run invocation-policy -- <receipt> を実行し、すべてのタスク、またはドメイン固有の理由による不使用を説明します。
6. 任意で mise run improvement-policy を実行します。保護対象の側面に悪影響がない場合に限り、変更する側面を1つに保ちます。

契約が必要な場合に限り、mise run use-case-policy を通じて assets/use-case-contract.json を、mise run evals を通じて evals/evals.json を読み込みます。

Mise は、再現可能な仕組み、順序、実行記録、チェックを管理します。モデルは、コードでは提供できない解釈、因果関係の判断、創造的な作業、直接的な知覚を担います。権限の不足、古い証拠、またはゲートの失敗があれば停止してください。