feat(validator): policy engine for extension compliance validation

[mrwogu]

Context

In enterprise environments with multi-layer registry architectures, organizations need to enforce rules about how skills can be composed. For example: "Only Layer 3 can extend Layer 2 skills", "Reference files must come from approved registries", or "Content property cannot be overridden without explicit policy approval". Currently there is no mechanism to express or enforce such rules.

Parent issue: #199 (Phase 3)
Spec: docs/superpowers/specs/2026-03-30-skill-overlay-extends-design.md §13
Review: docs/superpowers/specs/2026-03-30-skill-overlay-extends-review.md §10

Proposal

Add a policy engine that validates skill extensions against declarative organizational rules.

Policy definition (in promptscript.yaml or dedicated policy file)

policies:
  - name: "layer-boundary"
    description: "Only adjacent layers can extend each other"
    rule: |
      extensions where source.layer - target.layer > 1 → deny
    severity: error

  - name: "content-protection"
    description: "Content override requires explicit approval"
    rule: |
      extensions where overrides 'content' and not approved → warn
    severity: warning

  - name: "registry-allowlist"
    description: "References must come from approved registries"
    rule: |
      references where source.registry not in ['@clm5core', '@bu'] → deny
    severity: error

Evaluation

• Policies are evaluated during prs validate (and optionally during prs compile)
• Policy violations produce errors or warnings based on configured severity
• Policies are composable — each registry can define its own policies that apply to downstream consumers

Design considerations

• Rule language: Start with a simple declarative format (not a full expression language) — cover 80% of use cases with simple predicates
• Scope: Policies apply to @extend and @use declarations, not to base skill definitions
• Composability: Registry-level policies propagate to consumers (a base registry can enforce rules on its extenders)
• Escape hatch: --skip-policies flag for development, never for CI
• This is the most complex feature in the Phase 2/3 roadmap — consider a dedicated design spec before implementation

Prior art

• ESLint rule system (declarative rules with configurable severity)
• Open Policy Agent / Rego (policy-as-code for infrastructure)
• npm audit policies (allowlists for known vulnerabilities)

Acceptance criteria

• Declarative policy definition format in YAML
• Policies evaluated during prs validate
• Support for deny (error) and warn (warning) severities
• Layer-boundary enforcement (adjacent layers only)
• Property-override policies (protect specific properties)
• Registry allowlist policies (restrict reference sources)
• Registry-level policy propagation to consumers
• --skip-policies flag for development
• Clear violation messages with policy name and remediation
• Design specification before implementation (complex feature)
• Comprehensive test suite
• Documentation with enterprise governance examples