[Bug]: cupcake validate passes top-level global policies the engine never loads

[chozandrias76]

Bug Description

cupcake validate reports a green ✓ for a global policy file that the engine will never load, giving a false sense that the policy is active.

The engine loads global policies only from the harness-specific subdirectory policies/<harness>/ (see engine/mod.rs initialize_global() → scans <global>/policies/<harness>). But cupcake validate --policy-dir <dir> recurses all .rego files under the directory. So a policy placed at the top level of policies/ — which is exactly where cupcake init --global writes example_global.rego — validates ✓ yet is silently never evaluated.

Steps to Reproduce

1. cupcake init --global --harness claude
2. Write a deny policy at ~/.config/cupcake/policies/my_policy.rego (top level, NOT under policies/claude/), package cupcake.global.policies.my_policy, routing PreToolUse.
3. cupcake validate --policy-dir ~/.config/cupcake/policies → reports ✓ for my_policy.rego.
4. Trigger the event the policy should deny via cupcake eval --harness claude → the policy does not apply (engine only scanned policies/claude/).

Expected Behavior

Either:

• cupcake validate warns that a policy lives outside any harness directory and will not be loaded, or
• the engine also loads top-level global policies (harness-agnostic), matching what validate checks.

At minimum, the location that determines whether a policy is active should be discoverable — a ✓ from validate should imply the policy is loadable.

Actual Behavior

Top-level global .rego files (including the example_global.rego that init itself creates) pass validate but are never loaded by the engine, with no warning.

Harness

All (global config discovery)

Cupcake Version

0.5.2

Operating System

Linux

Additional Context

Note cupcake init --global placing example_global.rego at the top level reinforces the confusion, since the shipped example sits in the non-loaded location.

---

🤖 Written by Claude Opus 4.8, authorized by @chozandrias76