PROOF

Du hast es bereits gedruckt. Das ist der Moment, in dem du es herausfindest.

PROOF ist der Druckdialog, neu erfunden. Statt einer briefmarkengroßen Vorschau und einem Sprung ins Ungewisse zeigt es dir jede Seite des Auftrags in lesbarer Größe, misst, wie viel Tinte jede Seite tatsächlich kostet – basierend auf dem echten, gerenderten Layout des Dokuments – und markiert die Blätter, die Verschwendung sind, bevor du Papier dafür verbrennst – dann druckt es, was du gemeint hast, nicht das, was deine letzte Bearbeitung hinterlassen hat.

Gebaut für den Cursor Calgary Hackathon (Aug 2026), dessen Aufgabe es war, ein langweiliges, alltägliches Anwendungsformat zu nehmen und es dramatisch zu verbessern – visuell, funktional oder beides. Der Druckdialog hat sich seit 1995 nicht wesentlich verändert. So sieht es aus, wenn sich endlich jemand damit beschäftigt.

Das Problem konkret

Der Druckdialog, den die meisten Betriebssysteme heute mitbringen, gibt dir einen Vorschaubereich, der ungefähr so groß ist wie eine Briefmarke. Das ist die gesamte Sichtbarkeit, die du in ein Dokument bekommst, das vielleicht ein Dutzend oder mehr Seiten umfasst. Bei dieser Größe kannst du nicht erkennen, dass eine Seite eine einzelne verwaiste Zeile „Es gelten die Allgemeinen Geschäftsbedingungen.“ ist, die von einem Seitenumbruch zurückgelassen wurde, dass eine andere nichts als ein „— Fortsetzung —“-Marker ist, der auf ein eigenes Blatt übergegangen ist, oder dass eine dritte „Diese Seite wurde absichtlich leer gelassen“ in elf Punkt Serifenschrift sagt. Du klickst auf Drucken. Jede Seite kommt heraus. Mehrere davon sind Beiwerk, kein Inhalt – und du hast für das Papier und den Toner auf allen bezahlt, bevor du es je gesehen hast.

Das ist die Fehlerquelle, die PROOF schließen will: Der Dialog, dem du bereits vertraust, zeigt dir nicht genug, um die Entscheidung zu treffen, die er von dir verlangt.

PROOF wird mit einem realistischen Demo-Dokument geliefert – einem vierteljährlichen Geschäftsbericht mit etwa 20 Absätzen, „Q3_Operating_Review_FINAL_v4.docx“, mit einem Inhaltsverzeichnis, einer Zusammenfassung, einer echten Finanztabelle, einem Abschnitt zur Lieferkette, Personalzahlen und einem Ausblick, plus fünf absichtlich eingefügten Müllseiten, genau der Art, die echte Dokumente ansammeln: ein verwaister „Allgemeine Geschäftsbedingungen“-Fußzeile, ein „— Fortsetzung —“-Bruch-Artefakt, eine verirrte Copyright-Zeile, ein „Absichtlich leer gelassen“-Hinweis und eine einzelne Seitenzahl. Geladen und real paginiert, umfasst dieses Dokument 15 Seiten, und PROOFs eigene Live-Messung – keine handgetippte Zahl – markiert 5 davon als Verschwendung, druckt also 10. Öffne proof/index.html selbst, und die Leiste zeigt exakt dieselben Zahlen, weil sie bei jedem Laden der Seite frisch berechnet werden, nicht hier auswendig gelernt.

Related MCP server: MCP Mortgage Server

Wie die Zahlen tatsächlich entstehen

Das ist der Teil, bei dem es sich lohnt, präzise zu sein, denn es ist auch der Teil, der die ganze Idee zum Funktionieren bringt: Jede Zahl, die PROOF dir zeigt, wird aus dem geladenen Dokument berechnet, nicht von Hand eingegeben oder so aufbereitet, dass sie plausibel aussieht – und das gilt für das gebündelte Demo-Dokument und für jede Datei, die du darauf ablegst (siehe unten).

