TeXChronicle — historial de LaTeX por secciones y edición en vivo

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

TeXChronicle es un espacio de trabajo de LaTeX centrado en las personas para editar, renderizar y recuperar artículos. Combina un editor de código fuente, una vista de documento Live editable, una vista previa exacta en PDF, comentarios anclados y un historial de Git por secciones en una sola ventana del navegador. Cada compilación exitosa guarda el código fuente junto con su PDF exacto, sin alterar las ramas Git normales del artículo.

Puede funcionar por sí solo: un LLM es opcional. Claude Code, Codex y otros agentes compatibles con MCP pueden editar los mismos archivos o actuar sobre los comentarios cuando resulte útil. La compilación portable para Windows incluye su propio compilador, runtime de navegador, Node y Git, por lo que los destinatarios no necesitan una instalación local de TeX ni una cuenta de Overleaf.

El espacio de trabajo

Una sola ventana del navegador (inspirada en el editor de un sola superficie de Typst y en las anotaciones ancladas de 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 ✓    │
└────────────┴──────────────────────────────┴──────────────────┘

• Bucle de comentario → Claude (de eso trata todo). Revisa el documento renderizado como un director que marca una copia en papel: selecciona texto, coloca un comentario («aprieta este párrafo»). Luego pídele a Claude que “resuelva mis comentarios”: los obtiene a través de check_comments como elementos de trabajo localizados (página + pasaje citado

  • el archivo file:line al que están anclados + tu solicitud), edita el código fuente y resuelve cada tarjeta con una nota. Tú interactúas con el documento; Claude interactúa con el código fuente. Ejecútalo en modo automático con /loop — consulta docs/AGENT-LOOP.md.

• Panel editable de código fuente. Un editor de LaTeX para CodeMirror con los archivos del proyecto: guardar (Ctrl+S) recompila y refresca el PDF, al estilo de Typst. O sigue administrando tu propio editor: cualquier guardado dispara el mismo bucle en vivo. Code, Live y PDF son espacios de trabajo seleccionables a pantalla completa. Live convierte al instante el LaTeX académico habitual en un documento editable (encabezados, prosa, citas, notas al pie, listas, ecuaciones, figuras y tablas). Editar una palabra concluye solo el tramo exacto de código fuente; las matemáticas, las citas, las referencias, los comandos, los comentarios y el formato intacto se mantienen byte a byte. Las construcciones protegidas permanecen visibles y abiertas en Code; el PDF se mantiene exacto. Split mantiene el código fuente o Live junto al PDF cuando hace falta comparar.

• PDF → código exacto. Haz clic en un punto de un PDF generado por el backend local de TeX para abrir el archivo fuente correspondiente y la línea mediante SyncTeX. El refinamiento de texto visible se encarga de los bloques de título/autor expandidos por macros y se queda como respaldo de mejor esfuerzo cuando el backend WASM integrado no tiene mapa de SyncTeX.

• Recarga en vivo. Un observador de archivos recompila con cada guardado: las novedades de Claude, las del editor integrado o las de tu editor externo.

• Historial de cambios por sección. Cada compilación correcta se almacena automáticamente en un ref git oculto (refs/latex-preview/checkpoints); no toca nunca tus ramas, tu git log ni tu árbol de trabajo. Restaurar también crea primero una instancia de seguridad reversible; y un marcador independiente garantiza que un estado de recuperación no renderizado nunca se confunda con un PDF resultante. Un historial sigue a cada sección y subsección barren edits, rename y mov imientos using etiquetas y coincidencia difusa. Explore su propia línea temporal, compare solo su texto (o todo su subárbol), restaure esa parte sin revertir el resto del dijo, y vuelva al PDF exacto de ese checkpoint. Una línea temporal de todo el project también sigue disponible.

• Relación con Overleaf. Descargar PDF, Exportar .zip (paquete limpio de entrada de compilación) y un enlace de un clic Abrir en Overleaf para repos públicos de GitHub; la sincro Premium del Git-bridge es un git push documentado. Ver el 文档 docs/USER-GUIDE.md.

• Flujo de revisión (revisor → puerta → resolvedor). Un agente revisor/defensor publica comentarios a través de add_comment; tú los Aceptas/Rechazas (o activa el auto-accept para el modo de copiloto); el bucle de autor resuelve el número comprobado. Cada comentario lleva rol y hilo de respuesta. Consulte docs/AGENT-LOOP.md.

• Guardar vs. recompilar, tú decides. El editor integrado guarda automáticamente cada 30 s sin recompilar; Ctrl+S / Guardar / Recompilar reconstruye el PDF a demanda. (Cambia a ⚡ Live para recompilar mientras se escribe.) Tu propio editor y las ediciones de Claude siguen recompilando automáticamente por el observador.

• Proyectos reales. Detecta automáticamente el archivo principal, agrupa los archivos de \input/\include, los .bib, los elementos .cls/.sty/.bst del repo y las figuras del repositorio; ejecuta BibTeX y lo vuelve a ejecutar cuando se necesita; los paquetes comunes que faltan se agregan automáticamente.

• Backend de compilación. Usa tu latexmk local si lo tienes: la fidelidad de paquetes es completa y la salida coincide con Overleaf; si no, usa el WASM de TeX Live integrado y sin instalación. Puedes li forzar ninguna de las dos con backend: "system" o "wasm". Cada compilación informa de cuál se ejecutó.

• Clases de documentos. IEEEtran se incluye, porque revistas no llevan clase en TeX Live WASM y una clase que falta no se puede solucionar como un paquete. Las clases de congress (NeurIPS, ICML, CVPR, ACL, AAAI…) no tienen custodia redistribuible; así que deja el .cls del pack de autor junto al código fuente, y se lo recogerá automáticamente.

• Herramientas MCP: render_preview (compilar y abrir el espacio de trabajo), check_comments / resolve_comment / add_comment / reply_to_comment (bucle de revisión), taken Se muestra show_diff (diffLas imágenes costeras en los imagen-compatible).

• Error accionable. Los fallos de compilación devuelven errores analizables {file, line, message} para que Claude pueda self-corregirse, y se muestran en el espacio de trabajo.

Related MCP server: Unofficial Overleaf MCP Server

Ejecuta el editor sin un LLM

En edición portátil de Windows (sin instalación)

Descargue TeXChronicle-<version>-Portable-Windows-x64.zip desde la release, extraiga toda la carpeta y haga doble clic en TeXChronicle.exe. Incluye su propio runtime de Node, Git, Chromium sin cabecera y el conjunto completo de assets de BusyTex, así que el destinatario no instala npm, Node, Git, Perl, algo, TeX y la primera compilación no necesita descarga. Elija un artículo reciente, busque su archivo principal .tex o arrastre ese archivo a TeXChronicle.exe.

Esto es una carpeta portátil, no un instalador: mantén sus subcarpetas al lado del EXE. Los puestos de control, los comentarios y los PDF guardados del paper siguen en el directorio .latex-preview del article, de modo que Dropbox u otro sincronizador de carpetas normal los lleve entre machines. Una máquina a la vez: deja que la sincronización termine antes de abrir el mismo artículo en otra parte; dos equipos editados offline. Consulte la versión portable para Python para file compartido, sumas de comprobación, actualizaciones, limitaciones y el comando de contribución reproducible.

Lanzador de un clic (Windows)

Después de instalar o enlazar TeXChronicle, instale una vez su acceso directo en el escritorio y en el menú:

texchronicle install-launcher

A partir de ahí no tienes que recordar ningún comando de proyecto: clic en TeXChronicle y su ventana de Recent projects emprende los papers que hayas abierto, con Browse… para un nuevo archivo .tex principal. Doble clic en un interésro y se abre el espacio de trabajo en un navegador. También puede arrastrar un fichero .tex al icono de escritorio. Si el paper ya está abierto, reutiliza su espacio de trabajo en lugar de iniciar otro compilador. La pequeña ventana de estado mantiene vivo el workspace; ciérralo cuando termines. texchronicle open presenta el mismo selector de proyectos recientes.

Inicio desde la terminal

Hasta la salida a npm, instale desde GitHub: sin hacer clone ni paso de build:

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

npm clona el repositorio, lo installa (incluido el build de la interfaz — ver Configuración con un cliente LLM/MCP para qué hace exactamente y cuánto cuesta) y ejecuta el workspace. Tras el lanzamiento de npm, la misma línea será npx -y texchronicle preview main.tex.

En cambio, si es una vía más orientada a developer, instale y vincule TeXChronicle una vez desde un checkout del código:

npm install
npm run build:ui
npm link

npm run build:ui construye espacio de trabajo de navegador. Sin él, un clon nuevo se queda en el visor básico: una vista de PDF sin editor, historial ni comentarios.

Y ya lo puedes lanzar desde cualquier directorio de un projecto LaTeX:

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

El espacio de trabajo del navegador se abre y sigue en activo mientras la terminal esté abierta. Usa ⚡ Live para recompilar mientras escribes, o Ctrl+S para guardar y compilar. Cada render interfaz correcta se registra en History. Presiona Ctrl+C para detener. A project, project not in the folder, use texchronicle preview --project /path/to/paper main.tex.

Los clientes Claude Code, Codex y otros clientes MCP son opcionales: pueden modificar los mismos archivos mientras este workspace standalone se ejecute, pero no hacen falta para abrirlo o usarlo.

Configuración con un cliente LLM/MCP

El paquete y los pomocionales de MCP usan texchronicle y io.github.Aliutin/texchronicle. El paquete npm aún no está publicado — npm view. texchronicle` todavía da 404 — así que instales desde GitHub, que es lo que npm hace directamente, sin clon ni paso de construcción propio:

1. Añádelo a .mcp.json del proyecto (ver .mcp.json.example):

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

npm clona el repositorio y lo instala. Como este paquete tiene un script prepare, la instalación de npm también instalará su devDependencies y ejecuta prepare antes de extras la inclusión — ese script es npm run build:ui, de modo que el espacio de trabajo del navegador (ui/dist) se compila como parte de la instalación envez de olvidarlo. Un paso postinstall descarga entonces el explorador headless de Playwright; en Requirements puedes ver cómo saltarse ese paso oapuntar a un navegador que ya tengas.

Tres cosas sobre la vía GitHub, ninguna bloquea: la máquina necesita git en PATH; la instalación se devincorpora devDependencies (React, Vite, TypeScript) y compila la UI, por lo que es notablemente más costosa que la instalación desde un registro; y cada ejecución de npx vuelve a resolver el ref de git por red: la cantidad de caché de la anterior correspondiente depende de la versión de npm.

Hay otras dos formas:

• Para los desarrolladores. Si quieres que el servidor uso tu árbol de trabajo, en la carpeta de TeXChronicle ejecuta npm install (que ejecuta prepare → npm run build:ui), y luego apunta el cliente al script de entrada: "command": "node", "args": ["/absolute/path/to/TeXChronicle/bin/cli.mjs"]. Se va a bin/cli.mjs y no npx tsx src/server.ts: es el script de entrada, posibles de versión de Node, explica de forma clara cuando es demasiado vieja, y fácil de ejecutar, accede a recarga del os.userInfo fallback que algunas cuentas de Windows necesitan. Si lo llamamos directamente, src/server.ts se salta ambos y esos fallos de ese tipo se ven, en MCP clientes, solo como -32000. Después de pode editar cualquier cosa bajo ui/, ejecuta npm run build:ui manualmente de nuevo, y ten cuidado: un clon cuyos scripts se hayan saltado (npm install --ignore-scripts) abrirá el visor básico en vez del workspace, sin que se indique en pantalla por qué.

• Después del lanzamiento npm, la forma breve: "command": "npx", "args": ["-y", "texchronicle"].

2. Reinicia Claude Code (o /mcp reconecta) para que lo os capte.

3. Pídele a Claude muestee un preview del paper. Esa primera llamada descarga los assets del TeX Live WASM (~ 650 MB, una única vez), compila y abre la pestaña de vista pro. vieja en vivo. Las ediciones posteriores la recargan automáticamente.

Which folder is used?

La carpeta en la que se inició el servidor. Claude Code y Codex inician un servidor MCP en el directorio del projecto, por lo que un .mcp.json junto a tu paper necesita nada más. Algunos clientes — entre ellos Claude Desktop — arrancan el servidor desde su directorio personal, y allí el servidor no tiene ningún documento para compiling. Enese caso, indique la carpeta explícitamente, bien en la entrada de configuración del servidor:

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

o como argumento del servidor, añadido después del paquete: "args": ["-y", "github:Aliutin/TeXChronicle", "--project", "/abs/path/to/paper"] — y desde el código fuente, "args": ["/abs/path/to/TeXChronicle/bin/cli.mjs", "--project", "/abs/path/to/paper"].

La tercera vía no exige ningún cambio de configuración: pasa projectRoot a render_preview — basta con «renderiza una vista previa de /Users/me/papers/thesis» para que Claude lo rellene. Reorienta toda la sesión, así que cualquier llamada posterior a una herramienta (comentarios, historial, diffs) usa también esa carpeta, y es la única de las tres que un agente puede aplicar por su cuenta, en mitad de una conversación, sin que tú tengas que editar un archivo de configuración ni reiniciar el cliente.

Un servidor iniciado en un lugar donde no haya ningún archivo .tex lo comunica y se detiene, en lugar de observar esa carpeta o crear en ella un almacén de historial; y la negativa enumeró las tres vías anteriores.

Los activos WASM no están en este repositorio. Se descargan en la primera ejecución a una caché por usuario — ~/Library/Caches/texchronicle en macOS, $XDG_CACHE_HOME/texchronicle en Linux, %LOCALAPPDATA%\texchronicle en Windows — de modo que actualizar TeXChronicle no los vuelve a descargar, y un checkout, una instalación global y una ejecución con npx comparten la misma copia. Define TEXCHRONICLE_ASSETS_DIR para guardarlos en otro sitio. Para precargarlos: npx texlyre-busytex download-assets <that directory>.

Instalar como plugin de Claude Code (comandos de barra)

El plugin opcional de Claude Code aporta el servidor MCP y los comandos de barra:

/plugin marketplace add Aliutin/TeXChronicle
/plugin install texchronicle

Hasta la publicación en npm, la entrada de servidor incluida en el plugin es la misma fórmula de GitHub de antes (npx -y github:Aliutin/TeXChronicle), así que hereda sus mismas salvedades: git en PATH, y un primer arranque que instala y compila, no solo desempaqueta. Cambiará a npx -y texchronicle en cuanto el paquete esté en npm.

Luego, en tu proyecto de artículo, usa los comandos de flujo para los flujos habituales:

• /texchronicle — compila y abre el workspace (la vista previa en vivo).

• /ai-review [skill] — revisa el artículo con una skill (por defecto academic-paper-revision; también puedes indicar el nombre de cualquier skill) y deja comentarios para que los Aceptes/Rechaces. La skill que falta se informa con una sugerencia de instalación.

• /address-comments — resuelve los comentarios que hayas aceptado (repite con /loop 60s /address-comments).

• ⚡ /uultra-agents [skill] [depth] — totalmente autónomo: revisa, autoacepta, corrige, repite hasta depth rondas (por defecto 2), deteniéndose en cuanto una ronda no encuentra nada nuevo. Sin aprobación por ronda: es sugra, y el riesgo. Un depth > 5 te pide confirmación antes de comenzar. Termina con un resumen (qué se ha señalado, qué se ha cambiado, qué checkpoints conviene mirar); cada ronda sigue siendo un punto de control normal y reversible. Ver docs/AGENT-LOOP.md.

Un comando por herramienta

Cada herramienta MCP tiene además un comando de barra con el mismo nombre, así que puedes disparar cualquier paso suelto escribiendo el nombre de la herramienta. La regla que se enseña: la herramienta es X → escribe /X.

| Escribe esto | Ejecuta la herramienta | Qué hace | | -------------------------------- | ---------------------- | ---------------------------------------------------------- ------------------------------------------------------------ | | /render_preview | render_preview | Compila el artículo y abre/actualiza la vista previa en vivo. | | /check_comments | check_comments | Lista los comentarios que has aceptado, como instrucciones de edición (aún no edita nada). | | /resolve_comment [id] [note] | resolve_comment | Marca un comentario como hecho tras el cambio; se pone en verde para tu revisión. | | /add_comment ["quote"] [note] | add_comment | Ancla un comentario a un pasaje para que lo Aceptes/Rechaces. | | /reply_to_comment [id] [text] | reply_to_comment | Añade una respuesta en hilo a un comentario. | | /show_diff [checkpoint] | show_diff | Diferencia visual lado a lado como una imagen (cambios actuales, o un checkpoint). | | /list_checkpoints [limit] | list_checkpoints | Checkpoints recientes con su sha, del más nuevo al más eterno, para encontrar uno que pases a /show_diff. |

Nunca tienes que escribirlos: en lenguaje natural puedes decir también las mismas cosas ("renderiza una vista previa", "resuelve mis comentarios"). Los comandos son solo una forma rápida y enseñable de hacer lo mismo.

Los comandos de barra vienen con el plugin: son ficheros en commands/, que es el plugin quien los instala. El servidor en sí no registra prompts, así que un setup .mcp.json te da las herramientas de la tabla siguiente, pero sin los accesos / — las controlases en lenguaje natural ("renderiza una vista previa", "resuelve mis comentarios") que es a lo que al final esos comandos se reducen.

Herramientas

La superficie MCP para cualquier cliente que hable MCP. (En Claude Code puedes pedirlo en lenguaje natural simplemente, o usar los comandos de barra de arriba; estas son las herramientas que hay por debajo.)

| Herramienta | Parámetros | Qué hace | |------------------------------------|---------------------------------------------- ------------------------------------------------------------------------------------------------------------------------------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | render_preview | projectRoot? (ruta absoluta a la carpeta del artículo; se usasolo si el servidor no se inició ahí; se mantiene durante toda la sesión) · mainFile? · engine? (pdflatex | xelatex | lualatex, autodetectados si se omite) · backend? (wasm | system | auto, por defecto auto; un latexmk local si está instalado, con el motor WASM si no) | Compila el proyecto y abre/actualiza el workspace en vivo. El archivo principal se detecta buscando \documentclass si lo omites. | | check_comments | includeResolved? (por defecto false ) | Devuelve los comentarios aceptados como elementos de trabajo localizados — página, pasaje citado, la file:line del file:line de origen y la petición. Las sugerencias que esperan tu decisión se reportan, pero no como una tarea. | | add_comment | quote · comment · role? (reviewer | defender) · page? · accepted? | Ancla un comentario a un pasaje. Lo publica como sugerencia a la espera de tu Aceptar/Rechazar, salvo que flete accepted; solo así el modo autónomo funciona like that. | | resolve_comment : | id · note | Marca un comentario como finalizado tras la edición, con una línea que explique qué ha cambiado. Se acepta solo cuando el código fuente coincide exactamente con el checkpoint renderizado más reciente, y entonces se vuelve verde para tu revisión. | | reply_to_comment | id · text · role? (author | reviewer | defender) | Añade una respuesta en hilo, así un desacuerdo se puede solventar en ese comentario y no en el chat. | | show_diff | checkpoint? | Muestra un diff visual lado a lado como imagen, incrustado en la conversación. Por defecto muestra los cambios sin commitear; pasa el sha de un checkpoint para una versión guardada. | | list_checkpoints | limit? (por defecto 10, máximo 50) | Checkpoints recientes con su sha, de más nuevo a más antiguo — úsalo para localizar uno que pasar a show_diff. |

Los flujos principales se construyen sobre estas herramientas, no están encima de ellos. /texchronicle, /ai-review, /address-comments y ⚡ /ultra-agents son comandos del plugin Claude Code que orquestan las herramientas de la tabla. /ultra-agents encadena revisión → autoaceptación → corrección en tantas ronda como le permitas, y es la razón por la que add_comment acepta la opción accepted. No forman parte de la superficie MCP, por lo que cierto cliente MCP solo verá las siete herramientas. Consulta in the plugin section y docs/AGENT-LOOP.md.

Verlo en el terminal

Estas son salidas reales de las herramientas, copiadas literalmente de una ejecución real con el artículo de ejemplo, no estas montadas. Es lo que llama as entte enClaude Code enquanto el web workspace (captura arriba) refleja el mismo estado en vivo.

Tú escribes:

/texchronicle

Claude llama a render_preview y responde:

✓ 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

Tú (o una skill de reviso) dejas un comentario y luego preguntas qué está listo para actuar. Claude llama a 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 hace la edición y llama a resolve_comment:

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

Si preguntas de nuevo, la cola de aceptados está vacía: solo queda la sugerencia aún no aceptada, esperándote:

No accepted comments. (2 already resolved.)

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

Cómo funciona

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)

Los motores WASM necesitan los globales de DOM/Worker, así que el servidor le da de comer a un Chromium oculto contra como trabajador de compilación; el workspace que tú abres es una app ligera de React + pdf.js, sin WASM. Consulta 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

Ambas puertas de entrada —la tuya desde el área de trabajo y la de los agentes a través de las 7 herramientas MCP— convergen en el mismo coordinador, el mismo almacén de comentarios y el mismo historial de git. Tú actúas sobre el documento renderizado (anclas un comentario); Claude actúa sobre la fuente (lee tus comentarios con check_comments, edita, resolve_comment). Ese sustrato compartido es lo que hace posibles el bucle de comentarios, el flujo de revisión y el historial trazable.

Requisitos

Los siguientes requisitos se aplican a la instalación desde npm o desde el código fuente. La versión portable para Windows incluye estos runtimes por sí misma y solo necesita Windows 10 de 64 bits o posterior, además de un navegador web normal para la ventana del área de trabajo. Las variables TEXCHRONICLE_* que se nombran abajo se recogen todas juntas en la guía de usuario.

• Node 20.19+ (el mínimo que chokidar y playwright necesitan en realidad; el servidor lo comprueba al arrancar y así lo indica)

• El Chromium headless de Playwright (~150–300 MB), descargado automáticamente: un paso postinstall lo descarga en el momento de la instalación y, si falta cuando se necesita el navegador por primera vez, se reintenta la descarga en ese momento. Maneras de cambiarlo:

  • TEXCHRONICLE_SKIP_BROWSER_DOWNLOAD=1 (o la propia variable de Playwright PLAYWRIGHT_SKIP_BROWSER_DOWNLOAD=1) omite la descarga: útil con una conexión limitada, en CI o en una imagen creada sin conexión.

  • Cuando no hay Chromium de Playwright, TeXChronicle usa como alternativa un Chrome o Edge ya instalado en la máquina, y avisa cuando lo hace.

  • TEXCHRONICLE_BROWSER elige uno explícitamente, por delante de todo lo anterior: chrome, msedge, chromium o la ruta completa a un ejecutable.

  Troubleshooting: si la descarga automática se omitió o falló y no se encuentra ningún Chrome/Edge, la solución puntual es npx --no-install playwright install chromium --only-shell en la carpeta de TeXChronicle.

• Alrededor de ~650 MB de disco para los recursos WASM de TeX Live de una sola vez — todo se descarga en la primera ejecución, en tres conjuntos de paquetes (básico 87 MB, recomendado 190 MB, extra 324 MB, más el motor de 31 MB). Un artículo normal solo carga el conjunto básico; los dos más grandes permanecen en el disco hasta que algo los necesita. Se almacenan en caché por usuario, no por instalación, así que actualizar TeXChronicle no los vuelve a descargar. Cambia la ubicación con TEXCHRONICLE_ASSETS_DIR.

• Espacio en disco dentro de la carpeta del propio documento: el PDF de cada render limpio se guarda en .latex-preview/renders/<checkpoint>.pdf para que Ver PDF de History pueda mostrar el resultado exacto de una versión anterior. Se guardan los 50 más recientes y se eliminan los más antiguos: pon TEXCHRONICLE_KEEP_RENDERS en otro número, o en 0 para conservarlos todos. El render que está actualmente en pantalla nunca se elimina, sin importar su antigüedad.

• Una instalación local de TeX es opcional. Consulta abajo cuándo es importante.

¿Necesito una distribución local de TeX?

No — el motor WASM incluido compila con nada instalado, que es precisamente el objetivo. Pero incluye un subconjunto de TeX Live, así que algunas cosas no están: svg, la mayoría de las clases de documento de revistas y congresos, y varios paquetes menos comunes. Cuando algo falte, te lo dirán, en lugar de darte un PDF que está mal silenciosamente.

Instala una distribución cuando quieras una salida que coincida exactamente con Overleaf. TeXChronicle la detecta por sí solo, sin configuración:

latexmk no se instala por su cuenta: es un script de control que viene con los sistemas anteriores. En Windows, TeXChronicle también descubre directamente las ubicaciones estándar de MiKTeX y Strawberry Perl por usuario o por sistema, así que un PATH obsoleto o incompleto no obliga al compilador incluido. En otros sitios, compruébalo con latexmk -version, no con which latexmk: encontrar el archivo no demuestra que pueda ejecutarse. En macOS puede que necesites antes eval "$(/usr/libexec/path_helper)" o una terminal nueva.

Dos detalles de Windows que vale la pena conocer, y que están resueltos por ti:

• «Preguntar antes de instalar» de MiKTeX, el ajuste con el que te deja una instalación nueva de MiKTeX Console. Su pregunta es un diálogo de interfaz gráfica, y TeXChronicle ejecuta el motor oculto sin que nadie pueda responderla, así que la compilación simplemente se colgaría. TeXChronicle detecta ese ajuste, ejecuta con el instalador desactivado y, si la compilación requiere un paquete que esta máquina no tiene, lo avisa y señala la solución (mpm --install=<pkg>, o MiKTeX Console → Configuración → "Instalar siempre los paquetes que faltan").

• Dos perls. Si usas Git Bash o MSYS2, un perl de emulación POSIX está en tu PATH y no puede ejecutar el latexmk de MiKTeX. TeXChronicle lo nota y prefiere una instalación real de Strawberry Perl a la que está en PATH, así que el backend local funciona sin tener que recolocar nada.

Cada compilación te dice cuál se usó — xelatex · system o 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)

Hay dos niveles, a propósito. npm test cubre el almacén de comentarios, la coincidencia de anclas, la geometría de líneas y columnas, el repositorio de historial, las rutas de assets, la clasificación del log de compilación, el apagado del servidor de vista previa y un flujo de trabajo MCP E2E — todo sin navegador ni motor de TeX, para que siga siendo rápido y determinista. CI (.github/workflows/ci.yml) ejecuta el typecheck, la compilación de la UI y esa suite en Node 20 y 22 para cada push y pull request.

Lo que una prueba unitaria, por su estructura, no puede ver — geometría del refaltado en varios niveles de zoom, lo que un render fallido realmente transmite al lector, si el cierre de la aplicación apaga el servidor y avisa a cualquier ventana abierta — vive en scripts/smoke-*.mjs y se ejecuta contra un navegador real y una compilación real en .github/workflows/smoke-macos.yml. Cada uno de esos tests existe porque algo se publicó roto y la suite unitaria seguía en verde. Por favor, mantén las dos en verde y añade cobertura con los cambios.

Documentación

• Guía de usuario — uso cotidiano, el bucle de comentarios, edición Live, el árbol de archivos, cómo llevar tu documento a Overleaf, el cobertura de paquetes.

• El bucle del agente — los comentarios como activadores, ejecutarlo sin intervención con /loop, el flujo revisor → gate → resolver y ⚡ /ultra-agents.

• Hoja de ruta — lo que ya se ha implementado para agentes concurrentes y lo que la edición multiagente realmente paralela todavía necesita.

• Arquitectura — por qué un navegador sin gráficos, qué hace cada módulo, el flujo de compilación.

Los cuatro están traducidos a los mismos 8 idiomas que este README — cada página tiene su propio selector de idiomas de cada página en la parte superior.

Hoja de ruta

Varias sesiones de Claude Code ya pueden trabajar en el mismo proyecto a la vez sin corromper comentarios ni historial de rescate (consulta docs/ROADMAP.md) — la edición multiagente realmente paralela (revisor/autor/defensor en sus propias ramas de git, para fusionarlas de nuevo) es el siguiente hito.

Agradecimientos

TeXChronicle comenzó como una bifurcación de MagicTeX MCP por Zoe Lin y colaboradores, y desde entonces se ha rediseñado sustancialmente en torno a la edición en el centro de la persona primera y al historial por secciones. Consulte NOTICE.md para conocer el procedencia.

Gracias también a los mantenedores de texlyre-busytex, cuyo motor WASM TeX Live puede alimenta el compilador integrado.

Licencia

AGPL-3.0-or-later — en consonancia con el motor texlyre-busytex sobre el que se basa. Consulte NOTICE.md y THIRD_PARTY_NOTICES.md.