Muse Code の売りのひとつが「落ちても中断地点から再開できる」ことです。その実装は muse exec --json の出力を見ると分かります。イベントソーシング型の設計になっています。
1件のイベント
{
"schema_version": 1,
"id": "018f0000-0000-7000-8000-00000000c362",
"stream": { "kind": "session", "id": "b3880833-..." },
"sequence": 12,
"record_type": "event",
"durability": "durable",
"causation_id": "7a84409c-...",
"payload_type": "task.lifecycle.scheduled",
"payload_schema_version": 1,
"payload": { ... }
}
各フィールドの意味
| フィールド | 意味 |
|---|---|
| stream | 所属するストリーム。session / run / task の3種類 |
| sequence | ストリーム内の連番。順序の再現に使う |
| record_type | event / status / reconciliation |
| durability | durable（残す）か ephemeral（残さない） |
| causation_id | このイベントを引き起こしたコマンドのID |
| payload_type | イベントの種類（後述） |
| schema_version | スキーマの版。将来の互換性のため |
特に durability の区別が効いています。途中経過の表示（run.output.delta など）は ephemeral で、記録には残りません。再開に必要な事実だけが durable として残ります。
タスクのライフサイクル
実際に観測できた遷移は次のとおりです。
task.lifecycle.proposed 提案された task.lifecycle.accepted 受理された task.lifecycle.scheduled 実行予定に入った task.lifecycle.side_effect_intent 副作用の実行意図 task.lifecycle.started 開始 task.lifecycle.completed 完了 task.lifecycle.failed 失敗
単に「開始・終了」ではなく、提案 → 受理 → 予定 → 意図表明 → 開始 と細かく段階が分かれています。どこで落ちても、どこまで進んだかが分かる粒度です。
冪等キー
scheduled のイベントには idempotency_key が入ります。
"idempotency_key": "model:7a84409c-...:ce8ff758-..."
実行IDとタスクIDを組み合わせた文字列です。中断して再開したときに、同じモデル呼び出しを二度実行しないための仕組みです。「再開できる」という機能が、ログの体裁ではなく実行の同一性の担保として設計されていることが分かります。
副作用の方針判定
side_effect_intent というイベントには policy_decision というフィールドがあります。外部に影響する操作を実行する前に、方針による判定を通していることを示しています。承認モードやサンドボックスの設定は、ここで効いていると考えられます。
観測できたその他のイベント
runtime.command.accepted— コマンドの受理session.run.linked— セッションと実行の紐付けtask.stream.linked— タスクストリームの紐付けturn.input.user— ユーザー入力run.lifecycle.started— 実行の開始run.output.delta— 出力の断片（ephemeral）run.terminal.completed— 実行の終了
ログをディスクに残したくない場合は --no-session-log を付けます。