1. Paginierung wird gemessen, nicht angenommen. Das HTML des Dokuments wird in einem echten, versteckten DOM-Element bei echter Inhaltsbreite angeordnet, und PROOF durchläuft seine Block-Level-Kinder (Überschriften, Absätze, Tabellen, Blockzitate) und summiert die tatsächliche gerenderte Höhe jedes Elements (getBoundingClientRect()), wobei es auf eine neue Seite umbricht, sobald der nächste Block eine 816×1056px-Seitenbox überlaufen würde – 8,5"×11" Letter-Papier bei 96 dpi, mit ungefähr 1 Zoll Rändern. Ein expliziter Seitenumbruch-Marker im Quelltext erzwingt einen frühen Umbruch. Die Seitenzahl ist daher ein Ergebnis des Layouts, keine Zahl, die jemand gewählt hat.

2. Tintenabdeckung wird aus echter Textgeometrie gemessen. Für jede fertige Seite durchläuft PROOF jeden Textknoten und fragt die eigene Layout-Engine des Browsers nach den exakten Rechtecken, die seine Glyphen einnehmen (Range.getClientRects()) – kein Pixel-für-Pixel-Canvas-Scan, sondern dieselbe Idee, angewendet auf echte Geometrie, die der Browser bereits berechnet hat. Die Fläche jedes Rechtecks wird mit einer angegebenen Glyphen-Dichte-Konstante gewichtet (GLYPH_DENSITY = 0.16, d.h. ungefähr 16% einer Zeilenbox sind bei normalem Text echte Tinte, steigend mit der Schriftstärke), und Tabellen-/Blockzitat-Rahmenlinien werden zusätzlich hinzugefügt, da sie ebenfalls Tinte tragen. Die Summe, geteilt durch die Inhaltsfläche der Seite, ergibt den Tintenabdeckungsprozentsatz der Seite.

3. Ein Canvas-Rasterisierungspfad existiert ebenfalls, ist aber nicht die Hauptzahl. PROOF enthält auch eine zweite, unabhängige Methode (inkOf()): die Seite in ein SVG serialisieren, sie auf eine Offscreen-Canvas rastern und nicht-weiße Pixel gewichtet nach Luminanz-Dunkelheit zählen. Der Code kennzeichnet dies explizit als „eine zweite Meinung, nicht für die Hauptzahl verwendet“ – wissenswert, wenn du den Quellcode liest, da es die intuitivere der beiden Methoden ist, aber nicht die, die das steuert, was auf dem Bildschirm angezeigt wird.

4. Niedrige Tinte allein ist keine Verschwendung. Unter 2,0% Tintenabdeckung (WASTE_THRESHOLD) ist notwendig, aber nicht ausreichend. Eine Seite wird nur markiert, wenn sie auch entweder ein erkanntes Stück Paginierungs-Beiwerk ist (ein „Absichtlich leer gelassen“-Hinweis, ein „— Fortsetzung —“-Marker, eine Copyright-Zeile, eine einzelne Seitenzahl) oder überhaupt kein strukturelles Element hat (h1,h2,h3,table,ul,ol,svg,img,blockquote) und weniger als 120 Zeichen Text enthält. Das verhindert, dass eine Titelseite oder ein Inhaltsverzeichnis fälschlich nur wegen Spärlichkeit markiert wird – im gebündelten Demo misst die Titelseite 2,06% Tinte und das Inhaltsverzeichnis 1,0%, beide technisch dünn, und beide werden trotzdem gedruckt, weil jede eine Überschrift hat.

5. Der Grund, nicht nur die Markierung. Der tatsächliche Text einer markierten Seite wird mit den Arten von Beiwerk abgeglichen, die echte Dokumente ansammeln – „Absichtlich leer gelassen“-Hinweise, „— Fortsetzung —“-Marker, Copyright-Zeilen, einzelne Seitenzahlen oder eine kurze nachlaufende Zeile ohne klare Kategorie – sodass der für jede Verschwendungsseite angezeigte Grund aus dem abgeleitet wird, was diese Seite tatsächlich sagt, nicht aus einer Bildunterschrift, die für ein bestimmtes Demo geschrieben wurde.

Klar gesagt, weil es für das Vertrauen wichtig ist: Wenn die layoutbasierte Messung aus irgendeinem Grund nicht ausgeführt werden kann, zeigt PROOF nicht stillschweigend nichts an oder erfindet leise etwas – es fällt auf eine offengelegte, deterministische Schätzung zurück (estimateInk(): eine angegebene Formel über Zeichenanzahl, Überschriftenanzahl und Tabellenzellenanzahl), die im Code genau als das dokumentiert ist, was sie ist: eine Schätzung, keine Messung. Die Statuszeile der Benutzeroberfläche sagt dir, welche die Zahlen erzeugt hat, die du siehst – sie lautet entweder measured · N glyph runs across N pages oder estimated · layout measurement unavailable, sodass du nie auf eine Vermutung schaust, die als Messung präsentiert wurde. Das eigene „Methoden“-Feld des Detailbereichs pro Blatt stimmt damit überein und lautet measured · glyph-run geometry oder estimated · block model für dieses spezifische Blatt.

