レコーダー

recording lifecycle は 1 つの capture scope、1 つの WAL domain、1 つの finalization path を所有します。通常のユーザーは command mode から始めます。

chronicle record --name checkout -- ./my-app

コマンドモードのライフサイクル

1. 公開 data directory を解決してロックします。
2. recording identity と上限付きの WAL domain を準備します。
3. 監視対象のコマンドを起動する前に capture source をアタッチします。
4. 正規化されたイベントを上限付きの queue に取り込みます。
5. group commit で evidence を WAL に書き込み、欠損を可視化します。
6. プロセス終了、signal、期間の上限、物理 WAL limit のいずれかで停止します。
7. 権威ある WAL prefix を復旧します。
8. ETL を実行し、canonical session を atomic に公開します。
9. canonical publication の後にだけ advisory catalog を更新します。

recording が復旧可能なら、finalization の失敗時に再キャプチャする必要はありません。

chronicle record --retry checkout

継続レコーダー

リポジトリには対応するデプロイ向けの上限付き continuous recorder も含まれています。意図指向の公開 CLI surface が安定するまで、foreground entrypoint は非公開のままです。1 つの filesystem domain、epoch rotation、incremental ETL resume、liveness／health metadata、shutdown cleanup を所有します。

これは常時稼働する分散キャプチャサービスではありません。recorder state、WAL、manifest、checkpoint、catalog fact はローカルに保持され、上限もあります。この高度な経路を運用する前に、リポジトリの recorder runbookを確認してください。現在のローカルデプロイでは recorder runtime と incremental ETL を同一プロセスに配置しています。これはトポロジーの選択であり、論理的な所有権ではありません。ETL は独立した境界のままです（ETL を参照）。1 つの .chronicle-domain.lock がローカル filesystem の調整ドメインを保護しますが、Recorder と ETL の間のアーキテクチャ上の所有メカニズムではありません。

停止と復旧

最初の termination signal では、設定された上限内で drain と finalization を行います。強制終了や容量制限は recording metadata と WAL-loss evidence に残ります。復旧が修復するのは検証済みの不完全な final tail だけであり、完全な破損を隠したり acknowledgement history を作ったりはしません。