Deadlatch

Deadlatch

トレーディングエージェントの取引前ラッチです。 助言のみを行います。

まず、知っておくべきことは3つです。

1. ご自身で管理する、ブローカーを横断する独立したゲートが必要です。 エージェントが口座に注文を出せる場合、エージェントとブローカーの間にある最後のチェックをエージェント自身に任せるべきではありません。また、特定のブローカーの UI やルールに固定すべきでもありません。
2. Deadlatch は予測も推奨も注文の発注もしません。 答えるのは「この注文は今、許可されているか」という1つの問いだけです。シグナル生成ツールでも、ブローカーでもありません。
3. すべての回答には理由、根拠、Linux/macOS 上のローカル監査記録が付属します。 PASS / WARN / BLOCK は、判定だけで終わることはありません。どのルールに該当したのか、理由は何か、何が評価されたのかを確認できます。永続的な監査書き込み（init / append / repair / prune / シャドーレポート）は Linux と macOS のみでサポートされています。Windows ではパッケージをインポートでき、ルールエンジン / Guard / CLI / MCP による判定も行えますが、これらの書き込み処理は audit_platform_unsupported でフェイルクローズします。停止済みスナップショットのオフラインでの verify / read は引き続き利用できます。Windows の MCP は限定的な統合経路であり、完全に信頼できる監査チェーンではありません。

正直な制約（お読みください）： Deadlatch は助言を行うツールです。Deadlatch を呼び出さないエージェントに呼び出しを強制することはできません。また、BLOCK を無視して別の場所から注文を出すエージェントを止めることもできません。エージェントがガードを呼び出し、その結果を尊重するかどうかは、統合する側の判断です。損失を防ぐ保証としてこのツールに依存しないでください。これはゲートであり、保険ではありません。

• ライセンス： MIT — LICENSE をご覧ください。
• 中国語ドキュメント： README.zh-CN.md
• セキュリティ： SECURITY.md · コントリビューション： CONTRIBUTING.md · 免責事項： DISCLAIMER.md

まずはこちら

現在のインストール方法は、検証済みの PyPI deadlatch==0.1.2 です。 2026-09-22 に公開されました。安定版 GitHub v0.1.2 Release の対象は b072e8a4d4b053e1d5a428dbb9c47e06652fbf4c で、wheel/sdist アセットは PyPI のオリジナルと一致します。

pip install deadlatch==0.1.2

公開済みの MCP Registry 名は io.github.Diabloluo/deadlatch、バージョンは 0.1.2 です。 2026-09-22 に有効かつ最新であることが確認されています。ローカルの server.json は公開済みのバージョンと一致します。 以下のコマンドは、検証済みの PyPI パッケージを直接起動します。

MCP から始める：

uvx --from deadlatch==0.1.2 deadlatch-mcp --policy policy.yaml --portfolio portfolio.json

--policy と --portfolio は必須のローカルファイルです。--audit-path と --kill-switch-path は任意です。架空の入力、またはご自身で用意したシミュレーション用の入力のみを使用してください。Deadlatch は助言のみを行います。注文を発注することはなく、呼び出さないエージェントを止めることもできません。オプション注文の symbol には、ブローカー固有の完全な契約コードを使用してください。過去の GitHub プレリリースは v0.1.0.dev1 にありますが、現在のインストール方法ではありません。

その後：

1. 以下の架空データを使ったクイックスタート（Python、CLI、または MCP）を Linux または macOS で実行します。PASS → BLOCK → ローカル監査を確認してください。Windows ではパッケージをインポートしてルール計算を実行できますが、監査書き込みのクイックスタートには対応していません。
2. 注文インテントまたはシミュレーション実行経路をすでにお持ちの場合に限り、20分間の統合評価を依頼してください：評価フォームを開く。

この GitHub Issue は公開されています。口座、ポジション、注文、API キー、トークン、顧客名、非公開のパスを貼り付けないでください。セキュリティ上の欠陥は、公開 Issue ではなく GitHub Security Advisories から報告してください。

---

クイックスタート（各60秒）

3つのクイックスタートはすべて、架空のデータと一時的な監査パスを使用します。テストスイートによって同じソーススクリプトから実行されるため、ドキュメントとの食い違いが生じません。完全な監査書き込み／MCP クイックスタートには Linux または macOS が必要です。 Windows ではライブラリをインポートしてルールを評価できますが、永続的な監査コレクションの初期化や追記は行いません。

