CircleCI 2.1: Should YAML Linting Be Looser for Dynamic Configuration?

When migrating to CircleCI 2.1, teams often employ dynamic configuration to generate parts of the pipeline at runtime. The validator, however, treats the entire .circleci/config.yml as static, flagging errors that only surface after the dynamic block is rendered.

The core goal is to determine whether the linting process should differentiate between static and dynamic sections, allowing the latter to bypass certain strict checks until execution time. This would reduce false positives for legitimate dynamic constructs while preserving safety for the static portion.

Key uncertainties include how to identify dynamic blocks in the YAML tree, whether a new lint rule could be scoped to those blocks, and if runtime validation would be sufficient to catch misconfigurations that static linting currently prevents.

1. Should the CircleCI validator defer linting of dynamic blocks until they are rendered at runtime?
2. Is there a mechanism to annotate dynamic sections so that specific lint rules are selectively applied?
3. Could a new lint rule be introduced that flags only static configuration errors, leaving dynamic sections unchecked until execution?