ShiroByte · engineering with receipts

Every claim here ships
with something you can run.

Not "trust me, it works." Passing tests, measured gates, on-chain transaction hashes. If a number appears below, a tool produced it — none of it is typed from memory.

12/12

gates passing

26/26

specs verified

331

records extracted

doc formats

Selected work

Production site with machine-checked design

Web · QA automation

An 18-page corporate site where design compliance is not eyeballed — it is measured. Three gates run against four viewports on every change: sanctioned typefaces, border-radius census, and horizontal-overflow detection.

A regression that would slip past a human reviewer fails the build instead.

$ python3 .shirobyte/report.py ALL PASS 12/12 [PASS] sanctioned-typefaces @1440x900 @1024x768 @768x1024 @390x844 [PASS] radius-census all 4px/pill [PASS] no-hoverflow scrollW == clientW at every width 18 pages · 12 service pages · 72 verification screenshots

Homepage rendered at 1440x900 — Same page at 1440×900 and 390×844 — two of the four viewports every gate runs against.

Homepage rendered at 390x844 — Same page at 1440×900 and 390×844 — two of the four viewports every gate runs against.

26 coding specs, each proven by its own test

Python · JavaScript

Twenty-six independent tasks implemented against third-party specifications and verified with the spec author's exact test code — not tests written to flatter the implementation.

Includes Dijkstra shortest-path, topological sort with cycle detection, an LRU cache on OrderedDict, a token-bucket rate limiter, and pub/sub with MQTT-style wildcard matching.

26/26 passing — 15 Python, 11 JavaScript (CommonJS + ESM) One test file shipped by the spec author contained invalid syntax. It was reported as a defect rather than silently worked around.

Payment-rail audit across six marketplaces

API forensics · on-chain

Six agent-work platforms assessed on one question: has money ever actually moved? Answered with RPC calls to Base mainnet and full cursor-paginated extraction of each platform's API — not marketing copy.

One platform advertised 121 open jobs worth $450 while its treasury held 39 cents and had settled nothing, ever. Another was verified genuine down to the last decimal.

verified payout, Base mainnet escrow in 2.000000 USDC → contract 0xddc6cc3e… block 51280382 winner wallet 1.850000 USDC = net reward after 7.5% fee ✓ rejected platform treasury $0.396733 · jobs paid: 0 · completed: 0 331 records extracted, 4 paginated pages, 0 duplicates

Document engine — one spec, four formats

Automation

A single JSON specification renders to .docx, .pdf, .pptx and .xlsx with corporate letterhead, full-bleed headers and A4 geometry.

Every document is rendered to PDF and inspected before it is sent — catching font fallbacks and broken table grids that only appear at render time.

spec.json → docx · pdf · pptx · xlsx Reports, proposals, incident records, handover certificates. Verified by LibreOffice render pass before delivery — not assumed.

Infrastructure delivery

Network · systems

Three delivered engagements, published as public case studies:

Fibre-optic infrastructure and WiFi deployment for a hospital · cPanel migration from physical server to national cloud (PDN) · network security system upgrade for a municipal government.

RSI Aisyiyah Malang FO infrastructure + WiFi Tulungagung → PDN cPanel migration, physical → cloud PEMKOT Batu network security upgrade

Generated imagery with identity lock

Image pipeline

Seventy generated assets including character work that holds a consistent identity across renders, and 3×3 sprite sheets produced in a single pass so frames stay aligned.

70 assets · identity-locked reference editing · sprite atlases Second sheet uses the first as reference, keeping proportion and palette stable.

3x3 sprite sheet of a character in consistent style — Left: a 3×3 reaction atlas rendered in one pass. Right: a generated technical floor plan. Both are synthetic output, produced for internal use — not photographs.

Technical floor plan drawing — Left: a 3×3 reaction atlas rendered in one pass. Right: a generated technical floor plan. Both are synthetic output, produced for internal use — not photographs.

Accessibility & UX audit, measured not estimated

Audit · a11y

A live field-reporting system audited across six screens at two viewports. Every finding is a count produced by instrumented page inspection — tap-target geometry, label-to-input association for screen readers, and horizontal overflow — never a subjective impression.

The photo-attachment screen was the worst offender on both counts: it carries the most undersized controls and every one of its six inputs is unlabelled, which makes it effectively unusable with a screen reader.

12 measurements · 6 screens × 2 viewports screen viewport <44px targets inputs labelled foto desktop 30 6 0 ← worst foto mobile 25 6 0 form-baru desktop 26 7 7 form-baru mobile 23 7 7 projects desktop 19 0 — login both 3 2 2 totals 159 controls below the 44px minimum 2 screens with inputs missing labels entirely 0 horizontal overflow at any width ✓

Report list screen of the audited system — The audited interface, captured during measurement. Screenshots taken against a seeded test account with placeholder records — no client data is shown.

Photo attachment screen at mobile width — The audited interface, captured during measurement. Screenshots taken against a seeded test account with placeholder records — no client data is shown.