• What it is. A custom plugin for the TRMNL e-ink display that gathers everything the day needs — the next trains, the forecast and any rain or weather alerts, today’s calendar events, today’s tasks, birthdays, and the weekly and monthly checklists — and renders it as a single quiet screen. It hangs on a wall in my house and I read it every day.
• Why it matters. The information was already there, spread across a calendar, a notes vault, a weather app, and a transit app — each one a phone unlock and a context switch away. Putting it on a wall in e-ink makes it glanceable and unbaiting: it draws no attention until you look at it, and it has nothing to sell you when you do.

Technical details

• Built the aggregator as a fan-out of standalone executables: update runs each source’s fetch, and every one prints a JSON document and exits zero even on failure, so a rate-limited API or an unreachable feed degrades to an empty section instead of taking down the screen. Each result is validated with jq empty against a typed fallback before it reaches the merge
• Wrote the BART departures module in Go against the agency’s GTFS-Realtime protobuf feed, joining live trip updates to the static GTFS trip table to resolve route identities, filtered to the specific origin and destination platforms and the two routes I actually ride
• Pulled weather from the National Weather Service gridpoint API for two cities, deriving the rain call from the maximum hourly precipitation probability before the end of day rather than the daily summary, and merged active alert zones into a single banner
• Made events a pluggable aggregation of its own: source adapters (an ICS feed reader in Go, a recurring-events reader over my notes) each emit the same normalized event schema, and only the aggregator knows what “today” means
• Sourced tasks straight out of my plain-text Obsidian vault with ripgrep, matching the same dated-task syntax taskbuffer.nvim uses, so the wall screen and the editor read one set of files
• Wrote the display template in Liquid against a fixed 800×480 e-ink panel with no scroll: it counts the rows it is about to draw and steps the font size down through five stops so a heavy day still fits on one screen
• Publishes a single trmnl.json the device polls every fifteen minutes, with a containerized local preview server standing in for the endpoint during template work

• What it is. A Go daemon running on a home server that watches each Syncthing folder against a size budget. When a folder runs over, the oldest and least-touched files are moved off to a ZFS cold-storage pool, and Syncthing propagates the deletion so they leave every phone and laptop too. A React web interface shows the whole library — archived files alongside synced ones, with thumbnails — and any file can be restored to sync or downloaded straight from the browser.
• Why it matters. Syncthing keeps every device in step, which means every device carries the whole library and the smallest disk sets the ceiling. This puts a budget on each folder and makes the overflow addressable instead of gone: the photo from four years ago is still there with a thumbnail, one click from coming back.

Technical details

Direction and architecture mine; the Go and React implementation was built by AI coding agents I ran to my specification, in six reviewed phases. The original Flask prototype was hand-written.

• Provisioned the storage underneath it: three drives in a ZFS raidz1 pool giving ~3.6TB usable with single-drive fault tolerance, LZ4 compression, snapshots, and block checksumming that pairs with the daemon’s own SHA-256 move verification for end-to-end integrity
• Directed the offload policy as a scored eviction: files rank on max(mtime, atime) and the lowest goes first, with per-folder glob patterns marking directories that must never be evicted whatever their age
• Made the daemon safe to run against a live sync rather than fighting it — it only moves files on disk and lets Syncthing’s watcher notice, holds a grace period so it can’t race an in-flight transfer, re-checks mtime immediately before moving, and reconciles on every pass so a file another device re-syncs is caught and marked back to synced
• Directed the failure handling the design actually needs: cross-filesystem moves fall back to copy, verify, then delete when os.Rename returns EXDEV; offloading pauses with a warning under 5% free on the cold pool; and no eviction happens at all until the first full scan has completed
• Specified a SQLite catalog as the one source of truth for what exists where — every file synced or archived, its status, metadata, and thumbnail — so the web interface can present one library across two filesystems
• Directed a thumbnail pipeline over a bounded worker pool covering images, video, and PDF through three different tools, so the gallery works for a folder of books as well as a camera roll
• Directed the React frontend as a single page with no state-management library — an infinite-scroll gallery on an IntersectionObserver, a sortable file browser, and a config panel for budgets and never-evict rules — compiled into the Go binary at build time so deployment is one file plus a systemd unit
• Directed a two-tier test setup: in-process end-to-end tests behind a build tag that exercise the full scan-offload-restore pipeline on temp directories, plus a Docker Compose tier that runs the daemon against a real Syncthing instance with a health-gated startup

• What it is. A Python tool that reads an expert report, extracts every footnote and its citation, finds the matching source document, and assembles a verified, highlighted binder of supporting materials — work that was previously done by hand.
• Why it matters. Footnote verification is slow, error-prone, and high-stakes in legal and expert work. The tool cut the common case from ~60 to ~25 seconds per footnote against timecard baselines, while making the checks more consistent.

Technical details

• Built CLI application in Python using Click
• Parsed Word document XML to extract footnotes and associated text
• Used lightweight NLP to identify key citation attributes (authors, years, titles)
• Implemented candidate-file matching with fuzzy search (fzf, ripgrep, pymupdf)
• Integrated PDF rendering and highlighting via mupdf subprocesses
• Eliminated duplicated manual file-retrieval steps and improved consistency of QA