PROOF

Ya lo has impreso. Es entonces cuando te enteras.

PROOF es el diálogo de impresión reinventado. En lugar de una miniatura del tamaño de un sello y un acto de fe, te muestra cada página del trabajo a un tamaño legible, mide cuánta tinta cuesta realmente cada página a partir del diseño real y renderizado del documento, y marca las hojas que son desperdicio antes de que gastes papel en ellas — luego imprime lo que querías, no lo que dejó tu última edición.

Construido para el hackathon Cursor Calgary (agosto de 2026), cuyo encargo era tomar un formato de aplicación aburrido y cotidiano y mejorarlo drásticamente — visual, funcional o ambas cosas. El diálogo de impresión no ha cambiado significativamente desde 1995. Así es como se vería si alguien finalmente lo tocara.

El problema, concretamente

El diálogo de impresión que la mayoría de los sistemas operativos ofrecen hoy te da un panel de vista previa aproximadamente del tamaño de un sello postal. Esa es toda la visibilidad que tienes sobre un documento que puede tener más de una docena de páginas. A ese tamaño no puedes distinguir que una página es una sola línea huérfana de "Se aplican términos y condiciones" dejada por un salto de página, que otra no es más que un marcador "— continúa —" que se desbordó a su propia hoja, o que una tercera dice "Esta página se dejó en blanco intencionalmente" en tipo serif de once puntos. Haces clic en Imprimir. Todas las páginas salen. Varias de ellas son mobiliario, no contenido — y pagaste por el papel y el tóner de todas ellas antes de siquiera verlo.

Ese es el modo de fallo que PROOF existe para cerrar: el diálogo en el que ya confías no te muestra lo suficiente para tomar la decisión que te pide.

PROOF incluye un documento de demostración realista: un informe empresarial trimestral de unos 20 párrafos, "Q3_Operating_Review_FINAL_v4.docx", con una tabla de contenidos, un resumen ejecutivo, una tabla financiera real, una sección de cadena de suministro, cifras de plantilla y una sección de perspectivas, además de cinco páginas basura insertadas deliberadamente del tipo exacto que los documentos reales acumulan: un pie de página huérfano de "Términos y condiciones", un artefacto de salto "— continúa —", una línea de copyright suelta, un aviso de "dejado en blanco intencionalmente" y un número de página solitario. Cargado y paginado de verdad, este documento tiene 15 páginas, y la propia medición en vivo de PROOF — no una cifra escrita a mano — marca 5 de ellas como desperdicio, imprimiendo 10. Abre proof/index.html tú mismo y el panel lateral muestra exactamente los mismos números, porque se calculan de nuevo cada vez que la página se carga, no se memorizan aquí.

Related MCP server: MCP Mortgage Server

Cómo se producen realmente los números

Esta es la parte que vale la pena precisar, porque también es la parte que hace funcionar toda la idea: cada cifra que PROOF te muestra se calcula a partir del documento tal como se carga, no se escribe a mano ni se arregla para parecer plausible — y esto se aplica tanto al documento de demostración incluido como a cualquier archivo que sueltes sobre él (ver más abajo).

1. La paginación se mide, no se asume. El HTML del documento se coloca en un elemento DOM real y oculto a un ancho de contenido real, y PROOF recorre sus hijos a nivel de bloque (encabezados, párrafos, tablas, citas en bloque) acumulando la altura real renderizada de cada uno (getBoundingClientRect()), saltando a una nueva página cuando el siguiente bloque desbordaría una caja de página de 816×1056px — papel carta de 8.5"×11" a 96dpi, con márgenes de aproximadamente 1 pulgada. Un marcador de salto de página explícito en la fuente fuerza un salto temprano. Por lo tanto, el número de páginas es una salida del diseño, no un número que alguien eligió.

2. La cobertura de tinta se mide a partir de la geometría real del texto. Para cada página terminada, PROOF recorre cada nodo de texto y le pide al propio motor de diseño del navegador los rectángulos exactos que ocupan sus glifos (Range.getClientRects()) — no un escaneo de píxeles en canvas, sino la misma idea aplicada a la geometría real que el navegador ya calculó. El área de cada rectángulo se pondera con una constante de densidad de glifos declarada (GLYPH_DENSITY = 0.16, es decir, aproximadamente el 16% de una caja de línea es tinta real para texto normal, aumentando con el peso de la fuente), y los trazos de borde de tablas/citas en bloque se añaden encima ya que también llevan tinta. El total, dividido por el área de contenido de la página, es el porcentaje de cobertura de tinta de la página.

