Tableau Workbook Auditor

Encuentra qué falla en cualquier libro de trabajo de Tableau (.twbx) y mapea cada dependencia dentro de él, enteramente en tu navegador. Campos sin usar, cálculos duplicados, problemas de rendimiento, linaje completo de campos calculados, filtros, paneles y SQL almacenado. Nada se sube, almacena ni envía.

🔗 En vivo: https://tableau-lineage.com 📦 Servidor MCP: tableau-lineage-mcp

Por qué

Heredar el libro de trabajo de Tableau de otra persona significa hacer ingeniería inversa a docenas de campos calculados a mano para responder una pregunta: ¿de dónde sale este número y qué se rompe si lo cambio?

Dos preguntas más surgen con la misma frecuencia y no tienen respuesta gratuita:

• ¿Qué hay muerto aquí? Tableau no tiene una forma integrada de listar campos sin usar; la solicitud lleva abierta en el foro de la comunidad desde 2015.

• ¿Por qué va lento? El Workbook Optimizer de Tableau requiere una licencia de Creator, y Catalog requiere Data Management en Server o Cloud.

Esto lee el archivo del libro de trabajo y responde las tres, gratis, sin licencia y sin cuenta. Como los libros de trabajo suelen contener datos sensibles, todo se ejecuta localmente: el .twbx nunca sale de tu máquina, lo cual es una propiedad de la arquitectura, no una promesa (no hay servidor al que enviarlo).

Related MCP server: Tableau MCP

Características

Auditoría

• Campos muertos: cada campo, parámetro y cálculo que nada usa, clasificado por nivel de confianza (unused, likely-unused, referenced-in-comment) con el motivo explicado. Se reportan como candidatos, no como certezas, porque un archivo de libro de trabajo no puede demostrar que un campo no se use en ningún lado.

• Cálculos duplicados: fórmulas idénticas con nombres distintos, y el caso más peligroso: el mismo nombre con fórmulas distintas.

• Lint de rendimiento: 15 reglas estáticas sobre lo que el archivo realmente contiene. LODs pesados y anidados, cálculos largos, trabajo intensivo con cadenas, demasiados filtros rápidos, filtros de contexto faltantes, conexiones en vivo, tamaños de panel no fijos, paneles densos, hojas huérfanas.

Linaje

• Grafo de dependencias interactivo (vis-network): campos calculados, campos sin procesar, parámetros y hojas como nodos; las aristas muestran qué alimenta a qué. Agrupa por fuente de datos, busca, resalta cadenas, haz zoom y desplázate.

• Diccionario de datos buscable: cada fórmula agrupada por fuente de datos, más una sección de hojas.

• Siete métricas clicables: fuentes de datos, campos calculados, campos sin procesar, parámetros, cálculos LOD, cálculos de tabla, filtros.

Estructura

• Filtros decodificados: cada filtro deduplicado entre hojas, con su tipo (categórico / cuantitativo / fecha relativa), estado de filtro de contexto, selecciones de miembros almacenadas y rangos, y un desglose por hoja. Los filtros de fuente de datos se señalan por separado.

• Paneles: qué hojas coloca cada panel, su tamaño fijo y diseños de dispositivo, además de las hojas que no están en ningún panel y las hojas ocultas.

• Procedencia de datos: extracción o en vivo, clase de conexión / servidor / base de datos, fuentes publicadas (sqlproxy) e historial de actualización donde el libro de trabajo lo registra.

• SQL almacenado: cada consulta personalizada (texto completo), sentencia SQL inicial, procedimiento almacenado con parámetros y cálculo RAWSQL_*, cada uno mapeado a la conexión a la que apunta. Las consultas generadas en tiempo de ejecución para conexiones en vivo no se almacenan en los archivos de libro de trabajo, por lo que quedan explícitamente fuera de alcance.

Comparar versiones

Arrastra hasta cinco versiones del mismo panel y obtén un diff semántico: qué cálculos se añadieron, eliminaron, renombraron o editaron, y por cada edición los campos posteriores que puede romper, además de parámetros, filtros, hojas, paneles, fuentes de datos y SQL cambiados. Reformatear un cálculo no se reporta como cambio, y un campo que desaparece mientras una fórmula idéntica aparece con un nombre nuevo se reporta como renombrado.

