srdcheck

srdcheck

エージェントのための共有ルールレール：名前付きで引用可能なチェックに明示的な境界を設けることで、部分的なチェックを全体的な合法性と取り違えることなく、すべての呼び出し元が同じ決定論的な結果を利用できます。

System Reference Document 5.2.1 の特定のルールに対する機械判定です。ルールを適用した際には引用を示し、再現可能で、オフラインで動作し、提供範囲外の質問には正直に回答を拒否します。エージェントのためのルール弁護士です。権限を持つ DM として行動するエージェントも対象です。

エージェントはこちらから → SKILL.md — 最初の入口です。呼び出すタイミング、実例、必須事項／禁止事項を説明します。ファミリー契約：FAMILY.md。

ステータス：v0.9.0 alpha — まだ新しいものの、実際に動作しており、オープンに開発中です。 製品の方向性を形作ったキルテスト（当初のアイデアの半分を葬ったテストを含む）はeval/RESULTS-phase0.mdにあります。レールあり／なしのデモはdemo/mage-hand/にあります。以下の真実性スコアカードは CI によって生成されます。

ランタイムとオペレーティングシステムの保証はサポートマトリックスで定義しています。Python 3.10–3.13、Ubuntu の全テストスイート、Windows および macOS におけるインストール済みアーティファクトの明示的なスモークテスト契約が含まれます。

これが存在する理由

ゲームは、単一のモデルではなく、進化し続けるひとつの状態を複数のエージェントが共有する形で実行されることが増えています。GM、プレイヤーエージェント、ルール裁定者、ツール呼び出し役などです。複数の知性が裁定に関わった瞬間、拘束力のある問題は、個々のエージェントの知識や注意力の限界ではなく、一貫性になります。能力の高いモデルが5つあっても、それぞれが SRD を読んで、組みつき、集中、あるいは死亡セーヴについて少しずつ異なる裁定を下し、共有ゲーム状態がいつの間にか食い違うことがあります。個々の知性をどれだけ高めても、モデル同士が合意する保証はありません。ルールを一から導き直すたびに、ずれが生じる機会も増えます。解決策は、全員が呼び出す決定論的なレールです。同じアトム、同じ引用、毎回同じ判定により、適用されたルールの結果には、エージェント（または人間）が監査できる共通の来歴が付与されます。テーブル上の裁定には、別個の裁定来歴が保持されます。ここで srdcheck は単なる便利機能ではなく、ゲームを支える基盤になります。

参加者が一人だけのテーブルでも、このレールには価値があります。ゲームを進行するモデルは、注意力に限りのある優れた即興演者です。コンテキスト内で処理する、仕組みに関する細かなチェック――これは合法か、このスロットは消費済みか、リアクションは今ラウンドに再び使えるようになるか――はどれも、知性が必要な唯一の仕事であるストーリーに向けるはずのトークンと注意力を消費します。さらに、モデルが答えられるチェックであっても、証明や再現はできません。そして、私たち自身のベンチマークで示されたとおり、ルールの適用範囲外の質問に対して回答を拒否することもありません。

開発を始める前に、これをテストしました。最先端モデルは SRD のルールに関する質問にほぼ完璧に答えましたが、ハウスルール、GM の裁量、SRD に存在しない内容についても自信を持って裁定しました。その場合の唯一の正解は「私の判断ではありません」です。小型のローカルモデルは、回答拒否が一度もないまま19～30％の誤答を出しました。そのため、srdcheck はモデルの知識と競いません。srdcheck はレールです。構造化された事実を受け取り、対象範囲を限定した決定論的な結果を返し、ルールを適用した場合は引用を示します。そして、テーブルのすべてのエージェントが同じレールを使います。

これは何か

srdcheck は、次のような名前付きで範囲が限定された質問に答えます。この提案は、モデル化されたアクション・エコノミーのチェックに合格するか？、モデル化された予算オプションの種類のうち、残っているものはどれか？ 各ツールについて、チェック対象および対象外となる範囲の基準を示す、生成された機能・主張マップを参照してください。

• 雰囲気ではなく、判定を返します。 終了コード 0 はチェック対象の範囲に合格、1 はチェック対象の範囲と矛盾、2 は判定不能を意味します。適用されたすべてのルールには SRD の引用が付与されます。境界条件による拒否で引用をでっち上げることはありません。

