TeXChronicle — セクション対応 LaTeX 履歴とライブ編集

English · 简体中文 · 日本語 · 한국어 · Español · Français · Deutsch · Português

TeXChronicle は、論文の編集・レンダリング・復元を目的とした、人間中心の LaTeX ワークスペースです。ソースエディタ、編集可能なライブドキュメントビュー、正確な PDF プレビュー、アンカー付きコメント、セクション対応の Git 履歴を 1 つのブラウザウィンドウに統合しています。コンパイルが成功するたびに、ソースとそのときの正確な PDF を記録しますが、論文の通常の Git ブランチは変更しません。

単体で動作し、LLM はオプションです。Claude Code、Codex、その他の MCP 対応エージェントは、同じファイルを編集したり、必要に応じてコメントに対応したりできます。ポータブル版 Windows ビルドには、独自のコンパイラ、ブラウザランタイム、Node.js、Git が含まれているため、受け取る側に TeX のローカルインストールや Overleaf アカウントは必要ありません。

ワークスペース

1 つのブラウザウィンドウ（Typst のシンプルな全面エディタと LiquidText のアンカー付き注釈に着想を得ています）:

┌──────────────────────────────────────────────────────────────┐
│  ✓ up to date · 13 pages        Export .zip · Download PDF   │
├────────────┬──────────────────────────────┬──────────────────┤
│ Source /   │          PDF (live)          │    Comments      │
│ History    │  select text → 💬 comment    │  accepted → ask  │
│  editor,   │  highlights stay anchored    │  Claude to       │
│  timeline  │  auto-reloads on every edit  │  address them    │
│  + diffs   │                              │  → resolved ✓    │
└────────────┴──────────────────────────────┴──────────────────┘

• コメント → Claude ループ（そのための核となる機能）。 レンダリング済みドキュメントを、スーパーバイザーが印刷物にチェックを入れるように確認します。テキストを選択してコメント（例: 「この段落を簡潔に」）を付け加えます。次に Claude に 「コメントに対応して」 と指示すると、Claude は check_comments を介してコメントを配置された作業項目として取得します（ページ + 引用した箇所 * それが連結するソース file:line + あなたのリクエスト）。それからソースを編集し、各カードをメモ付きで解決します。あなたはドキュメントを操作し、Claude はソースを操作します。/loop で手を離して実行できます — docs/progest.md を参照してください。

• 編集可能なソース表示。 プロジェクトのファイルを表示する CodeMirror(bidirectional) LaTeXエディタ。保存（Ctrl+S）で PDF を再コンパイルして更新します。Typst と同じように。お気に入りのエディタを使い続けることもできます。どの編集であっても保存すれば、同じライブ・ループが起動します。Code、Live、および PDF は、キャンバス全面を選択可能なワークスペースです。Live は通常の学術用 LaTeX をすぐに編集可能なドキュメントに変換します（見出し、散文、引用、脚注、リスト、数式、図、表）。単語を編スる場合、その正確なソース範囲だけが変更されます。数式、引用符、参考文献、コマンド、コメント、そして未編集の書式はすべてバイト単位でそのまま保持されます。保護する必要がある構造は、Code 内で表示されたまま編集も可能で、PDF の正確性は維持されます。比較したい場合は、Split でソースまたは Live を PDF と並べて配置できます。

• PDF → 正確なソース。 ローカル TeX バックエンド が生成した PDF 内のポイントをクリックすると、SyncTeX 経由で対応するソースファイルとテキスト行が開きます。表示テキストの絞り込みは、マクロで展開される title/author 部分にも対応し、同梱の WASM バックエンドに SyncTeX マップがない場合の最大限のフェイルセーフとなります。

• ライブリロード。 ファイルウォッチャーが保存のたびに再コンパイルします（Claude の編集、ビルドインエディタの編集、外部エディタの編集のいずれでも）。