1. Python API

pip install dist/deadlatch-*.whl        # or: pip install -e .
python docs/quickstart/python.py

Guard.from_policy(...) → Order / Portfolio → guard.check(...) の流れを示します。 有効な注文は PASS / 0 を返し、サイズ超過の注文は該当ルールとともに BLOCK / 3 を返します。BLOCK の場合、呼び出し元のサンプルは処理を停止するため、ブローカーへの呼び出しは行われません。

2. CLI

bash docs/quickstart/cli.sh                  # requires `deadlatch` on PATH

一時ディレクトリに新しい入力を作成し（タイムスタンプは動的で、古くなりません）、その後 deadlatch check を実行して、PASS（exit 0）、BLOCK（exit 3）、入力エラー（exit 4）、および --json チェックを行います。さらに、監査ログに対して shadow report --json を実行します。

3. MCP（stdio）

python docs/quickstart/mcp_client.py         # requires `deadlatch` installed

deadlatch-mcp を stdio 経由の実際のサブプロセスとして起動し、5つのツールを一覧表示して、check_order をPASSの場合とBLOCKの場合に1回ずつ呼び出します。policy／portfolio／audit のパスはサーバー起動時の設定であり、エージェントがツール引数として差し替えることはできません。BLOCKは呼び出し元が順守すべき制約です。技術的には、ガードを完全に迂回するエージェントに呼び出しを強制することはできません。

---

これは何か／何ではないか

Deadlatch が提供するもの	Deadlatch が提供しないもの
注文送信前に評価される、ローカルで決定論的なリスクゲート	シグナル生成器、レコメンダー、またはポートフォリオ最適化ツール
ライブラリ、CLI、stdio MCP サーバー。ブローカー接続やポリシー変更はありません	ブローカーアダプター、執行エンジン、またはマーケットデータフィード
監査可能なチェック。すべての評価がローカルの JSONL ログに書き込まれます	クラウドサービス、データベース、またはテレメトリの送信先
USD のみ、単一レッグの注文、チェックごとに1つのスナップショット（v0.1）	複数レッグ、複数通貨、グリークス／IV 対応（制限事項を参照）

対象ユーザー

• 注文意図またはシミュレーション実行の経路がすでにあり、ローカルな監査証跡を備えた独立した決定論的な取引前ゲートを求めているチーム。
• 自社の執行パイプラインに統合できる、小規模で依存関係が少なく、フェイルクローズ設計の構成要素を求めている開発者。
• プレーンな YAML で記述された、自ら管理するポリシーに照らして注文を評価したいすべての方。

対象としないユーザー： 利益の保証、バックテストエンジン、ポートフォリオマネージャー、または自らを強制するツールを期待する方。エージェントがガードを呼び出さない場合や、BLOCKを無視した場合、このリポジトリの機能でそれを阻止することはできません。

中核となるセキュリティ境界

• ローカル： すべてがご利用のマシン上で動作します。アカウント認証情報が保存、読み取り、送信されることはありません。
• ネットワークを使わない中核経路： ライブラリ、CLI、MCP サーバーがソケットを開いたり、HTTP/SSE ルートを登録したり、相場情報などを外部に問い合わせたりすることはありません （MCP SDK の HTTP スタックは推移的依存関係ですが、ビジネスコードからインポートされることはありません）。
• 注文は決して発注しません： 中核パッケージ（ライブラリ、CLI、MCP サーバー）は ブローカーに接続する機能を持たず、注文を送信することもありません。読み取り専用のマッピング例は実験用として 開発ワークスペース内にのみ存在し、公開候補版や wheel には含まれておらず、 ライブ環境で検証された統合機能でもありません。
• フェイルクローズ： データがない、または不正な形式の場合 → BLOCK（exit 3）。入力／設定エラー → exit 4。内部エラー → exit 5。状態が不確かな場合に PASS と報告することはありません。
• 方向はスナップショットから導出： 注文側を示すテキストが、決済の証拠として受け入れられることはありません。株式およびオプションの決済意図は、新しいポートフォリオスナップショットに、数量が十分な、対応する反対側のポジションが含まれている場合にのみ認識されます。 オプションの場合、symbol にはブローカー固有の完全なコントラクトコードを指定する必要があります。異なる満期、権利行使価格、権利区分の間で、原資産のティッカーを使い回さないでください。
• USD のみ（v0.1）： 通貨が一致しない場合（注文、ポートフォリオ、ポジション）は入力エラー（exit 4）となります。MCP のアカウントステータスツールは、通貨が一致しない場合にフェイルクローズします。