• 範囲と来歴は判定とともに引き継がれます。 Verdict schema 4.0 では、すべての結果に coverage_level、checked_scope、unchecked_scope、assumptions が保持され、主張された／使用された／導出された／欠落している事実、助言的な rule_result、スコープ付きの DM table_decision、明示的な state_mutation が個別に報告されます。すべてのルール上の説明では、チェック済みの範囲内でのみ有効であることを明記します。

• シミュレーションではなく、裁定を行います。 ダイスを振らず、物語を語らず、ゲーム状態も所有しません。クエリとともに状態を受け取り、判定を返します。カーネルはステートレスな純粋関数であり、誰でも DM 製品、VTT、エージェントに組み込めます。

• 状態の確定はフェイルクローズで行います。 event.apply は評価された正確な状態にひも付く、冪等な遷移提案を出力します。transition.commit は古い提案や順序が不正な提案を拒否し、再試行時には同じ意味のレシートを返します。アトミックな状態書き込みは、引き続きエージェント DM またはホストが行います。安全な状態遷移を参照してください。

• エージェント DM の裁定は、隠れた状態なしで保持されます。 ポータブルなテーブルポリシーマニフェストと、リクエスト／遭遇／セッション／キャンペーン ID を既存のクエリツールに渡します。一致する裁定は自動的に適用され、SRD の結果とは区別され、テーブル権限の明示的な来歴情報が付与されます。テーブルポリシーを参照してください。

• 決定論的で高速です。 判定経路では LLM を一切呼び出しません。ローカルかつオフラインで動作します。

• テーブルの内容を記録せずに可観測性を確保します。 オプトインのメタデータのみのライフサイクルイベントは、リクエスト／判定 ID、バージョン、拒否クラス、所要時間を stderr または呼び出し元のシンクに出力します。契約により、未加工のプロンプト、状態、裁定、引用、エラーメッセージは対象外です。SRDCheck は何も永続化しません。

• まずエージェント向けです。 MCP + CLI、--pipe、--schema、リポジトリルートの tool.json を提供します。人間には同じペイロード内で平易な英語による 理由 を示し、エージェントはその文章を契約上の情報ではなく説明として扱います。

• ルールセットはアダプターです。 カーネルはゲームについて何も把握しません。ルールの内容はすべてアダプターパッケージから読み込まれ、各パッケージには出典ドキュメント、ハッシュ、ライセンス、帰属表示を含む独自の来歴マニフェストが付属します。適用されたルールの各結果は、このマニフェストをたどって参照します。SRD 5.2.1 アダプターはリファレンス実装としてこのリポジトリに含まれています。コミュニティ、プライベートなテーブル、独自 IP 向けのファーストパーティーアダプターを提供するパブリッシャーなど、誰でも別のルールセット用アダプターを構築できます。そのコンテンツがこのプロジェクトを経由することはありません。アダプターカタログは案内を行いますが、ホスティングは行いません。

このプロジェクトが遵守する不変条件についてはdocs/product-truths.md、今日実行できる例と目標の例についてはdocs/anatomy-of-a-turn.md、N/N-1 のマシン契約と修正ポリシーについてはdocs/compatibility-policy.mdを参照してください。

メンテナーおよび買収時のデューデリジェンス情報は引き継ぎインベントリにあり、アーキテクチャ、リリース、インシデント対応、サポートの各ランブックへのリンクも含まれています。未チェックの引き継ぎ項目は明示的な不足であり、準備完了を示唆するものではありません。

根拠を示しましょう。 大きなコンテキストウィンドウは SRD を 読む ことができます。srdcheck の価値はその上のレイヤーにあります。複数のエージェントがそれぞれルールをコンテキストに再導出して食い違うことなく利用できる、一貫性のある引用付きルール原子と共有スキーマです。docs/atom-concordance.mdはそのレイヤーの監査証跡です。エンジンが適用するすべてのルールを、根拠となる SRD の正確なテキストに対応付けています（順方向・逆方向）。生成後に CI で最新状態がチェックされ、引用文が実際に指定ページに記載されていることを逐語引用オラクルで証明します。機械可読なatom-concordance.jsonは、エージェントがこのレールの対象範囲と出典を確認するために読み込める軽量なインデックスです。

