GET /api/work/internal-erp/toolbox

The toolbox, extracted

Live · September 2026 · sole engineer

The system itself must stay private, but the useful parts don't have to. Nine pieces pulled out and scrubbed clean — real warehouse code, public and readable.Nine self-contained pieces of the ERP, lifted out and sanitized — barcode parsing, thermal-print layout, a self-updating device agent, invoice parsers.

TypeScript
Node.js
React
PostgreSQL
ZPL
zxing-wasm

Source

pieces extracted: 9
customer records included: 0

GET/api/work/{id}

Parameters

Request

curl "https://portfolio.dylansg0318.workers.dev/api/work/internal-erp/toolbox"

source: src/content/projects/{id}

Response200 OK · 3.0 KB

{
  "id": "internal-erp/toolbox",
  "title": "The toolbox, extracted",
  "status": "live",
  "year": 2026,
  "category": "work",
  "role": "sole engineer",
  "summary": "Nine self-contained pieces of the ERP, lifted out and sanitized — barcode parsing, thermal-print layout, a self-updating device agent, invoice parsers.",
  "summary_plain": "The system itself must stay private, but the useful parts don't have to. Nine pieces pulled out and scrubbed clean — real warehouse code, public and readable.",
  "stack": [
    "TypeScript",
    "Node.js",
    "React",
    "PostgreSQL",
    "ZPL",
    "zxing-wasm"
  ],
  "metrics": {
    "pieces_extracted": "9",
    "customer_records_included": "0"
  },
  "links": {
    "source": "https://github.com/Dylansg318/Portfolio/tree/main/code"
  },
  "parent": {
    "id": "internal-erp",
    "title": "The internal ERP that runs a dental supply company",
    "page": "https://portfolio.dylansg0318.workers.dev/projects/internal-erp"
  },
  "problem": "A one-company ERP can't be open-sourced, so a portfolio built on it asks to be taken on faith. But most of what's interesting in the codebase isn't the business at all — it's barcode grammar, thermal-printer geometry, self-updating field devices, defensive SQL helpers. The problem was proving the work is real without leaking a single customer, order number or vendor account.",
  "unique": "Extraction as a contract, not a copy-paste. Each piece was lifted along its natural seam (the app-coupled imports cut and replaced with injected config), sanitized against a hard deny-list enforced by grep, and kept its load-bearing comments, because the \"why\" is the point. Fixtures were regenerated, not scrubbed: a test barcode literally encodes a real order number, and a print-preview fixture carries a real name and address, so copying them was never an option.",
  "ai": "The extraction itself was run by a fleet of AI agents, one per piece, each briefed with the same hard sanitization contract and a grep-enforced deny list, working in parallel into disjoint folders. I wrote the contract, chose the seams, and audited the output — including a second-model review pass — before anything was committed.",
  "learned": [
    "The dangerous leaks aren't passwords, they're fixtures. Credentials live in env vars and never touch the repo; the real customer data hides in test barcodes, sample labels and invoice PDFs. Regenerate, never redact.",
    "How cleanly a module lifts out is a code-quality metric. The pieces that took minutes were the ones already built with the seams in the right place — pure functions, injected config, zero app imports. The ones that fought back were showing me where the design is tangled.",
    "Never publish by pruning a private repo. Git history keeps everything ever committed, including what you deleted. Anything meant to be public gets copied into a tree that never held the private material."
  ],
  "page": "https://portfolio.dylansg0318.workers.dev/projects/internal-erp/toolbox"
}

Live: this is the answer from this site’s API, not a mock. Send re-runs the request with your parameters; if the answer names a page, it opens.

The problem

A one-company ERP can't be open-sourced, so a portfolio built on it asks to be taken on faith. But most of what's interesting in the codebase isn't the business at all — it's barcode grammar, thermal-printer geometry, self-updating field devices, defensive SQL helpers. The problem was proving the work is real without leaking a single customer, order number or vendor account.

What was unique

Extraction as a contract, not a copy-paste. Each piece was lifted along its natural seam (the app-coupled imports cut and replaced with injected config), sanitized against a hard deny-list enforced by grep, and kept its load-bearing comments, because the "why" is the point. Fixtures were regenerated, not scrubbed: a test barcode literally encodes a real order number, and a print-preview fixture carries a real name and address, so copying them was never an option.

Where AI fit in

The extraction itself was run by a fleet of AI agents, one per piece, each briefed with the same hard sanitization contract and a grep-enforced deny list, working in parallel into disjoint folders. I wrote the contract, chose the seams, and audited the output — including a second-model review pass — before anything was committed.

GET/api/work/{id}

Parameters

idfields

Request

curl "https://portfolio.dylansg0318.workers.dev/api/work/internal-erp/toolbox?fields=problem%2Cunique%2Cai"

source: src/content/projects/{id}

Response200 OK · 1.3 KB