書き込み対象： このツールが policy、portfolio、キルスイッチの状態を変更したり、ブローカーに接続したり、注文を発注したりすることはありません。意図的にローカルファイルへ書き込む処理は次の 2 種類です。

1. 監査サブシステム： Guard.check() / check_order は、サニタイズ済みの v2 レコードを、論理監査パスと同じ場所にある UTC 日付のシャードに追記します（保持期間は 30 日間）。追記は共有ロック下で末尾に限定して行われ、履歴を書き換えることはありません。新しいコレクションに追記するには、事前に deadlatch audit init（または initialize_audit_state）を明示的に実行する必要があります。Guard/MCP が自動で移行することはありません。deadlatch shadow report と deadlatch audit prune は、30 暦日の期間外にあるシャードファイルを削除します。deadlatch audit repair --quarantine は、途中で切れた末尾部分を隔離する際も、ロック／一時ファイルと os.replace を使用します。通常の追記では、複数ファイルにまたがるクラッシュ時の原子性は保証されません。POSIX ロックはプロセス間で有効です。 v0.1.2 の永続的な監査書き込みは Linux/macOS のみで利用できます。Windows の書き込み処理では audit_platform_unsupported が返され、成功を報告するためにディレクトリの fsync を省略することはありません。
2. 明示的な移行出力： deadlatch migrate --output <file> は、--output を明示的に指定した場合にのみ、移行後のドキュメントを書き込みます。

これらのルール、Decimal のしきい値、終了コード、オプションシンボルの要件に関する公開仕様は、docs/rules-spec.md に記載されています。

12 のルール（v0.1）

#	ルール	対象
R1	kill_switch	グローバルスイッチ：off / full（すべてをブロック） / reduce_only（推定される決済注文のみ許可）
R2	input_validity	注文がスキーマ、バージョンゲート、通貨の整合性、有限の金額を満たしていること（違反時 → exit 4）
R3	max_order_quantity	1 件の注文の数量上限
R4	max_order_value	1 件の注文の想定元本上限（オプション：価格 × 乗数 × 数量）
R5	max_symbol_exposure	原資産ごとのエクスポージャー（オプション：権利行使価格 × 乗数 × 数量）
R6	max_total_exposure	ポートフォリオのグロスエクスポージャー比率
R7	cash_margin_check	取引後の現金下限とショートオプションの証拠金
R8	max_daily_loss	日次損失比率（損益 / その日の開始時の純資産）
R9	max_drawdown	ピークからのドローダウン比率
R10	order_time_validity	注文の経過時間 / 未来のタイムスタンプ（解析不能な場合はフェイルクローズで BLOCK）
R11	data_freshness	ポートフォリオスナップショットの鮮度（未来のスナップショットはフェイルクローズ）
R12	missing_data_fail_closed	ポートフォリオデータの欠落 / null / 不正な形式 → exit 3（データが使用不能な場合はリスク）

任意のルール（R3–R7）は、policy.yaml の設定キーで切り替えます。任意のキーがない場合は、 acknowledged_disabled で宣言する必要があります。宣言されていない場合、ポリシーは拒否されます （exit 4）。必須ルール（R1、R2、R8–R12）は無効化できません。

終了コード

コード	意味
0	PASS — 注文は指定された内容のまま許可されます
2	WARN — 実行ポリシーで警告を明示的に許可している場合にのみ続行します
3	BLOCK — 注文を送信してはいけません（リスクルールまたはフェイルクローズデータ）
4	入力 / 設定エラー — リスク事象ではなく、呼び出し元による API の誤用です
5	内部 / ルール例外 — BLOCK として扱われます（フェイルクローズ）

シャドウモードでは、内部判定が記録され（shadow_verdict）、外部への投影は PASS / 0 になります。キルスイッチへの抵触と exit 4/5 は投影によって隠されることは ありません。

データコントラクトと移行

スキーマはバージョン管理された JSON Schema 2020-12 ファイルで、パッケージに含まれています： order、portfolio、policy、result、audit-record、shadow-report、 audit-maintenance-result、audit-prune-result、audit-write-state、 audit-state-result。 レガシー文書には、明示的なオフライン移行を利用できます：