srdcheck がまだチェックしないこと

誠実さこそがこの製品の根幹です（真実 T8）。そのため、境界は暗黙にせず明示しています。現在の SRD アダプターは、戦闘ターンの基本事項をカバーしていますが、以下はまだチェックしません。

• 特徴の前提条件。 turn.plan はターンのアクション経済、つまりアクション、ボーナスアクション、リアクション、呪文スロットをそれぞれ最大1つまでしか消費していないかを判定します。ある特徴が実際に特定のアクションを付与しているかは検証しません。二刀流の利き手でない側の攻撃だけを行う場合、2024年ルールでは先に攻撃アクションが必要ですが、「アクション経済上は合法」と判定されます。この前提条件はキャラクターの特徴に属し、現バージョンではモデル化されていません。成功メッセージでは、その点を明示しています。
• 個々の呪文の効果。 ダメージ／HP、死亡セーヴ、セーヴィング・スローはモデル化されています（リデューサーが damage／heal／death-save を畳み込みます。また、save.check と concentration.check は呼び出し元がロールしたセーヴを解決します）が、個々の呪文の効果、たとえばファイアーボールの8d6ダメージや、セーヴ失敗時のホールド・パースンによる麻痺は、際限のない難題であり、引き続き対象外です。srdcheck はセーヴを計算しますが、サイコロを振ったり、呪文固有の効果を適用したりはしません。
• 状態のカバー範囲は、対象となる箇所ごとに異なります。 SRD の全15種類の状態はレジストリーを基準に各条項ごとに分類されていますが、各クエリが対象とするのは、実際に処理する効果のみです。これには、攻撃修正、モデル化されたアクション経済と移動速度、選択されたセーヴ／判定への効果、ダメージ種別、完全耐性、そして行動不能とその定義上の内包状態によるリアクションの阻止が含まれます。完全性オラクル が証明するのは、そこで名指しされた攻撃／ターンの対象箇所です。すべてのツールがあらゆる状態の条項をチェックするという意味ではありません。位置関係のジオメトリー、イニシアチブ順、隠密／知覚の対抗判定は、明示的に対象外です。
• SRD 5.2.1 の範囲外のコンテンツ — SRD に含まれないものは、jurisdiction から終了コード 2 を返します。アダプター 0.2.1 では、名前レジストリーが呪文、クリーチャー、状態、クラス、サブクラス、種族、特技、背景をカバーしています（CI でソーステキストを基準に全件確認されています）。背景のカバー範囲は管轄判定のみです。SRD 5.2.1 に実際に含まれる4つの背景（侍祭、犯罪者、賢者、兵士）は認識しますが、そのゲーム上の効果を構造化された事実として提供する機能はまだありません。
• スペルミスのあるフィールド名や不明なクエリフィールドがある場合は、明確に拒否します（アダプター 0.2.1）：すべてのクエリは、宣言されたスキーマに照らしてパラメーターを検証します。認識されないフィールドがあると、その名前を示して終了コード 2 を返し、黙ってデフォルト値で判定することはありません。CI のドリフトオラクルにより、ハンドラーとスキーマが二度と食い違わないようにしています。
• 事実の要求は、結果が変わり得る場合に限ります。 使用可能なメイジ・ハンドを使う場合、関連する距離が指定されるまで missing-fact で拒否されます。また、物体を運搬または操作する場合は、重量も指定される必要があります。禁止されている場合や、すでに上限を超えている場合は、それだけで判定が確定するため、無関係な修正を求めるループは発生しません。turn.plan で移動する場合は、feet を明示する必要があります。省略された値を0フィートの移動として扱うことはありません。

負の移動速度、99レベルの呪文、6を超える消耗状態など、意味をなさない入力には、確信があるように見える回答ではなく、終了コード 2 を返します。判断に迷った場合、srdcheck は拒否します。誤った判定こそ、決して許されない唯一のバグです。

今すぐ試す

