Changelog

Build logs, in the order they happened.

2026-07-02

PortixOne Build Log #1

Built:: Monorepo scaffold (runtime + sdk-js + shared/protocol/escpos packages), and the 7-repo knowledge network: portixone, portix-runtime, portix-sdk-js, awesome-web-printing, browser-printing-examples, escpos-cheatsheet, thermal-printer-test-files.
Learned:: ESC/POS command bytes are stable enough across vendors to build real, verifiable test fixtures and a cheatsheet from the Epson reference — verified by hex-dumping generated files, not just writing docs from memory.
Fixed:: Client errors (401/400) were logging at ERROR level in the runtime instead of WARN — reserved ERROR for actual system faults.
Next:: Connect this site's waitlist to a real Supabase project + Resend, then start Week 1 of the learning/content cycle (browser printing limitations write-up).
Question for developers:: What's the first real print job you've had to hand-roll a bridge for?

2026-07-03

Built:: Milestone 2 — Developer Zero: @portixone/sdk published on the public npm registry, a mock mode that renders a receipt preview with zero hardware, and a Windows Service + tray + Inno Setup installer verified end-to-end.
Learned:: Reinstalling over a running tray stacked duplicate processes, and a process-kill script matched and killed itself mid-run — both only surfaced by actually testing reinstall/uninstall, not by reading the installer script.
Fixed:: Print-cut timing (the cutter fired before paper cleared the head) and the runtime silently ignoring .env in favor of a stale persisted config.
Next:: Build the Local API: per-app pairing instead of one shared admin key, and a queue that survives a runtime restart.
Question for developers:: What almost-invisible bug has only ever shown up for you during a real reinstall, not a fresh install?

2026-07-05

Built:: Milestone 3 — Local API, pairing, and a persisted queue: per-app pairing (request/approve/poll), a queue rewritten as service/store/worker with crash recovery, LAN printer discovery, and human-readable hardware errors (PrinterOfflineError, PaperOutError, PrinterTimeoutError...) instead of raw exceptions.
Learned:: A generic connection error tells a developer nothing actionable — naming the exact failure (paper out vs. offline vs. busy) is the difference between a support ticket and a five-second fix on their own.
Fixed:: An unbounded PowerShell call in the Windows Spooler driver that could hang a print job forever if the spooler service itself hung.
Next:: Measure instead of build: real print latency, pairing duration, and failure rates from a live runtime.
Question for developers:: What error message from a piece of hardware infrastructure has wasted the most of your debugging time?

2026-07-05

Built:: Milestone 4 — Productization: GET /metrics (pairing duration, print latency, failures, WebSocket disconnects), a 1000-job stress test, Node.js embedded in the installer so it has zero prerequisites, a portable no-admin build, and @portixone/sdk@0.3.0/protocol@0.2.0/shared@0.2.0 republished with the full API. This site's own landing was rebuilt around an honest "Developer Preview" positioning to match.
Learned:: Naming a metric after what it actually measures — not what it is supposed to measure eventually — is what makes a metrics panel trustworthy. Our WebSocket counter is named totalDisconnects, not reconnectCount, because reconnect-on-drop isn't built yet: every value in it today is a disconnect nothing recovered from automatically.
Fixed:: npm does not include CHANGELOG.md in a published package by default (only package.json/README/LICENSE) — caught before three packages shipped without theirs.
Next:: A genuinely clean-machine install test (no Node.js, no dev tools) and real usage of PortixOne inside a production app, not a demo.
Question for developers:: Have you ever shipped a metric whose name quietly overclaimed what it measured?