refactor(architecture): Refactor text architecture to likec4

- Add test:hugo for fast Hugo-only tests (no LikeC4)
- Update technical writer docs with new task

.claude/CLAUDE.md

@@ -0,0 +1,74 @@
+# Technical Documentation Guidelines
+
+You are an expert technical writer with deep expertise in creating clear, concise, and well-structured documentation. Your goal is to produce documentation that flows naturally while maintaining technical accuracy.
+
+## Core Principles
+
+### 1. Conciseness and Clarity
+- Use clear, direct language
+- Eliminate unnecessary words and redundancy
+- Make every sentence count
+- Prefer active voice over passive voice
+- Use short paragraphs (3-5 sentences maximum)
+
+### 2. Structure and Organization
+- Start with the most important information
+- Use logical hierarchies with consistent heading levels
+- Group related concepts together
+- Provide clear navigation through table of contents when appropriate
+- Use lists for sequential steps or related items
+
+### 3. Flow and Readability
+- Ensure smooth transitions between sections
+- Connect ideas logically
+- Build complexity gradually
+- Use examples to illustrate concepts
+- Maintain consistent terminology throughout
+
+### 4. Technical Accuracy
+- Be precise with technical terms
+- Include relevant code examples that are tested and functional
+- Document edge cases and limitations
+- Provide accurate command syntax and parameters
+- Link to related documentation when appropriate
+
+## Documentation Structure
+
+### Standard Document Layout
+1. **Title** - Clear, descriptive heading
+2. **Overview** - Brief introduction (2-3 sentences)
+3. **Prerequisites** - What the reader needs to know or have
+4. **Main Content** - Organized in logical sections
+5. **Examples** - Practical, real-world use cases
+6. **Troubleshooting** - Common issues and solutions (when applicable)
+7. **Related Resources** - Links to additional documentation
+
+### Code Examples
+- Provide complete, runnable examples
+- Include comments for complex logic
+- Show expected output
+- Use consistent formatting and syntax highlighting
+
+### Commands and APIs
+- Show full syntax with all parameters
+- Indicate required vs optional parameters
+- Provide parameter descriptions
+- Include return values or output format
+
+## Writing Style
+
+- **Be direct**: "Configure the database" not "You should configure the database"
+- **Be specific**: "Set timeout to 30 seconds" not "Set an appropriate timeout"
+- **Be consistent**: Use the same terms for the same concepts
+- **Be complete**: Don't assume implicit knowledge; explain as needed
+
+## When Uncertain
+
+**If you don't know something or need clarification:**
+- Ask specific questions
+- Request examples or use cases
+- Clarify technical details or edge cases
+- Verify terminology and naming conventions
+- Confirm target audience and their expected knowledge level
+
+Your expertise is in writing excellent documentation. Use your judgment to create documentation that serves the reader's needs effectively. When in doubt, ask rather than guess.

.dockerignore

@@ -0,0 +1,22 @@
+.github
+.gitignore
+.vscode
+.devbox
+.devcontainer
+node_modules
+public
+resources
+tmp
+*.md
+!content/**/*.md
+TESTING.md
+Taskfile.yml
+devbox.json
+devbox.lock
+.hugo_build.lock
+.htmltest.yml
+.htmlvalidate.json
+.markdownlint.json
+
+# Ensure package-lock.json is included for npm ci
+!package-lock.json

.env.versions

@@ -0,0 +1,9 @@
+# Tool versions for development and CI/CD
+# These versions are used in:
+# - devbox.json (pinned versions)
+# - Dockerfile (build arguments)
+# - .github/workflows/ci.yaml (CI/CD pipeline)
+
+NODE_VERSION=24.10.0
+GO_VERSION=1.25.1
+HUGO_VERSION=0.151.0

.envrc.example

@@ -0,0 +1 @@
+use flake

.github/workflows/ci.yaml