$ pip install git+https://github.com/chaoz23/srdcheck
$ python -m srdcheck jurisdiction "Fireball"          # exit 0 — known content
$ python -m srdcheck jurisdiction "Hexblade"          # exit 2 — not in the SRD, honestly refused
$ python -m srdcheck query mage-hand.use '{"kind": "attack"}'
{
  "verdict": "illegal",
  "exit_code": 1,
  "why": "The hand can't attack.",
  "citations": [{"section": "SRD 5.2.1 p.145 'Spells > Mage Hand'", "page": 145,
                 "quote": "The hand can't attack"}],
  "rule_ids": ["mage-hand.cant-attack"],
  "adapter": "[email protected]",
  "coverage_level": "rule-surface-complete",
  "checked_scope": ["listed uses and prohibitions", "10-pound limit", "30-foot range for the proposal"],
  "unchecked_scope": ["fine-manipulation ambiguity", "duration or range trigger tracking across events", "narrative consequences"],
  "assumptions": ["the supplied use kind describes the proposal", "supplied weight and distance facts are accurate when relevant to the result"]
}
$ python -m srdcheck query mage-hand.use '{"kind": "attack"}' --table-evaluation
# deterministic table.evaluation/1.0; status=findings, authority=self_attested
$ python -m srdcheck query save.check '{"modifier":2,"dc":10,"d20_result":12,"save_ability":"dex","saver_conditions":[]}' \
    --table-evaluation --table-context '{"session_id":"session-7","correlation_id":"discord-42"}'
$ python -m srdcheck cite "Command"                    # verbatim SRD text + page for any registered name
$ python -m srdcheck --schema                          # I/O contract for agents
$ python -m srdcheck capabilities                      # engine, protocol, adapters, digests, tools

決定論的で、オフラインで動作し、トークンも不要です。CI では、100 件の判定における p95 レイテンシーが 100 ms 未満であることをゲートしています。ローカルでこれより低い値が観測されても、互換性を保証するものではありません。クエリーの対象範囲はまだ発展途上で、少しずつ拡大しています。重要なのはアーキテクチャ（カーネル＋アダプター、v0.9 RC の仕様）です。

query と --pipe は、共通の table.evaluation/1.0 エンベロープを必要とするポートフォリオホスト向けに --table-evaluation を受け付けます。適法／違法の判定が完全な確認済みクリーン結果／問題検出結果になるのは、名前付きのクエリスコープ内に限られます。不足している事実、未対応のコンテンツ、曖昧さ、DM の裁量が残る場合は、クリーンとは判定されません。対象には、機械可読な srdcheck-query-scope:* 参照が含まれます。オプションの --table-context JSON では、呼び出し元が管理する session_id、entity_refs、correlation_id を追加できます（correlation:* として出力されます）。ルールと引用のエビデンスは自己完結しており、すべての問題検出エビデンス参照に対応付けられています。呼び出し元が DM である場合も含め、すべての結果は self_attested です。このアダプターは、テーブル、エンカウント状態、アクション、保護対象ホストに対する権限を付与できません。

ライブのエージェントと DM のホストでは、プライバシーを保護できるリクエスト結合キーとして、Discord メッセージまたは解決済みインテントイベントのスノーフレーク ID を使用してください。

python -m srdcheck query mage-hand.use '{"kind":"attack"}' \
  --trace --request-id 123456789012345678

判定は stdout に出力されます。正規のメタデータのみを含む NDJSON は stderr に出力されます。イベントスキーマ、MCP の設定、保持境界、残存するメタデータリスクについては、プライバシーを保護した可観測性を参照してください。

エージェント向け（MCP）

srdcheck は依存関係ゼロの MCP サーバーです。標準ライブラリのみを使用します。pip install の後は、コマンドは srdcheck-mcp です。クローンから実行する場合は次のとおりです。

{
  "mcpServers": {
    "srdcheck": {
      "command": "python3",
      "args": ["-m", "srdcheck.mcp"],
      "cwd": "/path/to/srdcheck"
    }
  }
}

ツールの完全な一覧と各ツールの確認済み／未確認のスコープは、実行時メタデータからケイパビリティマップとして生成されます。CI は、古い一覧や不完全な一覧を拒否します。各呼び出しは、CLI と同じ判定オブジェクトを構造化コンテンツとして返します。適用されたルールの結果には出典の引用が含まれます。境界による拒否で、根拠を捏造することはありません。illegal 判定は結果であり、エラーではありません。cannot-adjudicate は失敗ではなく、正直な拒否です。ツールの説明とスキーマは、読み込まれたアダプターから取得されるため、カーネルを変更せずに新しいアダプターを追加してツール一覧を拡張できます。CLI の対象範囲については、tool.jsonも参照してください。オプトインの table_evaluation MCP ツールは {query_type, params, context?} を受け付け、ネイティブのクエリツールのレスポンスを変更せずに、同じ共通エンベロープを出力します。

