{% endfor %}

# To simplify the automations section, some calculations are placed under unique YAML keys defined here.
# Read the "|" not as "or", but as a "pipe", taking the output of the previous command and passing it to the next command.

# TODO: It would be very nice to avoid having this list somehow, but it needs to be defined in YAML and not in JS for the looping template to work

    "name": "functional",
    "path": "platforms/core-runtime/functional",
    "unitTests": true,
    "functionalTests": false,
    "crossVersionTests": false
  },
  {
    "name": "hashing",
    "path": "platforms/core-execution/hashing",
    "unitTests": true,
    "functionalTests": false,
    "crossVersionTests": false
  },
  {
    "name": "ide",
    "path": "platforms/ide/ide",
    "unitTests": true,

## Making your change

### Code change guidelines

All code contributions should contain the following:

* Create unit tests using [Spock](https://spockframework.org/spock/docs/2.0/index.html) for new classes or methods that you introduce.

The main logic with ADRs is to describe (architectural) decisions made:

* To provide best practices and solutions we (as the *build tool* team) want to promote.
* To avoid asking the same thing multiple times during code review.
* To explain *rejected solutions*, for now, and future development, in case they are proposed again.

ADRs can be written by any team.

- **Flexibility and Control:**
Java serialization offers limited control over the serialization process, such as excluding certain fields, customizing naming conventions, and handling complex data structures more gracefully.

- **Security:**
Java serialization poses security risks, especially related to deserialization vulnerabilities.

- **Version Compatibility:**