Un diff de git de dos archivos .twbx no puede hacer esto: el libro de trabajo es un único blob XML grande donde las coordenadas de diseño y los IDs regenerados ahogan el puñado de cambios reales.

Exportaciones

Todo se genera en el navegador, a partir del mismo modelo analizado:

• Informe HTML interactivo: autónomo y listo para usar sin conexión (vis-network incrustado), con marca de agua de la herramienta y el autor.

• Documento de entrega Markdown: el libro de trabajo documentado (métricas, auditoría, fuentes de datos, parámetros, filtros, cada fórmula, SQL almacenado) para un ticket, una wiki o un README. También es el formato que un LLM lee mejor cuando alguien pregunta sobre el libro de trabajo más tarde.

• CSV de inventario de campos (incluyendo qué hojas usan cada campo) y JSON del modelo completo, auditoría incluida.

Todo lo demás

• Privado por arquitectura: el análisis de .twbx (descompresión + XML) ocurre en el lado del cliente. Sin backend, sin subidas, sin cookies. La analítica es un recuento anónimo y agregado de visitas a páginas.

• Libros de trabajo de hasta 500 MB: solo se descomprime el XML del libro de trabajo; los datos empaquetados nunca se tocan.

• Accesible: navegación por teclado, gestión de enfoque, contraste AA, soporte de movimiento reducido y un diccionario de texto como equivalente al grafo.

• Siete idiomas de interfaz para las cadenas principales (botones, etiquetas, mensajes de estado), con inglés como respaldo. Los textos explicativos más largos están solo en inglés.

Cómo funciona

.twbx (a ZIP)
  └─ fflate unzips ONLY the .twb entry  ──►  DOMParser reads the XML once
        ├─ extractor.ts        lineage model: calcs, dependencies, params, stats
        ├─ filterExtractor.ts  filters + per-worksheet usage
        ├─ sqlExtractor.ts     Custom SQL, Initial SQL, stored procs, RAWSQL
        ├─ dashboardExtractor  dashboards, hidden/orphan sheets, provenance
        ├─ audit.ts            dead weight, duplicates, performance lint
        └─ diff.ts             semantic diff between two parsed workbooks
              ├─ in-app: a sandboxed <iframe srcdoc> report
              └─ exports: HTML / Markdown / CSV / JSON, all from the same model

Los datos empaquetados dentro de un .twbx nunca se descomprimen, por eso un libro de trabajo de 500 MB funciona bien y por eso la herramienta no puede ver tus filas ni siquiera en principio.

Notas de corrección

El núcleo analítico es un puerto a TypeScript del servicio original en Python, con correcciones que existen porque la versión ingenua fallaba con un libro de trabajo real:

1. Referencias a parámetros por título. Las fórmulas referencian parámetros por título ([Parameters].[Survival Target (Months)]) mientras que el nombre interno difiere ([Survival Benchmark]). El original filtraba una dependencia fantasma de Parameters.

2. Detección de cálculos de tabla por token, no por subcadena. TOTAL dentro de [total_views] marcaba campos ordinarios como cálculos de tabla. Ahora se compara con llamadas a funciones completas; la detección de LOD está anclada a llaves.

3. Los comentarios y las cadenas literales se eliminan antes del escaneo de dependencias. Un nombre de campo mencionado en un comentario // no es una dependencia, y tratarlo como tal hacía que campos sin usar parecieran usados.

4. Los nodos se identifican por fuente de datos, no solo por nombre. Dos fuentes de datos pueden definir ambas [Sales]; fusionarlas combinaba linajes no relacionados en un solo nodo.

5. Los títulos se resuelven en todo el documento. Los libros de trabajo construidos sobre fuentes de datos publicadas guardan los títulos solo en los stubs de dependencias de las hojas, por lo que los filtros y los campos de las hojas mostraban claves crudas como Calculation_5431234567890123.

6. Un bloque <datasources> solo es real en la raíz del libro de trabajo. Cada hoja lleva una lista de referencias con la misma forma, lo que contaba una fuente de datos trece veces en un libro de doce hojas.

Todo está cubierto por pruebas (npm test, npm run test:core).

Stack tecnológico

