openmcp-project · GenosseOtt · Mar 9, 2026 · Mar 17, 2026 · Mar 17, 2026 · Mar 17, 2026
diff --git a/.gitignore b/.gitignore
@@ -18,3 +18,4 @@
 npm-debug.log*
 yarn-debug.log*
 yarn-error.log*
+.idea/
diff --git a/BACKLOG.md b/BACKLOG.md
@@ -0,0 +1,51 @@
+# BACKLOG.md - Open Control Plane Documentation Project
+
+## Backlog
+
+
+## Next
+- [x] More engaging ansprache (improve language/tone)
+- [x] Farbverlauf (gradient styling) [ott]
+- [ ] Related? Crossplane usw (add related projects section) [ott]
+- [ ] Are CRD reflected? (stretch goal) [ott]
+- [ ] Teal farbspektrum und content aware coloring [ott]
+- [ ] Maybe in Browser with WASM? (stretch)
+- [x] Contributing: Design decisions (ADRs et al) 
+- [ ] Index: Was möchte ich machen (What do I want to do)
+- [ ] Onboarding API - why/what it helps for
+- [ ] Johannes change icons
+- [ ] End user getting started: MCP Server - max b to publish
+- [ ] End user getting started: Edit docs
+- [ ] Operators: getting started (currently empty)
+- [ ] Operators: Happy Path docs
+- [ ] Contributing: Wie mach ich was (How do I do what) - Extend - Fundamental - How to
+
+## In Progress
+
+## Review
+
+## Done
+
+- [x] Theme-aware section backgrounds (CSS vars instead of hardcoded dark)
+- [x] Navbar scroll transparency effect (transparent at top, solid on scroll)
+- [x] Footer logo sizing (EU + NeoNephos enlarged)
+- [x] Light-mode axolotl drop shadow (0.25 opacity + gradient blob restored)
+- [x] Content max-width alignment (1152px hero/features/footer, 1152px navbar)
+- [x] Swizzled footer — 3-row layout (EU banner, copyright, legal links)
+- [x] NeoNephos SVG logo in footer
+- [x] Feature card mouse-tracking glow effect
+- [x] Axolotl drop shadow (dark mode)
+- [x] Favicon update (axolotl mascot, multi-size .ico)
+- [x] SVG graphics/icons (co_axolotl.svg vector trace, 160KB)
+- [x] Navbar logo — mirrored axolotl facing left + transparent background variant
+- [x] End user getting started: Prerequisites (platform installed)
+- [x] End user getting started: authentication/authorization
+- [x] End user getting started: pictures (hierarchy diagram)
+- [x] Double check no openMCP → OpenControlPlane (cleanup legacy naming)
+- [x] SIGs mit rein (include SIGs)
+- [x] Community seite - how to participate
+- [x] Contributing: Wie kann ich partizipieren (How can I participate) - an der community
+
+---
+
+*This board tracks granular tasks for the Open Control Plane documentation project. For cross-project status, see the main Projects.md overview.*
diff --git a/CLAUDE.md b/CLAUDE.md
@@ -0,0 +1,96 @@
+# CLAUDE.md - OpenControlPlane Documentation
+
+## About
+
+**OpenControlPlane** provides Infrastructure- and Configuration-as-Data capabilities via Kubernetes Resource Model APIs. Part of ApeiroRA (IPCEI-CIS European cloud initiative).
+
+> **Note:** Legacy "openMCP" references should be updated to "OpenControlPlane"
+
+## Tech Stack
+
+- **Docusaurus 3** (React-based docs)
+- **TypeScript** + **MDX** 
+- **Mermaid** diagrams
+- **Node.js 18+**
+
+## Brand Colors
+
+**Teal Spectrum** (primary brand colors):
+- **Teal 2** (lightest): `#C2FCEE` | RGB 194/252/238 | Pantone 317 C
+- **Teal 4** (bright): `#2CE0BF` | RGB 44/224/191 | Pantone 3255 C  
+- **Teal 6** (medium): `#049F9A` | RGB 4/159/154 | Pantone 2233 C
+- **Teal 7** (darker): `#07838F` | RGB 7/131/143 | Pantone 2235 C
+- **Teal 10** (dark): `#02414C` | RGB 2/65/76 | Pantone 2215 C
+- **Teal 11** (darkest): `#012931` | RGB 1/41/49 | Pantone 2189 C
+
+**Usage:**
+- Use lighter teals (2, 4) for backgrounds and highlights
+- Medium teals (6, 7) for primary actions and branding  
+- Darker teals (10, 11) for text and contrast elements
+- Consider gradients between adjacent teal shades
+
+## Structure
+
+```
+docs/
+├── about/          # Project overview, concepts, design
+├── users/          # End-user guides  
+├── operators/      # Platform operator docs
+└── developers/     # Contributor/dev docs
+adrs/               # Architectural Decision Records
+templates/adr.*     # ADR template + script
+```
+
+## Commands
+
+```bash
+npm start           # Dev server (localhost:3000)
+npm run build       # Production build
+npm run new-adr     # Create new ADR
+npm run typecheck   # TypeScript validation
+```
+
+## Core Concepts
+
+- **Control Plane** - Kubernetes API server as a service
+- **Service/Cluster Providers** - Entities offering services/clusters  
+- **Platform Service** - Software/infrastructure via control plane
+- **OCM** - Open Component Model integration
+
+## Workflow
+
+1. **Content** → Add to appropriate `docs/` subfolder
+2. **ADRs** → Use `npm run new-adr`
+3. **Test** → `npm run build` + `npm run typecheck`
+4. **Deploy** → GitHub Pages on `main` branch push
+
+## Writing Style
+
+**Friendly but precise** - Be welcoming to newcomers while technically accurate for experts.
+
+**Concise** - Respect readers' time. Get to the point quickly.
+
+**Structure patterns:**
+- Lead with **what** and **why** before **how**
+- Use bullets and short paragraphs
+- Include examples for every concept
+- Link to related docs liberally
+
+**Voice:**
+- "You can..." not "One might..."  
+- "This feature helps you..." not "This feature provides the capability to..."
+- Active voice: "Install the CLI" not "The CLI should be installed"
+
+**Technical precision:**
+- Exact command syntax with copy-paste examples
+- Specify prerequisites clearly
+- Note version requirements
+- Include common error solutions
+
+## Sidebars
+
+Auto-generated from directory structure. Control order with `sidebar_position` frontmatter.
+
+---
+
+*Update BACKLOG.md when tasks move. Test locally before committing.*
diff --git a/COLOR_SCHEME_REFERENCE.md b/COLOR_SCHEME_REFERENCE.md
@@ -0,0 +1,50 @@
+# Role-Based Color Scheme - COMPLETE IMPLEMENTATION
+
+## CSS Variables (Lines 39-57 in custom.css)
+
+```css
+/* Role-based Teal Spectrum */
+--teal-2: #C2FCEE;
+--teal-4: #2CE0BF;
+--teal-6: #049F9A;
+--teal-7: #07838F;  ← End User Primary
+--teal-10: #02414C; ← Operator Primary
+--teal-11: #012931; ← Contributor Primary
+
+/* Role Colors */
+--role-enduser-primary: var(--teal-7);      #07838F
+--role-enduser-secondary: var(--teal-10);   #02414C
+--role-operator-primary: var(--teal-10);    #02414C
+--role-operator-secondary: var(--teal-11);  #012931
+--role-contributor-primary: transparent;
+--role-contributor-border: var(--teal-11);  #012931
+```
+
+## Where Colors Appear
+
+### 1. Hero Section Buttons (Landing Page)
+- **"Get Started"** → Teal 7 (#07838F), hover: Teal 10
+- **"Run Your Platform"** → Teal 10 (#02414C), hover: Teal 11
+- **"Build Together"** → Transparent, hover: subtle tint
+
+### 2. Navbar Links (Top Navigation)
+- Hover/Active states show role colors
+- Bottom border accent appears on hover
+- Colors: Teal 7 (users), Teal 10 (operators), Teal 11 (developers)
+
+### 3. Sidebar (Documentation Sections)
+- Left border shows section color
+- Active menu items highlighted in role color
+- Hover states use lighter tint of role color
+- Different color per section: userDocs, operatorDocs, developerDocs
+
+## Color Gradient Philosophy
+
+Light → Dark = Beginner → Advanced
+
+- **Teal 7** (lighter) = End users, getting started, welcoming
+- **Teal 10** (medium dark) = Operators, platform management, professional
+- **Teal 11** (darkest) = Contributors, developers, technical depth
+- **Transparent** = Open invitation to contribute
+
+This creates a visual progression through the documentation that mirrors the user journey.
diff --git a/README.md b/README.md
@@ -48,4 +48,4 @@ We as members, contributors, and leaders pledge to make participation in our com
 
 ## Licensing
 
-Copyright 2025 SAP SE or an SAP affiliate company and openMCP contributors. Please see our [LICENSE](LICENSE) for copyright and license information. Detailed information including third-party components and their licensing/copyright information is available [via the REUSE tool](https://api.reuse.software/info/github.com/openmcp-project/docs).
+Copyright 2025 SAP SE or an SAP affiliate company and OpenControlPlane contributors. Please see our [LICENSE](LICENSE) for copyright and license information. Detailed information including third-party components and their licensing/copyright information is available [via the REUSE tool](https://api.reuse.software/info/github.com/openmcp-project/docs).
diff --git a/adrs/2025-07-17-local-dns.md b/adrs/2025-07-17-local-dns.md
@@ -7,7 +7,7 @@ authors:
 
 ## Context and Problem Statement
 
-When creating services on a Kubernetes cluster, they shall be accessible from other clusters within an openMCP landscape. To achieve this a `Gateway` and `HTTPRoute` resource is created. The Gateway controller will assign a routable IP address to the Gateway resource. The HTTPRoute resource will then be used to route traffic to the service.
+When creating services on a Kubernetes cluster, they shall be accessible from other clusters within an OpenControlPlane landscape. To achieve this a `Gateway` and `HTTPRoute` resource is created. The Gateway controller will assign a routable IP address to the Gateway resource. The HTTPRoute resource will then be used to route traffic to the service.
 
 ```yaml
 apiVersion: gateway.networking.k8s.io/v1beta1
@@ -49,18 +49,18 @@ spec:
           port: 80
 ```
 
-The problem is that the service is only reachable via the IP address and not via the hostname. This is because the DNS server in the openMCP landscape does not know about the service and therefore cannot resolve the hostname to the IP address. The Kubernetes dns service only knows how to route to service within the same cluster. On an openMCP landscape however, services must be reachable from other clusters by stable host names.
+The problem is that the service is only reachable via the IP address and not via the hostname. This is because the DNS server in the OpenControlPlane landscape does not know about the service and therefore cannot resolve the hostname to the IP address. The Kubernetes dns service only knows how to route to service within the same cluster. On an OpenControlPlane landscape however, services must be reachable from other clusters by stable host names.
 
-Therefore there is a need for a openMCP DNS solution that makes these host names resolvable on all clusters that ar part of the openMCP landscape.
+Therefore there is a need for an OpenControlPlane DNS solution that makes these host names resolvable on all clusters that are part of the OpenControlPlane landscape.
 
-## openMCP DNS System Service
+## OpenControlPlane DNS System Service
 
-To solve the stated problem, a `openMCP DNS System Service` is needed. This system service will be responsible for the following tasks:
+To solve the stated problem, an `OpenControlPlane DNS System Service` is needed. This system service will be responsible for the following tasks:
 
-* Deploy a central openMCP DNS server in the openMCP landscape. This DNS server will be used to resolve all host names in the openMCP base domain `openmcp.cluster`.
-* For each cluster in the openMCP landscape, the system service will configure the Kubernetes local DNS service to forward DNS queries for the openMCP base domain to the central openMCP DNS server. This will ensure that all clusters can resolve host names in the openMCP base domain.
-* For each Gateway or Ingress resource, the system service will create a DNS entry in the central openMCP DNS server. The DNS entry will map the hostname to the IP address of the Gateway or Ingress resource.
-* For each cluster in the openMCP landscape, the system service will annotate the `Cluster` resource with the openMCP base domain. This will help service providers to configure their services to use the openMCP base domain for their host names.
+* Deploy a central OpenControlPlane DNS server in the OpenControlPlane landscape. This DNS server will be used to resolve all host names in the OpenControlPlane base domain `openmcp.cluster`.
+* For each cluster in the OpenControlPlane landscape, the system service will configure the Kubernetes local DNS service to forward DNS queries for the OpenControlPlane base domain to the central OpenControlPlane DNS server. This will ensure that all clusters can resolve host names in the OpenControlPlane base domain.
+* For each Gateway or Ingress resource, the system service will create a DNS entry in the central OpenControlPlane DNS server. The DNS entry will map the hostname to the IP address of the Gateway or Ingress resource.
+* For each cluster in the OpenControlPlane landscape, the system service will annotate the `Cluster` resource with the OpenControlPlane base domain. This will help service providers to configure their services to use the OpenControlPlane base domain for their host names.
 
 This shall be completely transparent to a service provider. The service provider only needs to create a Gateway or Ingress resource and the DNS entry will be created automatically.
 
@@ -75,7 +75,7 @@ For the example implementation, following components are used:
 The `DNS Provider` is running on the platform cluster. The `DNS Provider` is deploying an `ETCD` and the cental `CoreDNS` instance on the platform cluster. The `ETCD` instance is used to store the DNS entries. The `CoreDNS` is reading the DNS entries from the `ETCD` instance and is used to resolve the host names.
 
 ```yaml
-# CoreDNS configuration to read DNS entries from ETCD for the openMCP base domain `openmcp.cluster`
+# CoreDNS configuration to read DNS entries from ETCD for the OpenControlPlane base domain `openmcp.cluster`
 - name: etcd
     parameters: openmcp.cluster
     configBlock: |-
@@ -95,7 +95,7 @@ containers:
     - --source=ingress
     - --source=gateway-httproute
     - --provider=coredns
-    - --domain-filter=platform.openmcp.cluster # only detect hostnames in the openMCP base domain belonging to the cluster
+    - --domain-filter=platform.openmcp.cluster # only detect hostnames in the OpenControlPlane base domain belonging to the cluster
     env:
     - name: ETCD_URLS
         value: http://172.18.200.2:2379 # external routable IP of the ETCD instance running on the platform cluster
@@ -123,7 +123,7 @@ subgraph Platform Cluster
   end
 ```
 
-The `DNS Provider` is updating the `CoreDNS` configuration on the platform cluster and on all other clusters. The `CoreDNS` configuration is updated to forward DNS queries for the openMCP base domain to the central `CoreDNS` instance running on the platform cluster. This will ensure that all clusters can resolve host names in the openMCP base domain.
+The `DNS Provider` is updating the `CoreDNS` configuration on the platform cluster and on all other clusters. The `CoreDNS` configuration is updated to forward DNS queries for the OpenControlPlane base domain to the central `CoreDNS` instance running on the platform cluster. This will ensure that all clusters can resolve host names in the OpenControlPlane base domain.
 
 ```corefile
 openmcp.cluster {
@@ -146,4 +146,4 @@ subgraph Platform Cluster
   end
 ```
 
-Then on any pod in any cluster of the openMCP landscape, the hostname can be resolved to the IP address of the Gateway or Ingress resource.
+Then on any pod in any cluster of the OpenControlPlane landscape, the hostname can be resolved to the IP address of the Gateway or Ingress resource.
diff --git a/adrs/2025-08-12-mcp-namespace-strategy.md b/adrs/2025-08-12-mcp-namespace-strategy.md
@@ -7,7 +7,7 @@ authors:
 
 ## Context and Problem Statement
 
-In the openMCP platform, we need to determine how to organize resources in the Platform Cluster that belong to Managed Control Planes (MCPs). Each MCP represents a separate tenant or customer environment that needs to be isolated and managed independently. The key question is: Should every MCP on the Platform Cluster have its own Namespace to ensure proper isolation, resource management, and security boundaries?
+In the OpenControlPlane platform, we need to determine how to organize resources in the Platform Cluster that belong to Managed Control Planes (MCPs). Each MCP represents a separate tenant or customer environment that needs to be isolated and managed independently. The key question is: Should every MCP on the Platform Cluster have its own Namespace to ensure proper isolation, resource management, and security boundaries?
 
 Without proper namespace isolation, MCPs could interfere with each other, leading to security vulnerabilities, resource conflicts, and operational complexity.
 

diff --git a/docs/about/concepts/cluster-provider.md b/docs/about/concepts/cluster-provider.md
diff --git a/docs/about/concepts/managed-control-plane.md b/docs/about/concepts/managed-control-plane.md
diff --git a/docs/about/concepts/platform-service.md b/docs/about/concepts/platform-service.md
diff --git a/docs/about/concepts/service-provider.md b/docs/about/concepts/service-provider.md
Original file line number	Diff line number	Diff line change
Expand Up		@@ -48,4 +48,4 @@ We as members, contributors, and leaders pledge to make participation in our com

		## Licensing

		Copyright 2025 SAP SE or an SAP affiliate company and openMCP contributors. Please see our [LICENSE](LICENSE) for copyright and license information. Detailed information including third-party components and their licensing/copyright information is available [via the REUSE tool](https://api.reuse.software/info/github.com/openmcp-project/docs).
		Copyright 2025 SAP SE or an SAP affiliate company and OpenControlPlane contributors. Please see our [LICENSE](LICENSE) for copyright and license information. Detailed information including third-party components and their licensing/copyright information is available [via the REUSE tool](https://api.reuse.software/info/github.com/openmcp-project/docs).