Skip to content

タイムトラベル

Chronicle を象徴する機能です。セッション内の任意のメッセージをクリックすると、Git 履歴から再構築された、その瞬間そのままのコードを確認できます。

Playback モードこそが「タイムマシン」という名前の由来です。フラットなトランスクリプトをスクロールする代わりに、セッションを移動しながら、その下でコードベースが変化していく様子を見られます。専用のスナップショットストアも、現在の作業ツリーへの依存もありません。Chronicle は各メッセージのタイムスタンプを Git 履歴に照合し、そこからツリーとファイルの内容を再構築します。コードの状態については Git が信頼できる唯一の情報源です。

Playback のレイアウト

セッションを開き、Playback(左レール、または ⌘2)に切り替えます。3 ペア構成のビューです。

  • 会話リスト(左)。 すべてのメッセージが役割ごとにタイプ分けされます(User、Assistant、Thinking、Tool Call、Tool Result)。アプリの他の部分と同じ、役割に忠実なラベルを使用します。メッセージをクリックすると選択できます。長いメッセージは「Show all」トグルで省略表示され、非常に大きなセッションでは、Chronicle は選択箇所の周辺 約 400 行のウィンドウのみをレンダリングします(「earlier / later messages」ボタン付き)。これによりスクロールが高速に保たれます。
  • コードスナップショット(中央)。 選択したメッセージの時点でのファイルツリーとファイルの内容です。
  • TimberLine(下部)。 スクラブ操作のための、セッション全体のタイムラインです。

メッセージを選択すると、他の 2 つのペインが同時に切り替わります。

スナップショットが解決される仕組み

メッセージをクリックすると、Chronicle はそのタイムスタンプを取得し、その時刻以前で最も近いコミットを Git に問い合わせます(server/git.jscommitAt()。内部で git rev-list -1 --before を実行します)。そのコミットがスナップショットになります。

  • ファイルツリーは、そのコミット時点の git ls-tree です。
  • ファイルを選択すると、git show <commit>:<file> を通じてその内容が表示されます。
  • そのコミットで変更されたファイルにはツリー内で緑のドットが付き、最初の 1 件が自動選択されます。そのため、AI が実際に触れていた対象にすぐたどり着けます。

メッセージがすべての履歴より前の時刻である場合、Chronicle は最も古いコミットにフォールバックし、**「before first commit」**バッジで示します。これにより、正確な一致ではなく利用可能な最も初期の状態を見ていることが分かります。

Note: スナップショットは再構築された履歴であり、現在のディスクの状態ではありません。表示されるのはそのコミット時点でのファイルの姿であって、現在の作業ツリーの内容でも、未コミットの中間状態でもありません。

差分ビュー

D(またはコードツールバーの ± Diff ボタン)を押すと差分表示を切り替えられます。選択中のファイルを直前のコミット済みバージョンと比較し、追加/削除された行をインラインで表示します。変更のない行が長く続く箇所は数行のコンテキストに圧縮され(「··· N unchanged lines ···」マーカー付き)、実際の変更が際立ちます。このスナップショットでファイルが実際には変更されていない場合、Chronicle は空の差分を表示するのではなく、その旨を伝えます。

TimberLine

TimberLine は、会話の時間軸とコードの時間軸を結び付けるスクラバーです。マークの意味は次のとおりです。

  • 青いドット — ユーザーメッセージ
  • 緑の四角 — Git コミット
  • グレーの目盛り — AI およびツールのイベント

操作方法:

  • 任意の位置をクリックまたはドラッグしてシークします。Chronicle は最も近いメッセージにスナップし、それに合わせてスナップショットを更新します。
  • ホバーすると、カーソル位置のタイムスタンプが表示されます。
  • タイムラインにフォーカスがあるとき: / でカーソルを 1% 単位で動かし、Home / End でセッションの先頭または末尾にジャンプします。

巨大なセッションでは、タイムラインは AI/ツールの目盛りを間引いて(約 600 まで)読みやすさを保ちます。ただしコミットは常にレンダリングされます。これらはタイムトラベルを成立させるアンカーだからです。

Git の前提条件と再現精度

タイムトラベルには、コミットのある Git リポジトリが必要です。プロジェクトがリポジトリでない場合(またはコミットがない場合)、コードペインは「No Git history」の空状態を表示し、会話の Playback は引き続き動作すること(ただしスナップショットは得られないこと)を説明します。プロジェクトの Git ピルとヘッダーで、リポジトリの状態をひと目で確認できます(プロジェクト管理を参照)。

再現精度はコミット頻度に比例します。Chronicle は履歴に実際に記録された時点のコードしか再構築できないため、頻繁にコミットするプロジェクトは、少数の大きなコミットしかないプロジェクトよりも、緻密で正確なリプレイを得られます。スナップショットエンジンがコミットの照合、ツリー/ファイルの解決、マージコミットの処理までをエンドツーエンドでどう動かしているかについては、Git スナップショットエンジンを参照してください。

関連

Released under the MIT License.