すべてのファーストパーティの cannot-adjudicate 結果には、data の下に安定した復旧メタデータが含まれます。具体的には、理由コード、復旧可能性、不足入力の正確なパス、推奨される次のアクションです。これによりエージェントは、why を解析せずに、リクエストを修正する、事実を提示する、アダプターを選ぶ、別の機能を使う、テーブルの裁定を求める、古い状態を調整する、または停止するべきかを判断できます。DM の権限が必要な場合、権限を持つエージェント兼 DM は直接裁定でき、別の呼び出し元はエスカレーションできます。機械処理可能な拒否契約を参照してください。

Python ライブラリとして

内部ファイルパスに依存せず、安定したバージョン付きインターフェースを通じてルールセットのコンテンツを利用できます。

from srdcheck import load_adapter, available_adapters

available_adapters()               # ['srd-5.1', 'srd-5.2.1', 'toy-tictactoe']
a = load_adapter("srd-5.2.1")      # a versioned identifier
a.categories()                     # the content categories this adapter carries
a.names("creature")                # every creature name (326, complete from the stat blocks)
a.record("creature", "Ghast")      # {"name": "Ghast", "cr": "2", "xp": 450, "citation": "SRD 5.2.1 p.287"}
a.query("encounter.xp-budget", {"level": 3, "difficulty": "moderate"})  # a verdict dict

バージョンをまたいだエディションの罠の検出 — 以前のエディションでは有効だったものの、現在のエディションでは名前が変更された、または削除された名前を検出できます（LLM でよくある失敗です。例：「Goblin」は 2014 年版では有効でしたが、2024 年版では「Goblin Warrior」に変更されています）。

from srdcheck import edition_check
edition_check("Goblin", "creature")          # exit 1 — a srd-5.1 name, not in 5.2.1;
                                             #   data.candidates_in_current suggests Goblin Warrior/Minion
edition_check("Aboleth", "creature")         # exit 0 — valid in both
# or from the CLI: srdcheck edition-check "Goblin" --category creature

アダプター識別子にはバージョンが含まれるため、load_adapter("srd-5.2.1") と load_adapter("srd-5.1") を破壊的変更なしに共存させられます。edition_check のパラメーター（current / priors）は呼び出し元が指定するため、あらゆるバージョンとカテゴリに汎用化できます。このハンドルはコンテンツに依存せず、カテゴリとレコードを扱います。特定のルールセットの語彙には依存しません。

ベンチマーク

bench/ はルールへの忠実度を判定する基準です。SRDを根拠とする正解判定付きのバージョン管理された質問セット、任意のモデルやエージェント（標準入力／標準出力で動作する gemini:、ollama:、cmd:your-agent）を採点するハーネス、そしてカテゴリごとに誤答率、拒否率、誤った確信を別々に報告し、集計値は決して掲載しない生成済みスコアカードが含まれています。生成済みリーダーボードでは、許しがたい唯一の失敗である誤答数だけを基準に対象を順位付けしています。また、第三者なら誰でも改ざんチェック付きの結果を提出できます。正解は質問セットにあるため、自分の課題を自分で採点することはできません。公開済みの調査結果によると、最先端モデルは明文化されたルールには優れていますが、ルールの範囲外ではまさに誤った確信によって失敗します。また、正解判定をエンジン自体が導き出すホライズン別のドリフトレーンでは、30ラウンドのホライズンでもドリフトしません。一方、ローカルの8Bモデルの誤りは、記憶ではなくルール知識の不足によるものです。コマンドひとつで、ご自身のDM製品をベンチマークできます。

真偽スコアカード

タグ付きリリースごとに、製品の理念に対するスコアカードが公開されます。CI によって生成され、手作業で編集されることはなく、総合スコアもありません。

scripts/truth_scorecard.py によって生成されます。CI で再生成と差分チェックが行われ、手作業で編集されることはありません。ステータスは実態を反映しています。構造上の保証 と レビュー中 は、それぞれ文字どおりの意味です。

