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.

.envrc.example

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

.github/workflows/ci.yaml

@@ -22,11 +22,11 @@ jobs:
           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}"
@@ -47,18 +47,18 @@ jobs:
         id: docker
         with:
           images: ${{ steps.repository.outputs.registry }}/${{ steps.repository.outputs.repository }}
-
-      - name: Login to registry
+          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 QEMU
-        uses: docker/setup-qemu-action@v3
-
-      - name: Set up Docker Buildx
+      -
+        name: Set up Docker Buildx
         uses: docker/setup-buildx-action@v3
         with:
           buildkitd-flags: '--allow-insecure-entitlement network.host'
@@ -71,7 +71,6 @@ jobs:
           push: true
           allow: network.host
           network: host
-          platforms: linux/amd64,linux/arm64
           tags: ${{ steps.docker.outputs.tags }}
           labels: ${{ steps.docker.outputs.labels }}
           build-args: |

.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

@@ -26,11 +26,11 @@ jobs:
           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}"
@@ -100,7 +100,7 @@ jobs:
         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)
@@ -108,7 +108,7 @@ jobs:
             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'
@@ -128,22 +128,22 @@ jobs:
           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

@@ -1,15 +1,15 @@
 name: Hugo Site Tests
 
 on:
-  push:
-    branches: [ main ]
+#   push:
+#     branches: [ main ]
   pull_request:
     branches: [ main ]
 
 jobs:
   test:
     runs-on: ubuntu-latest
-    
+
     steps:
     - uses: actions/checkout@v4
       with:
@@ -38,7 +38,7 @@ jobs:
         npm run test:build
         npm run test:markdown
         npm run test:html
-        
+
     - name: Run link checker
       run: htmltest
       continue-on-error: true

.gitignore

@@ -13,6 +13,12 @@ tmp/
 # devbox
 .devbox/
 
+# Task cache
+.task/
+
+# Generated build data
+data/
+
 # IDE
 .vscode/
 .idea/
@@ -29,3 +35,7 @@ Thumbs.db
 npm-debug.log*
 yarn-debug.log*
 yarn-error.log*
+
+### direnv ###
+.direnv
+.envrc

.htmltest.yml

@@ -5,6 +5,20 @@ 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

@@ -4,7 +4,22 @@
     "no-inline-style": "off",
     "require-sri": "off",
     "no-trailing-whitespace": "off",
-    "void-style": "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"