deadlatch migrate --kind order    --input order_v1.json    [--output out.json]
deadlatch migrate --kind policy   --input policy_v1.json   [--output out.json]
deadlatch migrate --kind portfolio --input portfolio_v1.json [--output out.json]

移行では、裁定対象のフィールドのみを変換します（例：policy v1 のブール値のキルスイッチ → off/full）。業務上のフィールドを推測することはありません。通常の評価エントリーでは、 旧バージョンを黙って移行せず、拒否します（exit 4）。

監査ログ

各 Guard.check() は、論理パスの隣にある UTC 日付ごとのシャードに v2 レコードを 1 件追記します（デフォルトは ~/.deadlatch/audit.jsonl、--audit-path / DEADLATCH_AUDIT_PATH で変更できます）。追記する前に、新しいコレクションを deadlatch audit init / initialize_audit_state で一度初期化する必要があります。状態がない場合は書き込みを拒否し、ディレクトリをスキャンして再構築することはありません。v0.1.2 より前の単一ファイルは、従来の v1 として引き続き読み取れます。レコードはスキーマ検証され、サニタイズされます（認証情報、Cookie、絶対パスは平文に含まれません）。保持期間はシャードの暦日で 30 日間です。追記時に履歴が再書き込みされることはなくなりました。UTC シャードの日付は、コレクションのロック取得後に決定されます（デフォルトの時計または明示的な now を使用します）。永続的な書き込み日付のウォーターマーク（audit.jsonl.state.json）により、後の日付が予約された後は、それ以前の UTC 日付への書き込みが拒否されます。これには 30 日／365 日の空白がある場合も含まれます。元のログと状態のバイト列は変更されません。このウォーターマークは順序を制御するものであり、署名ではありません。evaluated_at は書き換えられません。期限切れのシャードを削除するには、deadlatch shadow report または deadlatch audit prune を使用してください。従来のファイルは自動削除されません。監査ログへの書き込みに失敗した場合、返される結果は重大度のみが上昇します。PASS/0 は WARN/2 になり、BLOCK/3/4/5 は判定を維持したまま audit_write_failed 警告のみが付加されます。ディスク上の内容と返される Result が矛盾することはありません。docs/audit-write-state.md を参照してください。

v0.1.2 のレコードには、ローカル SHA-256 ハッシュチェーン（prev_hash / record_hash）が含まれます。このチェーンは改ざんの検知を可能にするものであり、デジタル署名でも、改ざん防止機能でもありません。ディレクトリ全体を書き換えてハッシュを再計算できる攻撃者は対象外です。外部の不変アンカーがない場合、現在の最終レコードまたは表示されているレコード一式の削除は、チェーンだけでは確実に検知できません。

deadlatch audit verify は、表示されているコレクション（従来のファイルと、暦日で 30 日間の範囲内にある UTC シャード、および prune によって残される将来のシャード）をスキャンします。内容の変更や隔離ファイルへの書き込みは行いません。期限切れのシャードが prune されずに残っていても、チェーン検証の対象にはなりません。既存のコレクションでは、append/repair/prune と同じロックを共有するために .lock サイドカーを作成する場合があります。破損した従来の v1 の行は、deadlatch audit repair --quarantine で引き続き隔離できます。v2 の repair で隔離できるのは、最後のシャードの途中で切れた最終行のみです。ハッシュの不一致、ID の重複、バージョンのダウングレード、チェーン途中の破損がある場合、自動的な再リンクは拒否されます（終了コード 3、書き込みなし）。Shadow report と MCP recent_decisions は、同じロックの下で同じスナップショットを読み取り、レコードを返す前にハッシュ、チェーンのリンク、重複 ID、バージョンの配置を検証します。改ざんまたはダウングレードされたチェーンは、信頼できる履歴として提示されません。v1 との互換性は、従来のベースラインファイルに限られ、v2 レコードが一件もない場合にのみ有効です。UTC 日付のシャードにある v1 の行は拒否されます。G1 のオプション方向の修正についての架空の説明は、docs/postmortem-option-direction.md を参照してください。

MCP サーバー

