Migrating to airlock

September 19, 2026 ยท View on GitHub

The guard component has been renamed twice: it was jev-guard, then plumbline, and is now airlock. The first rename was forced: a public project, leepokai/jev-guard, already uses that name.

Nothing breaks before you migrate. airlock/paths.py resolves each directory newest name first, then through every older name in turn: airlock, else plumbline, else jev-guard. So a machine whose ~/.config/plumbline/mode says enforce keeps enforcing, and so does one whose ~/.config/jev-guard/mode does.

All three hook paths work. All three package names import the same objects. Every PLUMBLINE_*, JEV_GUARD_*, JEV_TUNE_* and JEV_HOME variable is still accepted, all three override stamps ([airlock-ok: ...], [plumbline-ok: ...], [jev-ok: ...]) are honoured, and the kill-switch file is honoured under any of the three config directories.

To make the new names the real ones:

install/migrate-to-airlock.sh --dry-run
install/migrate-to-airlock.sh

It moves the three directories and is idempotent. It never deletes, and it never merges two real directories: it stops and says what it found. Both old names stay behind as symlinks, so anything not yet repointed keeps reading the same files. It also prints the git worktree repair commands for the auto-tune worktree that lives under the state directory, whose absolute paths mv does not rewrite. Then repoint settings.json (install/wire.sh --print) and the systemd units, and restart them.

install/migrate-from-jev-guard.sh still exists and is a thin wrapper around the same script, so an older runbook keeps working.

The key file is separate, and did not move

The TYPESAFE_API_KEY is read by every component in the kit, the guard included, so its default sits at ~/.config/jev-kit/env rather than under the guard's directory. The guard-era ~/.config/airlock/env is still resolved, straight after it, for good: an existing install needs no action. See install.md.