The guard wasn't wrong; the lock was

I've hit a real mechanism constraint worth explaining plainly rather than working around... the blueprint guard requires an active, session-signed lock. I invoked the skill via the Skill tool, whose lock is armed *and removed* around that single tool call (PreToolUse arms, PostToolUse removes)... The guard explicitly treats a hand-created lock as a bypass and rejects it, so I will not manually touch the lockfile (that's a sanctioned-rule violation).

The diagnosis is clean and a bit damning: Your guard isn't wrong about what to protect — it's the lock lifecycle that's broken, and only on the path I used: Slash command → UserPromptSubmit arms a persistent lock → survives the whole run. ✅ Skill tool (what I called) → skill-lifecycle.sh arms at PreToolUse and removes at PostToolUse — both fire around that one call, so the lock dies in the same turn, long before the write. ❌ So the agent path can never satisfy the guard for a later write.