docs: Introduce project delivery automation ADR. This is still WIP

adr/012-project-delivery-automation.md

@@ -0,0 +1,63 @@
+# Architecture Decision Record: \<Title\>
+
+Initial Author: Jean-Gabriel Gill-Couture
+
+Initial Date: 2025-06-04
+
+Last Updated Date: 2025-06-04
+
+## Status
+
+Proposed
+
+## Context
+
+As Harmony's goal is to make software delivery easier, we must provide an easy way for developers to express their app's semantics and dependencies with great abstractions, in a similar fashion to what the score.dev project is doing.
+
+Thus, we started working on ways to package common types of applications such as LAMP, which we started working on with `LAMPScore`.
+
+Now is time for the next step : we want to pave the way towards complete lifecycle automation. To do this, we will start with a way to execute Harmony's modules easily from anywhere, starting with locally and in CI environments.
+
+## Decision
+
+To achieve easy, portable execution of Harmony, we will follow this architecture :
+
+- Host a basic harmony release that is compiled with the CLI by our gitea/github server
+    - This binary will do the following : check if there is a `harmony` folder in the current path
+    - If yes
+        - Check if cargo is available locally and compile the harmony binary, or compile the harmony binary using a rust docker container, if neither cargo or a container runtime is available, output a message explaining the situation
+        - Run the newly compiled binary. (Ideally using pid handoff like exec does but some research around this should be done. I think handing off the process is to help with OS interaction such as terminal apps, signals, exit codes, process handling, etc but there might be some side effects)
+    - If not
+        - Suggest initializing a project by auto detecting what the project looks like
+        - When the project type cannot be auto detected, provide links to Harmony's documentation on how to set up a project, a link to the examples folder, and a ask the user if he wants to initialize an empty Harmony project in the current folder
+            - harmony/Cargo.toml with dependencies set
+            - harmony/src/main.rs with an example LAMPScore setup and ready to run
+- This same binary can be used in a CI environment to run the target project's Harmony module. By default, we provide these opinionated steps :
+    1. **An empty check step.** The purpose of this step is to run all tests and checks against the codebase. For complex projects this could involve a very complex pipeline of test environments setup and execution but this is out of scope for now. This is not handled by harmony. For projects with automatic setup, we can fill this step with something like `cargo fmt --check; cargo test; cargo build` but Harmony is not directly involved in the execution of this step.
+    2. **Package and publish.** Once all checks have passed, the production ready container is built and pushed to a registry. This is done by Harmony.
+    3. **Deploy to staging automatically.** 
+    4. **Run a sanity check on staging.** As Harmony is responsible for deploying, Harmony should have all the knowledge of how to perform a sanity check on the staging environment. This will, most of the time, be a simple verification of the kubernetes health of all deployed components, and a poke on the public endpoint when there is one.
+    5. **Deploy to production automatically.** Many projects will require manual approval here, this can be easily set up in the CI afterwards, but our opinion is that 
+    6. **Run a sanity check on production.** Same check as staging, but on production.
+
+*Note on providing a base pipeline :* Having a complete pipeline set up automatically will encourage development teams to build upon these by adding tests where they belong. The goal here is to provide an opiniated solution that works for most small and large projects. Of course, many orgnizations will need to add steps such as deploying to sandbox environments, requiring more advanced approvals, more complex publication and coordination with other projects. But this here encompasses the basics required to build and deploy software reliably at any scale.
+
+### Environment setup
+
+TBD : For now, environments (tenants) will be set up and configured manually. Harmony will rely on the kubeconfig provided in the environment where it is running to deploy in the namespace.
+
+For the CD tool such as Argo or Flux they will be activated by default by Harmony when using application level Scores such as LAMPScore in a similar way that the container is automatically built. Then, CI deployment steps will be notifying the CD tool using its API of the new release to deploy.
+
+## Rationale
+
+Reasoning behind the decision
+
+## Consequences
+
+Pros/Cons of chosen solution
+
+## Alternatives considered
+
+Pros/Cons of various proposed solutions considered
+
+## Additional Notes