.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/**

DOCKER.md

@@ -1,98 +0,0 @@
-# Docker Build
-
-This project uses a multi-stage Docker build that matches the local devbox development environment.
-
-## Version Management
-
-All tool versions are defined in `.env.versions` as the single source of truth:
-
-```bash
-NODE_VERSION=24.10.0
-GO_VERSION=1.25.1
-HUGO_VERSION=0.151.0
-```
-
-These versions are used in:
-
-- `devbox.json` - Local development environment
-- `Dockerfile` - Docker build arguments (with defaults)
-- `.github/workflows/ci.yaml` - CI/CD pipeline
-
-**Important:** When updating versions, modify `.env.versions` and sync with `devbox.json`.
-
-## Local Build
-
-### Using Task (recommended)
-
-The easiest way to build the OCI image:
-
-```bash
-task build:oci-image
-```
-
-This automatically:
-
-- Loads versions from `.env.versions`
-- Builds the image with correct build arguments
-- Tags with `latest` and git commit hash
-
-To build and test:
-
-```bash
-task test:oci-image
-```
-
-### Automatic version loading
-
-Use the helper script to load versions from `.env.versions`:
-
-```bash
-source scripts/get-versions.sh
-```
-
-This will show you the Docker build command with the correct versions.
-
-### Manual build
-
-```bash
-docker build --network=host \
-  --build-arg NODE_VERSION=24.10.0 \
-  --build-arg GO_VERSION=1.25.1 \
-  --build-arg HUGO_VERSION=0.151.0 \
-  -t ipceicis-developerframework:latest .
-```
-
-### Test the image
-
-```bash
-docker run -d -p 8080:80 --name hugo-test ipceicis-developerframework:latest
-curl http://localhost:8080
-docker stop hugo-test && docker rm hugo-test
-```
-
-## CI/CD Pipeline
-
-The GitHub Actions workflow (`.github/workflows/ci.yaml`) automatically:
-
-1. Extracts versions from devbox environment
-2. Builds multi-arch images (amd64 + arm64)
-3. Pushes to the container registry with appropriate tags
-
-### Required Secrets
-
-Configure these secrets in your GitHub repository:
-
-- `PACKAGES_USER`: Container registry username
-- `PACKAGES_TOKEN`: Container registry token/password
-
-## Image Structure
-
-- **Build Stage**: Uses Node.js base image, installs Go and Hugo
-- **Runtime Stage**: Uses nginx:alpine to serve static content (~50MB)
-
-The build process:
-
-1. Installs npm dependencies
-2. Downloads Hugo modules
-3. Builds static site with `hugo --gc --minify`
-4. Copies built site to minimal nginx container

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.

TESTING.md

@@ -1,62 +0,0 @@
-# Hugo Site Testing
-
-Dieses Projekt verwendet mehrere automatisierte Tests zur Qualitätssicherung.
-
-## Verfügbare Tests
-
-### 1. Build-Test
-```bash
-npm run test:build
-```
-Prüft ob die Hugo-Seite überhaupt baut und zeigt Warnungen/Fehler an.
-
-### 2. Markdown-Linting
-```bash
-npm run test:markdown
-```
-Validiert Markdown-Dateien auf Stilprobleme und Best Practices.
-
-### 3. HTML-Validierung
-```bash
-npm run test:html
-```
-Prüft die generierte HTML auf HTML5-Konformität.
-
-### 4. Link-Checker
-```bash
-npm run test:links
-```
-Testet alle internen und externen Links auf Gültigkeit.
-
-### Alle Tests ausführen
-```bash
-npm test
-```
-
-### Schnelle Tests (ohne Link-Check)
-```bash
-npm run test:quick
-```
-
-## Konfigurationsdateien
-
-- `.htmltest.yml` - Link-Checker-Konfiguration
-- `.htmlvalidate.json` - HTML-Validierungs-Regeln
-- `.markdownlint.json` - Markdown-Linting-Regeln
-
-## CI/CD Integration
-
-GitHub Actions führt diese Tests automatisch bei jedem Push/PR aus:
-- `.github/workflows/test.yml`
-
-## Lokale Entwicklung
-
-Vor dem Commit empfohlen:
-```bash
-npm run test:quick  # Schnelle Tests
-```
-
-Vor dem Push:
-```bash
-npm test  # Alle Tests inkl. Link-Check
-```

Taskfile.yml

@@ -13,18 +13,37 @@ tasks:
   # 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"
+      - "{{.HUGO_CMD}} server --noHTTPCache"
 
   clean:
     desc: Clean build artifacts
@@ -34,43 +53,127 @@ tasks:
   # 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
+    desc: Check links (skips legacy content)
     cmds:
-      - htmltest
+      - |
+        # 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}} install"
+      - "{{.NPM_CMD}} ci"
       - "{{.HUGO_CMD}} mod get -u"
       - "{{.HUGO_CMD}} mod tidy"
 

VERSIONS.md

@@ -1,69 +0,0 @@
-# Version Management
-
-## Single Source of Truth: `.env.versions`
-
-All tool versions are centrally managed in `.env.versions`:
-
-```bash
-NODE_VERSION=24.10.0
-GO_VERSION=1.25.1
-HUGO_VERSION=0.151.0
-```
-
-## Where are versions used?
-
-1. **devbox.json** - Local development environment (manual sync required)
-2. **Dockerfile** - Build arguments with defaults
-3. **.github/workflows/ci.yaml** - CI/CD pipeline (automatic)
-4. **scripts/get-versions.sh** - Helper script for local builds
-
-## Updating Versions
-
-### Step 1: Update `.env.versions`
-
-Edit the file with new versions:
-
-```bash
-NODE_VERSION=24.12.0
-GO_VERSION=1.25.2
-HUGO_VERSION=0.152.0
-```
-
-### Step 2: Update `devbox.json`
-
-Manually sync the versions in `devbox.json`:
-
-```json
-{
-  "packages": [
-    "hugo@0.152.0",
-    "go@1.25.2",
-    "nodejs@24.12.0",
-    ...
-  ]
-}
-```
-
-### Step 3: Rebuild devbox environment
-
-```bash
-devbox shell --refresh
-```
-
-### Step 4: Test Docker build
-
-```bash
-source scripts/get-versions.sh
-# Follow the printed docker build command
-```
-
-## Why not automatic devbox sync?
-
-- devbox.json uses a different version format (e.g., `@latest` vs specific versions)
-- devbox package names may differ from Docker image names
-- Keeps devbox.json simple and readable
-- Manual sync ensures intentional version updates
-
-## CI/CD
-
-The GitHub Actions workflow automatically loads versions from `.env.versions` - no manual intervention needed.

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

@@ -406,6 +406,34 @@ table {
   }
 }
 
+// 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);
@@ -458,3 +486,39 @@ table {
   }
 }
 
+// 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/20250401_review.md

@@ -1,84 +0,0 @@
-# Review
-
-1) 09h35 Marco
-business plan
-issue: value of software, depreciation
-FTE: around 100 overall, 3 full teams of developers
-tax discussion
-
-10h04 Discussions
-
-2) 10h10 Julius
-
-3) 10h27 Sebastiano - DevDay bis 10h40
-
-schriften bei votes größer - fragen sollten lesbar sein!
-
-devops is dead .... claim
-
-
-4) Stephan bis 10h55
-
-5) christopher 10h58
-
-6) robert 11:11
-* app
-* devops-pipelines
-* edp in osc deployed
-
-7) michal has nothing to show
-
-8) evgenii wants to finish -- 11:30
-
-9) patrick 11:32
-
-
-====
-
-projekt management meeting
-
-workshops, externe teams
-
-customer episodes
-
-wem was wo prinzipien
-|
-Rollen, Personas
-
-weiter die perspektive des nutzers bekommen, inneres verlangen eines developers, mein anspruch an das EDP
-(bekommen wir das hin, möchte ic damit arbeiten)
-
-level 2 erklimmen
-
-workshops halten
-
-senioren bekommen
-
-
-level1: source code structure, artefakte builden, revision control, branching model, e.g. pull requesting, tests der software, local debugging
-level2: automatisierung des artefakte-builds, versionsmgmt, milestones, tickets, issues, compliances an security
-level3: deployment auf stages, feedback pipeline verhalten
-level4: feedback app-verhalten (logs, metrics, alerts) + development loop
-level5: 3rd level support in production
-
-level1: coding
-source code structure, artefakte builden, revision control, branching model, e.g. pull requesting, tests der software, local debugging
-
-level2: reaching the outdside world with output
-automatisierung des artefakte-builds, versionsmgmt, milestones, tickets, issues, compliances an security
-
-level3: run the app anywhere
-deployment auf stages, feedback pipeline verhalten
-
-level4: monitoring the app
-feedback app-verhalten (logs, metrics, alerts) + development loop
-
-level5: support
-3rd level support in production (or any outer stage)
-
-
-sprint 4
-leveraging säule
-eigene app säule
-chore säule
-

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

@@ -38,13 +38,13 @@ TBD
 
 ### Argo Workflows + Events
 
-**Pro**
+#### Pro
 
 * integration with ArgoCD
 * ability to trigger additional workflows based on events.
 * level of maturity and community support.
 
-**Con**
+#### Con
 
 * Ability to self-host runners?
 * way how composition for pipelines works (based on Kubernetes CRDs)
@@ -57,53 +57,53 @@ TBD
 
 ### Argo Workflows + Events + Additional Composition tool
 
-**Pro**
+#### Pro
 
 * Composability can be offloaded to another tool
 
-**Con**
+#### Con
 
 * All cons of the previous option (except composability)
 * Additional complexity by adding another tool
 
 ### Forgejo Actions
 
-**Pro**
+#### 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**
+#### Con
 
 * level of maturity - will require additional investments to provide a production-grade system
 
 ### Forgejo Actions + Additional Tool
 
-**Pro**
+#### Pro
 
 * may be possible to use GitHub actions alongside another tool
 
-**Con**
+#### Con
 
 * additional complexity by adding another tool
 
 ### Shuttle
 
-**Pro**
+#### Pro
 
 * Possibility to clearly define interfaces for pipeline steps
 * Relatively simple
 
-**Con**
+#### Con
 
 * basically backed by only one company
 * **centralized templates**, so no mechanism for composing pipelines from multiple repositories
 
 ### Dagger
 
-**Pro**
+#### Pro
 
 * Pipeline as code
   * if it runs it should run anywhere and produce the "same" / somewhat stable results
@@ -112,13 +112,13 @@ TBD
 * 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**
+#### 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**
+#### 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

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/concepts/5_platforms/CNOE/_index.md

@@ -1,7 +1,7 @@
-+++
-title = "CNOE"
-weight = 4
-+++
+---
+title: CNOE
+weight: 4
+---
 
 
 * https://cnoe.io/docs/intro

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

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