Lab notes

The work, in writing.

Short-form writing about the work in progress — design rationale, the failures before each project converged, technical asides that don't fit on a project page. Updated when there's something worth saying. Newest first.

  • 2026 · April 14
    cargo-forge

    Why cargo-forge uses zig instead of cross.

    The first version of cargo-forge wrapped cross, the standard tool for cargo cross-compilation. It worked. It also required Docker on every developer machine, and on FreeBSD — the primary development environment here — it required a Linux VM to host Docker, which negated half the point of cross-compiling natively in the first place.

    The replacement was cargo-zigbuild, which uses zig's universal C compiler as the cross-linker. Zig ships every libc and every linker for every supported platform inside one binary; with that available, cargo can produce FreeBSD, Linux, Windows, and ARM64 release binaries from a single FreeBSD workstation, no VMs, no containers, no root access required.

    The framing that stuck: zig is the engine, cargo-forge is the car. cargo-forge handles the rustup target installation, the unsupported host/target detection, the Windows-needs-PowerShell-not-zip detail, the proxy-aware HTTP fetch when zig isn't installed yet. Zig does the actual cross-compiling. Pulling those concerns apart was the real design move.

  • 2026 · March 28
    Folio

    Three failures before Folio's datasheet format converged.

    The earliest version of Folio tried to capture a software component the way a chip datasheet captures silicon: pinout, electrical characteristics, register map. It didn't survive contact with real consulting work, because software components don't have stable interfaces in the way silicon does. The "pinout" of a JWT auth pattern depends on which client codebase it's embedded in.

    The second version went the other direction — pure markdown notes in a folder, no schema. Easy to write, impossible to query. A consultant looking for "do we have a thing for X" couldn't get an answer in less time than just searching the codebases manually.

    The third pass added the fields that hardware datasheets don't need: Current Form, Lives In, Extraction Cost. These name what software has that silicon doesn't: a component is rarely shipped as a clean library. It's embedded in three places, has been ported once, and would take some specific number of days to extract. The datasheet captures that. That's the version that's now at v0.1, and it's the first version that's been useful in actual client conversations.

  • 2026 · February 02
    Conductor

    Conductor took a break. Here's why, and where it's going.

    Conductor is a C++ orchestration platform for distributed field nodes — SCADA-adjacent, with a time-travel debugging architecture that lets operators replay any past system state. The architecture is real. The first prototype demonstrated heartbeat tracking, event processing, and command dispatch across six simulated field nodes with full replay.

    Then it stopped. Not because the design was wrong, but because the surrounding tools weren't ready yet. Without Folio, there was no clean way to capture which auth pattern Conductor's gRPC layer should use. Without cargo-forge, every release build required a per-platform CI matrix that the project didn't have headroom to build out. Conductor was waiting on the rest of the lab to mature.

    Both of those are now in place. Conductor's next phase is currently being scoped — production target is critical infrastructure where auditability isn't optional, and the time-travel architecture is what makes that audit story credible. The entry on the home page will be expanded as the project moves out of stall.

From here

See the projects.

The notes describe the work; the catalog shows what's shipped.

Back to the work →