{
  "problem": "A one-company ERP can't be open-sourced, so a portfolio built on it asks to be taken on faith. But most of what's interesting in the codebase isn't the business at all — it's barcode grammar, thermal-printer geometry, self-updating field devices, defensive SQL helpers. The problem was proving the work is real without leaking a single customer, order number or vendor account.",
  "unique": "Extraction as a contract, not a copy-paste. Each piece was lifted along its natural seam (the app-coupled imports cut and replaced with injected config), sanitized against a hard deny-list enforced by grep, and kept its load-bearing comments, because the \"why\" is the point. Fixtures were regenerated, not scrubbed: a test barcode literally encodes a real order number, and a print-preview fixture carries a real name and address, so copying them was never an option.",
  "ai": "The extraction itself was run by a fleet of AI agents, one per piece, each briefed with the same hard sanitization contract and a grep-enforced deny list, working in parallel into disjoint folders. I wrote the contract, chose the seams, and audited the output — including a second-model review pass — before anything was committed.",
  "page": "https://portfolio.dylansg0318.workers.dev/projects/internal-erp/toolbox"
}

Live: this is the answer from this site’s API, not a mock. Send re-runs the request with your parameters; if the answer names a page, it opens.

What’s here

Nine working parts of the warehouse system, pulled out on their own and cleaned up. The barcode reader that turns a scan into “which product is this”. The converter that stopped labels printing as blank pages. The layout engine that decides how a packing slip fits on a 4-inch thermal label. The little program that keeps the warehouse printer PC updating itself safely, and rolls itself back if an update goes bad. The parsers that read what the shipping carriers actually billed us, line by line.

Every name, address, order number and account number was replaced first. The test data was rebuilt from scratch, because a barcode in a test file is a real barcode; it literally contains a real order.

The code sits in the code/ folder of this site’s own repository, open to anyone. This page is what it holds and how it was made safe to hand over.

The pieces

All of it lives under code/ in this site’s repository, readable excerpts with their tests and the production reasoning kept in the comments:

barcode-parsers — a pure-function GS1 Application Identifier parser (GTIN-8/12/13/14 equivalence, FNC1 ambiguity, code-ID prefixes) and carrier-label extraction for USPS IMpb, FedEx “96” and UPS 1Z barcodes.
camera-scanner — a zxing-wasm decode loop with an N-frame agreement policy, and a bench that models hand tremor as an AR(1) walk so the gate measures repeatability rather than amplitude.
zpl-layout-kit — glyph-advance text metrics (replacing a fontSize × 0.6 guess), barcode module-width fitting, Floyd–Steinberg 1-bit dithering, and a render-and-look preview loop.
epl-to-zpl — 184 lines that fix “the printer under a ZPL driver prints EPL as a blank page”.
device-agent — a self-updating Windows agent whose supervisor verifies sha256 + syntax before hot-swapping, runs a probation window, and rolls back and blacklists a crash-looping version. The rollback executor never updates itself.
carrier-invoice-parsers — the UPS 250-column billing file and FedEx PDF invoices, with column semantics worked out against invoice totals instead of trusted from a spec.
server-utils — withSavepoint (why catching a unique-violation inside a Postgres transaction is a trap), an SQL-shape guard for an LLM-driven write endpoint, AES-256-GCM secret storage, zero-dep TOTP, concurrency primitives.
client-utils — list-state hooks with URL + localStorage persistence and TTL expiry, a freeform US-address parser, a unified browser CSV/XLSX/XML reader.
arch-guard — a source-scan invariant engine for the rules an import graph can’t see.

The barcodes in the original test suite decode to a real order and the label fixtures print a real customer’s address, so a sanitization that only grepped for the company name would’ve missed every one of them. Every fixture was regenerated.

The three printing pieces — the layout kit, the EPL converter and the device agent — have their own write-up: printing labels when the printer can lie about it.

What stayed behind

The order pipeline, the repricing strategy, the channel syncs and the books: anything that is the business rather than engineering around it. Where an extracted piece had one foot in that territory, the README says exactly which seam was cut and why.

What I learned

The dangerous leaks aren't passwords, they're fixtures. Credentials live in env vars and never touch the repo; the real customer data hides in test barcodes, sample labels and invoice PDFs. Regenerate, never redact.
How cleanly a module lifts out is a code-quality metric. The pieces that took minutes were the ones already built with the seams in the right place — pure functions, injected config, zero app imports. The ones that fought back were showing me where the design is tangled.
Never publish by pruning a private repo. Git history keeps everything ever committed, including what you deleted. Anything meant to be public gets copied into a tree that never held the private material.

GET/api/work/{id}

Parameters

idfields

Request

curl "https://portfolio.dylansg0318.workers.dev/api/work/internal-erp/toolbox?fields=learned"

source: src/content/projects/{id}

Response200 OK · 821 B

{
  "learned": [
    "The dangerous leaks aren't passwords, they're fixtures. Credentials live in env vars and never touch the repo; the real customer data hides in test barcodes, sample labels and invoice PDFs. Regenerate, never redact.",
    "How cleanly a module lifts out is a code-quality metric. The pieces that took minutes were the ones already built with the seams in the right place — pure functions, injected config, zero app imports. The ones that fought back were showing me where the design is tangled.",
    "Never publish by pruning a private repo. Git history keeps everything ever committed, including what you deleted. Anything meant to be public gets copied into a tree that never held the private material."
  ],
  "page": "https://portfolio.dylansg0318.workers.dev/projects/internal-erp/toolbox"
}

Live: this is the answer from this site’s API, not a mock. Send re-runs the request with your parameters; if the answer names a page, it opens.