Alles nachgelagert – welche Seiten markiert werden, die Anzahl der eingesparten Blätter, der mittlere Tintenprozentsatz, der pro Seite angezeigte Grund, wenn du ein Blatt öffnest, und die Kostenangabe – wird aus dieser Pipeline abgeleitet, die gegen das aktuell geladene Dokument läuft. Nichts auf dem Bildschirm ist ein hartcodiertes Ergebnis, das als Berechnung ausgegeben wird.

Was du tatsächlich siehst

• Das Urteil zuerst. Seiten rein, Seiten raus, mit der Anzahl der entfernten Blätter und dem mittleren Tintenprozentsatz als Hauptstatistik in der Leiste – nicht in einem Einstellungsfeld vergraben.

• Die Blätterwand. Jede Seite des Auftrags als Live-Miniatur – die tatsächliche gerenderte Seite, mit CSS transform: scale() verkleinert, kein Platzhalter-Grafik oder eine von Grund auf neu gezeichnete Miniatur – mit sichtbar gestempelten Verschwendungsseiten und einer Tintenanzeige pro Seite.

• Die verschachtelte Enthüllung. Klicke auf ein Blatt, und es öffnet sich zu seiner eigenen Erklärung: wie es klassifiziert wurde, seine gemessene Tintenabdeckung im Vergleich zum 2,0%-Schwellenwert und – für eine markierte Seite – welche spezifische Art von Beiwerk es ist und warum das Entfernen nichts ändert, was du drucken wolltest. Das ist das Rückgrat des Designs: Dokument → Seiten → ein markiertes Blatt → der Grund, jede Ebene enthüllt die nächste. Von demselben Panel aus kannst du dieses eine Blatt einzeln wiederherstellen oder entfernen.

• Ein anderes Datei wirklich prüfen. Die Leiste hat eine echte Ablagezone: Ziehe deine eigene .html-, .txt- oder .md-Datei hinein (oder klicke, um eine auszuwählen), und PROOF paginiert und misst dieses Dokument mit exakt derselben Pipeline wie oben beschrieben – das ist kein zweiter Demo-Modus, es ist dieselbe load()-Funktion, durch die auch das gebündelte Dokument läuft.

• Ein echter Drucken-Button. „Drucken“ ruft das echte window.print() des Browsers gegen eine versteckte Druckwurzel auf, die den Bildschirmauftrag spiegelt; entfernte/Verschwendungsseiten tragen display:none unter @media print, sodass die Blätter, die du nicht drucken möchtest, wirklich nicht gedruckt werden. Es gibt auch einen expliziten „Trotzdem alles drucken“-Notausgang, und das Druck-CSS blendet die App-Oberfläche aus, sodass nur das Dokument selbst zum Drucker geht.

• Vorher / Nachher. Der Dialog von 1995 wird ehrlich auf der Präsentationsfolie (proof/deck.html) dargestellt, Seite an Seite mit dem, was PROOF stattdessen zeigt, sodass der Kontrast explizit dargestellt wird, nicht nur angedeutet.

Plattformen

Desktop und Mobil sind beide als erstklassige Layouts entworfen, nicht eines von dem anderen verkleinert – die Blätterwand, die Helden-Statistikzeile und die verschachtelte Detailansicht haben alle dedizierte Breakpoints bis zur Telefonbreite.

Der MCP-Server – ein Dokument ohne menschliches Zutun prüfen

Die Webseite ist eine Oberfläche von PROOF. Darunter ist PROOF dafür gedacht, direkt von einem KI-Agenten verwendet zu werden: Ein MCP-Server stellt dasselbe Dokumentmodell bereit, das auch die Web-UI verwendet, sodass ein Codierungsagent, eine Dokument-Pipeline oder Claude selbst einen Auftrag prüfen kann, bevor sich ein einziges Blatt bewegt – kein Screenshot, kein Mensch, der einen Vorschaubereich liest.

