Documented ADRs for Atmos

Have a question? Please checkout our [Slack Community](https://slack.cloudposse.com) or visit our [Slack Archive](https://archive.sweetops.com/).

[](https://slack.cloudposse.com)

## Describe the Feature

It would be nice to see ADRs as atmos continues to evolve

These answers we may know but not everyone knows

1. Decide to use ADRs
1. Decide on a new tool for terraform organization
- terragrunt and others do not meet the x, y, z requirements
- why is it called atmos
1. Decide to require null label inputs
1. Decide to use YAML
- why not json/toml/init
- deep merging
1. Decide to support YAML imports for DRYness
1. Decide to use variant
1. Decide to use golang instead of variant
- Why use golang instead of variant/shell scripts
1. Decide to add helmfile support
1. Decide to download external root components
1. Decide to add custom integrations
- atlantis.yaml generation
1. Decide on alien logo
1. Decide on atmos.tools website

Then maybe future ADRs

1. Decide to use library xyz
1. Decide on a plugin architecture
1. TBD

## Expected Behavior

- Architectural design records codified in the repo

## Use Case

Understanding on the status quo

## Describe Ideal Solution

- Create adrs for new design decisions on the atmos.tools website
- If time permits, create adrs retroactively

## Alternatives Considered

N/A

## Additional Context

N/A