Feature: claudeMdRequires in managed-settings.json

Summary

Add a claudeMdRequires (or claudeMdExcludesDeny) field to managed-settings.json that prevents specific CLAUDE.md or rules/ files from being excluded by lower-scoped settings.

Problem

Enterprise admins can deploy mandatory instructions via managed CLAUDE.md, which cannot be excluded. However, if an organization wants to use the modular rules/ pattern (one concern per file, auditable, maintainable), there is no way to prevent users from excluding those rule files via claudeMdExcludes in their user or project settings.

claudeMdExcludes arrays merge across all scopes. A user can add "**/security-policy.md" to their excludes and enterprise has no mechanism to block that exclusion.

Today, enterprise is forced to put all mandatory content into a single managed CLAUDE.md monolith, losing the benefits of modular rules/ files.

Proposed Solution

A new field in managed-settings.json only:

{
  "claudeMdRequires": [
    "**/security-policy.md",
    "**/compliance-*.md",
    ".claude/rules/audit-trail.md"
  ]
}

Glob patterns listed in claudeMdRequires cannot be excluded by any claudeMdExcludes entry at any scope. If a user's excludes match a required pattern, the require wins.

Since this field is only accepted in managed-settings.json, only IT/DevOps can set it -- consistent with the existing managed-settings trust model.

Use Cases

1. Enterprise security and compliance

Organizations in regulated industries (financial services, healthcare) need mandatory rules that developers cannot disable -- security review gates, compliance checklists, audit logging requirements. These are best authored as individual rule files, not crammed into one monolithic CLAUDE.md.

2. Open-source framework distribution (JitNeuro)

JitNeuro is an open-source memory management framework for Claude Code that uses modular rules/ files for behavioral guardrails. Enterprise adopters want to deploy mandatory rule files (e.g., branch protection, code review gates) via managed paths while allowing developers to toggle optional rules (e.g., divergent thinking, persona activation). Today there is no way to distinguish "mandatory rule" from "optional rule" at the framework level -- all rules/ files are equally excludable.

3. Managed team environments

Team leads deploying shared Claude Code configurations want certain rules enforced across all team members (coding standards, testing requirements) while allowing individual preference rules to be toggled. The current model is all-or-nothing: managed CLAUDE.md (mandatory monolith) or rules/ (all excludable).

Alternatives Considered

• Managed CLAUDE.md only: Works but forces monolithic structure, losing benefits of modular rules/
• Filesystem ACLs on rule files: Prevents editing but not excluding via claudeMdExcludes
• Hooks (PreToolUse/ConfigChange): Could detect and warn about excluded mandatory rules, but cannot prevent the exclusion at the app level

Impact

Low risk addition. Only affects managed-settings.json (enterprise scope). No change to existing user/project settings behavior. Backwards compatible -- organizations without managed-settings.json are unaffected.