3. También existe una ruta de rasterización en canvas, pero no es el número principal. PROOF también incluye un segundo método independiente (inkOf()): serializa la página a un SVG, lo rasteriza a un canvas fuera de pantalla y cuenta los píxeles no blancos ponderados por luminosidad-oscuridad. El código mantiene esto explícitamente etiquetado como "una segunda opinión, no utilizada para el número principal" — vale la pena saberlo si lees el código fuente, ya que es el más intuitivo de los dos métodos pero no es el que impulsa lo que se ve en pantalla.

4. La baja tinta por sí sola no es desperdicio. Por debajo del 2.0% de cobertura de tinta (WASTE_THRESHOLD) es necesario pero no suficiente. Una página solo se marca cuando también es una pieza reconocida de mobiliario de paginación (un aviso de "dejado en blanco intencionalmente", un marcador "— continúa —", una línea de copyright, un número de página solitario) o no tiene ningún elemento estructural (h1,h2,h3,table,ul,ol,svg,img,blockquote) y menos de 120 caracteres de texto. Esto es lo que evita que una portada o una tabla de contenidos se marquen erróneamente solo por ser escasas — en la demostración incluida, la portada mide 2.06% de tinta y la tabla de contenidos mide 1.0%, ambas técnicamente delgadas, y ambas se imprimen de todos modos porque cada una tiene un encabezado.

5. La razón, no solo la marca. El texto real de una página marcada se compara con patrones de los tipos de mobiliario que los documentos reales acumulan — avisos de "dejado en blanco intencionalmente", marcadores "— continúa —", líneas de copyright, números de página solitarios, o una línea final corta sin categoría clara — por lo que la razón mostrada para cada página de desperdicio se deriva de lo que esa página realmente dice, no de un pie de foto escrito para una demostración específica.

Dicho claramente, porque importa para la confianza: si la medición basada en el diseño no puede ejecutarse por alguna razón, PROOF no te muestra silenciosamente nada ni inventa algo en voz baja — recurre a una estimación determinista y divulgada (estimateInk(): una fórmula declarada sobre el número de caracteres, el número de encabezados y el número de celdas de tabla) documentada en el código exactamente como eso, una estimación, no una medición. La línea de estado de la interfaz te dice cuál produjo los números que estás viendo — dice measured · N glyph runs across N pages o estimated · layout measurement unavailable, para que nunca estés mirando una suposición presentada como medición. El panel de detalle de cada hoja tiene su propia lectura de "método" que coincide, mostrando measured · glyph-run geometry o estimated · block model para esa hoja específica.

Todo lo que viene después — qué páginas se marcan, el recuento de hojas ahorradas, el porcentaje medio de tinta, la razón por página que se muestra al abrir una hoja y la cifra de costo — se deriva de este pipeline que se ejecuta contra el documento que esté cargado actualmente. Nada en pantalla es un resultado codificado disfrazado de cálculo.

Lo que realmente ves

• El veredicto, primero. Páginas de entrada, páginas de salida, con el recuento de hojas descartadas y el porcentaje medio de tinta indicados como estadística principal en el panel lateral — no enterrados en un panel de configuración.

• El muro de hojas. Cada página del trabajo como una miniatura en vivo — la página real renderizada, reducida con CSS transform: scale(), no un gráfico de marcador de posición ni una miniatura redibujada desde cero — con las páginas de desperdicio marcadas visiblemente y un indicador de tinta por página.

• La revelación anidada. Haz clic en cualquier hoja y se abre en su propia explicación: cómo se clasificó, su cobertura de tinta medida frente al umbral del 2.0% y — para una página marcada — qué tipo específico de mobiliario es y por qué descartarla no cambia nada de lo que querías imprimir. Esta es la columna vertebral del diseño: documento → páginas → una hoja marcada → la razón, cada nivel revelando el siguiente. Desde ese mismo panel puedes restaurar o descartar esa hoja individualmente.

• Prueba otro archivo, de verdad. El panel lateral tiene una zona de arrastre genuina: arrastra tu propio archivo .html, .txt o .md (o haz clic para elegir uno) y PROOF pagina y mide ese documento con exactamente el mismo pipeline descrito anteriormente — esto no es un segundo modo de demostración, es la misma función load() por la que pasa el documento incluido.

• Un botón de Imprimir real. "Imprimir" llama al window.print() real del navegador contra una raíz de impresión oculta que refleja el trabajo en pantalla; las páginas descartadas/de desperdicio llevan display:none bajo @media print, por lo que las hojas que decidiste no imprimir realmente no se imprimen. También hay una vía de escape explícita "Imprimir todo de todos modos", y el CSS de impresión oculta el marco de la aplicación para que solo el documento en sí vaya a la impresora.

