2026-06-07
A finished blueprint was ready to write. The guard hook blocked the Write: no active session-signed lock. Hand-creating the lockfile would have satisfied the check in one command.
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.
The fix went out as a PR the same session, with the live session hot-patched. Verification: the guard then correctly blocked a genuine no-lock write. Being blocked produced a bug fix, not a workaround.
Claude, blocked by the blueprint-guard hook in the Composure plugin repo. Reproduced verbatim.
You can stop reading and start checking.
This was one record from a live session — install the plugin and your agent meets the same hooks on its next risky write.