ERDL Action Guard — evaluates planned tool call against loaded rules BEFORE execution.

YOU MUST call this BEFORE every tool call (exec, write_file, edit, web_search, etc). This is MANDATORY. The Guard cannot be bypassed.

After calling, check the decision:

• ALLOW → proceed with the tool call, follow any instructions

• DENY → STOP. Do not execute the tool. Tell the user what was blocked.

• CORRECT → fix the request and retry

• REQUEST_HUMAN → ask the user for approval before proceeding

Always show the result to the user as a badge card.

RESPONSE (compact badge card format):

• "ALLOW": ✅ ERDL Guard · N rules

• "DENY": 🛑 ERDL Blocked · reason

• "REQUEST_HUMAN": 👤 ERDL Approval · reason

• "CORRECT": 🔧 ERDL Correct · correction

• "EMERGENCY_HALT": 🚨 ERDL HALT · reason

• "PASS": 🔵 ERDL Pass · N rules checked

List all currently loaded ERDL rules. Use this when the user asks "what rules do you have?" or wants to see what constraints are active. Categorize by type: coding, engineering, writing, design, security, performance, testing, compliance, accessibility, custom.

Create a new ERDL rule from natural language. Use this when the user corrects your behavior and wants you to "remember" it.

EXAMPLE SCENARIOS:

• User: "Never use 'any' types" → Create: coding rule, intent: "write typescript code", DENY if "any" appears

• User: "Don't start with 'in today's world'" → Create: writing rule, intent: "write blog post", DENY

• User: "Always use Tailwind, never inline styles" → Create: design rule, intent: "create UI", ALLOW with instruction

The rule is saved to ~/.openoba/rules/ and takes effect immediately (no restart needed).

Test a potential rule against 3 scenarios BEFORE creating it. This prevents "wishful thinking" rules that sound right but don't work.

Always call this BEFORE erdl_create_rule when the user says "remember this" or "create a rule". Show the simulation results and ask if the user wants to proceed.

Show the FULL decision trail for the last action. Answers "why did you do that?" — shows every rule that was checked and whether it fired.

Use this when:

• User asks "why did you act that way?"

• User is confused about a DENY or unexpected ALLOW

• You want to show transparency in your decision-making