1. 実行前の責任経路を登録する
誰が実行し、誰が承認し、問題が起きたときに誰へ戻すかを登録します。RPRは、その内容と最初の証拠をSQLiteへ保存します。
実RPR wheel・ブラウザ内Python・SQLite
APIへ書き込んだ直後に通信が切れ、成功したか分からなくなった。そんな場面で、すぐ再送せず、状態を保存し、再起動後に外部の結果を確かめる流れを体験できます。
このデモでは、GitHub ActionsでRPRのソースから生成したwheelをPyodideへ読み込みます。RPR本体、SQLite、実行履歴、証拠チェーン、照合処理は実際に動作します。
実行シナリオ
誰が実行し、誰が承認し、問題が起きたときに誰へ戻すかを登録します。RPRは、その内容と最初の証拠をSQLiteへ保存します。
人間の承認後に、外部サービスへ1回だけ書き込みます。外部側では処理が完了しますが、応答だけが失われた状態を発生させ、結果不明として保存します。
RPRを新しく起動し直し、同じSQLiteから未解決の操作を読み戻します。外部サービスの状態を確認し、再送せずに完了へ進めます。
実行結果
RPRを読み込むと、ここに状態、外部実行の回数、証拠チェーンの検証結果を表示します。
まだ実行結果はありません。
デモの範囲
公開RPR wheel、Python Runtime API、状態遷移の検証、SQLiteへの保存、実行履歴、証拠チェーン、再起動後の読戻し、照合処理。
外部の決済サービスだけを、ブラウザ内の決定論的な処理へ置き換えます。反映済みの状態と実行回数は、RPRとは別に保持します。
OS subprocess、実MCP、秘密情報、実決済、外部サービス認証、Lean 4のbuildはブラウザ内では実行しません。Lean 4の形式資産はRepositoryとCIで検査します。