理念	主張	ステータス	根拠
T1	誤った判定を出さない	CI で強制	Phase 0 の評価から移植したゴールドスイートを含む 749 件のテストがあり、誤った判定が 1 件でもあればビルドは失敗します
T2	引用がなければ、ルールもない	CI で強制	90/90 件のルール原子に原文そのままの引用が付いています。適用されたルールの経路には引用があり、境界での拒否では出典を捏造しません
T3	助言はしても、覆さない	構造上の保証	API にはブロックや拒否権を行使するインターフェースがなく、判定は設計上、助言にとどまります
T4	1 つのペイロード、2 つの対象者	CI で強制	すべての判定に、機械処理用フィールドと、テンプレート化された平易な英語の説明が含まれます。スキーマによるテスト済みです
T5	列挙を方向性の軸にする	提供済みの範囲で実証済み	整合性チェック（50 のターン状態とテスト用ボード）により、プッシュのたびに両方向で列挙と検証の一致を確認します。すべてのクリーチャーを網羅する列挙は、引き続き目標です
T6	シミュレーションではなく、判定を行う	CI で強制	決定性テストと純粋性の lint により、カーネル内に乱数がないこと、判定経路にネットワーク通信やサブプロセスがないことを確認します
T7	仕組みにゲームの知識を持たせない	CI で強制	カーネルの lint がすべてのカーネルモジュールをスキャンし、ゲーム用語を検出します（開発中に実際の違反を検出しました）
T8	境界を正直に示す	CI で強制	拒否のゴールデンテストでは、未知のコンテンツ、モデル化されていない状況、真に曖昧なルール文のいずれも exit 2 を返します。曖昧さには出典を引用し、レジストリーや入力の境界では引用がない場合があります
T9	単一の数値に集約しない	CI で強制	ベンチマークのスコアカードの鮮度テストがあります。カテゴリ別の表があり、このリポジトリ内のどこにも総合スコアはありません。リーダーボードでさえ誤答数のみ（T1）で順位付けし、その他の失敗モードは合算せずに示します
T10	初見のエージェントが自力で起動できる	CI で強制	コールドスタートの適合性テストでは、tool.json/--schema/MCP だけを使って最初の判定に到達します（ツール数 24）。ライブプローブでは、tool.json だけを与えられた最先端モデルが、1 回の試行で正しい最初の判定を生成しました（3.9 秒、2026-07-16）
T11	卓上での速度	CI で強制	p95 レイテンシーの予算テストでは、100 件の判定を p95 で 100 ms 未満に保つ必要があります。ローカルでこれより短い時間が観測されても、互換性を保証するものではありません
T12	モデルが持つ知識を売りにしない	レビュー中	戦略上の不変条件です。知識の同等性を売りにした機能はレビューで削除されます。これは人間が強制しており、その事実も明示しています
T13	ベンチマークも製品の一部	提供済み	bench/ は、引用付きのゴールド判定を含む 5 つの対象分野の 5 セットを公開します。エンジン由来のゴールドを使う、予測期間別のドリフト評価レーンも含みます。生成される LEADERBOARD は任意の対象分野を順位付けできます。コマンドラインでは、driver と validate コマンドを使って、第三者が改ざんチェック済みの結果を提出できます
T14	派生状態のすべてに来歴がある	CI で強制	event.apply は、成功した派生遷移ごとに（先行状態のハッシュ、原因となったイベント、ルール ID、ルールまたは裁定の種別）を記録します。テストでは、リプレイ検証、改ざん検出、スキーマ最小性のラチェット、reducer と validator の一致を確認します。デモでは 15 ラウンドをハッシュ単位で完全に一致させて再生します

ライセンス

• コード：MIT。
• data/：CC-BY-4.0 に基づく System Reference Document 5.2.1 由来の素材を含みます。出典情報と必要な帰属表示については、srdcheck/adapters/srd-5.2.1/sources/README.md を参照してください。
• srdcheck は非公式であり、Wizards of the Coast との提携関係や、同社による推奨はありません。

代替手段との比較

