Experimental features

Some mdm features ship behind an experimental gate while the standards or conventions they build on are still settling. Experimental features:

• may change or be removed in any release - they are exempt from semantic versioning until they graduate
• are hidden from --help and shell completion until enabled
• print a warning banner on every invocation while enabled
• never destroy state used by stable features - mdm's lock and state files preserve keys they don't recognize, so an experimental section cannot be dropped by a binary that doesn't know it

Enabling a feature

Persistently, per user:

mdm experimental enable <feature>

Or for a single invocation / CI, via the environment (comma-separated feature names, or all):

MDM_EXPERIMENTAL=<feature> mdm <command>

The environment variable always wins: it activates a feature even if it was disabled with mdm experimental disable.

Commands

mdm experimental
├── list                 # show features, status, and spec links
├── enable <feature>     # persist an opt-in (stored in mdm-state.json)
└── disable <feature>    # remove the persisted opt-in

Current experimental features

This release ships none. knowledge and plugins graduated to full support in v2 - the command groups are always visible and need no opt-in. mdm migrate clears any stale persisted opt-ins for them.

Graduated features

Feature	Graduated	Now
knowledge	v2	mdm knowledge - always available, no opt-in
plugins	v2	mdm plugins - always available, no opt-in

A graduated name is no longer a gate. mdm experimental enable knowledge refuses with "knowledge graduated to full support in v2 - it is always on, no opt-in needed" rather than storing anything, and mdm experimental disable knowledge drops a stale opt-in an older release left behind. mdm migrate clears those opt-ins in bulk.