Fieldmouse Works

Website · Projects · Principles · Get involved

Fieldmouse Works builds open-source software for ecosystems that are expensive, restrictive, or difficult to leave. You should be able to run the software, understand how it behaves, move your data, and keep operating on your own terms.

Built and maintained by Peter Permenter. The current focus is upgrade paths for old Linux machines, machines run by AI coding agents, and self-hosted software for emergency communications.

Upgrade a 2007 server to today, one release at a time, along a path someone already proved works.

• A map, not a magic upgrader. Small, reviewed fixes for the places where a plain release upgrade breaks, pinned into release-to-release routes. The machine's own package manager stays in charge.
• Five routes so far: Debian 4.0 etch (2007) to Debian 13, Ubuntu 14.04 to 26.04, and CentOS 5, 7 and 8 to AlmaLinux 10, crossing yum to dnf and the /usr merge.
• Every route carries evidence: replays from scratch on test machines, with every health check green. Kernels, bootloaders and real reboots are tested separately in VMs.
• No model at upgrade time. A static Rust client (in progress) will snapshot before each hop and roll back if a check fails. When a hop breaks, a scrubbed gap report the user reviews feeds the next fix.

Status: early; the fix format may still change. MIT OR Apache-2.0.
Repository · Spec · Contributing

Give a coding agent the whole machine, and make nearly everything it does undoable instead of asking permission for it.

• Undo instead of prompts. Claude Code runs with permissions bypassed system-wide. A guard takes a ZFS snapshot before anything deletes files. The few one-way doors (wiping disks, flashing firmware, deleting remote data, force-pushing main) still ask.
• System changes that revert themselves. A new NixOS generation goes live but isn't the boot default; unless it's confirmed within 10 minutes, the old one comes back. A new kernel gets one trial boot and is dropped if it hangs.
• Everything current, unattended. Flake inputs and Claude Code are bumped, built, VM-tested and health-checked before and after; anything that breaks reverts and becomes an agent job. Renovate covers every repository, and new CVEs from CISA KEV, vulnix and osv-scanner become agent jobs the same hour.
• One front door. An always-on operator session you talk to from your phone changes the machine itself and hands project work to per-project sessions, or to a microVM per task with allowlisted egress and no GitHub token.

Status: in daily use on one machine; options may still move. MIT.
Repository · Example machine

Self-hosted training records for emergency communications centers, with agency-owned data.

• The training record, end to end. Versioned programs, Daily Observation Reports, weekly summaries, task signoffs, and trainee histories, with assignment-scoped access.
• Records you can defend. Finalized records are immutable; corrections create amendments or successor versions. Acknowledgments, retention policies, and holds are built in.
• Data you can take with you. Verifiable record exports, trainee packets, and a complete installation export that carries everything except credentials.
• Small enough to run yourself. One executable and one data directory, installed with one command. Upgrades take a validated backup before any database migration.

Status: pre-alpha, v0.3.0, for development and evaluation only; never use real personnel data. AGPL-3.0-only.
Repository · Install guide · Roadmap · Contributing

• Operate on your own terms. Self-hosting, understandable deployments, and freedom from permanent vendor dependence are design priorities.
• Make state and recovery explicit. Inspectable behavior, durable records, useful exports, and reproducible recovery matter as much as the happy path.
• Keep the claims honest. Implemented features, experiments, and future plans stay clearly separated. Each project's README and status documents describe its actual readiness.

Start with the README and contribution guide of the project that interests you. Reproducible bug reports, documentation corrections, and feedback grounded in real workflows are welcome.

• wend: a gap report from a real upgrade that broke is the most useful contribution. Fixes come in as pull requests that CI replays.
• burrow: a report from running it on a machine other than the one it was built on is the most useful thing right now.
• Consolebook: use invented examples. Never submit real personnel records or operational data.

A small creature willing to take on something much larger than itself. That is a useful model for the work here: understand the closed system, then build the open door.

_{fieldmouseworks.com (source) · peter@fieldmouseworks.com · Peter's games and runtime research live on his personal profile.}