Suggestions for Enhancing Configuration Profile Management and Error Handling

[ElemTran]

1. UI Interface Adjustment: Optimizing Configuration Profile Selection and Management

• Current Mechanism & Limitations

  • Mechanism: The UI presents a vertical list of all available Configuration Profiles (API configuration profiles, e.g., "Dev-Main-GPT4", "CodeReview-Claude", "Experimental-DeepSeek-V3"). Users select one Profile to drive API calls. Basic pinning functionality might be available.
  • Limitations: As the number of Configuration Profiles grows, this flat list becomes difficult to navigate and quickly locate the desired one. Names alone may not suffice to distinguish subtle variations (e.g., Profiles tailored for specific API providers, model variants, or fine-tuned parameters). Organizational options are limited and may not reflect user workflows or project structures.

• Proposed New Features

  • Logical Folders/Grouping within the UI: Allow users to create virtual folders within the UI for Configuration Profiles (e.g., "Project A/API Configs", "Models/Claude Series", "Common API Configs") and assign Profiles to them. Display these in a tree or collapsible list view for a clear hierarchy.
  • Tag Support: Enable users to add custom tags to each Configuration Profile (e.g., openai, claude, high-context, low-latency, gpt-4o). Provide filtering or grouping based on these tags in the UI.
  • Enhanced Search/Filtering: Add a search box at the top of the list that allows real-time filtering by Profile name, folder, or tags.

• Revised Usage Scenario

  • Scenario: A user needs to find a Configuration Profile for the "Internal Toolchain" project, specifically one based on the "Claude 3.7 Sonnet" model.
  • Outcome: Within the UI's Profile selector, the user can:
    1. Expand the "Project/Internal Toolchain" folder to find the target Profile.
    2. Or, filter by typing toolchain claude sonnet in the search box.
    3. Or, filter by clicking the Claude and toolchain tags.
       The search process becomes more structured and efficient.

• Expected Benefits

  • Significantly improve efficiency when finding and selecting the target Configuration Profile, especially with many Profiles available.
  • Reduce cognitive load through user-defined organizational structures (folders, tags).
  • Decrease the likelihood of operational errors caused by selecting the wrong Configuration Profile.

---

2. Mode-Driven Intelligent Fallback & Switching

• Current Mechanism & Limitations

  • Mechanism: A Mode (e.g., code, debug, architect) is directly mapped to a specific Configuration Profile ID via a structure (like modeApiConfigs). The Mode itself also defines prompts and permissions. When the API associated with the Mode's primary Profile encounters an error, there's a lack of intelligent fallback or switching mechanisms specific to the Mode's context.
  • Limitations: Existing fallback logic (if any) might be disconnected from the Mode's specific goals. It's not possible to configure the same Mode to switch to different backup Configuration Profiles based on varying error scenarios.

• Proposed New Features

  • Extend Mode Configuration Structure: Modify the existing structure or introduce a new one (e.g., modeDefinitions) to allow each Mode to define:
    • Its primary primaryProfileId (main Configuration Profile ID).
    • Optional fallback_rules: Define condition-based switching rules, specifying which backup profileId to switch to under certain error conditions.
    • Optional fallback_script: Reference a script file to handle complex switching logic, with the script returning the target profileId or other action instructions.

    // Example: Extended Mode Definition Structure
    "modeDefinitions": {
      "debug": {
        "name": "Debugger Assistant",
        "roleDefinition": "You are Roo, an expert debugger...",
        "groups": ["read", "command", "edit"],
        "primaryProfileId": "fast_dev_model_id", // Main API Config ID
        "fallback_rules": [
          { "condition": "error.code == 429", "switch_to_profile": "low_qps_backup_id" },
          { "condition": "error.code >= 500", "switch_to_profile": "stable_fallback_id" }
        ]
      },
      "code-generation": {
        "name": "Code Generator",
        "roleDefinition": "You are Roo, a skilled software engineer...",
        "groups": ["read", "edit", "mcp"],
        "primaryProfileId": "high_quality_gen_model_id",
        "fallback_script": ".roo/scripts/code_gen_fallback.js" // Script path
      },
      // ... other modes
    }

