docs: ADR for Helm Resource implementation style (#12)

Co-authored-by: tahahawa <tahahawa@gmail.com>
Reviewed-on: https://git.nationtech.io/NationTech/harmony/pulls/12

adr/000-ADR-Template.md

@@ -0,0 +1,33 @@
+# Architecture Decision Record: \<Title\>
+
+Name: \<Name\>
+
+Initial Date: \<Date\>
+
+Last Updated Date: \<Date\>
+
+## Status
+
+Proposed/Pending/Accepted/Implemented
+
+## Context
+
+The problem, background, the "why" behind this decision/discussion
+
+## Decision
+
+Proposed solution to the problem
+
+## Rationale
+
+Reasoning behind the decision
+
+## Consequences
+
+Pros/Cons of chosen solution
+
+## Alternatives considered
+
+Pros/Cons of various proposed solutions considered
+
+## Additional Notes

adr/009-helm-and-kustomize-handling.md

@@ -0,0 +1,61 @@
+# Architecture Decision Record: Helm and Kustomize Handling
+
+Name: Taha Hawa
+
+Initial Date: 2025-04-15
+
+Last Updated Date: 2025-04-15
+
+## Status
+
+Proposed
+
+## Context
+
+We need to find a way to handle Helm charts and deploy them to a Kubernetes cluster. Helm has a lot of extra functionality that we may or may not need. Kustomize handles Helm charts by inflating them and applying them as vanilla Kubernetes yaml. How should Harmony handle it?
+
+## Decision
+
+In order to move quickly and efficiently, Harmony should handle Helm charts similarly to how Kustomize does: invoke Helm to inflate/render the charts with the needed inputs, and deploy the rendered artifacts to Kubernetes as if it were vanilla manifests.
+
+## Rationale
+
+A lot of Helm's features aren't strictly necessary and would add unneeded overhead. This is likely the fastest way to go from zero to deployed. Other tools (e.g. Kustomize) already do this. Kustomize has tooling for patching and modifying k8s manifests before deploying, and Harmony should have that power too, even if it's not what Helm typically intends.
+
+Perhaps in future also have a Kustomize resource in Harmony? Which could handle Helm charts for Harmony as well/instead.
+
+## Consequences
+
+**Pros**:
+
+- Much easier (and faster) than implementing all of Helm's featureset
+- Can potentially re-use code from K8sResource already present in Harmony
+- Harmony retains more control over how the deployment goes after rendering (i.e. can act like Kustomize, or leverage Kustomize itself to modify deployments after rendering/inflation)
+- Reduce (unstable) surface of dealing with Helm binary
+
+**Cons**:
+
+- Lose some Helm functionality
+- Potentially lose some compatibility with Helm
+
+## Alternatives considered
+
+- ### Implement Helm resouce/client fully in Harmony
+  - **Pros**:
+    - Retain full compatibility with Helm as a tool
+    - Retain full functionality of Helm
+  - **Cons**:
+    - Longer dev time
+    - More complex integration
+    - Dealing with larger (unstable) surface of Helm as a binary
+- ### Leverage Kustomize to deal with Helm charts
+  - **Pros**:
+    - Already has a good, minimal inflation solution built
+    - Powerful post-processing/patching
+    - Can integrate with `kubectl`
+  - **Cons**:
+    - Unstable binary tool/surface to deal with
+    - Still requires Helm to be installed as well as Kustomize
+    - Not all Helm features supported
+
+## Additional Notes