tv-lock

What problem does it solve? A single dev television has no OS-level mutex, so two jobs driving it at once — a test run plus a deploy, or a capture plus a test suite — kill each other's app and produce plausible-looking wrong data that reads exactly like a real regression. This Skill enforces exclusive, lease-based access so only one lane drives the set at a time. ## Core Features & Use Cases - Lease lifecycle management: acquire, renew, release, queue with --wait, and run one-shot jobs via with that release even on Ctrl-C or a crash, with a 45-minute default lease auto-renewed on tool use. - Four-layer enforcement: the session tool, Makefile prerequisites, the test runner, and a PreToolUse hook all refuse device-driving commands that lack a lease, so there is no forgotten-lock path. - Multi-agent fleet coordination: lanes are per-checkout leases, subagents take their own lane via a per-command PLX_TV_LOCK_LANE prefix, and status pre-flights for humans or ssh sessions already on the set. - Use Case: Before running ./tests/run.py --fps on the TV, acquire the lock with a reason, do the device work, then release — or wrap the whole thing in tools/tv-lock.sh with --why "fps suite" -- ./tests/run.py --fps. ## Quick Start Run tools/tv-lock.sh with --why "my task" before any command that deploys to, tests on, or captures from the dev television, and release it when finished.