blocked-formlisted

# A Blocked Command Form Is Not a Blocked Action ## Problem A safety guard refuses a command. The refusal is correct: the form really is dangerous. The refusal text also names the safe form. What gets written down is *"the safety net blocks this — it needs the operator."* The item moves onto a human's list, and it stays there, because nobody re-reads a refusal they have already read once. The generalisation is the defect. **A guard scopes to a command form. The note scoped it to an action.** Those differ whenever a second spelling exists, and for destructive git operations a second spelling almost always exists. ## Context / Trigger Conditions - A guard, PreToolUse hook, permission prompt or sandbox refuses a command, and the next thing you write is that the task cannot be done. - A handoff or checkpoint carries an item whose entire justification is a tool refusal. - An item has waited on a human across more than one session with no new evidence. - The refused command is a destructive git form: `branch -D`, `reset --hard`, `checkout -- <path>`, `stash drop`, `push --force`, `clean -fdx`. - A refusal message contains the words *use*, *try*, *instead*, *consider*, *prefer*, or *alternative*. ## Solution 1. **Read the refusal text to the end.** Guards written to teach rather than merely block name the safe route in the same message. That sentence is the answer. 2. **Run the named alternative.** It is one call. A guard that suggests a form has already decided