Merge pull request #290 from mxenabled/wes/baseADR

docs: added a base Architecture Decision Record

Author: wesrisenmay-mx

architectureDecisionRecords/0000Example.md

@@ -2,6 +2,10 @@
 
 Title of the ADR
 
+## Date proposed
+
+01-01-0001
+
 ## Context
 
 What is the issue that we're seeing that is motivating this decision or change?

architectureDecisionRecords/0001Styling.md

@@ -2,6 +2,10 @@
 
 Styling our html
 
+## Date proposed
+
+08-19-2025
+
 ## Context
 
 According to the [state of css 2025](https://2025.stateofcss.com/en-US) the tools that people are the most happy with in 2025 are [css modules](https://github.com/css-modules/css-modules) and [tailwindcss](https://tailwindcss.com/).

architectureDecisionRecords/0002DocumentArchitectureDecisions.md

@@ -0,0 +1,37 @@
+# Title
+
+Document architecture decisions
+
+## Date proposed
+
+02-12-2026
+
+## Context
+
+It is unclear to engineers what the expectations are for contributing to this repository. We need a system for making, documenting, and enforcing architecture decisions.
+
+## Decision
+
+We will document our decisions in our repositories as architecture decision records.
+
+We will follow the template provided in 0000Example.md.
+
+Decisions will be made by consensus. If an ADR is agreed upon by at least 2/3 of the engineers on the team, then it can be added to the repository.
+
+Pull Requests with new code that doesn't adhere to the ADRs will not be approved. High-priority urgent production bugs are an exception to this rule. This exception should be immediately followed up with a PR to fix the code, so that it conforms with the ADRs.
+
+When making changes to code that doesn't conform to the ADRs the following steps should be taken:
+
+1. If feasible update the code to conform to the ADRs
+1. If updating the code to conform to the ADRs is too large of a scope, then at minimum create a ticket to fix the issue later, and write tests the cover the new code
+
+## Consequences
+
+Engineers will be able to go to a single place to learn the following
+
+1. What architecture decisions were made and why
+1. What libraries should be used
+1. What coding patterns and style should be used
+1. What expectations will need to be met before a PR can be merged
+
+Pull requests will need conform to the ADRs to be approved.