deadlatch-mcp は stdio 専用の MCP サーバーです（TCP リスナー、HTTP/SSE ルートはありません）。5 つのツールはすべて 読み取り専用です。いずれのツールも policy、portfolio、キルスイッチの状態を変更できません（これらのパスは起動時の設定であり、ツールの引数ではありません）。ポリシーの変更は検証され、次のツール呼び出し時に自動的に読み込まれます。任意の独立したキルスイッチファイルは呼び出しごとに読み込まれ、ポリシーをさらに制限することしかできません。サーバーは各 check_order の評価をローカル監査ログに追記します。これは設計上の動作であり、ツールの機能ではない点に注意してください。5 つのツールは次のとおりです。

ツール	目的
check_order	1 件の注文を評価します。完全な result（判定、終了コード、違反、証拠）を返します
get_account_status	スナップショットの鮮度、エクイティ、現金、PnL、ドローダウン、エクスポージャーの利用率を取得します
get_policy	有効なポリシーの読み取り専用の概要を取得します
kill_switch_status	現在のキルスイッチモードを取得します（読み取り専用。変更できるツールはありません）
recent_decisions	最近の監査記録を取得します（古い順、任意の since／limit を指定可能）

次のように起動します。

deadlatch-mcp --policy policy.yaml --portfolio portfolio.json \
  [--audit-path audit.jsonl] [--kill-switch-path kill-switch]

パス引数は起動時の設定のみです。ファイルの内容は引き続きローカルの状態として扱われます。設定されたキルスイッチファイルには、off、reduce_only、full のいずれかだけを記載する必要があります。ポリシーにすでに設定されている、より厳しいモードを緩和することはできません。稼働中のポリシー／スイッチが存在しない、不正な形式である、または同時に不安定な状態にある場合は、安全側に倒して失敗します。ツールエラーは isError=true + fail_closed となり、設定エラーには input_error=true + exit_code=4 が含まれます。

デモ

エージェントが過大な注文を check_order で評価すると、ガードは該当ルールとともに BLOCK / 3 を返します。エージェントはブローカーのツールを呼び出さずに停止します。架空のデータを使用した、実際のローカル MCP stdio 実行から生成されています（tools/make_demo_gif.py）。

既知の制限事項（v0.1）

• 裸のショートコールは、上昇リスクが無制限です。v0.1 では権利行使価格に基づくエクスポージャーの近似値を使用しており、この無制限のテールリスクはモデル化されません。ショートコールに対する保守的な上限として扱わないでください。
• 空売りによる現金流出は 0 としてモデル化されています（仕様として明記された簡略化です）。
• グリークス、IV、マルチレッグ戦略、複数通貨のポートフォリオには対応していません。
• 監査ログのプロセス間ロックは POSIX fcntl に依存します。POSIX 以外のプラットフォームでは、ロックはプロセス内ロックに格下げされます（プロセス間の保証はありません）。
• v0.1.2 の永続的な監査ログ書き込みに対応しているのは Linux と macOS のみです。Windows およびその他のプラットフォームでは、ロックの作成や状態の書き込みを行う前に、audit_platform_unsupported を返して init／append／repair／prune／シャドーレポートを拒否します。対応プラットフォームでのファイルおよびディレクトリの fsync の失敗時は、引き続き安全側に倒して失敗します。「機能がない」として扱われることはありません。停止済みスナップショットのオフライン検証／読み取りは引き続き利用できます。Windows での同時書き込みは対象外です。
• ガードは完全な回避を防げません。エージェントがガードを呼び出さない場合や、BLOCK を無視してブローカーを直接呼び出す場合、このツールでは停止させられません。
• リポジトリ内の例では、架空のティッカーとデータのみを使用しています。

ガバナンス

• SECURITY.md — 対応バージョン、脆弱性の対象範囲、報告方法。
• docs/rules-spec.md — 公開されている 12 ルールの仕様。
• CONTRIBUTING.md — 環境、テスト／スキーマ／スキャン／カバレッジのコマンド、ルールの運用方針。
• DISCLAIMER.md — 法的免責事項／リスクに関する免責事項の全文（以下に要約を記載）。
• README.zh-CN.md — 中国語のドキュメント。

免責事項（要約）： 投資助言ではありません。損失を防ぐ保証はありません。入力とルールはご自身で検証してください。ガードが注文を発注することはありません。すべての例は架空のものです。実資金で取引する前にテストしてください。SLA はありません。詳細は DISCLAIMER.md をご覧ください。