Re-organise ADRs and add dito react adr

doc/adr/0001-record-architecture-decisions.md

@@ -0,0 +1,25 @@
+# 1. Record architecture decisions
+
+Date: 2024-05-16
+
+## Status
+
+Accepted
+
+## Context
+
+We need to record the architectural decisions made on this project.
+
+## Decision
+
+We will use Architecture Decision Records, as [described by Michael Nygard](http://thinkrelevance.com/blog/2011/11/15/documenting-architecture-decisions).
+
+## Consequences
+
+See Michael Nygard's article, linked above. For a lightweight ADR toolset, see Nat Pryce's [adr-tools](https://github.com/npryce/adr-tools).
+
+Furthermore, some additional clarification on how we use the sections of an ADR:
+
+- The `Context` provides information about the requirements of the decision topic and describes the considerations made, like pros and cons of different competing options.
+- The `Decision` clearly states what we will do and can contain a short reasoning that lead to the decision.
+- The `Consequences` lay out the resulting context; mentioning specific benefits, drawbacks and derived actions/mitigations.

packages/tool-finder/doc/adr/0002-host-on-OTC.md → doc/adr/0002-host-on-OTC.md

@@ -8,7 +8,7 @@ Accepted
 
 ## Context
 
-The website needs to be hosted somewhere for public access.
+The websites needs to be hosted somewhere for public access.
 This hosting has to generally conform with the demands of GDPR and specifically with the needs of the BMI, which is the patron of the project.
 We identified two possible hosting options with their respective pros and cons:
 
@@ -29,7 +29,7 @@ We will host the application on **Open Telekom Cloud**, using the existing templ
 ## Consequences
 
 We setup nginx as a server for our application and use docker for building a shippable image.
-We create an additional infrastrucure repository and follow the platform docs to deploy our application on the DigitalService kubernetes cluster.
+We create an additional infrastructure repository and follow the platform docs to deploy our application on the DigitalService kubernetes cluster.
 
 There is a higher risk of the application breaking down. We either need to make sure to always have an engineer not on vacation or live with that risk (someone from plattform could probably also mitigate the issue). This is especially relevant from 2025 on, as we might not work on the project anymore.
 

packages/dito/doc/adr/0002-use-react.md

@@ -0,0 +1,20 @@
+# 2. Use React as the frontend framework
+
+Date: 2024-05-16
+
+## Status
+
+Accepted
+
+## Context
+
+The context is similar to the one described for the [tool-finder here](../../../tool-finder/doc/adr/0002-use-react.md).
+Additionally, the components already developed for the tool-finder should be re-used.
+
+## Decision
+
+We will use React as the frontend framework since it aligns well with the outlined requirements and considerations.
+
+## Consequences
+
+The consequences are similar to the ones described for the [tool-finder here](../../../tool-finder/doc/adr/0002-use-react.md).

packages/tool-finder/doc/adr/0003-use-react.md → packages/tool-finder/doc/adr/0002-use-react.md

@@ -1,4 +1,4 @@
-# 3. Use React as the frontend framework
+# 2. Use React as the frontend framework
 
 Date: 2024-04-11