Add a Setting to Enable All Experimental Features

[jerop]

Problem

Currently, enabling experimental features in the Gemini CLI requires editing the settings file and toggling each feature individually. This can be tedious for developers and dogfooders who wish to try out all the latest features and provide feedback.

Furthermore, there is no consistent way to mark a feature as "experimental" while keeping it in its logical category (e.g., "tools"). This makes discovery and management of experimental features more challenging.

Proposed Solution

1. Introduce an isExperimental flag: Add a new boolean property, isExperimental, to the SettingDefinition interface. This will allow features to be marked as experimental while remaining in their logical category.

2. Audit and standardize experimental flags: All settings for experimental features should be reviewed and updated to include isExperimental: true.

3. Implement a master experimentMode switch: A new top-level setting, experimentMode, should be added. This will be an enum with the following values:

   • 'none' (Default): Each experimental feature is controlled by its individual setting.
   • 'all': All features marked with isExperimental: true are enabled.

Benefits

• Improved Developer Experience: Provides a convenient, single-point configuration to opt-in to all experimental features.
• Streamlined Testing: Makes it significantly easier for testers and early adopters to evaluate new features without manual configuration overhead.
• Enhanced Feedback Loop: Encourages broader adoption and testing of experimental features, leading to more robust feedback and faster iteration.
• Improved Code Maintainability: Creates a scalable and maintainable system for managing experimental features.
• Better UI Organization: Allows experimental features to be displayed in their relevant categories in the settings UI, with a clear indication that they are experimental.

Considerations

1. Schema:
   • Add isExperimental?: boolean; to the SettingDefinition interface.
   • Add the experimentMode setting to the schema as an enum with values 'none' and 'all'.
2. Audit: Review all settings in packages/cli/src/config/settingsSchema.ts and apply isExperimental: true to all experimental features.
3. Configuration: Modify the configuration loading logic in packages/core/src/config/config.ts to check if settings.experimentMode === 'all'. If it is, the logic should iterate through the settings schema and override the value of any setting where isExperimental === true to true.
4. UI: The settings UI could be updated to visually indicate when a feature is experimental, for example, by checking the isExperimental flag and appending "[Experimental]" to the setting's label.
5. Precedence: The experimentMode: 'all' setting should take precedence over individual experimental feature settings. If experimentMode is 'all', individual false settings for experimental features should be ignored. If experimentMode is 'none' or not set, individual settings should be respected.

---

Future Work: Granular Stability Levels

Once the initial system is in place, it could be extended to provide even more granular control over feature stability. This would involve:

1. Introducing experimentalMaturity: A new property, experimentalMaturity, could be added to experimental features, with values like:

   • 'bleeding-edge': For highly experimental features.
   • 'stable': For features that are considered stable previews.

2. Expanding experimentMode: The experimentMode setting could be expanded with a 'stable' option, which would only enable features marked with experimentalMaturity: 'stable'.

This would create a clear path for features to graduate from "bleeding-edge" to "stable" and eventually to being on by default, allowing users to choose their desired level of exposure to new functionality.

[jerop]

Another alternative discussed with @allenhutchison is to package the master switch as a policy - https://github.com/google-gemini/gemini-cli/tree/main/packages/cli/src/config/policies