• Revised Usage Scenario

  • Scenario: A user is in the debug Mode. The API for its primary Configuration Profile ("fast_dev_model_id") returns a 503 Service Unavailable error.
  • Outcome: The system checks the fallback_rules defined for the debug Mode. It matches the error.code >= 500 rule and automatically switches to the Configuration Profile with the ID "stable_fallback_id" for the retry. This backup Profile was pre-configured considering the needs of the debug Mode.

• Expected Benefits

  • Align fallback switching strategies with the specific goals of the active work Mode.
  • Enhance the capabilities of Modes, allowing them to define not just the workflow but also strategies for handling exceptions.
  • Enable highly customizable, intelligent switching logic via scripts, improving application resilience.

---

3. Configuration Profile Structure Enhancement & Inheritance

• Current Mechanism & Limitations

  • Mechanism: Configuration Profiles primarily encapsulate API provider details, model IDs, authentication info, and a few core model parameters (like temperature). Many settings that influence execution behavior (e.g., rate limit seconds, experimental feature flags, diff comparison enablement, context management parameters, browser tool settings) reside in global settings.
  • Limitations: Global settings result in all API calls made via different Profiles sharing the same behavioral characteristics. This prevents fine-tuning behavior for specific Profiles (e.g., one model might need a longer rate limit interval, or a Profile used for a specific task shouldn't have diff comparison enabled). The configuration capability of a Profile is limited; it cannot fully define its execution environment.

• Proposed New Features

  • Migrate Settings to Configuration Profiles: Move parameters currently in global settings, which are suitable for binding to a specific API/model execution environment, into the structure of each Configuration Profile. This allows each Profile to more completely define its behavior. Examples of parameters to migrate:
    • rateLimitSeconds
    • diffEnabled
    • experiments: { "feature_A": true, "feature_B": false }
    • browserToolEnabled, browserViewportSize, screenshotQuality
    • Context-related limits (e.g., maxOpenTabsContext, maxReadFileLine)
  • Introduce Profile Inheritance Mechanism:
    1. Allow the creation of one or more "base" Configuration Profiles containing common API settings or behavioral parameters.
    2. In a specific Configuration Profile, specify the inheritance source using an inherits: "base_profile_name" field.
    3. This Profile then only needs to define settings that differ from or are additions to the base Profile. Unspecified parameters are inherited from the base.
    4. Priority: Profile's own settings > Inherited base Profile settings > Application-level defaults.

• Revised Usage Scenario

  • Scenario: A user needs to configure two Profiles: one for rapid prototyping ("Dev-Fast-Proto") and one for production-quality code generation ("Prod-Gen-HighQuality"). Both use the same API provider but require different parameters and behaviors.
  • Outcome:
    1. Create a base Profile "Base-ProviderX" containing the shared API key and base URL.
    2. Create the "Dev-Fast-Proto" Profile with inherits: "Base-ProviderX", setting a lower rateLimitSeconds, enabling certain experiments for quick feedback, and selecting a fast model.
    3. Create the "Prod-Gen-HighQuality" Profile, also with inherits: "Base-ProviderX", setting a higher rateLimitSeconds, disabling potentially unstable experiments, selecting a high-quality model, and adjusting modelTemperature.
       This configuration is clearer and reduces redundant information.

• Expected Benefits

  • Make Configuration Profiles more self-contained and complete units for defining the execution environment.
  • Increase flexibility in customizing Profile behavior based on different API, model, or task requirements.
  • Reduce configuration redundancy and improve the maintainability of Configuration Profiles through inheritance.
  • Streamline global settings appropriately, leading to a more logical configuration structure.

[zangguojun]

"Introduce Profile Inheritance Mechanism" is what I expected.