Der Server lebt in proof/mcp/ und spiegelt exakt dasselbe 15-seitige Dokument wider, das die Web-App misst – gleicher Dateiname (Q3_Operating_Review_FINAL_v4.docx), gleiche 5 Verschwendungsseiten (4, 6, 9, 11, 13) mit denselben Gründen und dieselben Kostenkonstanten (cost_per_sheet_usd: 0.012, cost_per_ink_point_usd: 0.0009), die auch index.html selbst verwendet, sodass ein Aufruf von ink_cost dasselbe Geld zitiert, das die UI auf dem Bildschirm zeigt (mittlere Tinte 2,97% und $0,0603 hier gespart, „2,9%“ und „$0,06“ in der UI gerundet). Eine Sache wird klar statt versteckt ausgesagt: Die Tintenprozentsätze in der document.js des Servers sind erfasste Werte, die aus einer echten Browsermessung gespiegelt werden, nicht vom Server selbst neu berechnet – es gibt kein portables Node-Äquivalent zur Range.getClientRects()-Glyphengeometrie-Methode von index.html, da diese API nur in einer echten Layout-Engine existiert, also gibt der Server seine Zahlen als "method": "measured_in_browser_layout" an, anstatt vorzutäuschen, sie unabhängig neu abzuleiten. Den Server so zu verdrahten, dass er ein beliebiges Dokument misst, das ihm übergeben wird – genauso wie es die Ablagezone der Web-UI bereits tut – ist der natürliche nächste Schritt.

Die vier Tools, die er bereitstellt, verifiziert gegen einen Live-Smoke-Test-Lauf (node proof/mcp/smoke_test.mjs):

Um es zu verbinden mit Claude Desktop, Claude Code oder einem beliebigen MCP-kompatiblen Client, weise den Client auf das Serververzeichnis:

cd proof/mcp
npm install

Füge es dann als MCP-Server (stdio-Transport) in der Konfiguration deines Clients hinzu, z.B. für Claude Desktops claude_desktop_config.json:

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

Es gibt keinen Netzwerk-Hop und nichts zu deployen: Der Server ist ein lokaler stdio-Prozess, genau wie jeder andere MCP-Server, den man für lokale Tools ausführen würde. Das war eine bewusste Einschränkung des gesamten Projekts – siehe „No backend" weiter unten –, erweitert auf die Agent-Ebene: agentische Fähigkeit ohne eine Hosting-Abhängigkeit, die während einer Demo ausfallen könnte.

Um zu verifizieren, dass der Server tatsächlich end-to-end funktioniert, ohne einen vollständigen Client aufzusetzen, führt man den enthaltenen Smoke-Test aus – er startet server.js als echten Kindprozess über stdio, führt den MCP-Handshake durch, listet alle vier Tools auf und ruft jedes einzelne auf:

cd proof/mcp
node smoke_test.mjs

Ausführlichere Verbindungsanweisungen (einschließlich einer Cursor-spezifischen Konfiguration) finden sich in proof/mcp/README.md.

So führt man es aus

Das Produkt ist statisches HTML/CSS/JS. Es gibt keinen Build-Schritt, keinen Bundler und keinen Server.

open proof/index.html

oder einfach proof/index.html im Finder/Explorer doppelklicken. Das ist die gesamte Installationsprozedur – kein npm install, kein Dev-Server, keinerlei Abhängigkeit von den node_modules dieses Repos, und keine externen Schriftarten, CDN-Skripte oder Netzwerkbilder.