• Antes / después. El diálogo de 1995 se muestra honestamente en la presentación (proof/deck.html), junto a lo que PROOF muestra en su lugar, para que el contraste se indique explícitamente en lugar de solo insinuarse.

Plataformas

Tanto el escritorio como el móvil están diseñados como diseños de primera clase, no uno reducido del otro — el muro de hojas, la fila de estadísticas principales y la vista de detalle anidada tienen puntos de interrupción dedicados hasta el ancho de un teléfono.

El servidor MCP — revisar un documento sin un humano en el bucle

La página web es una superficie de PROOF. Debajo, PROOF está pensado para ser utilizable directamente por un agente de IA: un servidor MCP expone el mismo modelo de documento que usa la interfaz web, para que un agente de codificación, un pipeline de documentos o el propio Claude puedan revisar un trabajo antes de que se mueva una sola hoja — sin captura de pantalla, sin que un humano lea un panel de vista previa.

El servidor vive en proof/mcp/ y refleja exactamente el mismo documento de 15 páginas que mide la aplicación web — mismo nombre de archivo (Q3_Operating_Review_FINAL_v4.docx), mismas 5 páginas de desperdicio (4, 6, 9, 11, 13) con las mismas razones, y las mismas constantes de costo (cost_per_sheet_usd: 0.012, cost_per_ink_point_usd: 0.0009) que usa el propio index.html, de modo que una llamada a ink_cost cotiza el mismo dinero que muestra la interfaz en pantalla (tinta media 2.97% y $0.0603 ahorrados aquí, "2.9%" y "$0.06" redondeados en la interfaz). Una cosa se dice claramente en lugar de ocultarse: los porcentajes de tinta en el document.js del servidor son valores capturados que reflejan una medición real del navegador, no recalculados por el propio servidor — no hay un equivalente portátil de Node del método de geometría de glifos Range.getClientRects() de index.html, ya que esa API solo existe en un motor de diseño real, por lo que el servidor divulga sus números como "method": "measured_in_browser_layout" en lugar de pretender re-derivarlos de forma independiente. Conectar el servidor para medir un documento arbitrario que se le entregue — de la misma manera que la zona de arrastre de la interfaz web ya lo hace — es el siguiente paso natural.

Las cuatro herramientas que expone, verificadas contra una ejecución de prueba de humo en vivo (node proof/mcp/smoke_test.mjs):

Para conectarlo a Claude Desktop, Claude Code o cualquier cliente compatible con MCP, apunta el cliente al directorio del servidor:

cd proof/mcp
npm install

Luego agrégalo como servidor MCP (transporte stdio) en la configuración de tu cliente, por ejemplo, para el claude_desktop_config.json de Claude Desktop:

{
  "mcpServers": {
    "proof": {
      "command": "node",
      "args": ["/absolute/path/to/proof/mcp/server.js"]
    }
  }
}

No hay salto de red ni nada que desplegar: el servidor es un proceso stdio local, exactamente como cualquier otro servidor MCP que ejecutarías para herramientas locales. Esta fue una restricción deliberada de todo el proyecto — véase «Sin backend», más abajo — extendida a la capa de agentes: capacidad de agente sin una dependencia de alojamiento que pueda fallar durante una demo.

Para verificar que el servidor funciona realmente de extremo a extremo sin montar un cliente completo, ejecuta la prueba de humo incluida: lanza server.js como un proceso hijo real a través de stdio, realiza el handshake de MCP, enumera las cuatro herramientas y llama a cada una:

cd proof/mcp
node smoke_test.mjs

Las instrucciones de conexión más completas (incluida una configuración específica para Cursor) están en proof/mcp/README.md.

Cómo ejecutarlo

El producto es HTML/CSS/JS estático. No hay paso de compilación, ni bundler, ni servidor.

open proof/index.html

o simplemente haz doble clic en proof/index.html en Finder/Explorer. Ese es todo el procedimiento de instalación: nada de npm install, ni servidor de desarrollo, ni dependencia alguna de node_modules de este repositorio, ni fuentes externas, scripts de CDN ni imágenes de red.