Vite · React 19 · TypeScript · Tailwind CSS · fflate (descompresión) · DOMParser nativo (XML) · vis-network (grafo). Sin backend.

Servidor MCP (para asistentes de IA)

El mismo motor se distribuye como un servidor MCP, así que Claude, Cursor y otros clientes MCP pueden leer y auditar libros de trabajo directamente desde tu disco. Sigue siendo 100% local, nada se sube.

Claude Desktop: descarga la extensión y haz doble clic. Un clic, sin terminal y sin instalar Node.

Claude Code (instala el MCP más una skill que sabe cuándo usarlo):

/plugin marketplace add andey0Saikiran/tableau-lineage
/plugin install tableau-lineage@tableau-lineage

Cursor y otros clientes MCP:

claude mcp add tableau-lineage -- npx -y tableau-lineage-mcp

Once herramientas: analyze_workbook, audit_workbook, diff_workbooks, list_calculated_fields, get_field, trace_dependencies, list_parameters, get_lineage_graph, list_sql_queries, list_filters, list_worksheets. Documentación completa en mcp/.

Cosas que vale la pena pedirle:

• "Audita este libro de trabajo y dime qué es seguro eliminar."

• "¿Qué cambió entre estas dos versiones y qué rompe?"

• "¿Qué hojas filtran por Region y qué valores están seleccionados?"

• "Escribe un diccionario de datos para este libro de trabajo."

Ejecutar localmente

npm install
npm run dev          # http://localhost:5173

Otros scripts:

npm run build        # typecheck + production build + pre-render to dist/
npm run preview      # serve the production build
npm run typecheck    # tsc --noEmit
npm test             # Vitest: extractors, audit, diff, exports
npm run test:core    # extractor parity + regression tests (Node)
npm run prerender    # re-run the static pre-render over an existing dist/

La compilación pre-renderiza la página de aterrizaje con react-dom/server e inyecta el marcado en dist/index.html, para que los rastreadores obtengan contenido real en lugar de un <div id="root"> vacío. Sigue siendo un sitio totalmente estático: no hay servidor ni en tiempo de compilación ni en tiempo de ejecución.

Desplegar (activos estáticos de Cloudflare Workers)

Este es un sitio estático; la carpeta dist/ puede ir a cualquier host estático. El sitio en vivo se ejecuta en activos estáticos de Cloudflare Workers, configurado por wrangler.jsonc en este repositorio:

{ "name": "tableau-lineage", "assets": { "directory": "./dist" } }

1. Sube este repositorio a GitHub.

2. Panel de Cloudflare → Workers & Pages → Create → Import a repository → selecciona el repositorio. Cloudflare lee wrangler.jsonc y sirve dist/ como activos estáticos.

3. Configuración de compilación:

   • Build command: npm run build

   • Deploy command: npx wrangler deploy

4. Cada push a main compila y despliega automáticamente.

5. Dominio personalizado: el Worker → Settings → Domains & Routes → añade tableau-lineage.com (deja el campo de subdominio vacío para el apex). www es un CNAME con proxy al apex más una regla de redirección. Mover los nameservers del dominio a Cloudflare da HTTPS automático.

Nota: esto es Workers, no Pages. Un proyecto de Pages construido desde el mismo repositorio desplegaría una segunda copia paralela del sitio.

public/_headers incluye una línea base de seguridad y una Content-Security-Policy que restringe las conexiones salientes solo a este origen y a la analítica de Cloudflare, que es lo que hace ejecutable la promesa de que "tus datos nunca salen de tu navegador".

Analítica (sin cookies)

Los conteos de visitantes provienen de Cloudflare Web Analytics: sin cookies, sin datos personales.

1. Panel de Cloudflare → Web Analytics → Add a site → introduce el hostname.

2. Copia el token del beacon y pégalo en el <script> comentado en index.html.

3. Consulta los números en el panel de Cloudflare → Web Analytics.

Ese único beacon de visita a página es el único dato que se recopila.

Libro de trabajo de demostración

public/demo.twbx alimenta el botón "probar un libro de muestra". Reemplázalo con cualquier .twbx que quieras destacar como ejemplo predeterminado.

Licencia

MIT © 2026 Sai Kiran Andey

Creado por Sai Kiran Andey.