Die Seite arbeitet mit proof/sample-document.js zusammen, das den vollständigen 15-seitigen Demo-Bericht (window.SAMPLE_DOC) liefert – die beiden Dateien in proof/ zusammenhalten, dann wird sie automatisch über ein einfaches <script src>-Tag geladen. Falls diese Datei jemals fehlt, bricht index.html nicht ab: Sie fällt auf ein kleineres, eigenständiges Demo-Dokument (FALLBACK) zurück, das direkt in die Seite eingebaut ist, sodass die App nie einen leeren Bildschirm zeigt, sondern nur ein kürzeres Dokument. In beiden Fällen funktioniert die Tintenmessung identisch, egal ob man die Datei direkt (file://) öffnet oder sie ausliefert, weil nichts in der Pipeline von Cross-Origin-Netzwerkzugriff abhängt.

Falls man sie aus irgendeinem Grund lieber über HTTP ausliefern möchte (manche Browser-Erweiterungen oder strengere lokale Sicherheitsrichtlinien können file://-Seiten stören), funktioniert jeder statische Dateiserver, z. B.:

npx serve proof

Screenshots und die Capture-Harness

Das Verzeichnis _brainstorming/ enthält die Arbeitsnotizen dieses Projekts, einschließlich capture.mjs, eines kleinen Playwright-Skripts, das frame-genaue Screenshots der Seite bei bestimmten Scroll-Positionen und Viewport-Größen (Desktop und Telefon) für die Hackathon-Einreichung aufnimmt. Es benötigt die playwright-devDependency, die in der package.json im Repo-Root deklariert ist:

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

Dies ist ein Entwicklungswerkzeug, kein Teil des Produkts – PROOF selbst benötigt nichts davon, um zu laufen.

Kein Backend, mit Absicht

PROOF hat keinen Server, keine Datenbank und keinen Deploy-Schritt für das Produkt selbst. Seine gebündelten Demo- „Daten" sind ein handgebauter, realistischer Quartalsbericht, der als statischer Inhalt ausgeliefert wird (sample-document.js, mit einem kleineren eingebauten Fallback, falls diese Datei fehlt), sodass jede daraus berechnete Zahl – Seitenzahl, Tintenabdeckung, Verschwendungs-Flags, Kosten – echte Arithmetik über echte Inhalte ist, sobald die Seite lädt, kein Fetch auf ein Backend, das während einer Demo down, langsam oder nicht vorhanden sein könnte. Sie akzeptiert außerdem wirklich eine Datei, die man darauf ablegt, und verarbeitet sie durch dieselbe Pipeline. Der MCP-Server ist der eine Prozess, der außerhalb des Browsers läuft, und er ist ein lokaler stdio-Prozess statt eines gehosteten, sodass er keinerlei Deploy-Risiko eines Web-Backends trägt.

Warum der Druckdialog

Ungefähr ein Dutzend andere Kandidaten für „langweilige Formate" wurden während des Designs in Betracht gezogen und verworfen, aus mehreren verschiedenen, jeweils einzeln begründeten Gründen: Ein Abonnement-Manager, ein Paket-Tracker und eine Stromrechnung wurden verworfen, weil eine ehrliche Neuerfindung bedeuten würde, Daten zu erfinden ohne legitime Quelle (ein Kontostand, der echte Tracking-Status eines Paketdienstes, ein Zählerstand); ein Kündigungsablauf und eine CAPTCHA wurden verworfen, weil sie keine echten Informationen hinzufügen; ein Browser-Tab- Manager und eine Flugzeugsitzkarte wurden verworfen, da sie bereits gut von bestehenden Produkten abgedeckt sind (OneTab/Arc, SeatGuru); ein Cookie-Banner war eine zu kleine Leinwand für die beabsichtigte geschichtete, scrollgetriebene Enthüllung; und ein früheres Konzept für eine Rezeptdosierung wurde gestrichen, weil es einen Sofortverständnis-Test nicht bestand. Der Druckdialog ist der eine Kandidat, der alle diese Hürden auf einmal überwand: sofort erkennbar, fügt echte Informationen hinzu, die der aktuelle Dialog verbirgt, und jede dramatische Zahl auf dem Bildschirm – Seiten, Erkennung leerer Seiten, Tintenabdeckung – ist etwas, das ein Browser tatsächlich aus einem echten Dokument live berechnen kann, ohne dass etwas vorgetäuscht wird. Der vollständige Entscheidungsbericht, einschließlich der verworfenen Kandidaten und der Begründung bei jedem Schritt, befindet sich in _brainstorming/SPEC.md.

Repository-Struktur

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 ist eine kurze, eigenständige Produktpräsentationsseite – man öffnet sie auf dieselbe Weise wie index.html –, die in sieben Folien in derselben visuellen Sprache wie das Produkt selbst erklärt, warum der Druckdialog kaputt ist, wie PROOF die Tintenabdeckung misst (gemessen vs. gerastert) und die Logik des Klassifikators für „trotz geringer Tinte beibehalten". proof/docs.html ist die tiefere, scrollbare Referenz: Jede Funktion – einschließlich des MCP-Servers – wird gegen den aktuellen Code mit echten, live verifizierten Zahlen dokumentiert.

Gebaut für den Cursor Calgary Hackathon, August 2026.