add adr001

docs/ADRs/adr001.md

@@ -20,9 +20,9 @@ We're building a sovereign, multi-CSP platform. The control model needs to be si
 
 The split control plane idea comes from [AppCat](https://kb.vshn.ch/app-catalog/control-plane/split-architecture.html).
 
-The control plane needs kubeconfigs to N service clusters. Each service cluster needs a kubeconfig back to the control plane. Due to how [Project Syn](https://syn.tools/) works, we can't create these kubeconfigs during compilation time, they have to be generated manually and put into Vault every time we add a new service cluster.
+The control plane needs kubeconfigs to N service clusters. Each service cluster needs a kubeconfig back to the control plane. Due to how SYN works, we can't create these kubeconfigs during compilation time, they have to be generated manually and put into Vault every time we add a new service cluster.
 
-Managing provider configs for Helm and Kubernetes gets complicated because they need to connect to service clusters from the control cluster. Connection details only exist on the control cluster and don't propagate to service clusters. Instead of writing connection details directly into instance namespaces, we have to wrap them into separate secrets and deploy via Crossplane provider-kubernetes.
+Managing provider configs for Helm and Kubernetes gets complicated because they need to connect to service clusters from the control cluster. Connection details only exist on the control cluster and don't propagate to service clusters. Instead of writing connection details directly into instance namespaces, we have to wrap them into separate secrets and deploy via provider-kubernetes.
 
 The deletion protection webhooks need to check against composites on the control cluster, which means service clusters need reverse connectivity back to the control plane for webhook lookups. And developers have to constantly remember whether they're dealing with Crossplane Managed Resources (control cluster) or plain Kubernetes resources (service cluster). Some objects like `ProviderConfigs` and `Usages` don't implement the `resource.Managed` interface, which makes this even harder.
 
@@ -64,30 +64,17 @@ Cons:
 
 ## Decision
 
-We've decided to move away from the split control plane architecture and instead let the Servala Portal handle orchestration.
+We're abandoning the split control plane architecture in favor of a converged model.
 
-After working with the split model for a while, we've learned that most of its theoretical benefits don't really help us in Servala's real-world use cases. In practice, it made development, testing, and day-to-day operations more complicated than they needed to be.
+The Portal will continue doing what it already does. It decides where to create resources based on CSP selection and environment requirements. What changes is the cluster architecture:
 
-The Portal is already where users express intent and choose CSPs, and it's also the only place with enough context to make good scheduling decisions. So it's a natural fit for orchestration. Workload clusters can stay focused on execution.
+- Each cluster has Crossplane installed and operates as a converged control and execution plane
+- Clusters are self-contained, no split between control and service clusters
+- No bidirectional dependencies between clusters
+- No reverse connectivity needed
 
 ![Control Plane Architecture](images/control-plane-architecture.png)
 
 ### Consequences
 
-#### What We Gain
-
-Architecture gets way simpler. We eliminate an entire class of problems around bidirectional control plane integration.
-
-All clusters behave consistently regardless of CSP.
-
-AppCat doesn't need conditional logic for different control plane models anymore.
-
-Fewer moving parts means less operational overhead and fewer failure points.
-
-Clear mental model: Portal orchestrates, clusters execute.
-
-#### What We're Trading Off
-
-The Portal becomes critical infrastructure for orchestration. If it's down, orchestration stops, though services still continue to be available.
-
-The Portal needs secure access to every workload cluster across all CSPs. We need a connectivity model that's secure, private, and scalable without exposing Kubernetes APIs publicly.
+The architecture gets way simpler. We eliminate an entire class of problems around bidirectional control plane integration. All clusters behave consistently regardless of which CSP they're running on. Onboarding becomes straightforward. AppCat doesn't need conditional logic for different control plane models anymore. Fewer moving parts means less operational overhead and fewer failure points. The mental model becomes clear: Portal orchestrates, clusters execute.