ユーザーには 試行モード として見せ、内部では dry_run、simulate、readonly を使い分けます。役割が違うので、1つに統合すると検証の抜けが出ます。
| モード | 何を止めるか | いつ使うか |
|---|---|---|
| dry_run | KabuLink側の実発注 | Webhookの流れ、注文内容、監査ログだけを先に確認したいとき |
| simulate / paper | ブローカー側の実口座発注 | ブローカーが模擬口座を持つときに、本番に近い約定確認をしたいとき |
| readonly | AgentやローカルAPIからの送信 | Gateway / OpenD / kabuステーションの接続だけを確認したいとき |
dry_run は KabuLink の中で止めます。simulate と paper は ブローカー側の模擬環境です。readonly は 接続確認だけを通し、注文送信を止めます。つまり、止めたい場所が違います。1つの名前で見せても、内部では別々に処理する必要があります。
dry_run で、Webhookと注文ログの形を確認する。simulate / paper で本番に近い流れを見る。readonly で、Gateway / OpenD / kabuステーションの接続だけ確認する。ユーザー向けの名前は1つでよいですが、止めたい層が違うため、内部では分けて持つ必要があります。
初回は dry_run、ブローカーの模擬口座があれば simulate / paper、Agent型なら readonly から始めるのが分かりやすいです。