• Section-aware な変更履歴。 成功するコンパイルのたびに、Git の隠し参照（refs/latex-preview/checkpoints）へ自動的にスナップショットとして保存され、ブランチ、git log、ワーキングツリーには一切触れません。復元時には、まず元に戻すことが可能な安全スナップショットを取得します。さらに別のマーカーにより、未レンダリングの復元状態が誤って「成功した PDF」として扱われることはありません。履歴はラベルと曖昧マッチングによって、編集・リネーム・移動を超えてすべてのセクションとサブセクションを追跡します。専用タイムラインでそのテキストのみ（あるいはそのサブツリー全体）を比較し、論文の他部分をロールバックせずにパーツを復元し、そのチェックポイントで生成された正確な PDF を再び開くことができます。プロジェクト全体のタイムラインも利用できます。

• Overleaf に到達。 PDF ダウンロード、.zip 書き出し（クリーンなビルド入力を一式まとめたバンドル）、および公開 GitHub リポジトリと連携するワンクリック Open in Overleaf リンク。Premium の Git ブリッジ同期は、文書化された git push で対応します。docs/USER-GUIDE.md を参照してください。

• レビューワークフロー（reviewer → gate → resolver）。 レビュー側/防御側エージェントが add_comment を使用してコメントを投稿します。あなたはそれらを 受け入れる/拒否 します（または Copilot モードに Auto-accept を設定します）。著者ループが受け入れられたコメントを解決します。コメントには「役割」と「返信スレッド」が含まれています。docs/AGENT-LOOP.md を参照ください。

• 保存と再コンパイルはあなた次第。 内蔵エディタは再コンパイルせずに 30 秒ごとに自動保存します。Ctrl+S / 保存 / 再コンパイル で PDF をオンディマンドに再ビルドします。（⚡ Live をオンにすると、入力中の再コンパイルが有効になります）。あなたの外部エディタや Claude の編集も、ウォッチャーで自動再コンパイルされます。

• 実プロジェクト対応。 メインファイルを自動検出し、複数ファイルの \input/\include、.bib、リポジトリ内の .cls/.sty/.bst と画像を収集し、BibTeX を実行して必要な場合に再実行します。よく使われる不足パッケージは自動的にインジェクションします。

• コンパイルバックエンド。 ローカルの latexmk が利用可能ならそれを使用します（全パッケージ対応、Overleaf と同等の出力）。利用できない場合は同梱のインストール不要 WASM TeX Live を使用します。backend: "system" / "wasm" の指定でどちらかに固定できます。どのコンパイルがどちらを実行したかを必ず表示します。

• ドキュメントクラス。 WASM 版 TeX Live には会場クラスが含まれず、パッケージのように回避が効かないため IEEEtran は同梱しています。会議クラス（NeurIPS、ICML、CVPR、ACL、AAAI など）には再配布可能なライセンスがないので、著者キットの .cls をソースの隣に置いてください — 自動的に拾われます。

• MCP ツール: render_preview（コンパイル＋ワークスペースを開く）、check_comments / resolve_comment / add_comment / reply_to_comment（レビューループ）、show_diff（画像としてサイド・バイ・サイド差分を表示する、画像対応クライアント役）。

• 具体的なエラー表示。 コンパイル失敗時は解析済みの {file, line, message} エラーが返され、Claude が自己修正できます。ワークスペースにも反映されます。

Related MCP server: Unofficial Overleaf MCP Server

LLM なしでエディタを実行

ポータブル版 Windows（インストール不要）

リリースから TeXChronicle-<version>-Portable-Windows-x64.zip をダウンロードし、フォルダ全体を展開して、TeXChronicle.exe をダブルクリックしてください。独自の Node ランタイム、Git、ヘッドレス Chromium、完全な BusyTeX アセットバンドルが含まれているため、受け手は npm、Node、Git、Perl、TeX をインストールする必要はなく、の初回コンパイルも行にはダウンロード不要です。適当な論文を選び、そのメインの .tex ファイルに移動するか、そのファイルを TeXChronicle.exe にドラッグしてください。

これはポータブルフォルダであり、インストーラではありません。エクスポートと同じ場所にサブフォルダを置いてください。論文のチェックポイント、コメント、保存されたレンダリング出品の写真は、論文の .latex-preview ディレクトリに残ります。そのため、Dropbox や別の一般的なフォルダ同期ツールでマシン間を同期できます。同時に一度にすべてのマシンで編集しないでください。同じ論文を別の場所で開く前に同期を完了させてください。オフラインで2台のマシンから同じ論文を編スと、チェックポイント履歴が分岐する可能性があります。ポータブル版 Windows ガイド で、共有、チェックサム、更新、制限事項、再現可能なビルドコマンドを参照してください。