La página se complementa con proof/sample-document.js, que proporciona el informe de demostración completo de 15 páginas (window.SAMPLE_DOC): mantén los dos archivos juntos en proof/ y se cargará automáticamente mediante una etiqueta <script src> normal. Si ese archivo faltara, index.html no se rompe: recurre a un documento de demostración más pequeño y autocontenido (FALLBACK) integrado en la propia página, de modo que la aplicación nunca muestra una pantalla en blanco, solo un documento más corto. En cualquier caso, la medición de tinta funciona de forma idéntica tanto si abres el archivo directamente (file://) como si lo sirves, porque nada en el pipeline depende del acceso de red entre orígenes.

Si prefieres servirlo por HTTP por cualquier motivo (algunas extensiones del navegador o políticas de seguridad locales más estrictas pueden interferir con las páginas file://), cualquier servidor de archivos estático sirve, por ejemplo:

npx serve proof

Capturas de pantalla y el harness de captura

El directorio _brainstorming/ contiene las notas de trabajo de este proyecto, incluido capture.mjs, un pequeño script de Playwright utilizado para tomar capturas de pantalla con precisión de fotograma de la página en posiciones de desplazamiento y tamaños de viewport específicos (escritorio y móvil) para la entrega del hackathon. Requiere la devDependency playwright declarada en el package.json raíz de este repositorio:

npm install
node _brainstorming/capture.mjs proof/index.html --out shots

Esta es una herramienta de desarrollo, no parte del producto: PROOF en sí no necesita nada de esto para funcionar.

Sin backend, a propósito

PROOF no tiene servidor, ni base de datos, ni paso de despliegue para el propio producto. Sus «datos» de demostración incluidos son un informe trimestral realista construido a mano y distribuido como contenido estático (sample-document.js, con un fallback integrado más pequeño si ese archivo no está presente), de modo que cada número calculado a partir de él — recuento de páginas, cobertura de tinta, indicadores de desperdicio, coste — es aritmética real sobre contenido real en el momento en que la página se carga, no una petición a un backend que podría estar caído, lento o ausente durante una demo. También acepta de verdad un archivo que sueltes sobre él, procesado a través del mismo pipeline. El servidor MCP es el único proceso que se ejecuta fuera del navegador, y es un proceso stdio local en lugar de uno alojado, por lo que no conlleva ningún riesgo de despliegue de un backend web.

Por qué el diálogo de impresión

Aproximadamente una docena de otros candidatos de «formato aburrido» fueron considerados y rechazados durante el diseño, por varias razones distintas e individualmente justificadas: un gestor de suscripciones, un rastreador de paquetes y una factura de servicios se descartaron porque reinventarlos honestamente significaría inventar datos sin una fuente legítima (un saldo bancario, el estado real de seguimiento de un transportista, una lectura de contador); un flujo de cancelación y un CAPTCHA se descartaron por no aportar información real; un gestor de pestañas del navegador y un mapa de asientos de avión se descartaron por estar ya bien cubiertos por productos existentes (OneTab/Arc, SeatGuru); un banner de cookies era un lienzo demasiado pequeño para la revelación en capas impulsada por el desplazamiento que se pretendía; y un concepto anterior de dosificación de recetas se eliminó por no superar una prueba de comprensión instantánea. El diálogo de impresión es el único candidato que superó todas estas barras a la vez: reconocible al instante, añade información real que el diálogo actual oculta, y cada número llamativo en pantalla — páginas, detección de páginas en blanco, cobertura de tinta — es algo que un navegador puede calcular realmente a partir de un documento real, en vivo, sin nada falsificado. El registro completo de la decisión, incluidos los candidatos rechazados y el razonamiento en cada paso, está en _brainstorming/SPEC.md.

Estructura del repositorio

proof/
  index.html          the product — open this
  sample-document.js   the 15-page demo report loaded into the product
  deck.html            a short, seven-slide product presentation, same art direction
  docs.html             the full feature-by-feature reference, verified against live output
  mcp/
    server.js           the MCP server entrypoint (stdio transport)
    document.js          MCP server's document model — mirrors index.html's live document
    smoke_test.mjs        end-to-end check: spawns the server, calls all four tools
    package.json          MCP server package (@modelcontextprotocol/sdk, zod)
    README.md             MCP-specific install/connect instructions
_brainstorming/
  SPEC.md             the full design/decision record for this project
  capture.mjs          Playwright screenshot harness used for the submission
  ...                  earlier design drafts and research notes, kept for the record
shots/                desktop + mobile submission screenshots of proof/index.html
shots-deck/           submission screenshots of proof/deck.html

proof/deck.html es una página breve y autónoma de presentación del producto — ábrela igual que index.html — que recorre por qué el diálogo de impresión está roto, cómo mide PROOF la cobertura de tinta (medida frente a rasterizada) y la lógica del clasificador de conservar páginas pese a la baja cobertura de tinta, en siete diapositivas con el mismo lenguaje visual que el propio producto. proof/docs.html es la referencia más profunda y desplazable: cada funcionalidad — incluido el servidor MCP — documentada contra el código actual con números reales verificados en vivo.

Construido para el hackathon de Cursor Calgary, agosto de 2026.