Rust systems and backend engineering · Linux and agent infrastructure · Game reconstruction
I'm Peter. I build Linux upgrade tooling, infrastructure for running AI coding agents, self-hosted public-safety software, and native game reconstructions. I care about software you can inspect, recover, and keep running without a permanent vendor relationship.
My infrastructure, agent tooling and public-safety work lives at Fieldmouse Works. My personal repositories cover native game reconstruction and persistent worlds.
Looking for systems/backend work, remote or based in Europe. I live in the Pacific Northwest and would like to move to Europe. I work best in writing: clear contracts, design documents, reviewable changes, and evidence from real machines.
Fieldmouse Works · Current work · Other projects · How I work · Contact
Training records for 911 centers · Rust / Axum / SQLite / SvelteKit
I've been a 911 dispatcher for nearly 20 years, in two states. Every new dispatcher spends months in a training program, and every shift produces a daily observation report that decides whether they're released to work alone and can resurface years later in a grievance or a lawsuit. Consolebook keeps those records the way they need to be kept: versioned training programs, daily reports that trainers draft and review together, weekly summaries, task signoffs, and each trainee's complete file. A finalized record never changes; a correction is an amendment that seals a new version, and every export verifies from the file alone.
One executable, an embedded web interface, and one SQLite data directory per center, installed and upgraded with one command. npm run demo serves a throwaway installation full of invented records.
Stage: pre-alpha, v0.3.0. Usable for development and evaluation; no production or personnel data. Remaining work is tracked in the roadmap.
Proven upgrade routes for old Linux machines · Python / Rust
Upgrades an old Linux server to a current release one hop at a time, carrying its services and data along (web server, PHP, database, DNS) and checking they still answer before the next hop. Each route uses small, reviewed fixes for the places where a plain release upgrade breaks, and it counts only after a replay from scratch on test machines keeps every health check green. The native package manager stays in charge. Agents help find the fixes; a static Rust client (in progress) walks a route with no model, snapshotting before each hop and rolling back if a health check fails.
Routes with passing replays: Debian 4.0 etch (2007) to Debian 13, Ubuntu 14.04 to 26.04, and CentOS 4, 5, 7, and 8 to AlmaLinux 10.
Stage: early. CI proves each route's userland in a chroot. Kernels, bootloaders, and real reboots are tested separately in maintainer-run VMs, where every route except the newest, CentOS 4, has passed on real installs with a reboot after every hop. See the README and spec.
NixOS modules for a machine run by an AI agent · Nix / Python / Rust / Shell
The server I develop on is run by talking to Claude Code, from a phone as often as a desk. burrow is the generic half of that setup. The agent gets the whole machine with no permission prompts, because nearly everything it can do undoes itself: ZFS snapshots before anything deletes files, a dead man's switch that reverts a system change unless it's confirmed within 10 minutes, and trial boots that fall back from a kernel that hangs. The few one-way doors (wiping disks, flashing firmware, deleting remote data, force-pushing main) still ask.
It also keeps the machine current unattended (flake inputs and Claude Code built, VM-tested, health-checked and reverted on failure; Renovate across every repository; new CVEs turned into agent jobs the same hour), runs every pull request through a review-and-merge steward, hands project work to per-project agent sessions, and gives a risky task its own microVM with allowlisted egress and no GitHub token.
Stage: in daily use on one machine; options may still move. VM tests boot the sandboxes under nested KVM. MIT. See the README.
A ledger for the code agents write · Rust
Conary keeps the record of code that agents write, on top of git and GitHub: every pull request on the machine with its intent, who made it down to the agent session, its revisions, the checks and reviews that proved it, and where it landed. cn why FILE:LINE names the change that brought a line onto trunk, from the ledger or from git notes in any clone, and agents query the same ledger through an MCP server. The log is anchored at a ref on GitHub, so one that loses history is refused.
Stage: early development. Recording, why and undo work today: undo reverts a landed change by its PR, a session's changes or everything since a time, always as a new change. Conary also decides each change's class (which ones need a review round, and which a person) and runs the merge train, which tests ready changes together in one run (a change that needs a person's yes runs alone) and has landed one repository's PRs since 2026-10-30. burrow's steward still asks for the reviews and says when a PR is settled; Conary takes over its jobs one at a time. MIT. See the README and roadmap.
Native game reconstruction · Rust / Godot / Python
A native reimplementation of Phantasy Star IV, built to be easy to mod. Rust reproduces the game rules frame by frame, and Godot handles presentation and input. No emulator runs while you play. Development compares native behavior against the original cartridge.
An automated playthrough now runs from New Game to the ending in 84 chapters, and the native game replays all 84 with every chapter save matching byte for byte. Every player technique and skill, and every enemy ability up to Dark Force 2, is implemented from the cartridge's code. There's a modding guide.
Stage: active development; presentation fidelity (some animations, scene staging, audio timing) is not finished. Linux and Steam Deck today; Windows and macOS are part of 1.0. Requires a user-supplied ROM; no ROM or extracted game assets are distributed. See where it stands.
Online game · Rust
An original game about a family line, a land where death stopped working, and a world that remembers. You play a lineage across lives: the dead cross to the land as it was and keep playing there, and ancestors stay part of the world. Anyone can host their own world.
Stage: building the first playable slice. The rules and the world are tested headless on one small map, a server hosts a world by invite and keeps it through a restart, and a client plays it. Code and original game content are both AGPL-3.0.
I prefer explicit state and typed contracts over hidden assumptions. Recovery, portability, and failure behavior belong in the design from the start. Documentation and reproducible tests should make it possible for someone else to understand the system and verify the difficult parts.
Most of my code is now written by AI agents working under my direction. So most of my engineering goes into what keeps that honest: specs and contracts the agent works against, evidence a change has to produce before it lands (route replays, cartridge comparisons, VM boots), and machines where a mistake is cheap to undo instead of expensive to prevent.
Every pull request in my repositories goes through the same loop. An AI reviewer reads the change, a Claude Code agent fixes or answers each finding and each failed check, and a steward merges only the exact change that was reviewed, once CI has passed on the commit it merges. A change to a one-way path, like secrets or CODEOWNERS, gets judged first, and waits for me only if it can't be undone or the call is mine. Each repository's AGENTS.md says what its reviewers must flag, and one shared set of rules is kept in sync across all of them.
I tune the loop from measurements, not impressions. When reviews were slow, I timed each stage and found most of the wait was a 15-minute poll, so every step now starts from a GitHub event, and reviews arrive about 3 minutes after a push. When I ran two reviewers side by side, I scored their findings and cost and dropped the one that didn't pay for itself. When fixes kept taking extra review rounds, the cause was new findings on code the last fix wrote, so each finding now spells out everything a complete fix has to cover.
The machinery is open source in burrow, and Conary keeps the record of every change it lands.
The repositories distinguish implemented behavior from design targets. Their READMEs and linked status documents are the source of truth as the work evolves.
For systems/backend roles (remote or based in Europe) or collaboration: