rdmsm4x-changelog-20260915-2251-bitroo-epic-scenes-tidbyt-catalog-esp32

2026-09-15 22:51:18 EDT · rdmsm4x · session_012cXdr2uPhnPS1cQfbt9pPQ

EPIC-20260915-01 (BitRoo program): all four children resolved. Scene library 5 → 31 public, Tidbyt's 888-app catalog inventoried and a tranche ported, ESP32 researched to a recommendation. Two follow-ups opened from doing the work.

Scope

Scene library: 5 → 31 public scenes

16 general scenes (sparkline, heatmap, dualMetric, progress, battery, calendar, countdown, uptime, binaryClock, weather, ticker, nowPlaying, textCard, alert…) plus 10 Tidbyt-inspired. All render from data handed in — none calls a network, so any scene renders with no token, device or service. 27 are offered in both apps' pickers.

The defect only looking could find: tracking does not enlarge glyphs. Font3x5 is a fixed 3×5 bitmap, so tracking widens the gaps between characters and does nothing at all to a single-character string like a day number. Several scenes — and the pre-existing clock — were written as though it scaled. Added PixelCanvas.textScaled, and a test now asserts scale 3 lights exactly 9× the pixels while tracking 3 changes a single glyph's width by zero.

scripts/render_contact_sheet.zsh makes the check repeatable: 38 variants into one PNG, and it fails if the output is under 1 KB, so a renderer that silently wrote nothing cannot pass.

Tidbyt catalog: the honest answer to "re-create them all"

Licence settled first, as the ticket required: the repo is Apache-2.0 and their CLA binds contributors to Tidbyt, not us. But the licence covers the code, not the content — many apps embed artwork Tidbyt cannot sublicense (Nyan Cat, Mario, Minions, Seinfeld, Oblique Strategies, Dothraki). A NOTICE file carries the attribution and statement of changes; none of that is reproduced.

All 888 apps classified by what each needs to run:

Of the 49 self-contained, 22 are third-party-IP wrappers and 6 are countdowns Scenes.countdown already covers with a date argument. ~10 were worth porting, and 10 were ported. "All of them" is not achievable for structural reasons, not effort ones.

ESP32 / reflashing: the blocker is ours, not the firmware's

Both Tidbyt generations are ESP32 and Tronbyt (Apache-2.0) can reflash them. But do not. The firmware pulls WebP; BitRoo only encodes GIF and pushes. Flashing today would void the warranty on Rich's hardware and produce a device that displays nothing.

Measured here rather than inherited from a code comment:

CGImageDestinationCopyTypeIdentifiers() -> 22 types, ZERO webp
gif present (control): true      <- so the empty webp result is a real absence
lipo -archs /opt/homebrew/lib/libwebp.dylib -> arm64      <- arm64 ONLY
lipo -archs /opt/homebrew/bin/cwebp        -> arm64

So the easy fix is closed off: linking Homebrew's libwebp breaks the universal2 gate in exactly its silent way — builds, copies, checksums and launches on Apple Silicon, dies at exec on the two Intel Mac Pros. Recommended sequence: vendor a universal2 libwebp → stand up the /next pull endpoint → prove the chain on a ~$30 matrixportal-s3 board the firmware already supports → only then consider the Tidbyt, and that is Rich's call. No device was flashed, powered on or modified.

Verification

swift test       -> 27 tests, 0 failures    (10 at session start, then 20, then 27)
                    incl. a negative control: different seeds MUST give different panels,
                    or a "seeded" generator returning a constant would pass
contact sheet    -> 38 variants rendered and visually inspected
make_app.zsh     -> "architectures ok: x86_64 arm64", signed ZU2882L4HT
iOS clean build  -> BUILD SUCCEEDED; reinstalled and screenshotted on iPhone 18 Pro
wiki             -> 4 ticket pages 200 through the live gateway, bogus path 404 as control

Still not true, and labelled everywhere

BitRoo has never talked to real hardware: no Tidbyt token, nothing ever pushed to a device, Tronbyt never pointed at a server, ESP32 still only a Display.Kind case, and the iOS app has run only in Simulator. Recorded in SESSION-STATE.md and STATUS.md.

Outstanding

• FEAT-20260915-05 — universal2 WebP encoder. The single blocker for ESP32/Tronbyt, and worth doing for the cloud path anyway (WebP is smaller on the wire than our GIFs).
• FEAT-20260915-04 — bitROO ships no App Intents, which apps/CLAUDE.md §2 makes mandatory. Whoever takes it must read the Metadata.appintents silent failure there first: swift build never runs the processor, so the intents compile and are invisible to Siri.

Nothing needs Rich. No secrets appear in this record.