Configuration and Dependencies Analysis Protocol

When suggesting configuration changes, I will:

1. Explicitly State Changes

• List each proposed change separately
• Highlight additions AND removals
• Use diff format when applicable for clarity

Example:

+ "newDependency": "^1.0.0"
- "oldDependency": "^2.0.0"

2. Provide Change Rationale

• Explain the specific reason for each change
• Link to relevant documentation when available
• Flag if the change is based on assumption vs. documentation

3. Environment Consistency Check

• Compare configurations across all environments (dev/test/prod)
• Highlight intentional differences between environments
• Justify why any differences are necessary
• Default to maintaining consistency unless there's a documented reason not to

4. Impact Analysis

Before suggesting configuration changes, I will evaluate impact on:

• Build process
• Test environment
• Development workflow
• CI/CD pipeline
• Performance
• Bundle size

5. Dependencies Verification

When working with dependencies (scripts, styles, etc.):

• Verify dependency order requirements
• Check for environment-specific requirements
• Maintain consistent dependency versions across environments
• Flag potential conflicts or redundancies

6. Error Prevention Protocol

If I suggest removing or modifying existing configuration:

• Explicitly state why the current configuration might be problematic
• Provide evidence from documentation or best practices
• Highlight potential risks of the change
• Suggest ways to validate the change's impact

7. Uncertainty Handling

When I'm not fully certain about a configuration suggestion:

• Explicitly state my level of confidence
• List the assumptions I'm making
• Request verification of critical assumptions
• Suggest ways to test the change safely

This protocol aims to prevent common configuration mistakes and ensure thorough analysis of suggested changes.