ワンクリックランチャー(Windows)

TeXChronicle をインストール/リンクした後、デスクトップとスタートメニューのショートカットを一度だけ作動します。

texchronicle install-launcher

これ以降は、覚えるプロジェクトコマンドはありません。TeXChronicle をクリックすると、最近使ったプロジェクトウィンドウに、以前開いた論文の一覧が表示されます。新しいメイン .tex ファイルには 参照… を使いります。論文をダブルクリックすると、ブラウザワークスペースが開きます。また .tex ファイルをデスクトップ ショートカットにドラッグすることもできます。すでに実行中の論文を開こうとすると、新しいゲーム用コンパイラを開始する代わりに、既存のワークスペースが再利用されます。小さなステータスウィンドウがローカルワークスペースを稼働し続けます。終了したら閉じてください。texchronicle open を実行すると同じ最近のプロジェクト選択画面が表示されます。

ターミナルでの起動

npm リリースまでは、ふつうに GitHub から直接、 этат install — クローンもビルド不要です。

cd /path/to/paper
npx -y github:Aliutin/TeXChronicle preview main.tex

npm はリポジトリをクローンしてインストールし（UIビルド含む— 何が行われどのくらいかは「LLM/MCP クライアントを使ったセットアップ」を参照）、ワークスペースを実行します。npm リリース発表後は、同じコマンドは npx -y texchronicle preview main.tex になります。

代わりにソースのクローンを使う — 開発者向けの方法 — オルトインストールとリンクを一度だけ行ってください。

npm install
npm run build:ui
npm link

npm run build:ui がブラウザワークスペースを構築します。これがないと、新しくクローンしたプロジェクトは基本的なビューア（エディタ、履歴、コメントなしの PDF ペイン）にフォールバックします。

その後、任意の LaTeX プロジェクトディレクトで実行できます:

cd /path/to/paper
texchronicle preview main.tex

ブラウザワークスペースが開き、そのターミナルが動作している間はライブ状態を維持します。⚡ Live でタイプしながら再コンパイルするか、Ctrl+S で保存してからコンパイルします。クリーンなレンダリングはすべて History に記録されます。Ctrl+C で停止します。プロジェクトが他の場所にある場合は、texchronicle preview --project /path/to/paper main.tex とします。

Claude Code、Codex、その他の MCP クライアントはオプションです。これらを開いたり使用したりする必要はありません。ただし、このスタンドアロンのワークスペース実行中に同じファイルを編集することは可能です。

LLM/MCP クライアントのセットアップ

パッケージと MCP のメタデータは、texchronicle と io.github.Aliutin/texchronicle を使います。npm パッケージはまだ公開されていません — npm view texchronicle はまだ 404 です — そのため GitHub からインストール してください。npm が直接行うので、自分でクローンやビルドは不要です:

