[aksharprabhudesai]

Description

Closes #3334

Passes the validation reference resolver chain into control validation (validateAllControls) so control requirement-url and config-url CURIEs resolve from the local cache, --assets-path, or --calm-hub-url.

Control CURIEs ({domain}:controls:{slug}@{version}) expand to domain-scoped Hub URLs (/calm/domains/{domain}/controls/{slug}/requirement/versions/{version}) via constructControlDocumentId. Plain URLs and #-prefixed JSON pointers continue to resolve through SchemaDirectory and the pattern document as before.

Type of Change

• 🐛 Bug fix (non-breaking change which fixes an issue)
• ✨ New feature (non-breaking change which adds functionality)
• 💥 Breaking change (fix or feature that would cause existing functionality to not work as expected)
• 📚 Documentation update
• 🎨 Code style/formatting changes
• ♻️ Refactoring (no functional changes)
• ⚡ Performance improvements
• ✅ Test additions or updates
• 🔧 Chore (maintenance, dependencies, CI, etc.)

Affected Components

• CLI (cli/)
• Schema (calm/)
• CALM AI (calm-ai/)
• CALM Hub (calm-hub/)
• CALM Hub UI (calm-hub-ui/)
• CALM Lab (calm-lab/)
• CALM Models (calm-models/)
• CALM Server (calm-server/)
• CALM Studio (calm-studio/)
• CALM Widgets (calm-widgets/)
• CALMGuard (calm-guard/)
• Documentation (docs/)
• Shared (shared/)
• VS Code Extension (calm-plugins/vscode/)
• Dependencies
• CI/CD

Commit Message Format ✅

Testing

• I have tested my changes locally
• I have added/updated unit tests
• All existing tests pass

Checklist

• My commits follow the conventional commit format
• I have updated documentation if necessary
• I have added tests for my changes (if applicable)
• My changes follow the project's coding standards

[markscott-ms]

@byrash @rohithashok What must a control requirement CURIE and a control config CURIE look like? Did you already agree on this as part of #3334?

The CURIE form is namespace:type:slug@version. This is sufficient for a requirement (domain, control, version). A Hub configuration also needs a config name (/controls/{control}/configurations/{config}/versions/{v}), and the current form has no place for it. #3334 asks for config-url CURIEs, but it does not say what they look like.

@aksharprabhudesai Review findings related to this:

1. config-url CURIEs resolve to the requirement. expandCurie always uses kind: 'requirement' for controls. For example, security:controls:micro-segmentation-prod@1.0.0 in config-url fetches .../controls/micro-segmentation-prod/requirement/versions/1.0.0. The result is a 404, or the requirement schema is validated as the config. The tests mock the resolver, so they do not show this.
2. Local assets use one path for both kinds. LocalCurieReferenceResolver (and the SHA cache) map requirement and config CURIEs to the same {ns}/controls/{slug}/{version}.json file. With --assets-path, a config CURIE reads the requirement file.
3. Non-CURIE ids now go to the Hub resolver. isCurie('urn:acme:pci') is true. With --calm-hub-url set, a requirement-url such as this now fails with "requires a version". Before this PR, it resolved through SchemaDirectory and the URL mapping.

Please wait for the CURIE form to be clarified before you make more changes. Many CALM maintainers are at OSFF New York this week, so a reply can take a few days.

[aksharprabhudesai]

Confirmed. I will hold further changes until the control configuration CURIE format is clarified.