• LLM に直接尋ねる場合 — 最先端モデルは、これらのルールをほぼ完璧に把握しています（測定した結果、私たち自身のアイデアの半分を断念しました）。設計上できないのは、判定を証明すること、再現すること、ルールの適用範囲外の質問に回答を拒否することです。実演の 6 回中 5 回で、裁量ゾーンにおいてルールを判断する権限があると主張しました。srdcheck が提供するのは、証明、拒否、決定性、経済性です。知識ではありません。
• 検索 API とリファレンス MCP サーバー（Open5e、5e-srd-api とそのラッパー）— これらが答えるのは*「ルールブックには何と書かれているか」であり、「この状態で合法か」*ではありません。競合するものではなく、相互に補完するものです。srdcheck は、これらのサービスが提供するものと同じテキストを引用します。
• AI-DM 製品内のクローズドなエンジン — この分野の有力製品は、決定論的なルールレイヤーを稼働させています。いずれも独自に再構築され、引用もベンチマークもなく、自社プラットフォームにロックインされています。srdcheck は、そのレイヤーをオープンにし、出典を明記し、ベンチマークを実施し、埋め込み可能にしたものです。それらの製品にも組み込めます。
• シミュレーターライブラリ（戦闘エンジン、キャラクターライブラリ）— これらはゲームを実行し、状態を保持します。srdcheck は判定を行い、何も保持しません（状態は来歴情報を付けてクエリとともに渡されます）。だからこそ、どこにでも埋め込めます。

先行事例

srdcheck は、Temple of Elemental Evil / Temple+（ディスパッチャーアーキテクチャ）、PCGen（前提条件の述語）、FoundryVTT の PF2e システム（データとしてのルール）、Datasworn（公式ルールを JSON で表す先例）、FIREBALL（構造化されたプレイ状態）から得た教訓を土台にしています。設計パターンは参考にしましたが、これらからコードを流用してはいません。

mcp-name: io.github.chaoz23/srdcheck

数式の空欄（v0.3）

ルールが数式である場合、判定結果は数式です。呼び出し元がすべての空欄を埋めた場合にのみ、数値が表示されます。必要なサイズ／空いている手に関する前提条件の情報が渡された後でも、str_modifier と proficiency_bonus を指定せずに grapple.initiate を呼び出すと、dc なしで dc_formula が返されます。perception_modifier を指定せずに passive.perception を呼び出すと、score なしで score_formula が返されます。きっかけは、基本値の 8 が「DC 8」として表示され、本当の DC は 13 だったという、実際の卓での出来事です。srdcheck は検索に徹します。数式はルールのテキストであり、呼び出し元から渡された空欄を埋めるのは算術演算です。シートから空欄の値を導き出すのは charactercheck の役割であり、srdcheck の役割ではありません。

呪文と特徴の情報（v0.4）

srdcheck query spell.facts '{"name": "Protection from Evil and Good", "cast_at": 1000}'
srdcheck query feature.uses '{"feature": "divine-sense", "charisma_modifier": 4}'

発動時間、射程、構成要素、持続時間、精神集中 — DM が午前 2 時に間違えて記憶しているような情報を、出典付きの判定結果として提供します。336 個すべての SRD 呪文を対象にセンサスと照合しており（呪文の解析が不完全な場合、ビルドは失敗します）。cast_at は、呼び出し元独自の時計に基づく単純な算術演算として expires_at を追加します。srdcheck は状態も時計も保持しません。feature.uses は、数式の空欄に関する方針に従って、SRD の使用回数に関する数式を扱います。きっかけは、人間のプレイヤーが、10 分間の結界が 70 分間有効だと語られていることに気付いたことです。

独自のアダプターを作成する（v0.5）

カーネルはゲームを認識しません。そして今、そのキットでそれを実証しています。同梱の 3 つのアダプターは、それぞれ異なる階層に対応しています（レジストリのみの srd-5.1、フル機能の srd-5.2.1、チュートリアル用の toy-tictactoe）。

srdcheck new-adapter my-ruleset     # conformant skeleton
srdcheck conformance <adapter-id>   # the bar every adapter must clear

準拠していることが参加条件です。ハッシュで固定されたソースを含む来歴マニフェスト、未知のキーを拒否するスキーマ宣言済み入力、クラッシュせずに誠実に拒否する機能、センサスと照合されたレジストリが必要です。ゴールデン判定の固定（CI で実行される scripts/build_golden.py --check）により、キットのリファクタリングが既存の利用者から見てバイト単位で変更されないことを保証します。ガイド：docs/ADAPTER-GUIDE.md。