1. あなたの論文プロジェクトの .mcp.json に追加（.mcp.json.example を参照）:

   {
     "mcpServers": {
       "texchronicle": {
         "command": "npx",
         "args": ["-y", "github:Aliutin/TeXChronicle"]
       }
     }
   }

   npm は、リポジトリをクローンし、インストールします。このパッケージには prepare スクリプトがあるため、npm は devDependencies もインストールし、パック前に prepare を実行します。そのスクリプトは npm run build:ui であるため、ブラウザワークスペース（ui/dist）は事後に行わずに、インストールの一部として構築されます。その後、postinstall ステップで Playwright のヘッドレス Chromium を取得します。この取得をスキップする方法、または既に持っているブラウザをポイントする方法は、Requirements を参照してください。

   GitHub ルートについていくつ留意が必要ですが、いずれもブロッカーにはなりません。マシンには PATH に git が必要です。また、インストールが devDependencies（React、Vite、TypeScript）を取得して UI をビルドするため、通常のレジストからのインストールよりへの圧倒的に遅くなります。そして、npx を実行するたびに、ネットワーク経由で git 参照を再解決します。どれだけ以前の実行を再利用できるかは npm のバージョンに依存します。

   もう2つの形式があります:

   • ソースのチェックアウト — これは開発者向けの方法で、サーバーを 自分のがワーキングツリーにしたい場合に使用。あなたの自分のコードを変更する。TeXChronicle のフォルダで npm install を実行し（prepare → npm run build:ui が動き、クライアントをエントリスクリプトにポイントします: "command": "node", "arguments": ["/absolute/path/to/TeXChronicle/bin/cli.mjs"]。npx tsx src/server.ts ではなく bin/cli.mjs を使用してください。エントリスクリプトは Node のバージョンを確認し、必要が低すぎる場合に平易な言葉で伝えます。また、一部の Windows アカウントで必要な os.userInfo のフォールバックをプリロードします。直接呼び出した場合、src/server.ts はその両方をスキップして、MCP クライアントが -32000 としか報告しないような形で失敗します。 ui/ 以下の何かを編集した後は手動で npm run build:ui を再保存してください。 また、スクリプトが sktipされたクローン (npm install --ignorescripts`) は、ワークスペースの代わりに基本的なビューアを開き、その理由を示す画面は一切表示されません。

   • npm リリリース後、short form: "command": "npx"と"at.line": ["-y", "texchronicle"]。

2. Claude Code を再起動（または /mcp でコモを再接続）して、サーバーを認識させます。

3. Claude にレンダリングを依頼。 例: "この論文のプレビューをレンダリング" → 最初の呼び出しで WASM 版 TeX Live アセット（約650MB、一度全で）をダウンロードし、コンパイルして、ライブ型ビューを開きます。その後の変更は自動的にリロードされます。

どのフォルダを使うのですか?

サーバーが起動したフォルダです。Claude Code と Codex はプロジェクトディレクトに MCP サーバーを起動するため、論文のそばにある .mcp.json が必要なものはすべて揃っています。ただし一部のクライアント — その中の Claude Desktop — は代わりにホームディレクトリからサーバーを起動するため、そこではサーバーがコンパイルする論文がありません。その場合は、サーバーの設定エントリに名前を明示してください:

{
  "mcpServers": {
    "texchronicle": {
      "command": "npx",
      "args": ["-y", "github:Aliutin/TeXChronicle"],
      "env": { "TEXCHRONICLE_PROJECT": "/absolute/path/to/paper" }
    }
  }
}

or as a server argument, appended after the package: "args": ["-y", "github:Aliutin/TeXChronicle", "--project", "/abs/path/to/paper"] — and from a source checkout, "args": ["/abs/path/to/TeXChronicle/bin/cli.mjs", "--project", "/abs/path/to/paper"].

The third way needs no config change at all: pass projectRoot to render_preview — 「/Users/me/papers/thesis のプレビューをレンダリングして」 と伝えるだけで、 Claude がそれを埋めてくれます。これはセッション全体の対象を変えるため、その後に行うすべての ツール呼び出し（コメント、履歴、差分）も同じフォルダを使います。またこの方法は、 3 つの方法の中で唯一、エージェントが会話の途中で、設定ファイルを編集してクライアントを 再起動することなく、単独で適用できる方法です。

.tex ファイルが存在しない場所で起動されたサーバーは、そのフォルダを監視したり その中に履歴ストアを作成したりはせず、その旨を伝えて停止します — 拒否メッセージには 上記 3 つの方法のすべてが列挙されます。

WASM アセットはこのリポジトリにはありません。初回実行時にユーザーごとのキャッシュへ 取得されます — macOS では ~/Library/Caches/texchronicle、Linux では $XDG_CACHE_HOME/texchronicle、 Windows では %LOCALAPPDATA%\texchronicle — そのため、TeXChronicle をアップグレードしても 再ダウンロードされず、チェックアウト、グローバルインストール、npx での実行は 1 つのコピーを共有します。TEXCHRONICLE_ASSETS_DIR を設定すれば別の場所に配置できます。 事前に取得するには: npx texlyre-busytex download-assets <that directory>。

Claude Code プラグインとしてインストールする（スラッシュコマンド）

オプションの Claude Code プラグインを使うと、MCP サーバー と スラッシュコマンドの 両方が使えます。

/plugin marketplace add Aliutin/TeXChronicle
/plugin install texchronicle

npm リリースまでは、プラグインに同梱されるサーバーのエントリは、上記と同じ GitHub 形式 （npx -y github:Aliutin/TeXChronicle）なので、同じ注意点があります: PATH に git があり、 最初の起動は展開だけではなくインストールとビルドを行います。パッケージが npm に公開されたら、 npx -y texchronicle に切り替わります。

次に、論文プロジェクト内で、一般的なフローを ワークフローコマンド で進めます:

• /texchronicle — ワークスペースをコンパイルして開きます（ライブプレビュー）。

• /ai-review [skill] — スキルで論文をレビューし（デフォルトは academic-paper-revision。任意のスキル名を渡せます）、承認/却下の判断を求める コメントを投稿します。見つからないスキルはインストールのヒントとともに報告されます。

• /address-comments — 承認済みコメントを解決します（/loop 60s /address-comments でループできます）。

• ⚡ /ultra-agents [skill] [depth] — 完全自律モード: レビュー → 自動承認 → 修正を 最大 depth ラウンド（デフォルト 2）繰り返し、あるラウンドで新しい指摘が何もなければ そこで早期終了します。ラウンドごとの承認はありません — それが意図であり、リスクでもあります。 depth > 5 のときは開始前に確認を求めます。最後に要約が表示されます（何が指摘されたか、 何が変更されたか、どのチェックポイントを確認すればよいか）。ただし、各ラウンドは 通常どおり元に戻せるチェックポイントのままです。docs/AGENT-LOOP.md を参照してください。

ツールごとに 1 コマンド

各 MCP ツールには、同じ名前 のスラッシュコマンドもあります。ツール名を入力するだけで 任意の 1 ステップを実行できます。覚えるルールは、ツールが X なら → /X と入力する です。

これらを必ず入力する必要はありません。普通の自然な言葉でも動作します（「プレビューをレンダリング」、 「コメントを処理して」）。コマンドはたまた "高速でテキスト" なだけの別の表記です。

プラグインには commands/ フォルダに実際のスラッシュコマンドが含まれており、それを作成するのは プラグインだけです。サーバー自体はプロンプトを登録しないため、.mcp.json の設定では 下の表のツールだけが使え、/ ショートカットはありません。代わりに、やはり普通の英語感覚で 指示します（「プレビューをレンダリング」、「コメントを処理して」）。コマンドはそれを 展開したものに過ぎません。

ツール

MCP を話せるクライアンドのための MCP サーフェスです。（Claude Code では普通の文章で すべてもらったり、上記のスラッシュコマンドを使えます。これらはその裏にあるツールです。）

主要なワークフローは、これらツールの上に構築されたもので、枠の中 に含まれるものではありません。 /texchronicle、/ai-review、/address-comments、⚡ /ultra-agents は、上記のツールを 組み合わせて実行する Claude Code プラグインコマンドです。/ultra-agents は「レビュー → 自動承認 → 修正」を、ユーザーが許したラウンド数だけ連続して行います。add_comment が accepted フラグを受け取るのは、このためです。これらのコマンドは MCP サーフェスの一部ではないので、 別の MCP クライアントにはそれらツールしか見えません。プラグインのセクション と docs/AGENT-LOOP.md を参照してください。

ターミナルで見る

次のものは実際の出力で、サンプル論文を使った実際の実行からそのまま収録したものです — 作り物では ありません。ブラウザ側のワークスペース（上のイメージ）が同じ状態をライブに反映している間に、 Claude Code ではこれが見えます。

あなたが入力:

/texchronicle

Claude は render_preview を呼び出し、次のように返します:

✓ Compiled main.tex with xelatex in 1900ms — 2 files. Workspace (live preview,
source editor, history, PDF comments — auto-reloads on edits):
http://127.0.0.1:52042/app

あなた（またはレビュースキル）がコメントを残し、次に実行準備が何か何を尋ねます。Claude は check_comments を呼び出します:

1 accepted comment — edit each at its source location per the instruction, then
call resolve_comment with its id and a one-line note:

[id: 2fce9e3c8b5f] p.1 — "Sorting widgets efficiently is a long-standing problem"
  ↳ source: main.tex:15
  → Tighten this opening sentence.

(1 reviewer suggestion still awaits the human's accept in the workspace — not
actionable yet.)

Claude が編集を行い、resolve_comment を呼び出します:

✓ Resolved comment 2fce9e3c8b5f ("Sorting widgets efficiently is a long-standing
problem…") — the card now shows: Rewrote the opening sentence.

もう一度聞くと、承認済みキューは空です — まだ承認待ちの suggestion だけが残り、あなたの判断を 待っています:

No accepted comments. (2 already resolved.)

(1 reviewer suggestion still awaits the human's accept in the workspace — not
actionable yet.)

仕組み

Claude edits .tex ─┐
 file watcher ─────┼─▶ compile coordinator ─▶ headless Chromium ─▶ WASM TeX ─▶ PDF
 render_preview ───┘         (serialized)         (engine host)                │
                                                                               ▼
                     your workspace (/app)  ◀── WebSocket "reload" ◀── local HTTP server
                     Source · PDF · History · Comments        (serves /app + /latest.pdf)

WASM エンジンは DOM / Worker のグローバルが必要なので、サーバーが非表示のヘッドレス Chromium を コンパイル用ワーカーとしてホストしています。あなたが開くワークスペースは、WASM を含まない軽量な React + pdf.js アプリです。docs/ARCHITECTURE.md を参照してください。

flowchart LR
  H["👤 You<br/>Source · PDF · History · Comments"]
  A["🤖 Claude Code<br/>+ review / author agents"]

  H <-->|"select text →<br/>anchor comment"| SRV["Preview server<br/>HTTP + WebSocket · serves /app"]
  A -->|"7 MCP tools"| MCP["MCP server<br/>render_preview · show_diff · list_checkpoints<br/>check / resolve / add / reply_comment"]

  SRV --> CO["Compile coordinator<br/>(serialized)"]
  MCP --> CO
  A -. edits source .-> FILES[("Paper files · git repo")]
  FILES --> WATCH["File watcher"] --> CO
  CO --> ENG["WASM busytex<br/>(headless Chromium)"] --> PDF["/latest.pdf"]
  PDF -. live reload .-> H
  CO --> CK["git checkpoints<br/>(hidden ref) → History"]

  SRV <--> CJSON[(".latex-preview/<br/>comments.json")]
  MCP <--> CJSON
  CJSON -->|"check_comments<br/>(your accepted asks)"| A

Both front doors — you in the workspace, agents through the 7 MCP tools — meet at the same coordinator, comment store, and git history. You act on the rendered document (anchor a comment); Claude acts on the source (reads your comments via check_comments, edits, resolve_comment). That shared substrate is what makes the comment loop, the review workflow, and the entire history possible.

Requirements

The requirements below apply to the npm/source installation. The Windows portable release carries these runtimes itself and needs only 64-bit Windows 10 or later and a normal web browser for the workspace window. The TEXCHRONICLE_* variables named below are listed together in the user guide.

• Node 20.19+ (the floor chokidar and playwright actually need; the server checks at startup and says so)

• Playwright's headless Chromium (~150–300 MB), installed automatically: a postinstall step downloads it at install time, and if it is missing when the browser is first needed, that download is retried then. Ways to change that:

  • TEXCHRONICLE_SKIP_BROWSER_DOWNLOAD=1 (or Playwright's own PLAYWRIGHT_SKIP_BROWSER_DOWNLOAD=1) skips the download — useful on a metered connection, in CI, or in a container built offline.

  • With no Playwright Chromium present, TeXChronicle falls back to a Chrome or Edge already installed on the machine, and says so when it does.

  • TEXCHRONICLE_BROWSER chooses one explicitly, ahead of all of the above: chrome, msedge, chromium, or the full path to an executable.

  Troubleshooting: if the automatic download was skipped or failed and no Chrome or Edge is found, the one-time fix is npx --no-install playwright install chromium --only-shell in the TeXChronicle folder.

• ~650 MB disk for the one-time WASM TeX Live assets — all of it fetched on the first run, in three package sets (basic 87 MB, recommended 190 MB, extra 324 MB, plus the 31 MB engine). A typical paper only loads the basic set; the other two sit on disk until something needs them. Cached per user, not per install, so upgrading TeXChronicle doesn't re-download them. Override the location with TEXCHRONICLE_ASSETS_DIR.

• Disk inside the paper's own folder: every clean render's PDF is kept at .latex-preview/renders/<checkpoint>.pdf so History's View PDF can show the exact output of an older version. The most recent 50 are kept, and older ones are deleted — set TEXCHRONICLE_KEEP_RENDERS to another number, or to 0 to keep every one. The render currently on screen is never deleted, whatever its age.

• A local TeX install is optional. See below for when it matters.

Do I need a local TeX distribution?

No — the bundled WASM engine compiles with nothing installed, which is the whole point. But it ships a subset of TeX Live, so some things are missing: svg, most venue document classes, and various less-common packages. When one is missing you'll be notified rather than getting a silently wrong PDF.

Install a distribution when you want output that matches Overleaf exactly. TeXChronicle picks it up automatically — no configuration required:

latexmk is not a standalone package — it is a driver script that comes with the distributions above. On Windows, TeXChronicle also detects the standard per-user/ system MiKTeX and Strawberry Perl locations directly, so a stale or incomplete PATH does not force the bundled compiler; elsewhere, verify with latexmk -version, not which latexmk — finding the file doesn't mean it can run. On macOS you may need eval "$(/usr/libexec/path_helper)" or a fresh terminal first.

Two Windows details worth knowing, both handled automatically:

• MiKTeX's "ask before installing" — the default a fresh MiKTeX Console leaves you with. It is a GUI dialog, and since TeXChronicle runs the engine hidden with no one around to click, the compile would simply hang. TeXChronicle detects this setting, switches the installer off, and if the document then requires a package this machine lacks, it says so and names the fix (mpm --install=<pkg> or MiKTeX Console → Settings → "Always install").

• Two installed perls are handled. If you have Git Bash or MSYS2, your PATH contains a POSIX-emulation perl that can't run MiKTeX's latexmk. TeXChronicle notices and prefers a real Strawberry Perl installation over the one on PATH, so the local backend works without any setup.

Every compile tells you which engine ran — xelatex · system or xelatex · wasm.

Development

npm install
npm run typecheck    # tsc for the server and the UI
npm run build:ui     # build the React workspace to ui/dist
npm test             # the unit suite — engine-free, no browser, seconds
npm start            # run the server on stdio (for a manual MCP client)

Two tiers, intentionally. npm test covers the comment store, anchor matching, line and column geometry, the history repo, asset paths, compile‑log classification, the preview server’s shutdown, and an E2E MCP flow — all without requiring a browser or a TeX engine, so it stays fast and deterministic. CI (.github/workflows/ci.yml) runs typecheck + UI build + that suite on Node 20 and 22 for every push and PR.

Things a unit test structurally cannot see — highlight geometry at several zoom levels, what a failed render actually tells the reader, and whether shutdown closes the server and warns any open window — live in scripts/smoke-*.mjs and are run against a real browser and a real compile in .github/workflows/smoke-macos.yml. These exist because something shipped broken while the unit suite was green. Please keep both green and add coverage with changes.

Documentation

• User guide — everyday use, the comment loop, live editing, the file tree, porting your paper into Overleaf, package coverage.

• Agent loop — comments as triggers, hands‑off running with /loop, the reviewer → gate → resolver workflow, and ⚡ /ultra-agents.

• Roadmap — what has shipped for concurrent agents, and what real parallel multi‑agent editing still needs.

• Architecture stamps — why a headless browser, what each module does, the compile flow.

All four are translated into the same 8 languages as this README — each page has its own language switch at the top.

Roadmap

Multiple Claude Code sessions can already work the same project concurrently without corrupting comments or the checkpoint history (see docs/ROADMAP.md) — true parallel multi‑agent editing (reviewer / author / defender on their own git branches, merged back together) is the next milestone.

Acknowledgements

TeXChronicle began as a fork of MagicTeX MCP by Zoe Lin and contributors, and has since been substantially redesigned around human-first editing and section-level history. See NOTICE.md for provenance.

Thanks also to the maintainers of texlyre‑busytex, whose WASM TeX Live engine powers the bundled compiler.

License

AGPL-3.0-or-later — matching the texlyre‑busytex engine it builds upon. See NOTICE.md and THIRD_PARTY_NOTICES.md.