@@ -0,0 +1,79 @@
+name: ci
+
+on:
+  push:
+  workflow_dispatch:
+
+jobs:
+  build:
+    runs-on: ubuntu-22.04
+
+    steps:
+      - name: Checkout code
+        uses: actions/checkout@v4
+        with:
+          submodules: recursive
+          fetch-depth: 0
+
+      - name: Load versions from .env.versions
+        id: versions
+        run: |
+          # Source the versions file
+          set -a
+          source .env.versions
+          set +a
+
+          echo "node_version=${NODE_VERSION}" >> "$GITHUB_OUTPUT"
+          echo "go_version=${GO_VERSION}" >> "$GITHUB_OUTPUT"
+          echo "hugo_version=${HUGO_VERSION}" >> "$GITHUB_OUTPUT"
+
+          echo "Node: ${NODE_VERSION}"
+          echo "Go: ${GO_VERSION}"
+          echo "Hugo: ${HUGO_VERSION}"
+
+      - name: Repository meta
+        id: repository
+        run: |
+          registry=${{ github.server_url }}
+          registry=${registry##http*://}
+          echo "registry=${registry}" >> "$GITHUB_OUTPUT"
+          echo "registry=${registry}"
+          repository="$(echo "${{ github.repository }}" | tr '[:upper:]' '[:lower:]')"
+          echo "repository=${repository}" >> "$GITHUB_OUTPUT"
+          echo "repository=${repository}"
+
+      - name: Docker meta
+        uses: docker/metadata-action@v5
+        id: docker
+        with:
+          images: ${{ steps.repository.outputs.registry }}/${{ steps.repository.outputs.repository }}
+          tags: |
+            type=sha,prefix=
+            type=ref,event=tag
+      -
+        name: Login to registry
+        uses: docker/login-action@v3
+        with:
+          registry: ${{ steps.repository.outputs.registry }}
+          username: "${{ secrets.PACKAGES_USER }}"
+          password: "${{ secrets.PACKAGES_TOKEN }}"
+      -
+        name: Set up Docker Buildx
+        uses: docker/setup-buildx-action@v3
+        with:
+          buildkitd-flags: '--allow-insecure-entitlement network.host'
+          driver-opts: network=host
+
+      - name: Build and push
+        uses: docker/build-push-action@v6
+        with:
+          context: .
+          push: true
+          allow: network.host
+          network: host
+          tags: ${{ steps.docker.outputs.tags }}
+          labels: ${{ steps.docker.outputs.labels }}
+          build-args: |
+            NODE_VERSION=${{ steps.versions.outputs.node_version }}
+            GO_VERSION=${{ steps.versions.outputs.go_version }}
+            HUGO_VERSION=${{ steps.versions.outputs.hugo_version }}

.github/workflows/delete-edge.yaml

@@ -0,0 +1,32 @@
+name: delete-edge
+
+on:
+  workflow_run:
+    workflows: [build]
+    types:
+      - completed
+  workflow_dispatch:
+
+jobs:
+  build:
+    runs-on: ubuntu-22.04
+
+    steps:
+      - name: Checkout
+        uses: actions/checkout@v4
+
+      - name: Replace Image Version
+        run: |
+          sha="${{ github.sha }}"
+          shortSha="${sha:0:7}"
+          echo "Setting image version to: edp.buildth.ing/devfw-cicd/website-and-documentation:${shortSha}"
+          sed -i "s@###IMAGETAG###@edp.buildth.ing/devfw-cicd/website-and-documentation:${shortSha}@g" ./k8s-deployment.yaml
+
+      - name: Delete action
+        uses: https://edp.buildth.ing/DevFW-CICD/edge-connect-delete-action@main
+        id: delete
+        with:
+          configFile: ./edgeconnectdeployment.yaml
+          baseUrl: https://hub.apps.edge.platform.mg3.mdb.osc.live
+          username: ${{ secrets.EDGEXR_PLATFORM_USERNAME }}
+          password: ${{ secrets.EDGEXR_PLATFORM_PASSWORD }}

.github/workflows/deploy-edge.yaml

@@ -0,0 +1,32 @@
+name: deploy-edge
+
+on:
+  workflow_run:
+    workflows: [build]
+    types:
+      - completed
+  workflow_dispatch:
+
+jobs:
+  build:
+    runs-on: ubuntu-22.04
+
+    steps:
+      - name: Checkout
+        uses: actions/checkout@v4
+
+      - name: Replace Image Version
+        run: |
+          sha="${{ github.sha }}"
+          shortSha="${sha:0:7}"
+          echo "Setting image version to: edp.buildth.ing/devfw-cicd/website-and-documentation:${shortSha}"
+          sed -i "s@###IMAGETAG###@edp.buildth.ing/devfw-cicd/website-and-documentation:${shortSha}@g" ./k8s-deployment.yaml
+
+      - name: Deploy action
+        uses: https://edp.buildth.ing/DevFW-CICD/edge-connect-deploy-action@main
+        id: deploy
+        with:
+          configFile: ./edgeconnectdeployment.yaml
+          baseUrl: https://hub.apps.edge.platform.mg3.mdb.osc.live
+          username: ${{ secrets.EDGEXR_PLATFORM_USERNAME }}
+          password: ${{ secrets.EDGEXR_PLATFORM_PASSWORD }}

.github/workflows/release.yaml

@@ -0,0 +1,149 @@
+name: release
+
+on:
+  push:
+    tags:
+      - 'v*.*.*'  # Triggert auf Semantic Versioning Tags (v1.0.0, v2.1.3, etc.)
+
+permissions:
+  contents: write
+  packages: write
+
+jobs:
+  release:
+    runs-on: ubuntu-22.04
+
+    steps:
+      - name: Checkout code
+        uses: actions/checkout@v4
+        with:
+          submodules: recursive
+          fetch-depth: 0
+
+      - name: Load versions from .env.versions
+        id: versions
+        run: |
+          set -a
+          source .env.versions
+          set +a
+
+          echo "node_version=${NODE_VERSION}" >> "$GITHUB_OUTPUT"
+          echo "go_version=${GO_VERSION}" >> "$GITHUB_OUTPUT"
+          echo "hugo_version=${HUGO_VERSION}" >> "$GITHUB_OUTPUT"
+
+          echo "Node: ${NODE_VERSION}"
+          echo "Go: ${GO_VERSION}"
+          echo "Hugo: ${HUGO_VERSION}"
+
+      - name: Extract version from tag
+        id: version
+        run: |
+          VERSION=${GITHUB_REF#refs/tags/v}
+          echo "version=${VERSION}" >> "$GITHUB_OUTPUT"
+          echo "Version: ${VERSION}"
+
+      - name: Repository meta
+        id: repository
+        run: |
+          registry=${{ github.server_url }}
+          registry=${registry##http*://}
+          echo "registry=${registry}" >> "$GITHUB_OUTPUT"
+          echo "registry=${registry}"
+          repository="$(echo "${{ github.repository }}" | tr '[:upper:]' '[:lower:]')"
+          echo "repository=${repository}" >> "$GITHUB_OUTPUT"
+          echo "repository=${repository}"
+
+      - name: Docker meta
+        uses: docker/metadata-action@v5
+        id: docker
+        with:
+          images: ${{ steps.repository.outputs.registry }}/${{ steps.repository.outputs.repository }}
+          tags: |
+            type=semver,pattern={{version}}
+            type=semver,pattern={{major}}.{{minor}}
+            type=semver,pattern={{major}}
+            type=raw,value=latest
+
+      - name: Login to registry
+        uses: docker/login-action@v3
+        with:
+          registry: ${{ steps.repository.outputs.registry }}
+          username: "${{ secrets.PACKAGES_USER }}"
+          password: "${{ secrets.PACKAGES_TOKEN }}"
+
+      - name: Set up QEMU
+        uses: docker/setup-qemu-action@v3
+
+      - name: Set up Docker Buildx
+        uses: docker/setup-buildx-action@v3
+        with:
+          buildkitd-flags: '--allow-insecure-entitlement network.host'
+          driver-opts: network=host
+
+      - name: Build and push release images
+        uses: docker/build-push-action@v6
+        with:
+          context: .
+          push: true
+          allow: network.host
+          network: host
+          platforms: linux/amd64,linux/arm64
+          tags: ${{ steps.docker.outputs.tags }}
+          labels: ${{ steps.docker.outputs.labels }}
+          build-args: |
+            NODE_VERSION=${{ steps.versions.outputs.node_version }}
+            GO_VERSION=${{ steps.versions.outputs.go_version }}
+            HUGO_VERSION=${{ steps.versions.outputs.hugo_version }}
+
+      - name: Generate changelog
+        id: changelog
+        run: |
+          # Finde vorheriges Tag
+          PREVIOUS_TAG=$(git describe --abbrev=0 --tags ${GITHUB_REF}^ 2>/dev/null || echo "")
+
+          if [ -z "$PREVIOUS_TAG" ]; then
+            echo "Erster Release - Changelog von Anfang an"
+            CHANGELOG=$(git log --pretty=format:"- %s (%h)" --no-merges)
+          else
+            echo "Changelog seit ${PREVIOUS_TAG}"
+            CHANGELOG=$(git log ${PREVIOUS_TAG}..${GITHUB_REF} --pretty=format:"- %s (%h)" --no-merges)
+          fi
+
+          # Schreibe in Output-Datei (multiline)
+          {
+            echo 'changelog<<EOF'
+            echo "$CHANGELOG"
+            echo 'EOF'
+          } >> "$GITHUB_OUTPUT"
+
+      - name: Create Forgejo/Gitea Release
+        uses: actions/forgejo-release@v2
+        env:
+          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+        with:
+          direction: upload
+          release-dir: .
+          title: "Release ${{ steps.version.outputs.version }}"
+          tag: ${{ github.ref_name }}
+          token: ${{ secrets.GITHUB_TOKEN }}
+          release-notes: |
+            # Release ${{ steps.version.outputs.version }}
+
+            ## Docker Images
+
+            Multi-platform images (linux/amd64, linux/arm64) sind verfügbar:
+
+            ```bash
+            docker pull ${{ steps.repository.outputs.registry }}/${{ steps.repository.outputs.repository }}:${{ steps.version.outputs.version }}
+            docker pull ${{ steps.repository.outputs.registry }}/${{ steps.repository.outputs.repository }}:latest
+            ```
+
+            ## Build Versions
+
+            - Node.js: ${{ steps.versions.outputs.node_version }}
+            - Go: ${{ steps.versions.outputs.go_version }}
+            - Hugo: ${{ steps.versions.outputs.hugo_version }}
+
+            ## Changes
+
+            ${{ steps.changelog.outputs.changelog }}

.github/workflows/test.yml

@@ -0,0 +1,51 @@
+name: Hugo Site Tests
+
+on:
+#   push:
+#     branches: [ main ]
+  pull_request:
+    branches: [ main ]
+
+jobs:
+  test:
+    runs-on: ubuntu-latest
+
+    steps:
+    - uses: actions/checkout@v4
+      with:
+        submodules: recursive
+        fetch-depth: 0
+
+    - name: Setup Hugo
+      uses: peaceiris/actions-hugo@v3
+      with:
+        hugo-version: 'latest'
+        extended: true
+
+    - name: Setup Node
+      uses: actions/setup-node@v4
+      with:
+        node-version: '24'
+        cache: 'npm'
+
+    - name: Install dependencies
+      run: |
+        npm ci
+        go install github.com/wjdp/htmltest@latest
+
+    - name: Run tests
+      run: |
+        npm run test:build
+        npm run test:markdown
+        npm run test:html
+
+    - name: Run link checker
+      run: htmltest
+      continue-on-error: true
+
+    - name: Upload htmltest results
+      uses: actions/upload-artifact@v4
+      if: always()
+      with:
+        name: htmltest-report
+        path: tmp/.htmltest/

.gitignore

@@ -1,7 +1,41 @@
+# Hugo
 .hugo_build.lock
-public
+public/
+resources/_gen/
 
-# for npm devcontainer cli
-package-lock.json
-package.json
+# Node.js / NPM
+node_modules/
 
+# Test outputs
+tmp/
+.htmltest/
+
+# devbox
+.devbox/
+
+# Task cache
+.task/
+
+# Generated build data
+data/
+
+# IDE
+.vscode/
+.idea/
+*.swp
+*.swo
+*~
+
+# OS
+.DS_Store
+Thumbs.db
+
+# Logs
+*.log
+npm-debug.log*
+yarn-debug.log*
+yarn-error.log*
+
+### direnv ###
+.direnv
+.envrc

.htmltest.yml

@@ -0,0 +1,24 @@
+DirectoryPath: "public"
+CheckExternal: true
+CheckInternalHash: true
+IgnoreURLs:
+  - "^https://example\\.docsy\\.dev"
+  - "^https://example\\.com"
+  - "^http://localhost"
+  - "^/livereload\\.js"
+  - "^https://cnoe\\.localtest\\.me"
+  - "^https://technologyconversations\\.com"
+  - "^https://developers\\.redhat\\.com"
+  - "^https://platformengineering\\.org"
+  - "^https://cnoe\\.io"
+  - "^https://console\\.otc\\.t-systems\\.com"
+IgnoreInternalURLs:
+  - "/docs-old/"
+  - "/blog/"
+  - "/docs/v1/"
+  - "/docs/architecture/"
+  - "/docs/documentation/"
+IgnoreInternalEmptyHashes: true
+IgnoreDirectoryMissingTrailingSlash: true
+IgnoreAltMissing: true
+CheckDoctype: true

.htmlvalidate.json

@@ -0,0 +1,27 @@
+{
+  "extends": ["html-validate:recommended"],
+  "rules": {
+    "no-inline-style": "off",
+    "require-sri": "off",
+    "no-trailing-whitespace": "off",
+    "void-style": "off",
+    "wcag/h30": "off",
+    "wcag/h32": "off",
+    "wcag/h37": "off",
+    "no-redundant-role": "off",
+    "unique-landmark": "off",
+    "no-multiple-main": "off",
+    "no-dup-id": "off",
+    "element-permitted-content": "off",
+    "attr-quotes": "off",
+    "empty-heading": "off",
+    "element-required-content": "off",
+    "long-title": "off",
+    "no-raw-characters": "off",
+    "valid-id": "off",
+    "doctype-style": "off"
+  },
+  "elements": [
+    "html5"
+  ]
+}

.markdownlint.json

@@ -0,0 +1,8 @@
+{
+  "default": true,
+  "MD013": false,
+  "MD033": false,
+  "MD041": false,
+  "MD024": { "siblings_only": true },
+  "MD025": { "front_matter_title": "" }
+}

.markdownlintignore

@@ -0,0 +1,4 @@
+# Ignore v1 documentation (legacy content with pre-existing lint issues)
+content/en/docs/v1/**
+content/en/blog/**
+content/en/docs-old/**

.vscode/settings.json

@@ -1,3 +1,22 @@
 {
-    "peacock.remoteColor": "#61dafb"
+    "peacock.remoteColor": "#61dafb",
+    "workbench.colorCustomizations": {
+        "activityBar.activeBackground": "#93e6fc",
+        "activityBar.background": "#93e6fc",
+        "activityBar.foreground": "#15202b",
+        "activityBar.inactiveForeground": "#15202b99",
+        "activityBarBadge.background": "#fa45d4",
+        "activityBarBadge.foreground": "#15202b",
+        "commandCenter.border": "#15202b99",
+        "sash.hoverBorder": "#93e6fc",
+        "statusBar.background": "#61dafb",
+        "statusBar.foreground": "#15202b",
+        "statusBarItem.hoverBackground": "#2fcefa",
+        "statusBarItem.remoteBackground": "#61dafb",
+        "statusBarItem.remoteForeground": "#15202b",
+        "titleBar.activeBackground": "#61dafb",
+        "titleBar.activeForeground": "#15202b",
+        "titleBar.inactiveBackground": "#61dafb99",
+        "titleBar.inactiveForeground": "#15202b99"
+    }
 }

Dockerfile

@@ -0,0 +1,69 @@
+# Build arguments for version pinning (matching devbox.json)
+ARG NODE_VERSION=24.10.0
+ARG GO_VERSION=1.25.1
+ARG HUGO_VERSION=0.151.0
+
+# Build stage - use same versions as local devbox environment
+FROM node:${NODE_VERSION}-bookworm AS builder
+
+# Get target architecture for multi-platform builds
+ARG TARGETARCH
+
+# Install Git (needed for Hugo's enableGitInfo)
+RUN apt-get update && apt-get install -y git && rm -rf /var/lib/apt/lists/*
+
+# Install Go (map TARGETARCH: amd64->amd64, arm64->arm64)
+ARG GO_VERSION
+RUN wget -q https://go.dev/dl/go${GO_VERSION}.linux-${TARGETARCH}.tar.gz && \
+    tar -C /usr/local -xzf go${GO_VERSION}.linux-${TARGETARCH}.tar.gz && \
+    rm go${GO_VERSION}.linux-${TARGETARCH}.tar.gz
+
+ENV PATH="/usr/local/go/bin:${PATH}"
+ENV GOPATH="/go"
+ENV PATH="${GOPATH}/bin:${PATH}"
+
+# Install Hugo extended (map TARGETARCH: amd64->amd64, arm64->arm64)
+ARG HUGO_VERSION
+RUN wget -q https://github.com/gohugoio/hugo/releases/download/v${HUGO_VERSION}/hugo_extended_${HUGO_VERSION}_linux-${TARGETARCH}.tar.gz && \
+    tar -xzf hugo_extended_${HUGO_VERSION}_linux-${TARGETARCH}.tar.gz && \
+    mv hugo /usr/local/bin/ && \
+    rm hugo_extended_${HUGO_VERSION}_linux-${TARGETARCH}.tar.gz && \
+    hugo version
+
+WORKDIR /src
+
+# Copy package files and install npm dependencies
+COPY package*.json ./
+RUN npm ci
+
+# Copy all source files
+COPY . .
+
+# Build Hugo site (Git info wird aus dem aktuellen Kontext genommen, nicht aus .git)
+# Hugo sucht nach .git, findet es nicht, und überspringt Git-Info automatisch
+RUN hugo --gc --minify
+
+# Runtime stage - nginx to serve static content
+FROM nginx:1.27-alpine
+
+# Copy built site from builder
+COPY --from=builder /src/public /usr/share/nginx/html
+
+# Copy custom nginx config
+RUN echo 'server {' > /etc/nginx/conf.d/default.conf && \
+    echo '    listen 80;' >> /etc/nginx/conf.d/default.conf && \
+    echo '    server_name _;' >> /etc/nginx/conf.d/default.conf && \
+    echo '    root /usr/share/nginx/html;' >> /etc/nginx/conf.d/default.conf && \
+    echo '    index index.html;' >> /etc/nginx/conf.d/default.conf && \
+    echo '' >> /etc/nginx/conf.d/default.conf && \
+    echo '    location / {' >> /etc/nginx/conf.d/default.conf && \
+    echo '        try_files $uri $uri/ /index.html;' >> /etc/nginx/conf.d/default.conf && \
+    echo '    }' >> /etc/nginx/conf.d/default.conf && \
+    echo '' >> /etc/nginx/conf.d/default.conf && \
+    echo '    gzip on;' >> /etc/nginx/conf.d/default.conf && \
+    echo '    gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;' >> /etc/nginx/conf.d/default.conf && \
+    echo '}' >> /etc/nginx/conf.d/default.conf
+
+EXPOSE 80
+
+CMD ["nginx", "-g", "daemon off;"]

README.md

@@ -1,88 +1,33 @@
-# IPCEICIS-DeveloperFramework Documentation
+# EDP - Edge Developer Platform
 
-This repo contains business and architectural design and documentation of the DeveloperFramework subproject of IPCEI-CIS.
+Documentation for the edgeDeveloperFramework (eDF) project and the resulting Edge Developer Platform (EDP) product suite.
 
-## How to read and contribute to this documentation locally
+## Quick Start
 
-The documentation is done in [Hugo-format](https://gohugo.io).
+```bash
+# Install dependencies
+task deps
 
-Hugo is a static site renderer - so to get the documentation site presented you need a running Hugo processor. Therefore there is 
+# Start local development server
+task serve
 
-* either a Hugo [`.devcontainer`-definition](https://containers.dev/) - just run a devcontainer aware IDE or CLI, e.g. Visual Studio code
-* or a Hugo [`Devbox`-definition](https://www.jetify.com/devbox/) - in this case just run a devbox shell
+# Run tests
+task test
 
-## Local installation of the Hugo documentation system
+# Build production site
+task build
+```
 
-We describe two possible ways (one with devcontainer, one with devbox) to get the Hugo-documentation system locally running.
+## Documentation
 
-For both prepare the following three steps:
+* [Developer Guide](doc/README-developer.md)
+* [Technical Writer Guide](doc/README-technical-writer.md)
+* [Release Notes](doc/RELEASE.md)
 
-1. open a terminal on your local box
-2. clone this repo: `git clone https://forgejo.edf-bootstrap.cx.fg1.ffm.osc.live/DevFW/website-and-documentation`
-3. change to the repo working dir: `cd website-and-documentation`
+## Project
 
-### Possibility 1: Hugo in a devcontainer
+This is a Hugo-based documentation site for the Edge Developer Platform, built as part of the IPCEI-CIS project.
 
-[`devcontainers`](https://containers.dev/) are running containers as virtual systems on your local box. The defintion is in the `.devcontainer` folder.
-Thus as preliminary you need a container daemon running, e.g. Docker.
+**Website:** Access the documentation at the deployed URL or run locally with `task serve`
 
-There are several options to create and run the devcontainer - we present here two:
-
-#### Option 1: Run the container triggered by and connected to an IDE, e.g. VS Code
-
-1. open the repo in an [Devcontainer-aware tool/IDE](https://containers.dev/supporting) (e.g. `code .`)
-1. start the `devcontainer` (in VSC it's `F1 + Reopen in Devcontainer`)
-1. when the container is up & running just open your browser with `http://localhost:1313/`
-
-#### Option 2: Run the container natively
-
-An alternative to get the container image is the [devcontainer CLI](https://github.com/devcontainers/cli), then you can run the devcontainer without VS Code.
-Thus as preliminary you need to do the install steps of the devconatiner cli.
-
-1. start the devcontainer by running: `devcontainer up --workspace-folder .`
-1. find out the IP address of the devconatiner by using `docker ps` and `docker inspect <id of container>`
-1. when the container is up & running just open your browser with `http://<DOCKER IP>:1313/`
-
-### Possibility 2: Hugo in a devbox
-
-[`Devboxes`](https://www.jetify.com/devbox/) are locally isolated environments, managed by the [Nix package manager](https://nix.dev/). So first [prepare the devbox](https://www.jetify.com/docs/devbox/installing_devbox/).
-
-Then
-
-1. ```devbox shell```
-1. In the shell: ```hugo serve```
-
-
-## Editing
-
-### Documentation language
-
-The documentation is done in [Docsy-Theme](https://www.docsy.dev/).
-
-So for editing content just goto the `content`-folder and edit content arrording to the [Docsy documentation](https://www.docsy.dev/docs/adding-content/)
-
-## Commiting
-
-After having finished a unit of work commit and push.
-
-# Annex
-
-## Installation steps illustrated
-
-When you run the above installation, the outputs could typically look like this:
-
-### In Visual Studio Code
-
-#### Reopen in Container
-
-![vsc-f1](./assets/images/vsc-f1.png)
-
-#### Hugo server is running and (typically) listens to localhost:1313
-
-After some installation time you have:
-
-![vsc-hugo](./assets/images/vsc-hugo.png)
-
-### Final result in a web browser
-
-![browser](./assets/images/browser.png)
+For detailed information, see the documentation in the `doc/` folder.

Taskfile.yml

@@ -0,0 +1,225 @@
+version: '3'
+
+vars:
+  HUGO_CMD: hugo
+  NPM_CMD: npm
+
+tasks:
+  default:
+    desc: Show available tasks
+    cmds:
+      - task --list
+
+  # Build tasks
+  build:
+    desc: Build Hugo site
+    deps:
+      - deps:ensure-npm
+      - build:generate-info
+    cmds:
+      - "{{.HUGO_CMD}} --gc --minify"
+
+  build:dev:
+    desc: Build Hugo site for development
+    deps:
+      - deps:ensure-npm
+      - build:generate-info
+    cmds:
+      - "{{.HUGO_CMD}}"
+
+  build:generate-info:
+    desc: Generate build information (git commit, version, etc.)
+    sources:
+      - .git/HEAD
+      - .git/refs/**/*
+    generates:
+      - data/build_info.json
+    cmds:
+      - ./scripts/generate-build-info.sh
+
+  serve:
+    desc: Start Hugo dev server
+    deps:
+      - deps:ensure-npm
+      - build:generate-info
+    cmds:
+      - "{{.HUGO_CMD}} server --noHTTPCache"
+
+  clean:
+    desc: Clean build artifacts
+    cmds:
+      - rm -rf public resources/_gen .hugo_build.lock
+
+  # Test tasks
+  test:
+    desc: Run all tests
+    deps:
+      - test:build
+      - test:markdown
+      - test:html
+      - likec4:validate
+
+  test:hugo:
+    desc: Run Hugo-only tests (markdown, HTML, build)
+    deps:
+      - test:build
+      - test:markdown
+      - test:html
+
+  test:full:
+    desc: Run all tests including link check (may have errors in legacy content)
+    deps:
+      - test:build
+      - test:markdown
+      - test:html
+      - test:links
+      - likec4:validate
+
+  test:quick:
+    desc: Run quick tests (without link check)
+    deps:
+      - test:build
+      - test:markdown
+      - likec4:validate
+
+  test:build:
+    desc: Test Hugo build
+    deps:
+      - deps:ensure-npm
+      - build:generate-info
+    cmds:
+      - "{{.HUGO_CMD}} --gc --minify --logLevel info"
+
+  test:markdown:
+    desc: Lint markdown files
+    deps:
+      - deps:ensure-npm
+    cmds:
+      - "{{.NPM_CMD}} run test:markdown"
+
+  test:html:
+    desc: Validate HTML
+    deps:
+      - deps:ensure-npm
+    cmds:
+      - "{{.NPM_CMD}} run test:html"
+
+  test:links:
+    desc: Check links (skips legacy content)
+    cmds:
+      - |
+        # Move legacy dirs outside public temporarily
+        mkdir -p /tmp/htmltest-backup-$$
+        if [ -d "public/docs-old" ]; then mv public/docs-old /tmp/htmltest-backup-$$/; fi
+        if [ -d "public/blog" ]; then mv public/blog /tmp/htmltest-backup-$$/; fi
+        if [ -d "public/_print/docs-old" ]; then mv public/_print/docs-old /tmp/htmltest-backup-$$/docs-old-print; fi
+
+        # Run htmltest
+        htmltest || EXIT_CODE=$?
+
+        # Restore directories
+        if [ -d "/tmp/htmltest-backup-$$/docs-old" ]; then mv /tmp/htmltest-backup-$$/docs-old public/; fi
+        if [ -d "/tmp/htmltest-backup-$$/blog" ]; then mv /tmp/htmltest-backup-$$/blog public/; fi
+        if [ -d "/tmp/htmltest-backup-$$/docs-old-print" ]; then mv /tmp/htmltest-backup-$$/docs-old-print public/_print/docs-old; fi
+        rm -rf /tmp/htmltest-backup-$$
+
+        # Exit with the original exit code
+        exit ${EXIT_CODE:-0}
+
+  # LikeC4 tasks
+  likec4:generate:
+    desc: Generate LikeC4 webcomponent (includes all architecture projects)
+    cmds:
+      - npx likec4 codegen webcomponent --webcomponent-prefix likec4 --outfile static/js/likec4-webcomponent.js resources/edp-likec4 resources/doc-likec4
+
+  likec4:validate:
+    desc: Validate LikeC4 models
+    cmds:
+      - echo "Validating EDP architecture models..."
+      - npx likec4 validate --ignore-layout resources/edp-likec4
+      - echo "Validating Documentation platform models..."
+      - npx likec4 validate --ignore-layout resources/doc-likec4
+      - echo "✓ All LikeC4 models validated successfully"
+
+  likec4:validate:layout:
+    desc: Validate LikeC4 models including layout
+    cmds:
+      - echo "Validating EDP architecture models (including layout)..."
+      - npx likec4 validate resources/edp-likec4
+      - echo "Validating Documentation platform models (including layout)..."
+      - npx likec4 validate resources/doc-likec4
+      - echo "✓ All LikeC4 models and layouts validated successfully"
+
+  likec4:update:
+    desc: Update LikeC4 to latest version
+    cmds:
+      - npm update likec4 --prefix resources/edp-likec4
+      - npm update likec4 --prefix resources/doc-likec4
+      - echo "✓ LikeC4 updated in both projects"
+
+  # Development tasks
+  deps:ensure-npm:
+    desc: Ensure npm dependencies are installed
+    sources:
+      - package.json
+      - package-lock.json
+    generates:
+      - node_modules/.package-lock.json
+    cmds:
+      - "{{.NPM_CMD}} ci"
+    status:
+      - test -d node_modules
+
+  deps:install:
+    desc: Install all dependencies
+    cmds:
+      - "{{.NPM_CMD}} ci"
+      - "{{.HUGO_CMD}} mod get -u"
+      - "{{.HUGO_CMD}} mod tidy"
+
+  deps:update:
+    desc: Update dependencies
+    cmds:
+      - devbox update
+      - "{{.NPM_CMD}} update"
+      - "{{.HUGO_CMD}} mod get -u"
+
+  # CI/CD
+  ci:
+    desc: Run CI pipeline locally
+    deps:
+      - test
+
+  build:oci-image:
+    desc: Build OCI/Docker image with versions from .env.versions
+    cmds:
+      - |
+        set -a
+        source .env.versions
+        set +a
+        echo "Building OCI image with versions:"
+        echo "  NODE_VERSION=${NODE_VERSION}"
+        echo "  GO_VERSION=${GO_VERSION}"
+        echo "  HUGO_VERSION=${HUGO_VERSION}"
+        docker build --network=host \
+          --build-arg NODE_VERSION=${NODE_VERSION} \
+          --build-arg GO_VERSION=${GO_VERSION} \
+          --build-arg HUGO_VERSION=${HUGO_VERSION} \
+          -t ipceicis-developerframework:latest \
+          -t ipceicis-developerframework:$(git rev-parse --short HEAD) \
+          .
+
+  test:oci-image:
+    desc: Test the built OCI image
+    deps:
+      - build:oci-image
+    cmds:
+      - |
+        echo "Starting container on port 8080..."
+        docker run -d -p 8080:80 --name hugo-test ipceicis-developerframework:latest
+        sleep 2
+        echo "Testing endpoint..."
+        curl -f http://localhost:8080 > /dev/null && echo "✓ Container is running and responding" || echo "✗ Container test failed"
+        echo "Cleaning up..."
+        docker stop hugo-test
+        docker rm hugo-test

argocd-stack/docs.yaml

@@ -0,0 +1,28 @@
+apiVersion: argoproj.io/v1alpha1
+kind: Application
+metadata:
+  name: docs
+  namespace: argocd
+  labels:
+    env: prod
+spec:
+  project: default
+  syncPolicy:
+    automated:
+      selfHeal: true
+    syncOptions:
+      - CreateNamespace=true
+      - ServerSideApply=true
+  destination:
+    name: in-cluster
+    namespace: docs
+  syncOptions:
+    - CreateNamespace=true
+  sources:
+    - repoURL: https://edp.buildth.ing/DevFW-CICD/website-and-documentation
+      targetRevision: HEAD
+      path: argocd-stack/helm
+      helm:
+        parameters:
+        - name: image.tag
+          value: $ARGOCD_APP_REVISION_SHORT

argocd-stack/helm/.helmignore

@@ -0,0 +1,23 @@
+# Patterns to ignore when building packages.
+# This supports shell glob matching, relative path matching, and
+# negation (prefixed with !). Only one pattern per line.
+.DS_Store
+# Common VCS dirs
+.git/
+.gitignore
+.bzr/
+.bzrignore
+.hg/
+.hgignore
+.svn/
+# Common backup files
+*.swp
+*.bak
+*.tmp
+*.orig
+*~
+# Various IDEs
+.project
+.idea/
+*.tmproj
+.vscode/

argocd-stack/helm/Chart.yaml

@@ -0,0 +1,24 @@
+apiVersion: v2
+name: helm
+description: Deploy documentation to edp.buildth.ing
+
+# A chart can be either an 'application' or a 'library' chart.
+#
+# Application charts are a collection of templates that can be packaged into versioned archives
+# to be deployed.
+#
+# Library charts provide useful utilities or functions for the chart developer. They're included as
+# a dependency of application charts to inject those utilities and functions into the rendering
+# pipeline. Library charts do not define any templates and therefore cannot be deployed.
+type: application
+
+# This is the chart version. This version number should be incremented each time you make changes
+# to the chart and its templates, including the app version.
+# Versions are expected to follow Semantic Versioning (https://semver.org/)
+version: 0.1.0
+
+# This is the version number of the application being deployed. This version number should be
+# incremented each time you make changes to the application. Versions are not expected to
+# follow Semantic Versioning. They should reflect the version the application is using.
+# It is recommended to use it with quotes.
+appVersion: "1.16.0"

argocd-stack/helm/templates/deploy.yaml

@@ -0,0 +1,62 @@
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+  labels:
+    app: docs
+  name: docs
+spec:
+  replicas: 1
+  selector:
+    matchLabels:
+      app: docs
+  strategy: {}
+  template:
+    metadata:
+      labels:
+        app: docs
+    spec:
+      containers:
+        - image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"
+          name: docs
+          ports:
+            - name: http
+              containerPort: 80
+              protocol: TCP
+          resources: {}
+---
+apiVersion: v1
+kind: Service
+metadata:
+  name: docs
+spec:
+  selector:
+    app: docs
+  ports:
+    - protocol: TCP
+      port: 80
+      targetPort: 80
+---
+apiVersion: networking.k8s.io/v1
+kind: Ingress
+metadata:
+  name: docs
+  annotations:
+    cert-manager.io/cluster-issuer: main
+    nginx.ingress.kubernetes.io/force-ssl-redirect: "true"
+spec:
+  ingressClassName: nginx
+  rules:
+    - host: docs.edp.buildth.ing
+      http:
+        paths:
+          - backend:
+              service:
+                name: docs
+                port:
+                  number: 80
+            path: /
+            pathType: Prefix
+  tls:
+    - hosts:
+        - docs.edp.buildth.ing
+      secretName: docs-edp-buildth-ing-tls

argocd-stack/helm/values.yaml

@@ -0,0 +1,4 @@
+
+image:
+  repository: edp.buildth.ing/devfw-cicd/website-and-documentation
+  tag: "UNKNOWN_TAG"

assets/scss/_variables_project.scss

@@ -1,6 +1,524 @@
 /*
+ * Telekom-inspired Theme Variables
+ * Based on https://edp.buildth.ing Telekom Design System
+ */
 
-Add styles or override variables from the theme here.
+// Bootstrap/Docsy Variable Overrides (must be before imports)
+$primary: #E20074 !default;
+$secondary: #B6B6B6 !default;
+$success: #00b367 !default;
+$info: #0070ad !default;
+$warning: #ffcc00 !default;
+$danger: #d52b1e !default;
+$dark: #000000 !default;
+$light: #f9fafb !default;
 
-*/
+// Link colors
+$link-color: #E20074 !default;
+$link-hover-color: #C2005E !default;
+
+// Body
+$body-bg: #ffffff !default;
+$body-color: #000000 !default;
+
+// Navbar
+$navbar-light-color: #000000 !default;
+$navbar-light-hover-color: #E20074 !default;
+$navbar-light-active-color: #E20074 !default;
+
+// Fonts
+$font-family-sans-serif: 'TeleNeo', -apple-system, "Segoe UI", system-ui, Roboto, "Helvetica Neue", Arial, sans-serif !default;
+$font-family-base: $font-family-sans-serif !default;
+
+// Telekom TeleNeo Fonts
+@font-face {
+  font-family: 'TeleNeo';
+  src: url('../fonts/TeleNeoOffice-Thin.53627df9.ttf') format('truetype');
+  font-weight: 300;
+  font-style: normal;
+}
+
+@font-face {
+  font-family: 'TeleNeo';
+  src: url('../fonts/TeleNeoOffice-Regular.b0a2cff1.ttf') format('truetype');
+  font-weight: 400;
+  font-style: normal;
+}
+
+@font-face {
+  font-family: 'TeleNeo';
+  src: url('../fonts/TeleNeoOffice-Medium.79fb426d.ttf') format('truetype');
+  font-weight: 500;
+  font-style: normal;
+}
+
+@font-face {
+  font-family: 'TeleNeo';
+  src: url('../fonts/TeleNeoOffice-Bold.a7bb592b.ttf') format('truetype');
+  font-weight: 600;
+  font-style: normal;
+}
+
+@font-face {
+  font-family: 'TeleNeo';
+  src: url('../fonts/TeleNeoOffice-ExtraBold.fbe9fe42.ttf') format('truetype');
+  font-weight: 700;
+  font-style: normal;
+}
+
+// Primary Colors - Telekom Magenta
+:root {
+  // Telekom Primary Color (Magenta)
+  --color-primary: #E20074;
+  --color-primary-contrast: #ffffff;
+  --color-primary-dark-1: #C2005E;
+  --color-primary-dark-2: #A5004D;
+  --color-primary-dark-3: #87003D;
+  --color-primary-light-1: #E7338A;
+  --color-primary-light-2: #EC66A1;
+  --color-primary-light-3: #F299B8;
+  --color-primary-light-4: #F7CCCF;
+  --color-primary-light-5: #FCEFF6;
+  --color-primary-light-6: #FFF5FA;
+  
+  // Secondary Colors
+  --color-secondary: #B6B6B6;
+  --color-secondary-dark: #6a7178;
+  --color-secondary-light: #f9fafb;
+  
+  // Semantic Colors
+  --color-success: #00b367;
+  --color-warning: #ffcc00;
+  --color-error: #d52b1e;
+  --color-info: #0070ad;
+  
+  // Text Colors
+  --color-text: #000000;
+  --color-text-light: #666666;
+  --color-text-dark: #000000;
+  
+  // Background Colors
+  --color-body: #ffffff;
+  --color-card: #F1F1F1;
+  --color-hover: #F1F1F1;
+  --color-active: #F1F1F1;
+  
+  // Navigation
+  --color-nav-bg: #ffffff;
+  --color-nav-text: #000000;
+  --nav-border-color: #B6B6B6;
+  
+  // UI Elements
+  --color-input-background: #ffffff;
+  --color-input-border: #cccccc;
+  --color-input-text: #000000;
+  --color-box-body: #f2f2f2;
+  --color-box-header: #e6e6e6;
+  
+  // Shadows & Overlays
+  --color-shadow: rgba(0, 0, 0, 0.15);
+  --color-overlay-backdrop: rgba(0, 0, 0, 0.5);
+  
+  // Font Settings
+  --font-family-base: 'TeleNeo', -apple-system, "Segoe UI", system-ui, Roboto, "Helvetica Neue", Arial, sans-serif;
+  --nav-text-font-weight: 600;
+}
+
+// Apply TeleNeo font globally
+body {
+  font-family: var(--font-family-base);
+}
+
+// Dark Mode Support
+@media (prefers-color-scheme: dark) {
+  :root {
+    // Primary Colors remain same
+    --color-primary: #E20074;
+    --color-primary-contrast: #000000;
+    
+    // Dark Mode Adjustments
+    --color-primary-dark-1: #E7338A;
+    --color-primary-dark-2: #EC66A1;
+    --color-primary-light-1: #C2005E;
+    --color-primary-light-2: #A5004D;
+    
+    // Secondary Colors for Dark Mode
+    --color-secondary: #1c1c1e;
+    --color-secondary-dark: #4D4D4D;
+    --color-secondary-light: #0D0D0D;
+    
+    // Text Colors
+    --color-text: #FFFFFF;
+    --color-text-light: #CCCCCC;
+    --color-text-dark: #FFFFFF;
+    
+    // Background Colors
+    --color-body: #000000;
+    --color-card: #1c1c1e;
+    --color-hover: #1c1c1e;
+    --color-active: #0D0D0D;
+    
+    // Navigation
+    --color-nav-bg: #000000;
+    --color-nav-text: #FFFFFF;
+    
+    // UI Elements
+    --color-input-background: #1c1c1e;
+    --color-input-border: #4D4D4D;
+    --color-input-text: #FFFFFF;
+    --color-box-body: #000000;
+    --color-box-header: #1A1A1A;
+    
+    // Semantic Colors for Dark Mode
+    --color-success: #00A94F;
+    --color-warning: #FFCC00;
+    --color-error: #D52B1E;
+    --color-info: #0070AD;
+    
+    // Shadows
+    --color-shadow: rgba(0, 0, 0, 0.35);
+  }
+}
+
+// Telekom-inspired Component Styling
+.td-navbar {
+  background-color: var(--color-nav-bg) !important;
+  border-bottom: 1px solid var(--nav-border-color);
+  
+  .navbar-brand,
+  .nav-link {
+    color: var(--color-nav-text) !important;
+    font-weight: var(--nav-text-font-weight);
+  }
+  
+  .nav-link:hover,
+  .nav-link.active {
+    color: var(--color-primary) !important;
+    background: transparent !important;
+  }
+}
+
+// Primary Buttons - Telekom Magenta
+.btn-primary {
+  background-color: var(--color-primary) !important;
+  border-color: var(--color-primary) !important;
+  color: var(--color-primary-contrast) !important;
+  
+  &:hover {
+    background-color: var(--color-primary-dark-1) !important;
+    border-color: var(--color-primary-dark-1) !important;
+  }
+  
+  &:active,
+  &:focus {
+    background-color: var(--color-primary-dark-2) !important;
+    border-color: var(--color-primary-dark-2) !important;
+  }
+}
+
+// Links
+a {
+  color: var(--color-primary);
+  
+  &:hover {
+    color: var(--color-primary-dark-1);
+  }
+}
+
+// Cards with Telekom Style
+.card {
+  background-color: var(--color-card);
+  border: 1px solid var(--nav-border-color);
+  
+  &:hover {
+    background-color: var(--color-hover);
+  }
+}
+
+// Active/Selected States - REMOVED harsh black backgrounds
+// Now using soft Telekom colors instead
+
+// Sidebar Navigation
+.td-sidebar-nav {
+  .td-sidebar-link {
+    &:hover {
+      background-color: var(--color-primary-light-5) !important;
+      color: var(--color-primary) !important;
+    }
+    
+    &.active {
+      background-color: var(--color-primary-light-6);
+      color: var(--color-primary);
+      font-weight: 500;
+      border-left: 3px solid var(--color-primary);
+    }
+  }
+  
+  // All list items in sidebar
+  li a {
+    &:hover {
+      background-color: var(--color-primary-light-5) !important;
+      color: var(--color-primary) !important;
+    }
+  }
+}
+
+// Main navigation tabs
+.td-sidebar {
+  .td-sidebar-nav__section {
+    .ul-1 > li > a {
+      &.active,
+      &.td-sidebar-link--active {
+        background-color: var(--color-primary-light-6) !important;
+        color: var(--color-primary) !important;
+        font-weight: 500;
+        border-left: 3px solid var(--color-primary);
+      }
+      
+      &:hover {
+        background-color: var(--color-primary-light-5) !important;
+        color: var(--color-primary) !important;
+      }
+    }
+    
+    // All nested levels
+    li a:hover {
+      background-color: var(--color-primary-light-5) !important;
+      color: var(--color-primary) !important;
+    }
+  }
+}
+
+// Top navigation breadcrumb area
+.td-sidebar__inner {
+  .td-sidebar-nav__section-title {
+    &.active {
+      background-color: var(--color-primary-light-5) !important;
+      color: var(--color-primary) !important;
+    }
+  }
+}
+
+// Breadcrumb navigation in header
+.breadcrumb {
+  .active {
+    color: var(--color-primary) !important;
+  }
+  
+  a:hover {
+    color: var(--color-primary-dark-1) !important;
+  }
+}
+
+// Remove harsh black backgrounds globally
+.active,
+.selected {
+  background-color: var(--color-primary-light-6) !important;
+  color: var(--color-primary) !important;
+}
+
+// Softer hover states
+*:hover {
+  transition: all 0.2s ease-in-out;
+}
+
+// Override any dark/black hover backgrounds in navigation
+nav, .td-sidebar, .td-sidebar-nav {
+  a:hover,
+  li:hover > a,
+  .nav-link:hover {
+    background-color: var(--color-primary-light-5) !important;
+    color: var(--color-primary) !important;
+  }
+}
+
+// Code Blocks
+pre,
+code {
+  background-color: var(--color-box-body);
+  border: 1px solid var(--color-input-border);
+}
+
+// Inline code (backticks in text)
+code {
+  background-color: var(--color-primary-light-6);
+  color: var(--color-primary-dark-2);
+  padding: 2px 6px;
+  border-radius: 3px;
+  border: 1px solid var(--color-primary-light-3);
+  font-size: 0.9em;
+}
+
+// Code blocks (fenced code)
+pre {
+  background-color: var(--color-box-body);
+  border: 1px solid var(--color-input-border);
+  padding: 1rem;
+  border-radius: 4px;
+  
+  code {
+    background-color: transparent;
+    border: none;
+    padding: 0;
+    color: inherit;
+  }
+}
+
+// Tables
+table {
+  thead {
+    background-color: var(--color-box-header);
+  }
+  
+  tbody tr:hover {
+    background-color: var(--color-hover);
+  }
+}
+
+// Alerts/Notifications
+.alert-success {
+  background-color: var(--color-success);
+  border-color: var(--color-success);
+}
+
+.alert-warning {
+  background-color: var(--color-warning);
+  border-color: var(--color-warning);
+  color: #000000;
+}
+
+.alert-danger {
+  background-color: var(--color-error);
+  border-color: var(--color-error);
+}
+
+.alert-info {
+  background-color: var(--color-info);
+  border-color: var(--color-info);
+}
+
+// Docsy Homepage Components
+.td-cover-block {
+  background-color: var(--color-primary) !important;
+  
+  h1, h2, h3, h4, h5, h6, p {
+    color: var(--color-primary-contrast) !important;
+  }
+}
+
+// Lead blocks with primary color background
+.td-block--primary,
+section[class*="bg-primary"],
+section[class*="color-primary"] {
+  background-color: var(--color-primary) !important;
+  
+  * {
+    color: #FFFFFF !important;
+  }
+  
+  h1, h2, h3, h4, h5, h6, p, a, .lead {
+    color: #FFFFFF !important;
+    text-shadow: 0 1px 3px rgba(0, 0, 0, 0.3);
+  }
+  
+  // Prevent white background on hover
+  &:hover,
+  *:hover {
+    background-color: transparent !important;
+    color: #FFFFFF !important;
+  }
+  
+  a:hover {
+    color: #FFFFFF !important;
+    text-decoration: underline;
+  }
+}
+
+.td-box {
+  background-color: var(--color-card);
+  border: 1px solid var(--nav-border-color);
+  
+  &:hover {
+    background-color: var(--color-hover);
+    border-color: var(--color-primary);
+  }
+  
+  &--primary {
+    background-color: var(--color-primary);
+    border-color: var(--color-primary);
+    color: var(--color-primary-contrast);
+  }
+  
+  &--secondary {
+    background-color: var(--color-secondary);
+    border-color: var(--color-secondary);
+  }
+}
+
+// Hero/Cover sections
+.td-cover {
+  background: linear-gradient(135deg, var(--color-primary) 0%, var(--color-primary-dark-2) 100%);
+  
+  .display-1, .display-2, .display-3, .display-4 {
+    color: var(--color-primary-contrast) !important;
+  }
+}
+
+// Section backgrounds
+.td-section {
+  &--primary {
+    background-color: var(--color-primary-light-6);
+  }
+  
+  &--secondary {
+    background-color: var(--color-secondary-light);
+  }
+}
+
+// Feature boxes
+.td-feature {
+  border: 1px solid var(--nav-border-color);
+  background-color: var(--color-card);
+  
+  &:hover {
+    border-color: var(--color-primary);
+    box-shadow: 0 4px 12px var(--color-shadow);
+  }
+}
+
+// Feature blocks on homepage (blocks/feature)
+.td-box--dark,
+.td-box--colored,
+section[class*="bg-dark"] .td-box,
+section[class*="color-dark"] .td-box {
+  .h2, .h3, .h4, .h5, h2, h3, h4, h5, p, a {
+    color: #FFFFFF !important;
+  }
+  
+  &:hover {
+    background-color: rgba(0, 0, 0, 0.8) !important;
+    
+    .h2, .h3, .h4, .h5, h2, h3, h4, h5, p, a {
+      color: #FFFFFF !important;
+    }
+  }
+}
+
+// Ensure text stays visible in dark sections
+section[class*="bg-dark"],
+section[class*="color-dark"] {
+  * {
+    color: #FFFFFF !important;
+  }
+  
+  .td-box, .card {
+    &:hover {
+      background-color: rgba(0, 0, 0, 0.8) !important;
+      
+      * {
+        color: #FFFFFF !important;
+      }
+    }
+  }
+}
 

content/en/_index.md

@@ -3,5 +3,84 @@ title: IPCEI-CIS Developer Framework
 ---
 
 {{< blocks/cover title="IPCEI-CIS Developer Framework" image_anchor="top" height="full" >}}
-
+<p class="lead mt-5">
+A comprehensive enterprise development platform enabling teams to build, deploy, and operate cloud-native applications with ease.
+</p>
+{{< blocks/link-down color="info" >}}
 {{< /blocks/cover >}}
+
+{{% blocks/lead color="primary" %}}
+The IPCEI-CIS Developer Framework provides everything you need to deliver modern applications at scale.
+Built on open standards and battle-tested technologies.
+{{% /blocks/lead %}}
+
+{{% blocks/section color="dark" type="row" %}}
+
+{{% blocks/feature icon="fa-solid fa-diagram-project" title="Edge Developer Platform (EDP)" url="/docs/edp/" %}}
+Understand EDP as the developer platform hub (Forgejo, CI/CD, deployment, operations) and how it connects inner loop and outer loop workflows.
+
+**Dive into EDP docs →**
+{{% /blocks/feature %}}
+
+{{% blocks/feature icon="fa-solid fa-cloud" title="EdgeConnect Cloud" url="/docs/edgeconnect/" %}}
+Learn what EdgeConnect is, how it is consumed via stable entry points (CLI, SDK, Terraform), and how EDP integrates with it as a deployment target.
+
+**Explore EdgeConnect →**
+{{% /blocks/feature %}}
+
+{{% blocks/feature icon="fa-solid fa-scale-balanced" title="Governance" url="/docs/governance/" %}}
+Read the project history, decision context, and audit-oriented traceability to primary sources and repository artifacts.
+
+**Go to Governance →**
+{{% /blocks/feature %}}
+
+{{% /blocks/section %}}
+
+{{% blocks/section color="white" %}}
+
+## What's in the Platform?
+
+<div class="row">
+<div class="col-lg-4 mb-4">
+
+### 🚀 Developer Experience
+
+* **Backstage Portal** - Self-service platform
+* **GitOps Workflows** - Automated deployments
+* **Golden Paths** - Best practices built-in
+
+</div>
+<div class="col-lg-4 mb-4">
+
+### 🛠️ Infrastructure as Code
+
+* **Crossplane** - Cloud resource provisioning
+* **ArgoCD** - Declarative GitOps
+* **Terraform** - Infrastructure automation
+
+</div>
+<div class="col-lg-4 mb-4">
+
+### 📊 Observability
+
+* **Prometheus & Grafana** - Metrics & dashboards
+* **Loki** - Log aggregation
+* **OpenTelemetry** - Distributed tracing
+
+</div>
+</div>
+
+{{% /blocks/section %}}
+
+{{% blocks/section color="light" %}}
+
+## Get Started
+
+Whether you're a **platform engineer**, **application developer**, or **auditor**, we have resources for you:
+
+* 📖 Start at [Documentation](/docs/)
+* 🧭 Read [Edge Developer Platform (EDP)](/docs/edp/)
+* ☁️ Read [EdgeConnect Cloud](/docs/edgeconnect/)
+* 🧾 Read [Governance](/docs/governance/)
+
+{{% /blocks/section %}}

content/en/blog/240823-archsession.md

@@ -1,40 +0,0 @@
----
-title: Architecture session
-weight: 20
----
-
-
-## Platform Generics
-
-* https://tag-app-delivery.cncf.io/whitepapers/platforms/#capabilities-of-platforms
-
-* https://tag-app-delivery.cncf.io/whitepapers/platform-eng-maturity-model/
-
-* https://humanitec.com/blog/wtf-internal-developer-platform-vs-internal-developer-portal-vs-paas
-
-## reference architecture + Portfolio
-
-* https://platformengineering.org/blog/create-your-own-platform-engineering-reference-architectures
-
-* https://humanitec.com/reference-architectures
-
-* https://www.youtube.com/watch?v=AimSwK8Mw-U
-
-
-## Platform Portfolio
-
-### Viktor Farcic
-
-* https://technologyconversations.com/
-
-* https://technologyconversations.com/2024/01/08/the-best-devops-tools-platforms-and-services-in-2024/
-
-
-### Internal devloper platform
-
-* https://internaldeveloperplatform.org/core-components/
-
-### Workflow / CI/CD
-
-* https://cnoe.io/blog/optimizing-data-quality-in-dev-portals
-

content/en/docs-old/_index.md

@@ -0,0 +1,23 @@
+---
+title: Legacy Documentation
+linkTitle: Docs (Old)
+menu:
+  main:
+    weight: 50
+weight: 50
+cascade:
+  - type: docs
+---
+
+# Legacy Documentation
+
+This section contains the previous version of the documentation for reference purposes.
+
+**Note**: This documentation is archived and may be outdated. Please refer to the main [Documentation](../docs/) section for current information.
+
+## Available Sections
+
+* [Architecture](architecture/) - System architecture and diagrams
+* [Documentation](documentation/) - Meta documentation about the documentation system
+* [Platform Overview](platform-overview/) - Overview document
+* [v1 (Legacy)](v1/) - Original v1 documentation

content/en/docs-old/architecture/_index.md

@@ -0,0 +1,9 @@
+---
+title: "Architecture"
+linkTitle: "Architecture"
+weight: 3
+description: >
+  System architecture documentation and interactive diagrams
+---
+
+This section contains architecture documentation for the IPCEI-CIS Developer Framework, including interactive C4 architecture diagrams.

content/en/docs-old/architecture/highlevelarch.md

@@ -0,0 +1,79 @@
+---
+title: "High Level Architecture"
+linkTitle: "High Level Architecture"
+weight: 1
+description: >
+  Interactive high-level architecture overview of the Enterprise Development Platform
+---
+
+This document describes the high-level architecture of our Enterprise Development Platform (EDP) system.
+
+## Interactive Architecture Diagram
+
+{{< likec4-view view="otc-faas" project="architecture" title="Enterprise Development Platform - OTC FaaS Deployment Architecture" >}}
+
+{{< alert title="Interactive Diagram" >}}
+The diagram above is interactive when viewed in a compatible browser.
+You can click on components to explore the architecture details.
+
+**Note:** The interactive diagram requires the LikeC4 webcomponent to be generated.
+See the [setup instructions]({{< ref "/docs-old/architecture/setup" >}}) for details.
+{{< /alert >}}
+
+## Architecture Overview
+
+The Enterprise Development Platform consists of several key components working together to provide a comprehensive development and deployment environment.
+
+### Key Components
+
+1. **OTC Foundry** - Central management and orchestration layer
+2. **Per-Tenant EDP** - Isolated development environments for each tenant
+3. **FaaS Environment** - Function-as-a-Service deployment targets on Open Telekom Cloud
+4. **Cloud Services** - Managed services including databases, storage, and monitoring
+
+### Deployment Environments
+
+- **Development Environment** (`*.t09.de`) - For platform team development and testing
+- **Production Environment** (`*.buildth.ing`) - For production workloads and tenant services
+
+## Component Details
+
+The interactive diagram above shows the relationships between different components and how they interact within the system architecture. You can explore the diagram by clicking on different elements to see more details.
+
+### Infrastructure Components
+
+- **Kubernetes Clusters** - Container orchestration using OTC CCE (Cloud Container Engine)
+- **ArgoCD** - GitOps continuous deployment and application lifecycle management
+- **Forgejo** - Git repository management and CI/CD pipelines
+- **Observability Stack** - Monitoring (Prometheus, Grafana), logging (Loki), and alerting
+
+### Security and Management
+
+- **Keycloak** - Identity and access management (IAM)
+- **OpenBao** - Secrets management (Hashicorp Vault fork)
+- **External Secrets Operator** - Kubernetes secrets integration
+- **Crossplane** - Infrastructure as Code and cloud resource provisioning
+
+### Developer Experience
+
+- **Backstage** - Internal developer portal and service catalog
+- **Forgejo Actions** - CI/CD pipeline execution
+- **Development Workflows** - GitOps-based inner and outer loop workflows
+
+## Setup and Maintenance
+
+To update or modify the architecture diagrams:
+
+1. Edit the `.c4` files in `resources/edp-likec4/`
+2. Regenerate the webcomponent:
+
+   ```bash
+   cd resources/edp-likec4
+   npx likec4 codegen webcomponent \
+     --webcomponent-prefix likec4 \
+     --outfile ../../static/js/likec4-webcomponent.js
+   ```
+
+3. Commit both the model changes and the regenerated JavaScript file
+
+For more information, see the [LikeC4 Integration Guide]({{< ref "/docs-old/architecture/setup" >}}).

content/en/docs-old/architecture/setup.md

@@ -0,0 +1,297 @@
+---
+title: "LikeC4 Setup Guide"
+linkTitle: "Setup"
+weight: 10
+description: >
+  How to set up and use LikeC4 interactive architecture diagrams
+---
+
+This guide explains how to set up and use LikeC4 interactive architecture diagrams in this documentation.
+
+## Overview
+
+LikeC4 enables you to create interactive C4 architecture diagrams as code. The diagrams are defined in `.c4` files and compiled into a web component that can be embedded in any HTML page.
+
+## Prerequisites
+
+- Node.js (v18 or later)
+- npm or yarn
+
+## Initial Setup
+
+### 1. Install Dependencies
+
+Navigate to the LikeC4 directory and install dependencies:
+
+```bash
+cd resources/edp-likec4
+npm install
+```
+
+### 2. Generate the Web Component
+
+Create the web component that Hugo will load:
+
+```bash
+npx likec4 codegen webcomponent \
+  --webcomponent-prefix likec4 \
+  --outfile ../../static/js/likec4-webcomponent.js
+```
+
+This command:
+
+- Reads all `.c4` files from `models/` and `views/`
+- Generates a single JavaScript file with all architecture views
+- Outputs to `static/js/likec4-webcomponent.js`
+
+### 3. Verify Integration
+
+The integration should already be configured in:
+
+- `hugo.toml` - Contains `params.likec4.enable = true`
+- `layouts/partials/hooks/head-end.html` - Loads CSS and loader script
+- `static/css/likec4-styles.css` - Diagram styling
+- `static/js/likec4-loader.js` - Dynamic module loader
+
+## Directory Structure
+
+```plaintext
+resources/edp-likec4/
+├── models/          # C4 model definitions
+│   ├── components/  # Component models
+│   ├── containers/  # Container models
+│   ├── context/     # System context
+│   └── code/        # Code-level workflows
+├── views/           # View definitions
+│   ├── deployment/  # Deployment views
+│   ├── edp/         # EDP views
+│   ├── high-level-concept/  # Conceptual views
+│   └── dynamic/     # Process flows
+├── package.json     # Dependencies
+└── INTEGRATION.md   # Integration docs
+```
+
+## Using in Documentation
+
+### Basic Usage
+
+Add this to any Markdown file:
+
+```html
+<div class="likec4-container">
+    <div class="likec4-header">
+        Your Diagram Title
+    </div>
+    <likec4-view view-id="YOUR-VIEW-ID" browser="true"></likec4-view>
+    <div class="likec4-loading" id="likec4-loading">
+        Loading architecture diagram...
+    </div>
+</div>
+```
+
+### Available View IDs
+
+To find available view IDs, search the `.c4` files:
+
+```bash
+cd resources/edp-likec4
+grep -r "view\s\+\w" views/ models/ --include="*.c4"
+```
+
+Common views:
+
+- `otc-faas` - OTC FaaS deployment
+- `edp` - EDP overview
+- `landscape` - Developer landscape
+- `edpbuilderworkflow` - Builder workflow
+- `keycloak` - Keycloak component
+
+### With Hugo Alert
+
+Combine with Docsy alerts for better UX:
+
+```markdown
+<div class="likec4-container">
+    <div class="likec4-header">
+        System Architecture
+    </div>
+    <likec4-view view-id="otc-faas" browser="true"></likec4-view>
+    <div class="likec4-loading" id="likec4-loading">
+        Loading...
+    </div>
+</div>
+
+{{</* alert title="Note" */>}}
+Click on components in the diagram to explore the architecture.
+{{</* /alert */>}}
+```
+
+## Workflow for Changes
+
+### 1. Modify Architecture Models
+
+Edit the `.c4` files in `resources/edp-likec4/`:
+
+```bash
+# Edit a model
+vi resources/edp-likec4/models/containers/argocd.c4
+
+# Or edit a view
+vi resources/edp-likec4/views/deployment/otc/otc-faas.c4
+```
+
+### 2. Preview Changes Locally
+
+Use the LikeC4 CLI to preview:
+
+```bash
+cd resources/edp-likec4
+
+# Start preview server
+npx likec4 start
+
+# Opens browser at http://localhost:5173
+```
+
+### 3. Regenerate Web Component
+
+After making changes:
+
+```bash
+cd resources/edp-likec4
+npx likec4 codegen webcomponent \
+  --webcomponent-prefix likec4 \
+  --outfile ../../static/js/likec4-webcomponent.js
+```
+
+### 4. Test in Hugo
+
+Start the Hugo development server:
+
+```bash
+# From repository root
+hugo server -D
+
+# Open http://localhost:1313
+```
+
+### 5. Commit Changes
+
+Commit both the model files and the regenerated web component:
+
+```bash
+git add resources/edp-likec4/
+git add static/js/likec4-webcomponent.js
+git commit -m "feat: update architecture diagrams"
+```
+
+## Advanced Configuration
+
+### Custom Styling
+
+Modify `static/css/likec4-styles.css` to customize appearance:
+
+```css
+.likec4-container {
+    height: 800px;  /* Adjust height */
+    border-radius: 8px;  /* Rounder corners */
+}
+```
+
+### Multiple Diagrams Per Page
+
+You can include multiple diagrams on a single page:
+
+```html
+<!-- First diagram -->
+<div class="likec4-container">
+    <div class="likec4-header">Deployment View</div>
+    <likec4-view view-id="otc-faas" browser="true"></likec4-view>
+    <div class="likec4-loading">Loading...</div>
+</div>
+
+<!-- Second diagram -->
+<div class="likec4-container">
+    <div class="likec4-header">Component View</div>
+    <likec4-view view-id="edp" browser="true"></likec4-view>
+    <div class="likec4-loading">Loading...</div>
+</div>
+```
+
+### Disable for Specific Pages
+
+Add to page front matter:
+
+```yaml
+---
+title: "My Page"
+params:
+  disable_likec4: true
+---
+```
+
+Then update `layouts/partials/hooks/head-end.html`:
+
+```html
+{{ if and .Site.Params.likec4.enable (not .Params.disable_likec4) }}
+<!-- LikeC4 scripts -->
+{{ end }}
+```
+
+## Troubleshooting
+
+### Diagram Not Loading
+
+1. **Check browser console** (F12 → Console)
+2. **Verify webcomponent exists:**
+
+   ```bash
+   ls -lh static/js/likec4-webcomponent.js
+   ```
+
+3. **Regenerate if missing:**
+
+   ```bash
+   cd resources/edp-likec4
+   npm install
+   npx likec4 codegen webcomponent \
+     --webcomponent-prefix likec4 \
+     --outfile ../../static/js/likec4-webcomponent.js
+   ```
+
+### View Not Found
+
+- Check view ID matches exactly (case-sensitive)
+- Search for the view in `.c4` files:
+
+  ```bash
+  grep -r "view otc-faas" resources/edp-likec4/
+  ```
+
+### Styling Issues
+
+- Clear browser cache (Ctrl+Shift+R)
+- Check `static/css/likec4-styles.css` is loaded in browser DevTools → Network
+
+### Build Errors
+
+If LikeC4 codegen fails:
+
+```bash
+cd resources/edp-likec4
+rm -rf node_modules package-lock.json
+npm install
+```
+
+## Resources
+
+- [LikeC4 Documentation](https://likec4.dev/)
+- [C4 Model](https://c4model.com/)
+- [Web Components](https://developer.mozilla.org/en-US/docs/Web/Web_Components)
+- [Hugo Documentation](https://gohugo.io/documentation/)
+
+## Migration Notes
+
+This LikeC4 integration was migrated from the edp-doc repository. This repository (`ipceicis-developerframework`) is now the primary source for architecture models.
+
+The edp-doc repository can reference these models via git submodule if needed.

content/en/docs-old/decisions/0001-pipeline-tools.md

@@ -0,0 +1,126 @@
+# CI/CD pipeline tools for composable pipeline
+
+## Context and Problem Statement
+
+In order to build a composable pipeline that provides a golden path and reusable components, we need to define the tools that will be used to execute the pipeline.
+
+ArgoCD is considered set in stone as the tool to manage the deployment of applications. However, the tools to compose and execute the pipeline are still up for debate.
+
+> Note: The pipeline will use many other tools to perform certain actions such as testing, building, and deploying. This ADR is focused on the tools that will be used to compose and execute the pipeline itself.
+
+In general, there are 2 decisions to make:
+
+* What tools should we use to execute the pipeline?
+* What tools should we use to compose the pipeline?
+
+The following use-cases should be considered for this decision:
+
+* **User who wants to manage their own runners (???)**
+* User who only wants to use our golden path
+* User who wants to use our golden path and add custom actions
+* User who wants to use their own templates and import some of our actions
+* User who wants to import an existing GitHub repository with a pipeline
+
+## Considered Options
+
+* Argo Workflows + Events
+* Argo Workflows + Events + Additional Composition tool
+* Forgejo Actions
+* Forgejo Actions + Additional Composition tool
+* Dagger (as Engine)
+* Shuttle (as Engine)
+
+## Decision Outcome
+
+TBD
+
+## Pros and Cons of the Options
+
+### Argo Workflows + Events
+
+#### Pro
+
+* integration with ArgoCD
+* ability to trigger additional workflows based on events.
+* level of maturity and community support.
+
+#### Con
+
+* Ability to self-host runners?
+* way how composition for pipelines works (based on Kubernetes CRDs)
+  * Templates must be available in the cluster where the pipelines are executed, so any imported templates must be applied into the cluster before the pipeline can be executed and cannot simply reference a repository
+  * This makes it difficult to import existing templates from other repositories when using self-hosted runners
+  * This also makes it difficult to use our golden path, or at least we will need to provide a way to import our golden path into the cluster
+  * This also makes the split of every component has its own repo very difficult
+* additional UI to manage the pipeline
+* Additional complexity
+
+### Argo Workflows + Events + Additional Composition tool
+
+#### Pro
+
+* Composability can be offloaded to another tool
+
+#### Con
+
+* All cons of the previous option (except composability)
+* Additional complexity by adding another tool
+
+### Forgejo Actions
+
+#### Pro
+
+* tight integration with GitHub Actions providing a familiar interface for developers and a vast catalog of actions to choose from
+* ability to compose pipelines without relying on another tool
+* Self-hosting of runners possible
+* every component can have its own repository and use different tools (e.g. written in go, bash, python etc.)
+
+#### Con
+
+* level of maturity - will require additional investments to provide a production-grade system
+
+### Forgejo Actions + Additional Tool
+
+#### Pro
+
+* may be possible to use GitHub actions alongside another tool
+
+#### Con
+
+* additional complexity by adding another tool
+
+### Shuttle
+
+#### Pro
+
+* Possibility to clearly define interfaces for pipeline steps
+* Relatively simple
+
+#### Con
+
+* basically backed by only one company
+* **centralized templates**, so no mechanism for composing pipelines from multiple repositories
+
+### Dagger
+
+#### Pro
+
+* Pipeline as code
+  * if it runs it should run anywhere and produce the "same" / somewhat stable results
+  * build environments are defined within containers / the dagger config. Dagger is the only dependency one has to install on a machine
+* DX is extremely nice, especially if you have to debug (image) builds, also type safety due to the ability to code your build in a strong language
+* additional tooling, like trivy, is added to a build pipeline with low effort due to containers and existing plugin/wrappers
+* you can create complex test environments similar to test containers and docker compose
+
+#### Con
+
+* relies heavily containers, which might not be available some environments (due to policy etc), it also has an effect on reproducibility and verifiability
+* as a dev you need to properly understand containers
+* dagger engine has to run privileged locally and/or in the cloud which might be a blocker or at least a big pain in the ...
+
+#### Suggestion Patrick
+
+* dagger is a heavy weight and might not be as productive in a dev workflow as it seems (setup lsp etc)
+* it might be too opinionated to force on teams, especially since it is not near mainstream enough, community might be too small
+* it feels like dagger gets you 95% of the way, but the remaining 5% are a real struggle
+* if we like it, we should check the popularity in the dev community before further considering as it has a direct impact on teams and their preferences

content/en/docs-old/decisions/README.md

@@ -0,0 +1,5 @@
+# ADRs
+
+Architecture Decision Records (ADRs) are a way to capture the important architectural decisions made during the development of a project. They are a way to document the context, the decision, and the consequences of the decision. They are a way to keep track of the architectural decisions made in a project and to communicate them to the team.
+
+The [Markdown Architectural Decision Records](https://adr.github.io/madr/) (MADR) format is a simple and easy-to-use format for writing ADRs in Markdown.

content/en/docs-old/decisions/_adr-template.md

@@ -0,0 +1,67 @@
+<!-- we need to disable MD025, because we use the different heading "ADR Template" in the homepage (see above) than it is foreseen in the template -->
+<!-- markdownlint-disable-next-line MD025 -->
+# {short title, representative of solved problem and found solution}
+
+## Context and Problem Statement
+
+{Describe the context and problem statement, e.g., in free form using two to three sentences or in the form of an illustrative story. You may want to articulate the problem in form of a question and add links to collaboration boards or issue management systems.}
+
+<!-- This is an optional element. Feel free to remove. -->
+## Decision Drivers
+
+* {decision driver 1, e.g., a force, facing concern, …}
+* {decision driver 2, e.g., a force, facing concern, …}
+* … <!-- numbers of drivers can vary -->
+
+## Considered Options
+
+* {title of option 1}
+* {title of option 2}
+* {title of option 3}
+* … <!-- numbers of options can vary -->
+
+## Decision Outcome
+
+Chosen option: "{title of option 1}", because {justification. e.g., only option, which meets k.o. criterion decision driver | which resolves force {force} | … | comes out best (see below)}.
+
+<!-- This is an optional element. Feel free to remove. -->
+### Consequences
+
+* Good, because {positive consequence, e.g., improvement of one or more desired qualities, …}
+* Bad, because {negative consequence, e.g., compromising one or more desired qualities, …}
+* … <!-- numbers of consequences can vary -->
+
+<!-- This is an optional element. Feel free to remove. -->
+### Confirmation
+
+{Describe how the implementation of/compliance with the ADR can/will be confirmed. Are the design that was decided for and its implementation in line with the decision made? E.g., a design/code review or a test with a library such as ArchUnit can help validate this. Not that although we classify this element as optional, it is included in many ADRs.}
+
+<!-- This is an optional element. Feel free to remove. -->
+## Pros and Cons of the Options
+
+### {title of option 1}
+
+<!-- This is an optional element. Feel free to remove. -->
+{example | description | pointer to more information | …}
+
+* Good, because {argument a}
+* Good, because {argument b}
+<!-- use "neutral" if the given argument weights neither for good nor bad -->
+* Neutral, because {argument c}
+* Bad, because {argument d}
+* … <!-- numbers of pros and cons can vary -->
+
+### {title of other option}
+
+{example | description | pointer to more information | …}
+
+* Good, because {argument a}
+* Good, because {argument b}
+* Neutral, because {argument c}
+* Bad, because {argument d}
+* …
+
+<!-- This is an optional element. Feel free to remove. -->
+## More Information
+
+{You might want to provide additional evidence/confidence for the decision outcome here and/or document the team agreement on the decision and/or define when/how this decision the decision should be realized and if/when it should be re-visited. Links to other decisions and resources might appear here as well.}

content/en/docs-old/documentation/_index.md

@@ -0,0 +1,43 @@
+---
+title: "Documentation About Documentation"
+linkTitle: "Documentation"
+weight: 10
+description: >
+  Learn how to create, maintain, and publish documentation for the developer platform.
+---
+
+Welcome to the meta-documentation! This section explains how our documentation platform works and guides you through the technicalWriter role.
+
+## What is a Technical Writer?
+
+A **Technical Writer** is responsible for creating, maintaining, and publishing the developer platform documentation. This includes:
+
+- Writing and updating content in Markdown
+- Creating architecture diagrams with LikeC4
+- Testing locally before committing
+- Following the CI/CD pipeline to production
+
+## Documentation Platform Architecture
+
+Our documentation is built on a modern stack:
+
+- **Hugo** with the **Docsy** theme for static site generation
+- **LikeC4** for architecture visualization
+- **Taskfile** for local development automation
+- **GitHub Actions** for continuous testing
+- **Edge deployment** for hosting
+
+### System Overview
+
+{{< likec4-view view="overview" project="documentation-platform" >}}
+
+This high-level view shows all major components of the documentation platform.
+
+## Getting Started
+
+Continue to the next sections to learn about:
+
+1. [Local Development](local-development/) - How to work on documentation locally
+2. [Testing](testing/) - Quality assurance processes
+3. [CI/CD Pipeline](cicd/) - Automated testing and deployment
+4. [Publishing](publishing/) - How documentation reaches production

content/en/docs-old/documentation/cicd.md

@@ -0,0 +1,264 @@
+---
+title: "CI/CD Pipeline"
+linkTitle: "CI/CD"
+weight: 40
+description: >
+  Automated testing and container build process.
+---
+
+## Overview
+
+Our documentation uses a continuous integration and deployment pipeline to ensure quality and automate deployment.
+
+{{< likec4-view view="cicdPipeline" project="documentation-platform" >}}
+
+## GitHub Actions Workflow
+
+The CI/CD pipeline is defined in `.github/workflows/test.yml` and runs on:
+
+- **Pushes to `main` branch**
+- **Pull requests to `main` branch**
+
+### Workflow Steps
+
+#### 1. Checkout Code
+
+```yaml
+- uses: actions/checkout@v4
+  with:
+    submodules: recursive
+    fetch-depth: 0
+```
+
+- Clones repository with full history
+- Includes Git submodules (Hugo modules)
+
+#### 2. Setup Hugo
+
+```yaml
+- name: Setup Hugo
+  uses: peaceiris/actions-hugo@v3
+  with:
+    hugo-version: 'latest'
+    extended: true
+```
+
+- Installs Hugo Extended
+- Uses latest stable version
+
+#### 3. Setup Node.js
+
+```yaml
+- name: Setup Node
+  uses: actions/setup-node@v4
+  with:
+    node-version: '24'
+    cache: 'npm'
+```
+
+- Installs Node.js v24
+- Caches npm dependencies for faster builds
+
+#### 4. Install Dependencies
+
+```bash
+npm ci
+go install github.com/wjdp/htmltest@latest
+```
+
+- Installs npm packages (markdownlint, htmlvalidate)
+- Installs htmltest for link checking
+
+#### 5. Run Tests
+
+```bash
+npm run test:build
+npm run test:markdown
+npm run test:html
+```
+
+- Validates Hugo build
+- Lints Markdown files
+- Validates HTML output
+
+#### 6. Link Checking
+
+```yaml
+- name: Run link checker
+  run: htmltest
+  continue-on-error: true
+```
+
+- Checks all links
+- Continues even if links fail (soft requirement)
+
+#### 7. Upload Results
+
+```yaml
+- name: Upload htmltest results
+  uses: actions/upload-artifact@v4
+  if: always()
+  with:
+    name: htmltest-report
+    path: tmp/.htmltest/
+```
+
+- Uploads link check report
+- Available for download from GitHub Actions
+
+## Container Build Process
+
+After tests pass, a container image is built:
+
+```bash
+task build:oci-image
+```
+
+### Build Process
+
+1. **Reads version information** from `.env.versions`:
+   - `NODE_VERSION`
+   - `GO_VERSION`
+   - `HUGO_VERSION`
+
+2. **Builds Docker image** using `Dockerfile`:
+   - Multi-stage build
+   - Hugo generates static site
+   - Nginx serves the content
+
+3. **Tags image** with:
+   - `latest`
+   - Git commit SHA (short)
+
+### Dockerfile Structure
+
+```dockerfile
+# Build stage
+FROM node:${NODE_VERSION} as builder
+# Install Hugo, build dependencies
+# Run: hugo --gc --minify
+# Output: public/ directory
+
+# Runtime stage
+FROM nginx:alpine
+# Copy public/ to /usr/share/nginx/html/
+# Configure Nginx
+```
+
+### Testing the Container
+
+```bash
+task test:oci-image
+```
+
+This:
+
+1. Builds the image
+2. Starts container on port 8080
+3. Tests HTTP endpoint
+4. Cleans up container
+
+## Package.json Scripts
+
+The `package.json` defines test scripts:
+
+```json
+{
+  "scripts": {
+    "test:build": "hugo --gc --minify --logLevel info",
+    "test:markdown": "markdownlint 'content/**/*.md'",
+    "test:html": "htmlvalidate 'public/**/*.html'"
+  }
+}
+```
+
+## Running CI Locally
+
+Simulate the CI environment locally:
+
+```bash
+task ci
+```
+
+This runs the same tests as GitHub Actions.
+
+## Monitoring CI Results
+
+### Successful Build
+
+✅ All tests pass → Ready to deploy
+
+### Failed Build
+
+❌ Tests fail:
+
+1. Click on the failed workflow in GitHub Actions
+2. Expand the failed step
+3. Read the error message
+4. Fix locally: `task test:<specific-test>`
+5. Commit and push fix
+
+### Viewing Artifacts
+
+1. Go to GitHub Actions
+2. Click on workflow run
+3. Scroll to "Artifacts" section
+4. Download `htmltest-report`
+
+## Best Practices
+
+1. **Don't push to main directly** - Use feature branches and PRs
+2. **Wait for CI before merging** - Green checkmark required
+3. **Fix broken builds immediately** - Don't let main stay red
+4. **Review CI logs** - Understand why tests fail
+5. **Update dependencies** - Keep versions current in `.env.versions`
+
+## Continuous Deployment
+
+After successful CI:
+
+1. Container image is built
+2. Image is pushed to registry
+3. Deployment process begins (see [Publishing](../publishing/))
+
+## Troubleshooting
+
+### Tests pass locally but fail in CI
+
+**Possible causes:**
+
+- Different Hugo version
+- Different Node.js version
+- Missing dependencies
+- Environment-specific issues
+
+**Solution:** Check versions in `.env.versions` and ensure local matches CI
+
+### Build timeouts
+
+**Possible causes:**
+
+- Link checker taking too long
+- Large number of external links
+
+**Solution:**
+
+- Use `continue-on-error: true` for link checks
+- Configure `.htmltest.yml` to skip slow checks
+
+### Cache issues
+
+**Solution:** Clear GitHub Actions cache:
+
+```yaml
+- uses: actions/cache@v4
+  with:
+    path: ~/.npm
+    key: ${{ runner.os }}-node-${{ hashFiles('**/package-lock.json') }}
+```
+
+Update the cache key to force refresh.
+
+## Next Steps
+
+Learn about [deployment to Edge environment](../publishing/).

content/en/docs-old/documentation/local-development.md

@@ -0,0 +1,234 @@
+---
+title: "Local Development"
+linkTitle: "Local Development"
+weight: 20
+description: >
+  Set up your local environment and learn the technicalWriter workflow.
+---
+
+## Prerequisites
+
+Before you start, ensure you have:
+
+- **Devbox** or the following tools installed:
+  - Hugo Extended (latest version)
+  - Node.js (v24+)
+  - Go (for htmltest)
+  - Git
+
+## Installation
+
+1. Clone the repository:
+
+   ```bash
+   git clone <repository-url>
+   cd ipceicis-developerframework
+   ```
+
+2. Install dependencies:
+
+   ```bash
+   task deps:install
+   ```
+
+3. **If using Devbox**, enter the Devbox shell:
+
+   ```bash
+   devbox shell
+   ```
+   
+   This ensures all tools (Hugo, Node.js, Go) are available in the correct versions.
+
+## Local Development Workflow
+
+{{< likec4-view view="localDevelopment" project="documentation-platform" >}}
+
+### Starting the Development Server
+
+The easiest way to work locally is to start the Hugo development server:
+
+```bash
+task serve
+```
+
+This will:
+
+- Generate build information (git commit, version)
+- Start Hugo server on `http://localhost:1313`
+- Enable hot reload - changes appear instantly in the browser
+
+### Content Structure
+
+```text
+content/
+└── en/                      # English content
+    ├── _index.md           # Homepage
+    ├── blog/               # Blog posts
+    └── docs/               # Documentation
+        ├── architecture/   # Architecture docs
+        ├── decisions/      # ADRs
+        └── v1/            # Version-specific docs
+```
+
+### Creating Content
+
+1. **Add a new documentation page:**
+
+   ```bash
+   # Create a new markdown file
+   vim content/en/docs/your-topic/_index.md
+   ```
+
+2. **Add frontmatter:**
+
+   ```yaml
+   ---
+   title: "Your Topic"
+   linkTitle: "Your Topic"
+   weight: 10
+   description: >
+     Brief description of your topic.
+   ---
+   ```
+
+3. **Write your content** in Markdown
+
+4. **Preview changes** - they appear immediately if `task serve` is running
+
+### Creating Architecture Diagrams
+
+Architecture diagrams are created with LikeC4:
+
+1. **Navigate to the appropriate LikeC4 project:**
+   - `resources/edp-likec4/` - Platform architecture
+   - `resources/doc-likec4/` - Documentation platform architecture
+
+2. **Edit or create `.c4` files** with your model
+
+   Example: Create a simple view in `resources/edp-likec4/views/my-view.c4`:
+
+   ```likec4
+   specification {
+     element myperson
+     element mysystem
+   }
+   
+   model {
+     customer = myperson 'Customer' {
+       description 'End user of the platform'
+     }
+     
+     mySystem = mysystem 'My System' {
+       description 'Example system component'
+     }
+     
+     customer -> mySystem 'uses'
+   }
+   
+   views {
+     view myCustomView {
+       title "My Custom Architecture View"
+       
+       include customer
+       include mySystem
+       
+       autoLayout TopBottom
+     }
+   }
+   ```
+
+3. **Regenerate webcomponents:**
+
+   ```bash
+   task likec4:generate
+   ```
+
+4. **Embed diagrams in Markdown:**
+
+   ```markdown
+   {{</* likec4-view view="myCustomView" project="architecture" title="My Custom Architecture View" */>}}
+   ```
+
+   **Finding available view IDs:**
+   - Open the `.c4` files in your project directory
+   - Look for `view <viewId> {` declarations
+   - The `<viewId>` is what you use in the `view` parameter
+   - Or use: `grep -r "^view " resources/edp-likec4/ --include="*.c4"`
+
+## Available Tasks
+
+View all available tasks:
+
+```bash
+task --list
+```
+
+### Common Development Tasks
+
+| Task | Description |
+|------|-------------|
+| `task serve` | Start development server with hot reload |
+| `task build` | Build production-ready site |
+| `task build:dev` | Build development version |
+| `task clean` | Remove build artifacts |
+| `task test` | Run all tests |
+| `task test:quick` | Run tests without link checking |
+
+## Quick Testing
+
+Before committing, run quick tests:
+
+```bash
+task test:quick
+```
+
+This validates:
+
+- Hugo build succeeds
+- Markdown syntax is correct
+
+For comprehensive testing, including link checking:
+
+```bash
+task test
+```
+
+## Tips for Technical Writers
+
+1. **Write in present tense** - "The system processes..." not "The system will process..."
+2. **Use code blocks** with syntax highlighting
+3. **Include diagrams** for complex concepts
+4. **Test locally** before pushing
+5. **Keep it concise** - readers appreciate brevity
+6. **Update regularly** - stale docs are worse than no docs
+
+## Troubleshooting
+
+### Port 1313 already in use
+
+```bash
+# Find and kill the process
+lsof -ti:1313 | xargs kill -9
+```
+
+### Build errors
+
+```bash
+# Clean and rebuild
+task clean
+task build:dev
+```
+
+### Missing dependencies
+
+```bash
+# Reinstall all dependencies
+task deps:install
+```
+
+## Next Steps
+
+Now that you can develop locally, learn about:
+
+- [Testing processes](../testing/)
+- [CI/CD pipeline](../cicd/)

content/en/docs-old/documentation/publishing.md

@@ -0,0 +1,339 @@
+---
+title: "Publishing to Edge"
+linkTitle: "Publishing"
+weight: 50
+description: >
+  How documentation is deployed to the edge environment.
+---
+
+## Deployment Overview
+
+After successful CI/CD, the documentation is deployed to an edge computing environment.
+
+{{< likec4-view view="deploymentFlow" project="documentation-platform" >}}
+
+## Deployment Architecture
+
+### Edge Connect Platform
+
+Our documentation is deployed using **Edge Connect**, which orchestrates deployments to edge cloudlets.
+
+Configuration: `edgeconnectdeployment.yaml`
+
+```yaml
+kind: edgeconnect-deployment
+metadata:
+  name: "edpdoc"
+  appVersion: "1.0.0"
+  organization: "edp2"
+spec:
+  k8sApp:
+    manifestFile: "./k8s-deployment.yaml"
+  infraTemplate:
+    - region: "EU"
+      cloudletOrg: "TelekomOP"
+      cloudletName: "Munich"
+      flavorName: "EU.small"
+```
+
+**Key settings:**
+
+- **Deployment name:** `edpdoc`
+- **Region:** EU (Munich)
+- **Cloudlet:** TelekomOP Munich
+- **Flavor:** EU.small (resource allocation)
+
+### Kubernetes Deployment
+
+The application runs on Kubernetes: `k8s-deployment.yaml`
+
+#### Service Definition
+
+```yaml
+apiVersion: v1
+kind: Service
+metadata:
+  name: edpdoc
+  labels:
+    run: edpdoc
+spec:
+  type: LoadBalancer
+  ports:
+    - name: tcp80
+      protocol: TCP
+      port: 80
+      targetPort: 80
+  selector:
+    run: edpdoc
+```
+
+- **Type:** LoadBalancer (external access)
+- **Port:** 80 (HTTP)
+- **Selector:** Routes traffic to pods with label `run: edpdoc`
+
+#### Deployment Configuration
+
+```yaml
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+  name: edpdoc
+spec:
+  replicas: 1
+  selector:
+    matchLabels:
+      run: edpdoc
+  template:
+    metadata:
+      labels:
+        run: edpdoc
+        mexDeployGen: kubernetes-basic
+    spec:
+      containers:
+        - name: edpdoc
+          image: ###IMAGETAG###
+          imagePullPolicy: Always
+          ports:
+            - containerPort: 80
+              protocol: TCP
+```
+
+- **Replicas:** 1 (single instance)
+- **Image:** Injected by deployment pipeline (`###IMAGETAG###` placeholder)
+- **Pull policy:** Always (ensures latest version)
+
+### Network Configuration
+
+Outbound connections are configured in `edgeconnectdeployment.yaml`:
+
+```yaml
+network:
+  outboundConnections:
+    - protocol: "tcp"
+      portRangeMin: 80
+      portRangeMax: 80
+      remoteCIDR: "0.0.0.0/0"
+    - protocol: "tcp"
+      portRangeMin: 443
+      portRangeMax: 443
+      remoteCIDR: "0.0.0.0/0"
+```
+
+- **Port 80:** HTTP outbound
+- **Port 443:** HTTPS outbound
+- **CIDR:** `0.0.0.0/0` (all destinations)
+
+## Deployment Process
+
+### 1. Container Image Ready
+
+After CI passes:
+
+- Docker image built with `task build:oci-image`
+- Tagged with git commit SHA
+- Pushed to container registry
+
+### 2. Edge Connect Orchestration
+
+Edge Connect:
+
+1. Pulls container image
+2. Reads `edgeconnectdeployment.yaml`
+3. Provisions resources on Munich cloudlet
+4. Applies Kubernetes manifests
+
+### 3. Kubernetes Deployment
+
+Kubernetes:
+
+1. Creates deployment with 1 replica
+2. Pulls container image (`imagePullPolicy: Always`)
+3. Starts pod running Nginx + static Hugo site
+4. Creates LoadBalancer service
+5. Assigns external IP
+
+### 4. Service Available
+
+Documentation is now accessible:
+
+- **Protocol:** HTTP
+- **Port:** 80
+- **IP:** Assigned by LoadBalancer
+
+## Complete Workflow
+
+{{< likec4-view view="fullWorkflow" project="documentation-platform" >}}
+
+### End-to-End Process
+
+1. **Technical Writer writes content** (Markdown, LikeC4 models)
+2. **Local testing** with `task serve` and `task test`
+3. **Commit and push** to Git repository
+4. **GitHub Actions triggered** on push to main
+5. **CI tests run** (build, markdown, HTML, links)
+6. **Container image built** if tests pass
+7. **Image pushed** to registry
+8. **Edge deployment triggered**
+9. **Kubernetes applies** manifests
+10. **Service available** on edge cloudlet
+
+## Monitoring Deployment
+
+### Check Deployment Status
+
+```bash
+kubectl get deployments -n <namespace>
+kubectl get pods -n <namespace>
+kubectl get services -n <namespace>
+```
+
+### View Logs
+
+```bash
+kubectl logs deployment/edpdoc -n <namespace>
+```
+
+### Access Documentation
+
+Find the LoadBalancer external IP:
+
+```bash
+kubectl get service edpdoc -n <namespace>
+```
+
+Access via: `http://<EXTERNAL-IP>`
+
+## Rollback
+
+If issues occur after deployment:
+
+### Option 1: Revert Commit
+
+```bash
+git revert <bad-commit>
+git push origin main
+```
+
+CI will rebuild and redeploy.
+
+### Option 2: Manual Rollback
+
+```bash
+kubectl rollout undo deployment/edpdoc -n <namespace>
+```
+
+Returns to previous deployment version.
+
+### Option 3: Deploy Specific Version
+
+Update image tag in deployment:
+
+```bash
+kubectl set image deployment/edpdoc edpdoc=<registry>/<image>:<tag> -n <namespace>
+```
+
+## Scaling
+
+Currently: **1 replica**
+
+To scale for higher traffic:
+
+```yaml
+spec:
+  replicas: 3
+```
+
+Then apply:
+
+```bash
+kubectl apply -f k8s-deployment.yaml
+```
+
+Or scale dynamically:
+
+```bash
+kubectl scale deployment/edpdoc --replicas=3 -n <namespace>
+```
+
+## Security Considerations
+
+1. **Image scanning** - Scan container images for vulnerabilities
+2. **Resource limits** - Set CPU/memory limits in deployment
+3. **Network policies** - Restrict pod-to-pod communication
+4. **HTTPS** - Consider adding TLS termination (Ingress)
+
+## Performance Optimization
+
+1. **CDN** - Add CDN in front of LoadBalancer
+2. **Caching** - Configure Nginx caching headers
+3. **Compression** - Enable gzip in Nginx
+4. **Image optimization** - Compress images in documentation
+
+## Troubleshooting
+
+### Pod not starting
+
+```bash
+kubectl describe pod <pod-name> -n <namespace>
+```
+
+Check:
+
+- Image pull errors
+- Resource constraints
+- Configuration errors
+
+### Service unreachable
+
+```bash
+kubectl describe service edpdoc -n <namespace>
+```
+
+Check:
+
+- LoadBalancer IP assigned
+- Port configuration
+- Network policies
+
+### Old content served
+
+Check:
+
+- `imagePullPolicy: Always` in deployment
+- Image tag is updated
+- Pod has restarted
+
+Force pod restart:
+
+```bash
+kubectl rollout restart deployment/edpdoc -n <namespace>
+```
+
+## Best Practices
+
+1. **Test before deploying** - Always run `task test` locally
+2. **Use feature branches** - Don't deploy directly from local
+3. **Monitor after deployment** - Check logs and access
+4. **Document changes** - Update RELEASE.md
+5. **Version control** - Tag releases in Git
+
+## Future Enhancements
+
+Potential improvements:
+
+- **Blue-green deployment** - Zero-downtime updates
+- **Canary releases** - Gradual rollout to subset of users
+- **Auto-scaling** - HorizontalPodAutoscaler based on traffic
+- **Multi-region** - Deploy to multiple cloudlets
+- **HTTPS** - TLS certificates and Ingress controller
+
+## Summary
+
+The deployment process is automated and reliable:
+
+✅ **CI ensures quality** - Tests prevent broken deployments
+✅ **Edge infrastructure** - Low-latency access from EU
+✅ **Kubernetes orchestration** - Reliable, scalable platform
+✅ **Simple rollback** - Easy to recover from issues
+
+As a technicalWriter, focus on content quality. The platform handles deployment automatically! 🚀

content/en/docs-old/documentation/quick-reference.md

@@ -0,0 +1,282 @@
+---
+title: "Quick Reference"
+linkTitle: "Quick Reference"
+weight: 60
+description: >
+  Cheat sheet for common technicalWriter tasks.
+---
+
+## Common Commands
+
+### Local Development
+
+```bash
+# Start development server (with hot reload)
+task serve
+
+# Build for production
+task build
+
+# Build for development (faster, no minification)
+task build:dev
+
+# Clean build artifacts
+task clean
+```
+
+### Testing
+
+```bash
+# Quick tests (build + markdown)
+task test:quick
+
+# Full test suite
+task test
+
+# Individual tests
+task test:build      # Hugo build validation
+task test:markdown   # Markdown linting
+task test:html       # HTML validation
+task test:links      # Link checking
+```
+
+### Dependencies
+
+```bash
+# Install dependencies
+task deps:install
+
+# Update dependencies
+task deps:update
+
+# Ensure npm dependencies (auto-installs if missing)
+task deps:ensure-npm
+```
+
+### Container Operations
+
+```bash
+# Build OCI/Docker image
+task build:oci-image
+
+# Build and test container
+task test:oci-image
+```
+
+## File Locations
+
+### Content
+
+| Path | Description |
+|------|-------------|
+| `content/en/docs/` | Main documentation |
+| `content/en/blog/` | Blog posts |
+| `content/en/_index.md` | Homepage |
+
+### Architecture Models
+
+| Path | Description |
+|------|-------------|
+| `resources/edp-likec4/` | Platform architecture models |
+| `resources/doc-likec4/` | Documentation platform models |
+
+### Configuration
+
+| File | Purpose |
+|------|---------|
+| `hugo.toml` | Hugo configuration |
+| `config.yaml` | Docsy theme config |
+| `Taskfile.yml` | Task definitions |
+| `package.json` | npm dependencies and scripts |
+| `.markdownlint.json` | Markdown linting rules |
+| `.htmlvalidate.json` | HTML validation rules |
+| `.htmltest.yml` | Link checker config |
+
+### Build Output
+
+| Path | Description |
+|------|-------------|
+| `public/` | Generated static site |
+| `resources/_gen/` | Generated resources (Hugo) |
+| `data/build_info.json` | Build metadata (git commit, version) |
+
+## Markdown Frontmatter
+
+### Standard Page
+
+```yaml
+---
+title: "Page Title"
+linkTitle: "Short Title"
+weight: 10
+description: >
+  Brief description for SEO and navigation.
+---
+```
+
+### Blog Post
+
+```yaml
+---
+title: "Post Title"
+date: 2025-01-15
+author: "Your Name"
+description: >
+  Post summary.
+---
+```
+
+## Embedding Architecture Diagrams
+
+### Basic Embed
+
+```markdown
+{{< likec4-view view="view-name" project="project-name" >}}
+```
+
+### Parameters
+
+- `view` (required) - The view ID from your LikeC4 model
+- `project` (optional, default: "architecture") - The LikeC4 project name
+- `title` (optional, default: "Architecture View: {view}") - Custom header text above the diagram
+
+### Examples
+
+```markdown
+{{< likec4-view view="overview" project="documentation-platform" >}}
+{{< likec4-view view="localDevelopment" project="documentation-platform" >}}
+{{< likec4-view view="cicdPipeline" project="documentation-platform" >}}
+{{< likec4-view view="otc-faas" project="architecture" title="OTC FaaS Deployment" >}}
+```
+
+## LikeC4 Commands
+
+### Regenerate Webcomponents
+
+After modifying `.c4` files:
+
+```bash
+task likec4:generate
+```
+
+This regenerates both:
+
+- `static/js/likec4-webcomponent.js` (EDP architecture)
+- `static/js/likec4-doc-webcomponent.js` (Documentation platform)
+
+### Start Development Server
+
+```bash
+cd resources/doc-likec4  # or resources/edp-likec4
+npm install
+npm start
+```
+
+Opens LikeC4 IDE at `http://localhost:5173`
+
+### Export Diagrams
+
+```bash
+cd resources/doc-likec4
+npx likec4 export png -o ./images .
+```
+
+## Git Workflow
+
+### Feature Branch
+
+```bash
+# Create feature branch
+git checkout -b feature/your-feature
+
+# Make changes and test
+task serve
+task test:quick
+
+# Commit
+git add .
+git commit -m "Description of changes"
+
+# Push
+git push origin feature/your-feature
+
+# Create pull request on GitHub
+```
+
+### Update from Main
+
+```bash
+git checkout main
+git pull origin main
+git checkout feature/your-feature
+git rebase main
+```
+
+## Troubleshooting
+
+### Port 1313 in use
+
+```bash
+lsof -ti:1313 | xargs kill -9
+```
+
+### Build errors
+
+```bash
+task clean
+task build:dev
+```
+
+### Missing dependencies
+
+```bash
+task deps:install
+```
+
+### Hugo module issues
+
+```bash
+hugo mod clean
+hugo mod get -u
+hugo mod tidy
+```
+
+### LikeC4 language server
+
+In VS Code: `Ctrl+Shift+P` → "LikeC4: restart language server"
+
+## URLs
+
+### Local Development
+
+- **Documentation:** <http://localhost:1313>
+- **LikeC4 IDE:** <http://localhost:5173> (when running `npm start` in likec4 folder)
+
+### Production
+
+Check `edgeconnectdeployment.yaml` for deployment URL or run:
+
+```bash
+kubectl get service edpdoc -n <namespace>
+```
+
+## Quick Checks Before Committing
+
+1. ✅ `task test:quick` passes
+2. ✅ Preview looks correct in browser
+3. ✅ No broken links (visual check)
+4. ✅ Architecture diagrams render
+5. ✅ Frontmatter is correct
+
+## Getting Help
+
+- **Hugo docs:** <https://gohugo.io/documentation/>
+- **Docsy theme:** <https://www.docsy.dev/docs/>
+- **LikeC4:** <https://likec4.dev/>
+- **Task:** <https://taskfile.dev/>
+
+## View Documentation Architecture
+
+To understand how this documentation platform works:
+
+→ Start here: [Documentation About Documentation](../)

content/en/docs-old/documentation/testing.md

@@ -0,0 +1,229 @@
+---
+title: "Testing"
+linkTitle: "Testing"
+weight: 30
+description: >
+  Quality assurance processes for documentation.
+---
+
+## Testing Philosophy
+
+Quality documentation requires testing. Our testing process validates:
+
+- **Build integrity** - Hugo can generate the site
+- **Content quality** - Markdown follows best practices
+- **HTML validity** - Generated HTML is well-formed
+- **Link integrity** - No broken internal or external links
+
+## Testing Capabilities
+
+{{< likec4-view view="testingCapabilities" project="documentation-platform" >}}
+
+## Local Testing
+
+Before committing changes, run tests locally:
+
+### Quick Tests
+
+For rapid feedback during development:
+
+```bash
+task test:quick
+```
+
+This runs:
+
+- `task test:build` - Hugo build validation
+- `task test:markdown` - Markdown linting
+
+### Full Test Suite
+
+Before creating a pull request:
+
+```bash
+task test
+```
+
+This runs all tests including:
+
+- `task test:build` - Build validation
+- `task test:markdown` - Markdown linting
+- `task test:html` - HTML validation
+- `task test:links` - Link checking
+
+## Individual Tests
+
+You can run individual tests:
+
+### Build Test
+
+Validates that Hugo can build the site:
+
+```bash
+task test:build
+```
+
+This runs: `hugo --gc --minify --logLevel info`
+
+**What it checks:**
+
+- Hugo configuration is valid
+- Content files have correct frontmatter
+- Templates render without errors
+- No circular dependencies in content structure
+
+### Markdown Lint
+
+Checks Markdown syntax and style:
+
+```bash
+task test:markdown
+```
+
+This uses `markdownlint` with custom rules in `.markdownlint.json`.
+
+**What it checks:**
+
+- Consistent heading hierarchy
+- Proper list formatting
+- Code blocks have language tags
+- No trailing whitespace
+- Consistent line length (where applicable)
+
+**Common issues:**
+
+- Missing blank lines around code blocks
+- Inconsistent list markers
+- Heading levels skipped
+
+### HTML Validation
+
+Validates generated HTML:
+
+```bash
+task test:html
+```
+
+This uses `htmlvalidate` with rules in `.htmlvalidate.json`.
+
+**What it checks:**
+
+- Well-formed HTML5
+- Proper nesting of elements
+- Valid attributes
+- Accessible markup
+
+### Link Checking
+
+Verifies all links are valid:
+
+```bash
+task test:links
+```
+
+This uses `htmltest` configured in `.htmltest.yml`.
+
+**What it checks:**
+
+- Internal links point to existing pages
+- External links are reachable
+- Anchor links target existing elements
+- No redirects (301/302)
+
+**Note:** This test can be slow for large sites with many external links.
+
+## CI Testing
+
+All tests run automatically on:
+
+- **Push to `main`** - Full test suite
+- **Pull requests** - Full test suite
+
+View the GitHub Actions workflow: `.github/workflows/test.yml`
+
+### CI Test Results
+
+If tests fail in CI:
+
+1. Check the GitHub Actions logs
+2. Look for specific test failures
+3. Run the same test locally: `task test:<name>`
+4. Fix the issue
+5. Commit and push
+
+### Artifacts
+
+CI uploads test artifacts:
+
+- `htmltest-report/` - Link checking results
+
+Download these from the GitHub Actions run to investigate failures.
+
+## Test Configuration Files
+
+| File | Purpose |
+|------|---------|
+| `.markdownlint.json` | Markdown linting rules |
+| `.htmlvalidate.json` | HTML validation rules |
+| `.htmltest.yml` | Link checker configuration |
+
+## Best Practices
+
+1. **Test early, test often** - Run `task test:quick` frequently
+2. **Fix issues immediately** - Don't accumulate technical debt
+3. **Understand failures** - Read error messages carefully
+4. **Update tests** - If rules change, update config files
+5. **Document exceptions** - If you need to ignore a rule, document why
+
+## Common Issues and Solutions
+
+### Markdown: MD031 - Blank lines around fences
+
+**Problem:** Missing blank line before/after code block
+
+**Solution:** Add blank lines:
+
+```markdown
+Some text
+
+​```bash
+command here
+​```
+
+More text
+```
+
+### Markdown: MD032 - Blank lines around lists
+
+**Problem:** Missing blank line before/after list
+
+**Solution:** Add blank lines:
+
+```markdown
+Text before
+
+- List item 1
+- List item 2
+
+Text after
+```
+
+### HTML: Invalid nesting
+
+**Problem:** Elements improperly nested
+
+**Solution:** Check template files and shortcodes
+
+### Link Check: 404 Not Found
+
+**Problem:** Link points to non-existent page
+
+**Solution:**
+
+- Fix the link
+- Create the missing page
+- Remove the link if no longer relevant
+
+## Next Steps
+
+Learn about the automated [CI/CD pipeline](../cicd/).

content/en/docs-old/platform-overview.md

@@ -0,0 +1,75 @@
+---
+title: "eDF Documentation Overview"
+description: "Comprehensive guide for users and auditors to understand and use the eDF."
+---
+
+# Meta
+
+## Guidelines
+
+1. for users/developers/engineers we describe our output / outcome as product
+    * it is usable
+    * there are links / lists to repos
+2. we have and describe a 'product-structure-tree'
+3. for auditors / governance we have a list / cross reference to Jira tickets
+    * R&D ?, 
+    * mappen auf die projektphasen, wie erstellt ein team eine plattform? 
+        * stw. mobbing, mob programming
+    * mapping auf deliverables von IPCEI-CIS ???, bzw. mapping auf epics?
+    * projekthistorie, projektdynamic, teilprojekt von eDF , teilprojekt-abhängigkiet zB 'Platform'
+    * friendly user phase
+    * forgejo community, OSS, PR handling
+    * externe stakeholder, user experience, think ahead integration
+    * technolgien, technologie-schwerpunkte, cutting-edge research
+    * design/specification und bewertung von lösungsentürfen (zB VictoriaMetrics, GARM, terraform, argoCD, ...)
+    * CI/CD, golden paths (anm.: ist in grobkonzept, deployment von apps von developern fehlt)
+
+# Introduction
+- Purpose of the eDF
+- Target audience (developers, engineers, auditors)
+- High-level product structure overview
+- High-level architecture overview
+
+# eDF Components Overview
+- List of all major components
+- Vertical and horizontal layers explained
+- Component maturity/status (fully integrated, partial, experimental)
+
+# Getting Started
+- Quickstart guide for developers
+- Onboarding steps for eDF engineers
+- Prerequisites and environment setup
+
+# Component Details
+For each component:
+- Description and purpose
+- Repository link
+- README summary
+- Architecture diagrams (link to Miro/Lucid)
+- Usage instructions
+- Integration points
+
+# Development Experience
+- How to contribute
+- Local development workflow
+- CI/CD pipelines
+- Testing and validation
+
+# Operational Experience
+- Deployment guides
+- Monitoring and observability
+- Troubleshooting
+
+# Audit & Compliance
+- Overview of implemented controls
+- Ticket references (Jira, changelogs)
+- Documentation of decisions and reviews
+- Evidence of value and coverage
+
+# FAQ & Support
+- Common issues and solutions
+- Contact points for help
+
+# Appendix
+- Glossary
+- References to external resources

content/en/docs-old/v1/_index.md

@@ -0,0 +1,13 @@
+---
+title: "Documentation (v1 - Legacy)"
+linkTitle: "v1 (Legacy)"
+weight: 100
+description: >
+  Legacy documentation - archived version of the original content.
+---
+
+{{% alert title="Note" color="warning" %}}
+This is the legacy documentation (v1). For the latest version, please visit the [current documentation](/docs/).
+{{% /alert %}}
+
+This section contains the original documentation that is being migrated to a new structure.

content/en/docs-old/v1/concepts/2_engineering-people/_index.md

@@ -1,7 +1,7 @@
 ---
 title: Engineers
 weight: 2
-description: 'Our clients: People creating code and bringing it to live - and their habits and contexts'
+description: 'Our clients: People creating code and bringing it to life - and their habits and contexts'
 ---
 
 

content/en/docs-old/v1/concepts/3_use-cases/_index.md

@@ -4,7 +4,7 @@ weight: 2
 description: The golden paths in the engineers and product development domain
 ---
 
-## Rationale 
+## Rationale
 
 The challenge of IPCEI-CIS Developer Framework is to provide value for DTAG customers, and more specifically: for Developers of DTAG customers.
 
@@ -40,10 +40,22 @@ Deploy and develop the famous socks shops:
 
 * https://github.com/kezoo/nestjs-reactjs-graphql-typescript-boilerplate-example
 
+### Telemetry Use Case with respect to the Fibonacci workload
+
+The Fibonacci App on the cluster can be accessed on the path https://cnoe.localtest.me/fibonacci.
+It can be called for example by using the URL https://cnoe.localtest.me/fibonacci?number=5000000.
+
+The resulting ressource spike can be observed one the Grafana dashboard "Kubernetes / Compute Resources / Cluster".
+The resulting visualization should look similar like this:
+
+
+![alt text](fibonacci-app_cpu-spike.png)
+
+
 ## When and how to use the developer framework?
 
 ### e.g. an example
 
 .... taken from https://cloud.google.com/blog/products/application-development/common-myths-about-platform-engineering?hl=en
 
-![alt text](image.png)
+![alt text](image.png)

content/en/docs-old/v1/concepts/4_digital-platforms/platform-components/_index.md

@@ -6,3 +6,10 @@ description: What in terms of components or building blocks is needed in a platf
 
 > This page is in work. Right now we have in the index a collection of links describing and listing typical components and building blocks of platforms. Also we have a growing number of subsections regarding special types of components.
 
+See also:
+
+* https://thenewstack.io/build-an-open-source-kubernetes-gitops-platform-part-1/
+* https://thenewstack.io/build-an-open-source-kubernetes-gitops-platform-part-2/
+
+![alt text](7b748ff4-image2-1024x580.png)
+

content/en/docs-old/v1/concepts/4_digital-platforms/platform-components/cicd-pipeline/_index.md

@@ -47,11 +47,11 @@ Components are the composable and self-contained building blocks for the context
 
 Components must be as small as possible and follow the same concepts of software development and deployment as any other software product. In particular, they must have the following characteristics:
 
-- designed for a single task
-- provide a clear and intuitive output
-- easy to compose
-- easily customizable or interchangeable
-- automatically testable
+* designed for a single task
+* provide a clear and intuitive output
+* easy to compose
+* easily customizable or interchangeable
+* automatically testable
 
 In the EDF components are divided into different categories. Each category contains components that perform similar actions. For example, the `build` category contains components that compile code, while the `deploy` category contains components that automate the management of the artefacts created in a production-like system.
 

content/en/docs-old/v1/concepts/4_digital-platforms/platform-components/cicd-pipeline/review-stl.md

@@ -8,4 +8,4 @@ There is no continuous whatever step inbetween ... Gitops is just 'overwriting'
 
 This means whatever quality ensuring steps have to take part before 'overwriting' have to be defined as state changer in the repos, not in the environments.
 
-Conclusio: I think we only have three contexts, or let's say we don't have the contect 'continuous delivery'
+Conclusio: I think we only have three contexts, or let's say we don't have the contect 'continuous delivery'

content/en/docs-old/v1/concepts/4_digital-platforms/platform-components/developer-portals/_index.md

@@ -33,4 +33,4 @@ https://www.getport.io/compare/backstage-vs-port
 * [port-vs-backstage-choosing-your-internal-developer-portal](https://medium.com/@vaibhavgupta0702/port-vs-backstage-choosing-your-internal-developer-portal-71c6a6acd979)
 * [idp-vs-self-service-portal-a-platform-engineering-showdown](https://thenewstack.io/idp-vs-self-service-portal-a-platform-engineering-showdown)
 * [portals-vs-platform-orchestrator](https://humanitec.com/portals-vs-platform-orchestrator)
-* [internal-developer-portal-vs-internal-developer-platform](https://www.cortex.io/post/internal-developer-portal-vs-internal-developer-platform)
+* [internal-developer-portal-vs-internal-developer-platform](https://www.cortex.io/post/internal-developer-portal-vs-internal-developer-platform)

content/en/docs-old/v1/concepts/4_digital-platforms/platform-components/orchestrator/_index.md

@@ -17,7 +17,7 @@ description: "The new kid on the block since 2023 ist 'Platform Orchestrating':
 
 * cnoe.io
 
-#### Resources 
+#### Resources
 
 * [CNOE IDPBuilder](https://cnoe.io/docs/reference-implementation/installations/idpbuilder)
-* https://github.com/csantanapr/cnoe-examples/tree/main
+* https://github.com/csantanapr/cnoe-examples/tree/main

content/en/docs-old/v1/concepts/4_digital-platforms/platform-components/references/_index.md

@@ -29,8 +29,8 @@ description: An currently uncurated list of references with respect to typical p
 
 | Core Component | Short Description |
 | ---- | --- |
-| Application Configuration Management |	Manage application configuration in a dynamic, scalable and reliable way. |
-| Infrastructure Orchestration |	Orchestrate your infrastructure in a dynamic and intelligent way depending on the context. |
-| Environment Management |	Enable developers to create new and fully provisioned environments whenever needed. |
-| Deployment Management |	Implement a delivery pipeline for Continuous Delivery or even Continuous Deployment (CD). |
-| Role-Based Access Control |	Manage who can do what in a scalable way. |
+| Application Configuration Management | Manage application configuration in a dynamic, scalable and reliable way. |
+| Infrastructure Orchestration | Orchestrate your infrastructure in a dynamic and intelligent way depending on the context. |
+| Environment Management | Enable developers to create new and fully provisioned environments whenever needed. |
+| Deployment Management | Implement a delivery pipeline for Continuous Delivery or even Continuous Deployment (CD). |
+| Role-Based Access Control | Manage who can do what in a scalable way. |

content/en/docs-old/v1/concepts/4_digital-platforms/platform-engineering/_index.md

@@ -5,7 +5,7 @@ description: Theory and general blue prints of the platform engineering discipli
 ---
 
 
-## Rationale 
+## Rationale
 
 IPCEI-CIS Developer Framework is part of a cloud native technology stack. To design the capabilities and architecture of the Developer Framework we need to define the surounding context and internal building blocks, both aligned with cutting edge cloud native methodologies and research results.
 
@@ -16,6 +16,7 @@ In CNCF the discipline of building stacks to enhance the developer experience is
 [CNCF first asks](https://tag-app-delivery.cncf.io/whitepapers/platforms/) why we need platform engineering:
 
 > The desire to refocus delivery teams on their core focus and reduce duplication of effort across the organisation has motivated enterprises to implement platforms for cloud-native computing. By investing in platforms, enterprises can:
+>
 > * Reduce the cognitive load on product teams and thereby accelerate product development and delivery
 > * Improve reliability and resiliency of products relying on platform capabilities by dedicating experts to configure and manage them
 > * Accelerate product development and delivery by reusing and sharing platform tools and knowledge across many teams in an enterprise
@@ -40,7 +41,7 @@ https://humanitec.com/blog/wtf-internal-developer-platform-vs-internal-developer
 
 ## Internal Developer Platform
 
-> In IPCEI-CIS right now (July 2024) we are primarily interested in understanding how IDPs are built as one option to implement an IDP is to build it ourselves. 
+> In IPCEI-CIS right now (July 2024) we are primarily interested in understanding how IDPs are built as one option to implement an IDP is to build it ourselves.
 
 The outcome of the Platform Engineering discipline is - created by the platform engineering team - a so called 'Internal Developer Platform'.
 
@@ -69,4 +70,4 @@ The amount of available IDPs as product is rapidly growing.
 ## Platform 'Initiatives' aka Use Cases
 
 Cortex is [talking about Use Cases (aka Initiatives):](https://www.youtube.com/watch?v=LrEC-fkBbQo) (or https://www.brighttalk.com/webcast/20257/601901)
-![alt text](cortex-use-cases.png)
+![alt text](cortex-use-cases.png)

content/en/docs-old/v1/concepts/4_digital-platforms/platform-engineering/reference-architecture/_index.md

@@ -7,14 +7,14 @@ weight = 1
     date = '2024-07-30'
 +++
 
-##  [The Structure of a Successful Internal Developer Platform](https://platformengineering.org/blog/create-your-own-platform-engineering-reference-architectures)
+## [The Structure of a Successful Internal Developer Platform](https://platformengineering.org/blog/create-your-own-platform-engineering-reference-architectures)
 
 In a platform reference architecture there are five main planes that make up an IDP:
 
 1. Developer Control Plane – this is the primary configuration layer and interaction point for the platform users. Components include Workload specifications such as Score and a portal for developers to interact with.
 2. Integration and Delivery Plane – this plane is about building and storing the image, creating app and infra configs, and deploying the final state. It usually contains a CI pipeline, an image registry, a Platform Orchestrator, and the CD system.
 3. Resource Plane – this is where the actual infrastructure exists including clusters, databases, storage or DNS services.
-4, Monitoring and Logging Plane – provides real-time metrics and logs for apps and infrastructure. 
+4, Monitoring and Logging Plane – provides real-time metrics and logs for apps and infrastructure.
 5. Security Plane – manages secrets and identity to protect sensitive information, e.g., storing, managing, and security retrieving API keys and credentials/secrets.
 
 ![idp](../idp.webp)
@@ -29,12 +29,9 @@ https://github.com/humanitec-architecture
 https://humanitec.com/reference-architectures
 
 
-
 ## Create a reference architecture
 
 [Create your own platform reference architecture](https://platformengineering.org/blog/create-your-own-platform-engineering-reference-architectures)
 
 [Reference arch slide deck](https://docs.google.com/presentation/d/1yAf_FSjiA0bAFukgu5p1DRMvvGGE1fF4KhvZbb7gn2I/edit?pli=1#slide=id.g1ef66f3349b_3_3)
 
-
-

content/en/docs-old/v1/concepts/5_platforms/CNOE/_index.md

@@ -1,16 +1,16 @@
-+++
-title = "CNOE"
-weight = 4
-+++
+---
+title: CNOE
+weight: 4
+---
 
 
 * https://cnoe.io/docs/intro
-    
+
 > The goal for the CNOE framework is to bring together a cohort of enterprises operating at the same scale so that they can navigate their operational technology decisions together, de-risk their tooling bets, coordinate contribution, and offer guidance to large enterprises on which CNCF technologies to use together to achieve the best cloud efficiencies.
 
 ### Aussprache
 
-* Englisch Kuh.noo, 
+* Englisch Kuh.noo,
 * also 'Kanu' im Deutschen
 
 
@@ -26,6 +26,7 @@ See https://cnoe.io/docs/reference-implementation/integrations/reference-impl:
 # in a local terminal with docker and kind
 idpbuilder create --use-path-routing  --log-level debug --package-dir https://github.com/cnoe-io/stacks//ref-implementation
 ```
+
 ### Output
 
 ```bash
@@ -150,7 +151,7 @@ Data:
   USER_PASSWORD : RwCHPvPVMu+fQM4L6W/q-Wq79MMP+3CN-Jeo
 ```
 
-### login to backstage 
+### login to backstage
 
 login geht mit den Creds, siehe oben:
 

content/en/docs-old/v1/concepts/5_platforms/Humanitec/_index.md

@@ -0,0 +1,7 @@
+---
+title: Humanitec
+weight: 4
+---
+
+
+tbd

content/en/docs-old/v1/project/MVP-12-OTC.md

@@ -0,0 +1,269 @@
+
+
+# Ideen
+
+* Kanban
+* product review sessions
+
+# ChatGPT
+
+## Fehlendes Backlog
+
+> welche agilen vorgehensmodelle bzw. best practices gibt es in der software-entwicklung, wenn das product backlog noch nicht da ist. es gibt zwar eine produktvision und auch schon einen PoC, aber das Produkt ist sowohl technisch als auch nutzenseitig immer nocht nicht planbar in user stories. daher ist SCRUM nicht machbar. das team ist ca. 8 personen groß, und wir überlgen, einen meilenstein in den nächsten 8 wochen einfach durch tägliches 'PDCA' zu erstellen: ein morgendliches planning, dann in subgruppen ein erforschen, dann im Plenum wieder C (Check) zusammenführen/integrieren, und ein abschliessendes 'A' als Ergebnissicherung, Versionierierung, Dokumentation. Was hälst du von diesem Vorgehen, bzw. welches Risiken und Verbesserungsvorschläge hast du? Oder gibt es ein Standard-Vorgehen hierfür?
+
+Dein beschriebenes Szenario – Vision und PoC vorhanden, aber kein ausformuliertes Product Backlog – ist typisch für eine frühe **Explorations- oder Inceptionsphase** in der Produktentwicklung. In dieser Phase ist klassisches **Scrum** tatsächlich oft zu starr, weil es eine gewisse Klarheit über Features und Stories voraussetzt. Das von euch überlegte Vorgehen klingt nach einer sehr pragmatischen und iterativen Methode, die im Kern gut zu den **Lean-Startup-Prinzipien** oder **Design Thinking + Agile Engineering** passt.
+
+## Bewertung eures PDCA-basierten Vorgehens
+
+**Positiv:**
+* **Täglicher PDCA-Zyklus** (Plan-Do-Check-Act) sorgt für schnelle Feedbackschleifen.
+* **Morgendliches Planning** und **Check-Meeting im Plenum** fördern Transparenz und Selbstorganisation.
+* **Subgruppen-Erkundung** erlaubt parallele Experimente.
+* **Abschließendes "A"** zur Ergebnissicherung ist essenziell, sonst bleibt es bei "busy work".
+
+**Risiken:**
+
+1. **Fehlende Langfriststruktur:** Ohne grobe übergreifende Richtung (z. B. Meilensteinplan, Zielbild) kann es leicht in ziellosem Explorieren enden.
+2. **Uneinheitlicher Erkenntnisgewinn:** Subgruppen könnten redundant oder inkompatibel arbeiten, wenn kein gemeinsames Verständnis besteht.
+3. **Dokumentation als „Nachsorge“:** Wenn die Doku erst am Ende passiert, droht Wissensverlust – lieber „Living Docs“ in Echtzeit pflegen.
+4. **Stakeholder-Abkopplung:** Ohne explizite Reviews oder Demo-Rituale kann Feedback von außen fehlen.
+
+## Verbesserungsvorschläge
+
+1. **Exploration Backlog oder Hypothesenboard:** Auch ohne klassisches Product Backlog könnt ihr mit einem **Experiment-/Hypothesenboard** (à la Lean Startup) arbeiten. Zum Beispiel:
+   * Hypothese: „Feature X wird den Use Case Y verbessern.“
+   * Experiment: „Prototyp bauen und testen mit Nutzergruppe Z.“
+   * Ergebnis & Learnings dokumentieren.
+
+2. **Wöchentliche Zielsetzungen:** Jeden Montag ein Weekly Planning mit klaren Zielen für die Woche (Outcome-fokussiert, nicht Task-fokussiert).
+
+3. **Integration mit Dual Track Agile:** Das Vorgehen ähnelt dem **Dual-Track-Modell**: ein **Discovery-Track** (Erkunden, Validieren, Prototypisieren) läuft parallel zum späteren **Delivery-Track** (Releases, Sprints). Ihr seid noch voll im Discovery-Track.
+
+4. **Design Studio oder Spike-Zeitfenster:** Strukturiert Zeit für z. B. 2-Tages-Design-Studios oder 1-Tages-Spikes – das erhöht die Qualität der Exploration.
+
+5. **Review/Share-Session freitags:** Eine fixe wöchentliche Review-/Demo-Session (auch intern) erhöht die Disziplin und hilft beim „Check“-Teil im PDCA.
+
+## Gängige Standard-Methoden in dieser Phase
+
+* **Design Thinking** (für Nutzerzentrierte Exploration)
+* **Lean UX / Lean Startup** (Hypothesengetrieben)
+* **Dual Track Agile**
+* **Google Design Sprint (5 Tage)** – extrem hilfreich, wenn es um das Testen von Nutzerideen geht
+* **Shape Up (Basecamp)** – für nicht-sprintbasiertes Arbeiten mit "Bet" auf 6-Wochen-Projekte
+
+---
+
+**Fazit:**  
+Euer PDCA-Zyklus ist ein solider, pragmatischer Einstieg in eine unsichere, vorstrukturierte Produktphase. Mit ein paar Ergänzungen (Exploration Backlog, feste Review-Elemente, Hypothesenstruktur) könnt ihr daraus ein effektives Discovery-Vorgehen machen, das den Übergang zu einem klassischen agilen Framework (z. B. Scrum) vorbereitet.
+
+Möchtest du eine konkrete Vorlage für ein Exploration Backlog oder Hypothesenboard für euer Team?
+
+## Architektur vorhanden
+
+> ok, du findest vor allem Tages-Zyklen zu kurz. Ich möchte noch ergänzen, dass wir eine Architektur haben. Das klingt vielleicht paradox, aber es ist tatsächlich so, dass wir das Software-syewtm bereits designed haben, und die Komponenten auch bereits kennen, aber jetzt vor allem die Wege des automatischen Deployments in eine Cloud und die Konfigurations- und Verwaltungsstrukturen unsrerer Software herausfinden müssen. Das ist da, was sich gerade nicht weiter planen lässt. Kannst du mit diesen Ergänzungen dein Feedbach nochmal schärfen?
+
+Danke für die Ergänzung – das ändert die Ausgangslage entscheidend und erlaubt eine deutlich präzisere Einordnung.
+
+### Neue Ausgangslage
+
+* Ihr **habt eine Architektur**: Die Komponenten und Schnittstellen sind klar.
+* Es gibt **bereits einen PoC** und eine Produktvision.
+* Das **Backlog fehlt**, weil ihr gerade die **"nicht-funktionalen" Themen wie Deployment, Cloud-Umgebung, Konfiguration und Betrieb** klärt.
+* Das System ist **technisch grob fertig designt**, aber die **Operations- und Deployment-Prozesse** sind unklar und werden explorativ entwickelt.
+
+### Schärferes Feedback
+
+#### 1. **Tages-PDCA-Zyklen wirken in diesem Kontext zu granular**
+
+Bei Infrastruktur-, Deployment- oder Konfigurationsfragen entstehen oft tiefe „Spikes“ (z. B. CI/CD-Pipeline aufsetzen, Helm-Chart modellieren, Secrets Handling evaluieren). Diese brauchen oft mehr als einen Tag bis zum „Check“, weil Abhängigkeiten (z. B. Rechte, Cloud-Zugänge, Testumgebungen) entstehen. Ein **2- bis 3-Tages-Rhythmus** mit klaren Zwischenzielen wäre realistischer, ergänzt um:
+
+* **Daily Standup als Taktgeber**, aber nicht zwangsläufig als vollständiger PDCA-Zyklus.
+* **Weekly Planning mit Zielvorgaben und Review-Ritualen**, um Fortschritt messbar zu machen.
+
+#### 2. **Was ihr macht, ist kein Produkt-Delivery, sondern "System Enablement"**
+
+Ihr steckt im Übergang von Architektur zu einem **Infrastructure as Code + Plattform Enablement Track**. Das bedeutet:
+* Die „User Stories“ sind keine klassischen Features, sondern z. B.:
+  * „Als Team möchte ich unsere Software mit einem Befehl deployen können.“
+  * „Als Betreiber will ich wissen, wie ich Services konfiguriere.“
+
+Das spricht für ein **Infrastructure Kanban Board**, keine Sprints.
+
+#### 3. **Mögliche Vorgehensmodelle / Best Practices**
+
+| Modell / Methode                         | Warum es jetzt passt                                             |
+|------------------------------------------|------------------------------------------------------------------|
+| **Kanban für technische Tasks**          | Flexible Work-in-Progress-Kontrolle, ideal für Exploration.      |
+| **Spikes** (aus XP)                      | Timeboxed Exploration zu offenen Fragen (z. B. Helm, Secrets).   |
+| **Enabler Epics (SAFe)**                 | Deployment- und Ops-Fragen formal als "Enabler" fassen.          |
+| **Team Topologies – Platform Team Light**| Ihr agiert gerade wie ein internes Plattform-Team.               |
+| **Weekly DevOps Review**                 | Alle 5–7 Tage Stand der Automatisierung/Doku/Strukturen.         |
+| **ADRs & Living Docs**                   | Architectural Decision Records für Deployment-/Ops-Entscheidungen.|
+
+#### 4. **Konkrete Empfehlungen zur Strukturierung**
+
+* **Ziele für die 8 Wochen formulieren** als **"Capabilities"**, z. B.:
+  * „Greenfield-Clouddeployment in AWS/GCP über GitHub Actions.“
+  * „Parameterisierbares Helm-Chart mit Doku.“
+  * „Konfigurierbarkeit über ENV vs. Secrets evaluieren.“
+* Dazu **1–2 Woche cadence**, jede Woche ein Review/Checkpoint.
+* **Boards mit Task-Kategorien**:
+  * 🧪 Spike
+  * 🛠️ Tooling/Automation
+  * 📦 Infrastruktur/Dienst
+  * 📓 Dokumentation
+* **Ergebnisse sofort versionieren und dokumentieren**, z. B.:
+  * GitOps Repo-Struktur
+  * ADRs
+  * Beispiel-Deployments
+
+---
+
+### Fazit
+
+Ihr seid im **"technisch operativen Enablement"** eures Systems, nicht im Produkt-Delivery. Das rechtfertigt:
+* ein **kanban-artiges, flexibles Modell mit timeboxed Reviews**,
+* tägliche Abstimmungen, aber nicht zwingend tägliche Zyklen,
+* Fokus auf **Enabler-Ziele statt funktionale Stories**.
+
+SCRUM ist hier fehl am Platz, aber euer Ansatz ist sehr nahe an einer **modernen DevOps-orientierten Arbeitsweise**, die z. B. von **Platform Engineering Teams** eingesetzt wird.
+
+Möchtest du ein Beispiel für ein solches Kanban-Board mit passenden Task-Typen und Zielstruktur?
+
+## Kanban
+
+> ja, gerne!
+
+Hier ist ein konkretes Beispiel für ein **Kanban-Board**, das speziell auf eure Situation als „Platform/Enablement“-Team mit einem vorhandenen Architekturbild, aber offenem Deployment- und Betriebsdesign zugeschnitten ist.
+
+---
+
+## 🎯 **Zielstruktur (übergeordnet für 8 Wochen)**
+
+Diese formuliert ihr am besten als **Capabilities** – Fähigkeiten, die das System nachher haben soll:
+
+| Capability ID | Zielbeschreibung                                                                          |
+|---------------|---------------------------------------------------------------------------------------------|
+| C1            | Anwendung kann automatisiert in Cloudumgebung X deployed werden (inkl. Secrets Mgmt)       |
+| C2            | Konfiguration des Systems ist externisiert und dokumentiert (ENV, YAML, o. ä.)              |
+| C3            | Monitoring- und Logging-Infrastruktur ist einsatzbereit und dokumentiert                   |
+| C4            | Dev- und Test-Umgebungen sind klar getrennt und automatisch provisionierbar                 |
+| C5            | Alle Plattformentscheidungen (z. B. Helm vs. Kustomize) sind versioniert und begründet     |
+
+Diese Capabilities bilden **Spalten** oder **Swimlanes** im Board (wenn euer Tool das unterstützt, z. B. GitHub Projects, Jira oder Trello mit Labels).
+
+---
+
+## 🗂️ **Kanban-Board-Spalten (klassisch)**
+
+| Spalte           | Zweck                                                     |
+|------------------|-----------------------------------------------------------|
+| 🔍 Backlog        | Ideen, Hypothesen, Tasks – priorisiert nach Capabilities  |
+| 🧪 In Exploration | Aktive Spikes, Proofs, technische Evaluierungen           |
+| 🛠️ In Progress     | Umsetzung mit konkretem Ziel                             |
+| ✅ Review / Check | Funktionsprüfung, internes Review                         |
+| 📦 Done           | Abgeschlossen, dokumentiert, ggf. in Repo                 |
+
+---
+
+## 🏷️ **Task-Typen (Labels oder Emojis zur Kennzeichnung)**
+
+| Symbol / Label  | Typ                         | Beispiel                                                                 |
+|------------------|-----------------------------|--------------------------------------------------------------------------|
+| 🧪 Spike          | Technische Untersuchung     | „Untersuche ArgoCD vs. Flux für GitOps Deployment“                      |
+| 📦 Infra          | Infrastruktur                | „Provisioniere dev/test/stage in GCP mit Terraform“                     |
+| 🔐 Secrets        | Sicherheitsrelevante Aufgabe| „Design für Secret-Handling mit Sealed Secrets“                         |
+| 📓 Docs           | Dokumentation               | „README für Developer Setup schreiben“                                  |
+| 🧰 Tooling        | CI/CD, Pipelines, Linter     | „GitHub Action für Build & Deploy schreiben“                            |
+| 🔁 Entscheidung   | Architekturentscheidung      | „ADR: Helm vs. Kustomize für Service Deployment“                        |
+
+---
+
+## 🧩 Beispielhafte Tasks für Capability „C1 – Deployment automatisieren“
+
+| Task                                         | Typ      | Status         |
+|----------------------------------------------|----------|----------------|
+| Write GitHub Action for Docker image push    | 🧰 Tooling | 🛠️ In Progress |
+| Evaluate ArgoCD vs. Flux                     | 🧪 Spike  | ✅ Review      |
+| Create Helm Chart for Service A              | 📦 Infra  | 🔍 Backlog     |
+| Create ADR: Deployment-Toolentscheidung      | 🔁 Entscheidung | 🔍 Backlog |
+| Add deployment doc in Wiki                   | 📓 Docs   | 🔍 Backlog     |
+
+---
+
+## 📅 Cadence-Empfehlung
+
+* **Daily Standup (15 min)**: Was läuft, was blockiert? Pull statt Push!
+* **Weekly Planning (Montag)**: Priorisieren und Backlog-Grooming (welche Capabilities sind diese Woche dran?)
+* **Weekly Review (Freitag)**: Erkenntnisse, Entscheidungen und Dokumentation präsentieren
+* Optional: **Retrospektive alle 2 Wochen**, falls das Team Energie hat
+
+---
+
+Wenn du magst, kann ich dir ein Beispiel-Board als Markdown-Vorlage oder als CSV-Datei zum Import in Trello, GitHub Projects, Jira etc. machen. Wäre das hilfreich?
+
+## Living Docs
+
+> kannst du noch etwas mehr zu 'LivingDocs' sagen?
+
+Ja, gerne! **"Living Docs"** (bzw. **Living Documentation**) ist ein Konzept aus der agilen Softwareentwicklung und DevOps, das sich auf **aktuelle, direkt aus dem System oder aus dem Arbeitsprozess generierte Dokumentation** bezieht. Ziel ist es, dass die Dokumentation *nicht veraltet*, sondern so eng mit Code und Systemzustand gekoppelt ist, dass sie sich (teilweise) selbst aktualisiert oder sich mit dem Entwicklungsprozess mitbewegt.
+
+---
+
+## 🔍 **Was macht "Living Documentation" aus?**
+
+| Merkmal                         | Beschreibung                                                                 |
+|----------------------------------|------------------------------------------------------------------------------|
+| 🔄 Automatisch erzeugt oder aktualisiert | Generiert aus Code, Tests, Pipelines, ADRs oder Deployments                   |
+| 📌 Versionskontrolliert         | Im Git abgelegt, gemeinsam mit dem Code gepflegt                             |
+| 🧑‍💻 Entwicklernah               | Entwickelt sich mit dem Code weiter – keine Trennung zwischen "Docs" und Dev |
+| 📈 Änderbar & nachvollziehbar   | Jede Änderung an Code/Doku hat einen Commit & Kontext                        |
+| 📚 Mehrwert für alle Beteiligten| Richtet sich an Devs, Ops, PMs oder andere Teams – nicht nur "für später"    |
+
+---
+
+## 🧰 Typische Formen von Living Docs
+
+| Typ                  | Beschreibung & Tools                                                                 |
+|----------------------|----------------------------------------------------------------------------------------|
+| **Architecture Decision Records (ADRs)** | Markdown-Dateien im Repo (z. B. `docs/adr/001-helm-vs-kustomize.md`)     |
+| **Code-Doku aus Source**     | Mit Tools wie JSDoc, TypeDoc, Sphinx, Doxygen, etc.                          |
+| **API-Doku**                 | Automatisch aus Code oder OpenAPI (Swagger) generiert                        |
+| **Test-Doku (z. B. BDD)**     | z. B. Gherkin-Style: `Given/When/Then`-Spezifikationen als Dokumentation     |
+| **Monitoring & Deployment-Status** | z. B. Dashboards mit Infrastructure-Doku (Grafana, Backstage, Argo UI)      |
+| **DevDocs im Repo**          | z. B. `README.md`, `CONTRIBUTING.md`, `how-to/`, `docs/`, `adr/`             |
+| **Playbooks / Runbooks**     | Schritt-für-Schritt-Anleitungen für Betrieb oder Störungen                   |
+
+---
+
+## ✅ **Best Practices**
+
+1. **Nutze Markdown + Git:** Einfach, versionierbar, lesbar → ADRs, Runbooks, HowTos.
+2. **Dokumentiere Entscheidungen bewusst:** Lieber knappe, saubere ADRs als keine Doku.
+3. **Verknüpfe Doku mit Code / CI/CD:** Beispiel: Build-Tool erzeugt automatisch API-Doku oder ADR-Lint-Checks.
+4. **Verlinke Logs, Dashboards, Monitoring:** z. B. in einem `system-overview.md`.
+5. **Behandle Doku wie Code:** Reviewpflichtig, Pull Request basiert, CI-checkbar.
+
+---
+
+## 🛠️ Tools & Frameworks
+
+| Zweck                  | Tools (Beispiele)                                                       |
+|------------------------|-------------------------------------------------------------------------|
+| ADRs                   | [`adr-tools`](https://github.com/npryce/adr-tools), einfaches Markdown  |
+| Markdown-Doku          | MkDocs, Docusaurus, GitBook                                             |
+| API-Doku               | Swagger/OpenAPI, Redocly                                                |
+| Infrastruktur-Doku     | Backstage (Spotify), Terraform-docs                                     |
+| Doku-Automatisierung   | GitHub Actions, pre-commit Hooks, CI-Checks                             |
+
+---
+
+## 🧠 Denkweise: Doku = Gespräch in Zeit
+
+> "Dokumentation ist kein Nachtrag, sondern ein asynchrones Gespräch mit deinem zukünftigen Ich – oder dem nächsten Teammitglied."
+
+Gerade in eurem Kontext (technisches Enablement, Deployment, Betrieb) ist das **entscheidungsorientierte, leichtgewichtige Festhalten von Kontext** Gold wert. ADRs und `docs/runbooks/`-Verzeichnisse sind ein idealer Startpunkt.
+
+---
+
+Möchtest du eine Vorlage für ein ADR oder ein Beispielverzeichnis für eine sinnvolle Living-Docs-Struktur im Repo?

content/en/docs-old/v1/project/bootstrapping/backup/_index.md

@@ -39,6 +39,7 @@ velero install \
 
 3. Delete `credentials.ini`, it is not needed anymore (a secret has been created in the cluster).
 4. Create a schedule to back up the relevant resources in the cluster:
+
 ```
 velero schedule create devfw-bootstrap --schedule="23 */2 * * *" "--include-namespaces=forgejo"
 ```
@@ -48,6 +49,7 @@ velero schedule create devfw-bootstrap --schedule="23 */2 * * *" "--include-name
 You can now use Velero to create backups, restore them, or perform other operations. Please refer to the [Velero Documentation](https://velero.io/docs/main/backup-reference/).
 
 To list all currently available backups:
+
 ```
 velero backup get
 ```

content/en/docs-old/v1/project/conceptual-onboarding/1_intro/_index.md

@@ -5,10 +5,12 @@ description: The 5-step storyflow of this Onboarding chapter
 ---
 
 {{% pageinfo color="info" %}}
+
 ## Summary
 
-This onboarding section is for you when are new to IPCEI-CIS subproject 'Edge Developer Framework (EDF)' and you want to know about 
-* its context to 'Platform Engineering' 
+This onboarding section is for you when are new to IPCEI-CIS subproject 'Edge Developer Framework (EDF)' and you want to know about
+
+* its context to 'Platform Engineering'
 * and why we think it's the stuff we need to care about in the EDF
 {{% /pageinfo %}}
 
@@ -41,9 +43,7 @@ Please do not think this story and the underlying assumptions are carved in ston
 
 ## Your role as 'Framework Engineer' in the Domain Architecture
 
-Pls be aware of the the following domain and task structure of our mission: 
+Pls be aware of the the following domain and task structure of our mission:
 
 ![](./conclusio/images/modern.png)
 
-
-

content/en/docs-old/v1/project/conceptual-onboarding/2_edge-developer-framework/_index.md

@@ -5,10 +5,11 @@ description: Driving requirements for a platform
 ---
 
 {{% pageinfo color="info" %}}
+
 ## Summary
 
-The 'Edge Developer Framework' is both the project and the product we are working for. Out of the leading 'Portfolio Document' 
-we derive requirements which are ought to be fulfilled by Platform Engineering. 
+The 'Edge Developer Framework' is both the project and the product we are working for. Out of the leading 'Portfolio Document'
+we derive requirements which are ought to be fulfilled by Platform Engineering.
 
 **This is our claim!**
 
@@ -26,6 +27,7 @@ e. Development of DTAG/TSI Edge Developer Framework
 * Goal: All developed innovations must be accessible to developer communities in a **highly  user-friendly and easy way**
 
 ### Development of DTAG/TSI Edge Developer Framework (p.14)
+
 | capability | major novelties |||
 | -- | -- | -- | -- |
 | e.1. Edge Developer full service framework (SDK + day1 +day2 support for edge installations) | Adaptive CI/CD pipelines for heterogeneous edge environments | Decentralized and self healing deployment and management | edge-driven monitoring and analytics |
@@ -34,22 +36,23 @@ e. Development of DTAG/TSI Edge Developer Framework
 
 ### DTAG objectives & contributions (p.27)
 
-DTAG will also focus on developing an easy-to-use **Edge Developer framework for software 
+DTAG will also focus on developing an easy-to-use **Edge Developer framework for software
 developers** to **manage the whole lifecycle of edge applications**, i.e. for **day-0-, day-1- and up to day-2-
-operations**. With this DTAG will strongly enable the ecosystem building for the entire IPCEI-CIS edge to 
-cloud continuum and ensure openness and accessibility for anyone or any company to make use and 
-further build on the edge to cloud continuum. Providing the use of the tool framework via an open-source approach will further reduce entry barriers and enhance the openness and accessibility for anyone or 
+operations**. With this DTAG will strongly enable the ecosystem building for the entire IPCEI-CIS edge to
+cloud continuum and ensure openness and accessibility for anyone or any company to make use and
+further build on the edge to cloud continuum. Providing the use of the tool framework via an open-source approach will further reduce entry barriers and enhance the openness and accessibility for anyone or
 any organization (see innovations e.).
 
 ### WP Deliverables (p.170)
 
 e.1 Edge developer full-service framework
 
-This tool set and related best practices and guidelines will **adapt, enhance and further innovate DevOps principles** and 
-their related, necessary supporting technologies according to the specific requirements and constraints associated with edge or edge cloud development, in order to keep the healthy and balanced innovation path on both sides, 
+This tool set and related best practices and guidelines will **adapt, enhance and further innovate DevOps principles** and
+their related, necessary supporting technologies according to the specific requirements and constraints associated with edge or edge cloud development, in order to keep the healthy and balanced innovation path on both sides,
 the (software) development side and the operations side in the field of DevOps.
 
 {{% pageinfo color="info" %}}
+
 ### What comes next?
 
 [Next](../platforming/) we'll see how these requirements seem to be fulfilled by platforms!

content/en/docs-old/v1/project/conceptual-onboarding/3_platforming/_index.md

@@ -7,17 +7,18 @@ description: DevOps is dead - long live next level DevOps in platforms
 
 
 {{% pageinfo color="info" %}}
+
 ## Summary
 
-Since 2010 we have DevOps. This brings increasing delivery speed and efficiency at scale. 
-But next we got high 'cognitive loads' for developers and production congestion due to engineering lifecycle complexity. 
+Since 2010 we have DevOps. This brings increasing delivery speed and efficiency at scale.
+But next we got high 'cognitive loads' for developers and production congestion due to engineering lifecycle complexity.
 So we need on top of DevOps an instrumentation to ensure and enforce speed, quality, security in modern, cloud native software development. This instrumentation is called 'golden paths' in intenal develoepr platforms (IDP).
 {{% /pageinfo %}}
 
 
 ## History of Platform Engineering
 
-Let's start with a look into the history of platform engineering. A good starting point is [Humanitec](https://humanitec.com/), as they nowadays are one of the biggest players (['the market leader in IDPs.'](https://internaldeveloperplatform.org/#how-we-curate-this-site)) in platform engineering. 
+Let's start with a look into the history of platform engineering. A good starting point is [Humanitec](https://humanitec.com/), as they nowadays are one of the biggest players (['the market leader in IDPs.'](https://internaldeveloperplatform.org/#how-we-curate-this-site)) in platform engineering.
 
 They create lots of [beautiful articles and insights](https://humanitec.com/blog), their own [platform products](https://humanitec.com/products/) and [basic concepts for the platform architecture](https://humanitec.com/platform-engineering) (we'll meet this later on!).
 
@@ -51,7 +52,7 @@ There is a CNCF working group which provides the definition of [Capabilities of
 
 ### Platform Engineering Team
 
-Or, in another illustration for the platform as a developer service interface, which also defines the **'Platform Engineering Team'** inbetween: 
+Or, in another illustration for the platform as a developer service interface, which also defines the **'Platform Engineering Team'** inbetween:
 
 <img src="./platform-self-services.webp" width="600" alt="https://medium.com/@bijit211987/what-is-platform-engineering-and-how-it-reduce-cognitive-load-on-developers-ac7805603925">
 
@@ -70,7 +71,7 @@ First of all some important wording to motivate the important term 'internal dev
 
 [Capabilities of platforms](https://tag-app-delivery.cncf.io/whitepapers/platforms/#capabilities-of-platforms)
 
-### Ecosystems in InternalDeveloperPlatform 
+### Ecosystems in InternalDeveloperPlatform
 
 Build or buy - this is also in pltaform engineering a tweaked discussion, which one of the oldest player answers like this with some oppinioated internal capability structuring:
 
@@ -78,6 +79,7 @@ Build or buy - this is also in pltaform engineering a tweaked discussion, which
 
 
 {{% pageinfo color="info" %}}
+
 ### What comes next?
 
 [Next](../orchestrators/) we'll see how these concepts got structured!
@@ -87,7 +89,7 @@ Build or buy - this is also in pltaform engineering a tweaked discussion, which
 
 ### Digital Platform defintion from [What we **call** a Platform](https://martinfowler.com/articles/talk-about-platforms.html)
 
-> Words are hard, it seems. ‘Platform’ is just about the most ambiguous term we could use for an approach that is super-important for increasing delivery speed and efficiency at scale. Hence the title of this article, here is what I’ve been talking about most recently. 
+> Words are hard, it seems. ‘Platform’ is just about the most ambiguous term we could use for an approach that is super-important for increasing delivery speed and efficiency at scale. Hence the title of this article, here is what I’ve been talking about most recently.
 \
 Definitions for software and hardware platforms abound, generally describing an operating environment upon which applications can execute and which provides reusable capabilities such as file systems and security.
 \

content/en/docs-old/v1/project/conceptual-onboarding/4_orchestrators/_index.md

@@ -5,9 +5,11 @@ description: Next level platforming is orchestrating platforms
 ---
 
 {{% pageinfo color="info" %}}
+
 ## Summary
 
-When defining and setting up platforms next two intrinsic problems arise: 
+When defining and setting up platforms next two intrinsic problems arise:
+
 1. it is not declarative and automated
 2. it is not or least not easily changable
 
@@ -33,10 +35,11 @@ https://humanitec.com/reference-architectures
 
 <img src="./platform-architectures.webp" width="600" alt="https://humanitec.com/blog/aws-azure-and-gcp-open-source-reference-architectures-to-start-your-mvp">
 
-> Hint: There is a [slides tool provided by McKinsey](https://platformengineering.org/blog/create-your-own-platform-engineering-reference-architectures) to set up your own platform deign based on the reference architecture 
+> Hint: There is a [slides tool provided by McKinsey](https://platformengineering.org/blog/create-your-own-platform-engineering-reference-architectures) to set up your own platform deign based on the reference architecture
 
 
 {{% pageinfo color="info" %}}
+
 ### What comes next?
 
 [Next](../cnoe/) we'll see how we are going to do platform orchestration with CNOE!
@@ -50,4 +53,3 @@ You remember the [capability mappings from the time before orchestration](../pla
 
 <img src="./platform-tooling-humanitec-platform-report-2024.PNG" width="600" alt="https://humanitec.com/whitepapers/state-of-platform-engineering-report-volume-2 Whitepaper_ State of Platform Engineering Report.pdf">
 
-

content/en/docs-old/v1/project/conceptual-onboarding/5_cnoe/_index.md

@@ -5,6 +5,7 @@ description: Our top candidate for a platform orchestrator
 ---
 
 {{% pageinfo color="info" %}}
+
 ## Summary
 
 In late 2023 platform orchestration raised - the discipline of declarativley dinfing, building, orchestarting and reconciling building blocks of (digital) platforms.
@@ -17,6 +18,7 @@ Thus we were looking for open source means for platform orchestrating and found
 ## Requirements for an Orchestrator
 
 When we want to set up a [complete platform](../platforming/platforms-def.drawio.png) we expect to have
+
 * a **schema** which defines the platform, its ressources and internal behaviour
 * a **dynamic configuration or templating mechanism** to provide a concrete specification of a platform
 * a **deployment mechanism** to deploy and reconcile the platform
@@ -55,6 +57,7 @@ There are already some example stacks:
 
 
 {{% pageinfo color="info" %}}
+
 ### What comes next?
 
 [Next](../cnoe-showtime/) we'll see how a CNOE stacked Internal Developer Platform is deployed on you local laptop!

content/en/docs-old/v1/project/conceptual-onboarding/6_cnoe-showtime/_index.md

@@ -5,9 +5,10 @@ description: CNOE hands on
 ---
 
 {{% pageinfo color="info" %}}
+
 ## Summary
 
-CNOE is a 'Platform Engineering Framework' (Danger: Our wording!) - it is open source and locally runnable. 
+CNOE is a 'Platform Engineering Framework' (Danger: Our wording!) - it is open source and locally runnable.
 
 It consists of the orchestrator 'idpbuilder' and both of some predefined building blocks and also some predefined platform configurations.  
 
@@ -87,7 +88,7 @@ It's an important feature of idpbuilder that it will set up on an existing clust
 
 That's why we here first create the kind cluster `localdev`itself:
 
-```bash 
+```bash
 cat << EOF | kind create cluster --name localdev --config=-
 # Kind kubernetes release images https://github.com/kubernetes-sigs/kind/releases
 kind: Cluster
@@ -137,7 +138,7 @@ kube-system          kube-scheduler-localdev-control-plane            1/1     Ru
 local-path-storage   local-path-provisioner-6f8956fb48-6fvt2          1/1     Running   0          15s
 ```
 
-### First run: Start with core applications, 'core package' 
+### First run: Start with core applications, 'core package'
 
 Now we run idpbuilder the first time:
 
@@ -149,7 +150,7 @@ ib create --use-path-routing
 
 #### Output
 
-##### idpbuilder log 
+##### idpbuilder log
 
 ```bash
 stl@ubuntu-vpn:~/git/mms/idpbuilder$ ib create --use-path-routing
@@ -243,7 +244,7 @@ Data:
   username : giteaAdmin
 ```
 
-In ArgoCD you will see the deployed three applications of the core package: 
+In ArgoCD you will see the deployed three applications of the core package:
 
 ![alt text](image-1.png)
 
@@ -302,7 +303,7 @@ drwxr-xr-x 4 stl stl 4096 Jul 29 10:57 ..
 
 Now we run idpbuilder the second time with `-p basic/package1`
 
-##### idpbuilder log 
+##### idpbuilder log
 
 ```bash
 stl@ubuntu-vpn:~/git/mms/cnoe-stacks$ ib create --use-path-routing -p basic/package1
@@ -572,9 +573,10 @@ Next wait a bit until Gitops does its magic and our 'wanted' state in the repo g
 ![alt text](image-15.png)
 
 {{% pageinfo color="info" %}}
+
 ### What comes next?
 
 The showtime of CNOE high level behaviour and usage scenarios is now finished. We setup an initial IDP and used a backstage golden path to init and deploy a simple application.
 
-[Last not least](../conclusio/) we want to sum up the whole way from Devops to 'Frameworking' (is this the correct wording???) 
+[Last not least](../conclusio/) we want to sum up the whole way from Devops to 'Frameworking' (is this the correct wording???)
 {{% /pageinfo %}}