diff --git a/.gitea/workflows/check-version.yml b/.gitea/workflows/check-version.yml
index 229b1ee..f30c35f 100644
--- a/.gitea/workflows/check-version.yml
+++ b/.gitea/workflows/check-version.yml
@@ -33,6 +33,8 @@ jobs:
           if [ -n "${VERSION_FILE}" ]; then
             if echo "${VERSION_FILE}" | grep -q '\.json$'; then
               RAW_VERSION=$(jq -r '.version' "${VERSION_FILE}")
+            elif echo "${VERSION_FILE}" | grep -q -E '\.ya?ml$'; then
+              RAW_VERSION=$(grep -oP '^version:\s*\K\S+' "${VERSION_FILE}")
             else
               RAW_VERSION=$(cat "${VERSION_FILE}" | tr -d '[:space:]')
             fi
@@ -42,10 +44,8 @@ jobs:
             RAW_VERSION=$(jq -r '.version' package.json)
           elif [ -f pom.xml ]; then
             RAW_VERSION=$(grep -oP '<version>\K[^<]+' pom.xml | head -1)
-          elif [ -f Chart.yaml ]; then
-            RAW_VERSION=$(grep -oP '^version:\s*\K\S+' Chart.yaml)
           else
-            echo "ERROR: No VERSION file, package.json, pom.xml, or Chart.yaml found" >&2
+            echo "ERROR: No VERSION file, package.json, Chart.yaml or pom.xml found" >&2
             exit 1
           fi
           BASE_VERSION=$(echo "$RAW_VERSION" | cut -d'.' -f1-2)
diff --git a/.gitea/workflows/git-pages.ci-main.yml b/.gitea/workflows/git-pages.ci-main.yml
new file mode 100644
index 0000000..5f5bbd4
--- /dev/null
+++ b/.gitea/workflows/git-pages.ci-main.yml
@@ -0,0 +1,47 @@
+name: CI Git-Pages Main
+on:
+  push:
+    branches:
+      - main
+      - feature/helm-chart
+    paths:
+      - git-pages/**
+      - .gitea/workflows/helm-build-push.yml
+      - .gitea/workflows/git-pages.*
+  workflow_dispatch:
+
+jobs:
+  load-config:
+    name: Load git-pages.gitea-env.conf to pipeline env
+    uses: niko/gitea-ci-library/.gitea/workflows/config-provider.yml@main
+    secrets: inherit
+    with:
+      config_path: .gitea/workflows/git-pages.gitea-env.conf
+
+  check-version:
+    name: Check existing artifact
+    needs: [load-config]
+    uses: niko/gitea-ci-library/.gitea/workflows/check-version.yml@main
+    secrets: inherit
+    with:
+      env_json: ${{ needs.load-config.outputs.env_json }}
+
+  helm-push:
+    name: Build & Push Helm chart
+    needs: [load-config, check-version]
+    if: needs.check-version.outputs.artifact_exists != 'true'
+    uses: niko/gitea-ci-library/.gitea/workflows/helm-build-push.yml@main
+    secrets: inherit
+    with:
+      env_json: ${{ needs.load-config.outputs.env_json }}
+      version: ${{ needs.check-version.outputs.version }}
+      chart_path: git-pages
+
+  report-summary:
+    name: Report Summary
+    needs: [load-config, helm-push]
+    if: always()
+    uses: niko/gitea-ci-library/.gitea/workflows/report-summary.yml@main
+    with:
+      env_json: ${{ needs.load-config.outputs.env_json }}
+      suites: ""
diff --git a/.gitea/workflows/git-pages.gitea-env.conf b/.gitea/workflows/git-pages.gitea-env.conf
new file mode 100644
index 0000000..c497b13
--- /dev/null
+++ b/.gitea/workflows/git-pages.gitea-env.conf
@@ -0,0 +1,5 @@
+GITEA_API_URL=https://gitea.app.keskikuja.site
+HELM_REGISTRY=gitea.app.keskikuja.site/niko
+HELM_UI_URL=https://gitea.app.keskikuja.site/niko/-/packages/container
+GIT_TAG_PREFIX=git-pages/
+VERSION_FILE=git-pages/Chart.yaml
diff --git a/.gitea/workflows/helm-build-push.yml b/.gitea/workflows/helm-build-push.yml
new file mode 100644
index 0000000..1f919e8
--- /dev/null
+++ b/.gitea/workflows/helm-build-push.yml
@@ -0,0 +1,97 @@
+name: Helm Build & Push
+on:
+  workflow_call:
+    inputs:
+      env_json:
+        required: true
+        type: string
+      version:
+        required: true
+        type: string
+      chart_path:
+        required: false
+        type: string
+        default: '.'
+    secrets:
+      GITEA_TOKEN:
+        required: true
+      HELM_USER:
+        required: false
+      HELM_PASSWORD:
+        required: true
+
+env:
+  GITEA_API_URL: ${{ fromJson(inputs.env_json).GITEA_API_URL }}
+  GITEA_TOKEN: ${{ secrets.GITEA_TOKEN }}
+  HELM_REGISTRY: ${{ fromJson(inputs.env_json).HELM_REGISTRY || '' }}
+  HELM_UI_URL: ${{ fromJson(inputs.env_json).HELM_UI_URL || '' }}
+  GIT_TAG_PREFIX: ${{ fromJson(inputs.env_json).GIT_TAG_PREFIX || '' }}
+  CHART_PATH: ${{ inputs.chart_path }}
+  VERSION: ${{ inputs.version }}
+
+concurrency:
+  group: ${{ github.workflow }}-${{ github.ref }}
+  cancel-in-progress: true
+
+jobs:
+  build-push:
+    runs-on: ubuntu-latest
+    container:
+      image: alpine/helm:3.19.0
+    steps:
+      - uses: actions/checkout@v4
+      - uses: actions/checkout@v4
+        with:
+          repository: niko/gitea-ci-library
+          path: .ci
+
+      - name: Package Helm chart
+        run: |
+          helm package "${CHART_PATH}" \
+            --version "${VERSION}" \
+            --app-version "${VERSION}" \
+            --destination /tmp/helm-packages
+
+      - name: Push to OCI registry
+        env:
+          HELM_USER: ${{ secrets.HELM_USER || github.actor }}
+          HELM_PASSWORD: ${{ secrets.HELM_PASSWORD }}
+        run: |
+          REGISTRY="${HELM_REGISTRY:?HELM_REGISTRY not set in env.conf}"
+          echo "$HELM_PASSWORD" | helm registry login "${REGISTRY}" \
+            -u "$HELM_USER" \
+            --password-stdin
+          helm push /tmp/helm-packages/*.tgz "oci://${REGISTRY}"
+          helm registry logout "${REGISTRY}"
+
+      - name: Report status with UI link
+        if: success() && env.HELM_UI_URL != ''
+        run: |
+          CHART_NAME=$(grep '^name:' "${CHART_PATH}/Chart.yaml" | awk '{print $2}')
+          UI_URL="${HELM_UI_URL}/${CHART_NAME}/${VERSION}"
+          bash .ci/scripts/report-status.sh success "Helm chart ${VERSION}" ci-helm-build-push "" "$UI_URL"
+
+  tag-commit:
+    runs-on: ubuntu-latest
+    needs: [build-push]
+    steps:
+      - uses: actions/checkout@v4
+
+      - name: Create git tag
+        env:
+          GITEA_TOKEN: ${{ secrets.GITEA_TOKEN }}
+          SERVER_URL: ${{ gitea.server_url }}
+          RUN_NUMBER: ${{ github.run_number }}
+          SHA: ${{ github.sha }}
+        run: |
+          HTTP_CODE=$(curl -s -o /dev/null -w "%{http_code}" -X POST \
+            "$SERVER_URL/api/v1/repos/${{ github.repository }}/tags" \
+            -H "Authorization: token $GITEA_TOKEN" \
+            -H "Content-Type: application/json" \
+            -d "{\"tag_name\": \"${GIT_TAG_PREFIX}${VERSION}\", \"message\": \"Build #$RUN_NUMBER\", \"target\": \"$SHA\"}")
+
+          if [ "$HTTP_CODE" = "201" ] || [ "$HTTP_CODE" = "409" ]; then
+            exit 0
+          else
+            exit 1
+          fi
diff --git a/guides/helm-registry-setup.md b/guides/helm-registry-setup.md
new file mode 100644
index 0000000..0f526fd
--- /dev/null
+++ b/guides/helm-registry-setup.md
@@ -0,0 +1,113 @@
+# Helm Registry Setup (OCI)
+
+Pipeline paketoi Helm chartin OCI-artefaktiksi ja pushee sen OCI-rekisteriin.
+
+---
+
+## 1. Konfiguroi `gitea-env.conf`
+
+```
+# HELM_REGISTRY on muotoa:  registry.example.com/org
+#
+#   host+org:              registry.example.com/org
+#
+# Pipeline rakentaa OCI-refin:  oci://${HELM_REGISTRY}/<chart-name>:${VERSION}
+# (chart-name tulee Chart.yaml:n name-kentästä)
+
+HELM_REGISTRY=gitea.app.keskikuja.site/niko                     # PAKOLLINEN — tyhjä ei käy
+HELM_UI_URL=                                                    # valinnainen — tarkista Giteasta kontin oma UI-osoite, workflow liittää perään /chart-name/VERSION
+GIT_TAG_PREFIX=git-pages/                                        # valinnainen — monorepo-tägäys
+VERSION_FILE=git-pages/Chart.yaml                                # valinnainen — jos Chart.yaml ei rootissa
+```
+
+| Kenttä | Pakollinen | Kuvaus |
+|---|---|---|
+| `HELM_REGISTRY` | **kyllä** | Registry host + owner (esim. `gitea.app.site/niko`). **Tyhjä pysäyttää workflow'n.** |
+| `HELM_UI_URL` | ei | Base-URL OCI-paketin UI-sivulle (ilman chart-nimeä ja versiota). Osoite riippuu onko paketti linkitetty repoon vai ei — tarkista Giteasta. Workflow liittää perään `/chart-name/VERSION`. Jos tyhjä, commit-statusia ei erikseen aseteta. |
+| `GIT_TAG_PREFIX` | ei | Etuliite git-tägille. Pakollinen monorepossa, jotta tagit eivät sekoitu muihin komponentteihin. |
+| `VERSION_FILE` | ei | Polku version lähteeseen (Chart.yaml, package.json, VERSION). Oletus: juuren `Chart.yaml`. |
+
+**OCI-ref = `oci://${HELM_REGISTRY}/<chart-name>:${VERSION}`**
+Esim. `oci://gitea.app.keskikuja.site/niko/git-pages:1.2.3`
+
+Chartin nimi (`<chart-name>`) määräytyy `Chart.yaml`-tiedoston `name`-kentästä.
+
+---
+
+## 2. Luo PAT (Personal Access Token) Giteassa
+
+**Gitea → oma profiili (oikea yläkulma) → Settings → Applications → Manage Access Tokens → Generate New Token**
+
+Valitse scope:
+
+| Scope | Pääsy |
+|---|---|
+| `package` | **Read and Write** |
+
+> Tämä token toimii salasanana `helm registry login` -komennossa. Muut scopet (kuten `repository`) eivät riitä — konttirekisteri vaatii nimenomaan `package`-scopen.
+
+Tokenin arvo näytetään **vain kerran** luomisen yhteydessä. Kopioi se talteen.
+
+---
+
+## 3. Tallenna PAT repositoryn Secretsiin
+
+Nämä ovat kaksi eri paikkaa:
+- **Access Tokenit** (User Settings) = missä luot tokenin
+- **Repository Secrets** (Repository Settings) = minne talletat sen workflow'n käyttöön
+
+**Repository → Settings → Actions → Secrets → Add new secret**
+
+| Secret | Arvo |
+|---|---|
+| `HELM_PASSWORD` | Edellisessä vaiheessa luotu PAT |
+
+`HELM_USER`-secretiä **ei tarvita**. Workflow käyttää automaattisesti `${{ github.actor }}` (workflowin käynnistäjä).
+
+Jos registry vaatii eri käyttäjätunnuksen kuin `github.actor` (esim. Harbor, Artifactory), lisää myös:
+
+| Secret | Arvo |
+|---|---|
+| `HELM_USER` | Registryn käyttäjätunnus |
+
+---
+
+## 4. Tarkistuslista ennen ajoa
+
+- [ ] `HELM_REGISTRY` asetettu `gitea-env.conf`issa
+- [ ] (tarvittaessa) `HELM_UI_URL` asetettu — ilman tätä commit-statusia ei erikseen aseteta
+- [ ] PAT luotu Giteassa scopella `package` Read and Write
+- [ ] `HELM_PASSWORD`-secret tallennettu repositoryn Secretsiin (se PAT)
+- [ ] (tarvittaessa) `HELM_USER`-secret — oletus `github.actor`
+
+---
+
+## 5. Esimerkkejä eri polkurakenteista
+
+### 5a. Hosti + org — Gitea user-taso
+
+```
+HELM_REGISTRY=gitea.app.keskikuja.site/niko
+```
+
+- OCI-ref: `oci://gitea.app.keskikuja.site/niko/git-pages:1.2.3`
+- Paketti käyttäjän `niko` alla. Linkitys repoon tehdään Gitean UI:sta: paketin sivulta (Package → Settings) → linkitä repositoryyn.
+- `HELM_PASSWORD` = Gitea PAT scopella `package`
+
+### 5b. Hosti + org — Harbor
+
+```
+HELM_REGISTRY=harbor.example.com/projekti
+```
+
+- `HELM_USER` = Harbor-käyttäjä
+- `HELM_PASSWORD` = Harbor-token
+
+### 5c. Artifactory
+
+```
+HELM_REGISTRY=artifactory.example.com/helm-local
+```
+
+- `HELM_USER` = service account
+- `HELM_PASSWORD` = API-token
diff --git a/skills/consumer-pipelines/REFERENCE.md b/skills/consumer-pipelines/REFERENCE.md
new file mode 100644
index 0000000..773b945
--- /dev/null
+++ b/skills/consumer-pipelines/REFERENCE.md
@@ -0,0 +1,480 @@
+# Consumer Pipelines — Reference
+
+Mallipohjat, esimerkit ja konfiguraatiot. Katso säännöt `SKILL.md`:stä.
+
+## Reititin — täydellinen esimerkki
+
+```yaml
+jobs:
+  load-config:
+    uses: <owner>/gitea-ci-library/.gitea/workflows/config-provider.yml@v1
+    secrets: inherit
+
+  <test-1>:
+    needs: [load-config]
+    uses: ./.gitea/workflows/<component>.<test-1>.yml
+    secrets: inherit
+    with:
+      env_json: ${{ needs.load-config.outputs.env_json }}
+
+  <test-2>:
+    needs: [load-config]
+    uses: ./.gitea/workflows/<component>.<test-2>.yml
+    secrets: inherit
+    with:
+      env_json: ${{ needs.load-config.outputs.env_json }}
+
+  report-summary:
+    needs: [load-config, <test-1>, <test-2>]
+    if: always()
+    uses: <owner>/gitea-ci-library/.gitea/workflows/report-summary.yml@v1
+    with:
+      env_json: ${{ needs.load-config.outputs.env_json }}
+      suites: <suite-1> <suite-2>
+```
+
+## CI-kontin build — parametroitu workflow
+
+CI-kontin build on `workflow_dispatch`-triggeröity job, joka näkyy Gitea Actionsissa kuten Jenkinsin
+parametroitu job — käyttäjä antaa inputit UI:sta ennen ajoa.
+
+```yaml
+name: CI Container Build <työkalu>
+on:
+  workflow_dispatch:
+    inputs:
+      config_path:
+        required: true
+        type: string
+        default: '.gitea/workflows/<komponentti>.gitea-env.conf'
+        description: 'Polku .gitea-env.conf-tiedostoon'
+      dockerfile_path:
+        required: true
+        type: string
+        default: '<komponentti>/Dockerfile.ci-<työkalu>'
+        description: 'Polku Dockerfileen'
+      image_name:
+        required: true
+        type: string
+        default: 'ci-<työkalu>'
+        description: 'Kontin nimi ilman registry-polkua'
+      tag:
+        required: true
+        type: string
+        default: 'latest'
+        description: 'Image-tägi'
+
+jobs:
+  load-config:
+    uses: <owner>/gitea-ci-library/.gitea/workflows/config-provider.yml@v1
+    secrets: inherit
+    with:
+      config_path: ${{ inputs.config_path }}
+
+  build-push:
+    needs: [load-config]
+    uses: <owner>/gitea-ci-library/.gitea/workflows/ci-container-build-push.yml@v1
+    secrets: inherit
+    with:
+      env_json: ${{ needs.load-config.outputs.env_json }}
+      dockerfile_path: ${{ inputs.dockerfile_path }}
+      image_name: ${{ inputs.image_name }}
+      tag: ${{ inputs.tag }}
+```
+
+### CI-kontin ajaminen testijobissa
+
+**Ainoa sallittu tapa** consumer-puolella on `container:`-direktiivi. `docker run` komennolla
+kontin käynnistäminen stepin sisällä on anti-pattern. `container:`-direktiivillä kaikki stepit
+ajetaan samassa kontissa — tiedostot ovat suoraan filesystemillä eikä erillistä
+volyyminhallintaa tarvita.
+
+```yaml
+jobs:
+  <työkalu>:
+    runs-on: ubuntu-latest
+    container:
+      image: ${{ inputs.<image-name> }}
+    steps:
+      - uses: actions/checkout@v4
+      - uses: actions/checkout@v4
+        with:
+          repository: <owner>/gitea-ci-library
+          path: .ci
+
+      - name: Run <työkalu>
+        shell: bash
+        run: |
+          mkdir -p "reports/<suite>"
+          <komento> > "reports/<suite>/results.txt" 2>&1
+
+      - name: Post-process reports
+        if: always()
+        run: |
+          <mahdollinen_raporttien_jälkikäsittely>
+
+      - name: Report
+        if: always()
+        run: bash .ci/scripts/ci-report.sh "<kuvaus>" <context> <suite> ${{ job.status }}
+```
+
+**Usean runnerin cache-ongelma:** Jos eri kerroilla käynnistyy eri runnereita,
+niillä voi olla eri versio `latest`-imagen digesteistä. Ratkaisuja:
+- Rebuildaa kontti ja aja `docker pull <image>` manuaalisesti kaikilla runnereilla
+- Käytä versioitua tagia (`v2`, `v3`, ...) ja päivitä workflow'n default buildauksen jälkeen
+
+**Mallit:**
+- `example-cucumber-tests.yml` — ei post-processia
+- `example-bats-tests.yml` — post-process coverage + report
+
+## Raporttitasot — tarkat YAML-mallit
+
+### Taso 1: Ei jälkikäsittelyä
+
+```yaml
+- name: Run tests
+  shell: bash
+  run: |
+    mkdir -p "reports/<suite>"
+    <testikomento>
+
+- name: Report
+  if: always()
+  run: bash .ci/scripts/ci-report.sh "<kuvaus>" <context> <suite> ${{ job.status }}
+```
+
+### Taso 2: Jälkikäsittely tarvitaan
+
+```yaml
+- name: Run tests
+  shell: bash
+  run: |
+    mkdir -p "reports/<suite>"
+    <testikomento> > "reports/<suite>/results.txt" 2>&1
+
+- name: Post-process coverage
+  if: always()
+  run: <siirrä coverage-data reports/<suite>/coverage/-hakemistoon>
+
+- name: Post-process test report
+  if: always()
+  run: <HTML-generointi raa'asta outputista>
+
+- name: Report
+  if: always()
+  run: bash .ci/scripts/ci-report.sh "<kuvaus>" <context> <suite> ${{ job.status }}
+```
+
+### Väärin vs oikein — yksi asia per step
+
+```yaml
+# VÄÄRIN — helm template fail → kubeconform jää ajamatta, report jää tekemättä
+- name: Run tests
+  run: |
+    helm template ... > /tmp/manifests.yaml
+    kubeconform ... > results.txt 2>&1
+
+# OIKEIN — erilliset stepit
+- name: Helm template
+  run: helm template platform-helm/ -f values.yaml > /tmp/manifests.yaml 2>&1
+
+- name: Kubeconform
+  if: success()
+  run: |
+    mkdir -p reports/kubeconform
+    kubeconform ... > reports/kubeconform/results.txt 2>&1
+
+- name: Report
+  if: always()
+  run: bash .ci/scripts/ci-report.sh "Helm kubeconform" helm-test kubeconform ${{ job.status }}
+```
+
+### Väärin vs oikein — post-process
+
+```yaml
+# VÄÄRIN — jos coverage epäonnistuu, report jää generoimatta
+- name: Post-process reports
+  run: |
+    bash .ci/.gitea/scripts/bats-coverage.sh reports/bats
+    bash .ci/.gitea/scripts/bats-report.sh reports/bats
+
+# OIKEIN — erilliset stepit if: always()
+- name: Post-process coverage
+  if: always()
+  run: bash .ci/.gitea/scripts/bats-coverage.sh reports/bats
+
+- name: Post-process test report
+  if: always()
+  run: bash .ci/.gitea/scripts/bats-report.sh reports/bats
+```
+
+## Raportin julkaisukelpoisuus
+
+`ci-report.sh` päättää onko raportti julkaisukelpoinen skannaamalla `reports/<suite>/`-hakemistoa.
+
+### Mitä skannataan
+
+| Mitä | Sääntö |
+|---|---|
+| **Tiedostot (FILES)** | Kaikki `reports/<suite>/`-juuressa olevat tiedostot paitsi `index.html` |
+| **Alihakemistot (SUBDIRS)** | Vain ne, joissa on `index.html` |
+
+### Julkaisukelpoisuus
+
+| Tila | Seuraus |
+|---|---|
+| `FILES + SUBDIRS = 0` | **Failure** — `ci-report.sh` palauttaa virheen, raporttia ei julkaista |
+| `FILES + SUBDIRS = 1` | Suora linkki itemiin — ei generoi index-sivua |
+| `FILES + SUBDIRS > 1` | Generoi `reports/<suite>/index.html`-sivun, linkit kaikkiin itemeihin |
+
+### Hakemistorakenne
+
+```
+reports/<suite>/
+├── results.txt               ← testin stdout (skannataan FILES)
+├── test-report.html          ← generoitu HTML (skannataan FILES)
+└── <mikä tahansa>/           ← alihakemisto (skannataan SUBDIRS)
+    └── index.html            ← VAIN jos tämä on olemassa
+```
+
+### Esimerkki: coverage-näkymä
+
+```
+reports/<suite>/coverage/index.html   ← on olemassa
+```
+
+Coverage-dataa ei siirretä automaattisesti. Testin tai post-process-stepin pitää
+siirtää coverage `reports/<suite>/coverage/`-hakemistoon ja varmistaa että `index.html` on mukana.
+
+**Provider vastuulla:** `ci-report.sh` (provider-skripti) hoitaa sekä hakemistorakenteen
+skannauksen, `index.html`-generoinnin että julkaisun git-pagesiin. Consumer tuottaa
+vain raakatiedostot `reports/<suite>/`-hakemistoon — `ci-report.sh` päättää
+julkaisukelpoisuuden ja generoi tarvittavan navigaation.
+
+## Debug-ohje: raportti ei näy
+
+### 1. Aja lokaalisti samalla komennolla kuin CI
+
+```bash
+mkdir -p reports/bats
+bashcov -- bats tests/ > reports/bats/results.txt 2>&1
+echo "exit: $?"
+ls -la reports/bats/
+```
+
+### 2. Lisää `echo "DEBUG: ..." >&2` ennen ja jälkeen kriittisen operaation
+
+```bash
+echo "DEBUG: coverage exists? $([ -d coverage ] && echo YES || echo NO)" >&2
+echo "DEBUG: target/index.html exists? $([ -f reports/suite/coverage/index.html ] && echo YES || echo NO)" >&2
+```
+
+### 3. Tarkista kutsuparametrit
+
+Yleisin virhe: skripti odottaa `$1` = X, mutta kutsuja antaa `$1` = Y ja `$2` = X.
+
+### 4. Tarkista tiedostopolut
+
+1. Onko lähdetiedosto olemassa ennen kopiointia?
+2. Onko kohde olemassa kopioinnin jälkeen?
+3. Onko `index.html` subdirissä (vaaditaan `ci-report.sh`:lle)?
+
+### 5. Poista debug-echot kun ongelma on korjattu
+
+### 6. Älä kokeile — debuggaa
+
+Kokeilu = arvaus. Debuggaus = lisää echo, aja, lue logi, eristä ongelma. Vasta sitten korjaa.
+
+## Konfiguraatiotiedosto (.gitea-env.conf)
+
+Tiedosto on `key=value`-muotoinen (kuten `.env`). Kommentit ja tyhjät rivit sallittuja.
+
+### Single repo
+
+```ini
+# .gitea/workflows/gitea-env.conf
+GITEA_API_URL=https://gitea.example.com
+GIT_PAGES_URL=https://reports.example.com
+```
+
+### Docker-artifaktin buildaavat projektit
+
+```ini
+DOCKER_REGISTRY=gitea.example.com/myorg
+DOCKER_IMAGE_NAME=my-service
+DOCKER_UI_URL=https://gitea.example.com/myorg/-/packages/container
+#DOCKERFILE=Dockerfile.platform   # valinnainen, oletus Dockerfile
+```
+
+`DOCKER_UI_URL` ei sisällä image-nimeä — se on puhdas container-registryn osoite.
+Image-nimi lisätään automaattisesti URL:iin `docker-build-push.yml`:ssä.
+
+### Helm-artifaktin buildaavat projektit
+
+```ini
+HELM_REGISTRY=gitea.example.com/myorg
+GIT_TAG_PREFIX=git-pages/
+VERSION_FILE=git-pages/Chart.yaml
+```
+
+| Kenttä | Pakollinen | Kuvaus |
+|---|---|---|
+| `HELM_REGISTRY` | **kyllä** | Registry host + owner, esim. `gitea.example.com/myorg`. **Tyhjä pysäyttää workflow'n.** |
+| `GIT_TAG_PREFIX` | ei | Etuliite git-tägille. Pakollinen monorepossa. |
+| `VERSION_FILE` | ei | Polku version lähteeseen. Oletus: juuren `Chart.yaml`. |
+
+### Salaisuudet (Gitea Settings → Secrets)
+
+| Secret | Pakollinen |
+|---|---|
+| `GITEA_TOKEN` | Aina (Gitean sisäinen, automaattisesti saatavilla) |
+| `GIT_PAGES_PUBLISH_TOKEN` | Aina |
+| `DOCKER_USERNAME` | Vain jos buildaat kontteja |
+| `DOCKER_PASSWORD` | Vain jos buildaat kontteja |
+| `HELM_USER` | Vain jos pushaat Helm chartin OCI-rekisteriin (oletus `github.actor`) |
+| `HELM_PASSWORD` | Vain jos pushaat Helm chartin OCI-rekisteriin |
+
+## Monorepo
+
+Monorepossa yhdessä repossa asuu useampi julkaistava komponentti. Jokaiselle komponentille
+oma conf-tiedosto `.gitea/workflows/<komponentti>.gitea-env.conf`.
+
+### Suositus: komponentit omiin juurihakemistoihin
+
+On suositeltavaa sijoittaa jokaisen komponentin koko lähdekoodi omaan juuritason
+hakemistoonsa (`api/`, `frontend/`, `shared/`). Tämä helpottaa `paths:`-filtteröintiä,
+pitää komponentit selkeästi erillään, ja tekee repossa navigoinnista suoraviivaista.
+
+### Ongelmat ja ratkaisut
+
+| Ongelma | Ratkaisu |
+|---|---|
+| Monta komponenttia, yksi repo — mikä triggeröi? | `paths:`-filtteri: `push: { paths: ['<komponentti>/**'] }` |
+| Jokaisella komponentilla oma versio | `VERSION_FILE=<komponentti>/package.json` confissa |
+| Git-tägit sekaisin ellei nimiavaruutta | `GIT_TAG_PREFIX=<komponentti>/` confissa → tägi `<komponentti>/1.2.3` |
+| Eri julkaisutahdit | Riippumattomat CI-triggerit, omat versiopolut |
+
+### Komponenttikohtainen conf
+
+```ini
+# .gitea/workflows/<komponentti>.gitea-env.conf
+GITEA_API_URL=https://gitea.example.com
+GIT_PAGES_URL=https://reports.example.com
+DOCKER_REGISTRY=gitea.example.com/myorg
+DOCKER_IMAGE_NAME=<image-nimi>
+DOCKER_UI_URL=https://gitea.example.com/myorg/-/packages/container
+GIT_TAG_PREFIX=<komponentti>/
+# Jompikumpi — JSON (.version-kenttä) tai plain text:
+VERSION_FILE=<komponentti>/package.json
+#VERSION_FILE=<komponentti>/VERSION
+```
+
+### Monorepo reititin
+
+```yaml
+name: CI <Komponentti> Main
+on:
+  push:
+    branches:
+      - main
+    paths:
+      - '<komponentti>/**'
+
+jobs:
+  load-config:
+    uses: <owner>/gitea-ci-library/.gitea/workflows/config-provider.yml@v1
+    secrets: inherit
+    with:
+      config_path: .gitea/workflows/<komponentti>.gitea-env.conf
+
+  check-version:
+    needs: [load-config]
+    uses: <owner>/gitea-ci-library/.gitea/workflows/check-version.yml@v1
+    secrets: inherit
+    with:
+      env_json: ${{ needs.load-config.outputs.env_json }}
+
+  <testit>:
+    needs: [load-config, check-version]
+    if: needs.check-version.outputs.artifact_exists != 'true'
+    uses: ./.gitea/workflows/<komponentti>.<testi>.yml
+    secrets: inherit
+    with:
+      env_json: ${{ needs.load-config.outputs.env_json }}
+
+  build-push:
+    needs: [load-config, check-version, <testit>]
+    if: needs.check-version.outputs.artifact_exists != 'true'
+    uses: <owner>/gitea-ci-library/.gitea/workflows/docker-build-push.yml@v1
+    secrets: inherit
+    with:
+      env_json: ${{ needs.load-config.outputs.env_json }}
+      version: ${{ needs.check-version.outputs.version }}
+
+  report-summary:
+    name: Report Summary
+    needs: [load-config, build-push]
+    if: always()
+    uses: <owner>/gitea-ci-library/.gitea/workflows/report-summary.yml@v1
+    with:
+      env_json: ${{ needs.load-config.outputs.env_json }}
+      suites: '<suite-1> <suite-2>'
+```
+
+### Version elinkaari per komponentti
+
+`GIT_TAG_PREFIX` takaa että eri komponenttien versiohistoria pysyy erillään.
+Git-tägi `<komponentti>/0.2.3` ei sekoitu toisen komponentin tägeihin.
+
+`check-version.yml` suodattaa ja laskee seuraavan patchin vain kyseisen
+komponentin etuliitteellä. Idempotenttius toimii komponenttikohtaisesti:
+jos commitilla on jo tägi, pipeline skipataan `if: artifact_exists != 'true'`.
+
+### Mitä EI kannata tehdä monorepossa
+
+- Älä aja kaikkia komponentteja samasta triggeristä — `paths:` pitää CI:t erillisinä
+- Älä käytä samaa versionhallintatiedostoa usealle komponentille
+- Älä anna monorepo-parametreja pipeline-overrideina — kaikki kuuluu conf-tiedostoon
+
+## Versionhallinta
+
+`check-version.yml` lukee version automaattisesti prioriteettijärjestyksessä:
+
+| # | Lähde | Formaatti |
+|---|---|---|
+| 1 | `VERSION_FILE` confissa | Määritelty polku |
+| 2 | `VERSION`-tiedosto (root) | Plain text |
+| 3 | `package.json` (root) | `.version`-kenttä |
+| 4 | `pom.xml` (root) | `<version>`-elementti |
+
+`major.minor` otetaan tästä. Patch lasketaan automaattisesti git-tageista.
+Esim. `VERSION` = `0.2`, tagit = `0.2.0`, `0.2.1` → seuraava `0.2.2`.
+
+## Branch protection (PR-gate)
+
+Gitean Settings → Branches → Add Rule:
+
+- **Branch:** `main`
+- **Enable Require Status Checks:** päälle
+- **Status checks:** valitse testijobien nimet
+
+## Provider-rajapinnat — referenssi
+
+### Workflowt
+
+| Workflow | Käyttötarkoitus |
+|---|---|
+| `config-provider.yml` | Lataa + validoi `.conf`, tuottaa `env_json` |
+| `check-version.yml` | Tarkistaa onko commit buildattu, laskee version |
+| `docker-build-push.yml` | Buildaa + puskea Docker-imagen, tagittaa commitin |
+| `helm-build-push.yml` | Paketoi + puskea Helm chartin OCI-rekisteriin, tagittaa commitin |
+| `report-summary.yml` | `GITHUB_STEP_SUMMARY`-taulukko raporttilinkeillä (Gitea 1.27+) |
+
+### Skriptit (kutsutaan `.ci/scripts/`-polun kautta)
+
+| Skripti | Käyttötarkoitus |
+|---|---|
+| `ci-report.sh` | Yhdistetty raportointi: julkaisee git-pagesiin ja asettaa commit-statuksen. Korvaa erilliset `publish-git-pages.sh` + `report-status.sh` -kutsut. Käyttö: `bash .ci/scripts/ci-report.sh "<kuvaus>" <context> <suite> ${{ job.status }}` |
+| `report-status.sh` | POSTaa commit-statuksen linkillä (kutsutaan `ci-report.sh`:n sisältä) |
+| `publish-git-pages.sh` | Julkaisee raporttihakemiston git-pagesiin (kutsutaan `ci-report.sh`:n sisältä) |
+| `ci-validate.sh` | Validoi `.conf`-tiedoston (kutsutaan `config-provider.yml`:stä) |
diff --git a/skills/consumer-pipelines/SKILL.md b/skills/consumer-pipelines/SKILL.md
index d4f2c12..9a5fd55 100644
--- a/skills/consumer-pipelines/SKILL.md
+++ b/skills/consumer-pipelines/SKILL.md
@@ -19,6 +19,8 @@ impact: high
 Säännöt joilla consumer-projektit rakentavat CI-pipelinejä `gitea-ci-library`-kirjaston päälle.
 Nämä eivät ole provider-kirjaston sääntöjä — ne kuvaavat miten consumerin kuuluu käyttää kirjastoa oikein.
 
+Katso tarkat mallipohjat ja esimerkit `REFERENCE.md`:stä.
+
 ## 1. Reitittimen puhtaus
 
 Reitittimet (`ci-feature.yml`, `ci-main.yml`) eivät sisällä `run:`-steppejä. Ne koostuvat vain:
@@ -36,36 +38,7 @@ with:
 Jokainen job vastaa yhtä loogista testiä tai operaatiota. Reititin on orkestraattori — kaikki suorittava
 logiikka on omassa `workflow_call`-tiedostossaan.
 
-**Esimerkki:**
-
-```yaml
-jobs:
-  load-config:
-    uses: <owner>/gitea-ci-library/.gitea/workflows/config-provider.yml@v1
-    secrets: inherit
-
-  <test-1>:
-    needs: [load-config]
-    uses: ./.gitea/workflows/<component>.<test-1>.yml
-    secrets: inherit
-    with:
-      env_json: ${{ needs.load-config.outputs.env_json }}
-
-  <test-2>:
-    needs: [load-config]
-    uses: ./.gitea/workflows/<component>.<test-2>.yml
-    secrets: inherit
-    with:
-      env_json: ${{ needs.load-config.outputs.env_json }}
-
-  report-summary:
-    needs: [load-config, <test-1>, <test-2>]
-    if: always()
-    uses: <owner>/gitea-ci-library/.gitea/workflows/report-summary.yml@v1
-    with:
-      env_json: ${{ needs.load-config.outputs.env_json }}
-      suites: <suite-1> <suite-2>
-```
+Katso täydellinen esimerkki `REFERENCE.md`:stä.
 
 ## 2. Yksi asia per tiedosto
 
@@ -89,310 +62,60 @@ ja exit-koodi välittyy natiivisti. Ylimääräistä `EXIT=$?` + `echo >> GITHUB
     <testikomento> > results.txt 2>&1
 ```
 
-**Miksi ei pipeä (`| tee`):**
+**Miksi ei pipeä (`| tee`):** `|` syö exit-koodin. Käytä redirectiä `>`.
 
-```bash
-# VÄÄRIN — pipe syö exit-koodin
-<komento> | tee results.txt
-
-# OIKEIN — redirect tiedostoon
-<komento> > results.txt 2>&1
-```
-
-`set -e` ei pelasta pipe-tilanteessa — `|` syö exit-koodin kuten ennenkin. Redirectillä exit-koodi
-välittyy luonnollisesti.
-
-**Yksi asia per step:** Älä koskaan niputa useaa komentoa samaan `run:`-blockiin — oli kyse
-sitten post-processista tai testi- / tarkistusvaiheista. `bash -e` pysäyttää koko stepin
-ensimmäisellä failaavalla komennolla, ja loput jäävät ajamatta.
-
-```yaml
-# VÄÄRIN — helm template fail → kubeconform jää ajamatta, report jää tekemättä
-- name: Run tests
-  run: |
-    helm template ... > /tmp/manifests.yaml
-    kubeconform ... > results.txt 2>&1
-
-# OIKEIN — erilliset stepit
-- name: Helm template
-  run: helm template platform-helm/ -f values.yaml > /tmp/manifests.yaml 2>&1
-
-- name: Kubeconform
-  if: success()
-  run: |
-    mkdir -p reports/kubeconform
-    kubeconform ... > reports/kubeconform/results.txt 2>&1
-
-- name: Report
-  if: always()
-  run: bash .ci/scripts/ci-report.sh "Helm kubeconform" helm-test kubeconform ${{ job.status }}
-```
-
-Sama pätee post-process-steppeihin. Älä koskaan niputa useaa post-process-komentoa
-samaan `run:`-blockiin. Käytä erillisiä steppejä `if: always()`:lla, jotta jokainen
-vaihe ajetaan itsenäisesti:
-
-```yaml
-# VÄÄRIN — jos coverage epäonnistuu, report jää generoimatta
-- name: Post-process reports
-  run: |
-    bash .ci/.gitea/scripts/bats-coverage.sh reports/bats
-    bash .ci/.gitea/scripts/bats-report.sh reports/bats
-
-# OIKEIN — erilliset stepit if: always()
-- name: Post-process coverage
-  if: always()
-  run: bash .ci/.gitea/scripts/bats-coverage.sh reports/bats
-
-- name: Post-process test report
-  if: always()
-  run: bash .ci/.gitea/scripts/bats-report.sh reports/bats
-```
+**Yksi asia per step:** Älä koskaan niputa useaa komentoa samaan `run:`-blockiin. `bash -e` pysäyttää
+koko stepin ensimmäisellä failaavalla komennolla, ja loput jäävät ajamatta. Sama pätee post-process-steppeihin.
 
 ## 4. Konttipolitiikka
 
 1. **Julkiset registry-kontit kiinteällä versiolla** — `alpine/helm:3.19.0`, `node:22`, `maven:3.9-eclipse-temurin-21`.
-   Toistettavuus ja turvallisuus eivät saa riippua ulkoisesta `latest`:sta
+   Toistettavuus ja turvallisuus eivät saa riippua ulkoisesta `latest`:sta.
 2. **Projektin omat CI-kontit `latest`-tägillä** — buildattu `ci-container-build-<kontti>.yml`:llä.
    Kontin build-pipeline päivittää `latest`:n automaattisesti. Rebuild = käyttöönotto
    kaikissa pipelineissa ilman versioviittauksien päivittelyä.
-   `latest` on näille paras käytäntö, ei kompromissi
 3. **Ei koskaan `curl`-latauksia CI-ajon sisällä** — työkalujen asennus CI-stepeissä hidastaa,
-   epäluotettavaa, ja vaikeuttaa toistettavuutta
+   epäluotettavaa, ja vaikeuttaa toistettavuutta.
 4. **Konttikuva hallitaan workflow'ssa, ei kutsujassa** — jos workflow vaatii tietyn
    konttikuvan, se määritellään oletuksena (`default:`) workflow'n inputissa.
    Kutsujan ei tarvitse tietää eikä välittää image-nimeä ellei halua ylikirjoittaa.
 
-CI-kontin build-workflow'n template: [skills/ci-container-build/SKILL.md](../ci-container-build/SKILL.md) — sisältää
-valmiin `ci-container-build-<kontti>.yml`-pohjan jossa `workflow_dispatch`-tuki manuaaliajoon.
+CI-kontin build-workflow'n template: `skills/ci-container-build/SKILL.md`.
 
 ### 4.1 CI-kontin ajaminen jobissa
 
 Ainoa sallittu tapa on `container:`-direktiivi. `docker run` komennolla kontin
 käynnistäminen stepin sisällä on anti-pattern.
 
-**Miksi:** `docker run` erilliskonttina aiheuttaa:
-- Tiedostojen jako vaatii erillisen volyyminhallinnan (`docker volume create`)
-- Coverage-data jää volyymiin, ei filesystemille → post-process-skriptit eivät löydä sitä
-- Ylimääräisiä siirtoja (`tar`, `docker cp`), jotka voivat epäonnistua hiljaa
-- Vaikeampi debugata (data on kontissa, ei CWD:ssä)
-
-`container:`-direktiivillä kaikki ajetaan samassa kontissa — tiedostot ovat suoraan
-filesystemillä, post-process-skriptit näkevät ne ilman erillistä siirtoa.
-
-```yaml
-jobs:
-  <työkalu>:
-    runs-on: ubuntu-latest
-    container:
-      image: ${{ inputs.<image-name> }}
-    steps:
-      - uses: actions/checkout@v4
-      - uses: actions/checkout@v4
-        with:
-          repository: <owner>/gitea-ci-library
-          path: .ci
-
-      - name: Run <työkalu>
-        shell: bash
-        run: |
-          mkdir -p "reports/<suite>"
-          <komento> > "reports/<suite>/results.txt" 2>&1
-
-      - name: Post-process reports
-        if: always()
-        run: |
-          <mahdollinen_raporttien_jälkikäsittely>
-
-      - name: Report
-        if: always()
-        run: bash .ci/scripts/ci-report.sh "<kuvaus>" <context> <suite> ${{ job.status }}
-```
+Katso CI-kontin template `REFERENCE.md`:stä.
 
 **Huomio `actions/checkout@v4`:stä:** `container:`-direktiivillä kaikki stepit
 ajetaan kontin *sisällä* — myös `actions/checkout@v4`. Se on JavaScript-action
-joka vaatii sekä `nodejs` että `git`. Ilman kumpaa tahansa checkout feilaa
-`exit 127`.
-
-```dockerfile
-# Varmista että kontissa on nodejs + git
-RUN apk add --no-cache nodejs git
-```
-
-**Tarkista siis aina** että CI-kontin Dockerfilessä on sekä `nodejs` että `git`
-asennettuna. Sama pätee mihin tahansa konttiin jota käytetään `container:`-direktiivillä.
-
-**Usean runnerin cache-ongelma:** Jos eri kerroilla käynnistyy eri runnereita,
-niillä voi olla eri versio `latest`-imagen digesteistä. Tämä on `latest`-tagin
-tunnettu ongelma. Ratkaisuja:
-- Rebuildaa kontti ja aja `docker pull <image>` manuaalisesti kaikilla
-  runnereilla
-- Käytä versioitua tagia (`v2`, `v3`, ...) ja päivitä workflow'n default
-  buildauksen jälkeen
-
-Jos testi tuottaa raportteja suoraan ilman jälkikäsittelyä, Post-process-steppiä ei tarvita.
-Jos jälkikäsittely on tarpeen (coverage-siirto, HTML-generointi raa'asta outputista),
-se tehdään omassa stepissä `if: always()` — katso tarkemmin [Raporttitasot](#5-raporttitasot).
-
-**Mallit:**
-- `example-cucumber-tests.yml` — ei post-processia
-- `example-bats-tests.yml` — post-process coverage + report
+joka vaatii sekä `nodejs` että `git`. Varmista että CI-kontin Dockerfilessä on molemmat.
 
 ## 5. Raporttitasot
 
 Testi tuottaa raportin `reports/<suite>/`-hakemistoon. Yksi `ci-report.sh`-kutsu hoitaa sekä
-julkaisun että commit-statuksen — erillistä Publish + Report Status -kaksivaiheisuutta ei tarvita.
+julkaisun että commit-statuksen.
 
 ### Taso 1: Ei jälkikäsittelyä
 
 Kun testi tuottaa raportit suoraan (kuten `pytest --html` tai `cucumber-js --format html`):
-
-```yaml
-- name: Run tests
-  shell: bash
-  run: |
-    mkdir -p "reports/<suite>"
-    <testikomento>
-
-- name: Report
-  if: always()
-  run: bash .ci/scripts/ci-report.sh "<kuvaus>" <context> <suite> ${{ job.status }}
-```
+- testi kirjoittaa `reports/<suite>/`-hakemistoon
+- `ci-report.sh` julkaisee ja asettaa commit-statuksen
 
 ### Taso 2: Jälkikäsittely tarvitaan
 
 Kun testi tuottaa raakadataa (stdout, coverage-tiedostot) joka pitää muuntaa tai siirtää
-`reports/<suite>/`-hakemistoon, käytetään Post-process-steppejä. **Jokainen operaatio
-omassa stepissään** — älä koskaan niputa useaa post-process-komentoa samaan `run:`-blockiin:
+`reports/<suite>/`-hakemistoon. **Jokainen operaatio omassa stepissään** `if: always()`.
 
-```yaml
-- name: Run tests
-  shell: bash
-  run: |
-    mkdir -p "reports/<suite>"
-    <testikomento> > "reports/<suite>/results.txt" 2>&1
-
-- name: Post-process coverage
-  if: always()
-  run: <siirrä coverage-data reports/<suite>/coverage/-hakemistoon>
-
-- name: Post-process test report
-  if: always()
-  run: <HTML-generointi raa'asta outputista>
-
-- name: Report
-  if: always()
-  run: bash .ci/scripts/ci-report.sh "<kuvaus>" <context> <suite> ${{ job.status }}
-```
-
-**Huomio subdir-sisällöstä:** Jos testi tuottaa dataa alihakemistoon (esim.
-coverage `./coverage/`-kansioon), se pitää erikseen SIIRTÄÄ
-`reports/<suite>/<subdir>/`-hakemistoon ennen `ci-report.sh`:n ajoa.
-Ilman siirtoa sisältö ei näy index-sivulla, vaikka työkalu tuottaisi sen oikein.
-Subdir vaatii lisäksi `index.html`:n, jotta `ci-report.sh` löytää sen.
-
-**Miksi:** Gitea Actions käyttää `bash -e`-oletusta. Jos yksi post-process-komento
-epäonnistuu (esim. `set -euo pipefail`-skripti), koko stepi pysähtyy eivätkä seuraavat
-komennot käynnisty — raportti jää julkaisematta. Erilliset stepit `if: always()` takaavat
-että jokainen post-process-vaihe ajetaan itsenäisesti.
-
-### Monta raportoitavaa tiedostoa
-
-Kun `reports/<suite>/`-hakemistossa on useita tiedostoja tai alihakemistoja,
-`ci-report.sh` generoi automaattisesti `reports/<suite>/index.html` jos hakemistossa
-on enemmän kuin yksi raportoitava item.
-
-```
-reports/<suite>/
-├── results.txt               ← testin stdout (skannataan FILES)
-├── test-report.html          ← generoitu HTML (skannataan FILES)
-└── <mikä tahansa>/           ← alihakemisto (skannataan SUBDIRS)
-    └── index.html            ← VAIN jos tämä on olemassa
-```
+Tarkat YAML-mallit molemmista tasoista: `REFERENCE.md`.
 
 **Subdir-sääntö:** Alihakemisto näkyy indexissä VAIN jos se sisältää `index.html`:n.
-Pelkkä tyhjä subdir ilman `index.html`:ää ei näy — tämä on yleisin syy miksi
-jokin raportin osa (kuten coverage) puuttuu indexistä.
 
-## 6. Raportin julkaisukelpoisuus
+## 6. Nimeäminen
 
-`ci-report.sh` päättää onko raportti julkaisukelpoinen skannaamalla
-`reports/<suite>/`-hakemistoa.
-
-### Mitä skannataan
-
-| Mitä | Sääntö |
-|---|---|
-| **Tiedostot (FILES)** | Kaikki `reports/<suite>/`-juuressa olevat tiedostot paitsi `index.html` |
-| **Alihakemistot (SUBDIRS)** | Vain ne, joissa on `index.html` |
-
-### Julkaisukelpoisuus
-
-| Tila | Seuraus |
-|---|---|
-| `FILES + SUBDIRS = 0` | **Failure** — `ci-report.sh` palauttaa virheen, raporttia ei julkaista |
-| `FILES + SUBDIRS = 1` | Suora linkki itemiin — ei generoi index-sivua |
-| `FILES + SUBDIRS > 1` | Generoi `reports/<suite>/index.html`-sivun, linkit kaikkiin itemeihin |
-
-### Esimerkki: coverage-näkymä
-
-```
-reports/<suite>/coverage/index.html   ← on olemassa
-```
-
-Coverage-dataa ei siirretä automaattisesti. Testin tai post-process-stepin pitää
-siirtää coverage `reports/<suite>/coverage/`-hakemistoon ja varmistaa että
-`index.html` on mukana. Sama periaate pätee mihin tahansa subdir-sisältöön.
-
-## 7. Debug-ohje: raportti ei näy
-
-### 1. Aja lokaalisti samalla komennolla kuin CI
-
-Näet mitä tiedostoja syntyy, mihin ne tulevat ja mikä on työkalun exit-koodi.
-
-```bash
-# Esimerkki
-mkdir -p reports/bats
-bashcov -- bats tests/ > reports/bats/results.txt 2>&1
-echo "exit: $?"
-ls -la reports/bats/
-```
-
-### 2. Lisää `echo "DEBUG: ..." >&2` ennen ja jälkeen kriittisen operaation
-
-Debuggaus stderriin (`>&2`) näkyy CI-logissa eikä häiritse skriptin normaalia outputia.
-
-```bash
-echo "DEBUG: coverage exists? $([ -d coverage ] && echo YES || echo NO)" >&2
-echo "DEBUG: target/index.html exists? $([ -f reports/suite/coverage/index.html ] && echo YES || echo NO)" >&2
-```
-
-### 3. Tarkista kutsuparametrit
-
-Yleisin virhe: skripti odottaa `$1` = X, mutta kutsuja antaa `$1` = Y ja `$2` = X.
-Skripti lukee väärän parametrin ja etsii dataa väärästä paikasta.
-
-### 4. Tarkista tiedostopolut
-
-1. Onko lähdetiedosto olemassa ennen kopiointia?
-2. Onko kohde olemassa kopioinnin jälkeen?
-3. Onko `index.html` subdirissä (vaaditaan `ci-report.sh`:lle)?
-
-Jos vastaus johonkin on "ei" — tiedät mikä pitää korjata.
-
-### 5. Poista debug-echot kun ongelma on korjattu
-
-Debug-rivit eivät kuulu tuotantoon.
-
-### 6. Älä kokeile — debuggaa
-
-Kokeilu = arvaus. Debuggaus = lisää echo, aja, lue logi, eristä ongelma.
-Vasta sitten korjaa. Tämä on nopeampi tie oikeaan ratkaisuun.
-
-## 8. Nimeäminen
-
-Tiedostonimet `.gitea/workflows/`-kansiossa noudattavat yhtenäistä rakennetta, jotta
-tiedostot löytyvät nopeasti ja niiden rooli on selvillä:
+Tiedostonimet `.gitea/workflows/`-kansiossa noudattavat yhtenäistä rakennetta:
 
 ```
 <komponentti>.ci-feature.yml                  ← feature-haaran reititin
@@ -402,216 +125,35 @@ tiedostot löytyvät nopeasti ja niiden rooli on selvillä:
 <komponentti>.gitea-env.conf                  ← komponenttikohtainen konfiguraatio
 ```
 
-Single repossa `<komponentti>` jätetään pois — tiedostot ovat suoraan `ci-feature.yml`,
-`ci-main.yml`, `<testityyppi>.yml`, `ci-container-build-<kontti>.yml`.
+Single repossa `<komponentti>` jätetään pois.
+Monorepossa prefiksi pitää komponentin tiedostot yhdessä.
 
-Monorepossa prefiksi pitää komponentin tiedostot yhdessä: `ls <komponentti>.*` löytää kaikki
-kerralla.
-
-## 9. Artifact-kuri
+## 7. Artifact-kuri
 
 Gitea Actionsin `upload-artifact` jättää pysyvän tiedoston. Artifakteja ei käytetä
-workflow_call:ien väliseen datan siirtoon ellei se ole teknisesti välttämätöntä.
+`workflow_call`:ien väliseen datan siirtoon ellei se ole teknisesti välttämätöntä.
 
 **Ensisijainen ratkaisu:** jokainen testi tuottaa tarvitsemansa datan itse. Ei
 `upload-artifact` + `download-artifact` -riippuvuuksia.
 
-```yaml
-# OIKEIN — molemmat testit tuottavat oman datansa
-- name: Prepare data
-  run: <komento> > /tmp/data
-- name: Validate data
-  run: <validointikomento> /tmp/data
-```
+## 8. Report-Summary — pakollinen jokaisen pipelinen lopuksi
 
-**Miksi:**
-- Testit pysyvät itsenäisinä — yhden testin fail ei estä muita
-- Ei "artifact expired" -virheitä myöhemmin
-- Ei pysyviä artifakteja siivoamatta
+Jokaisen reitittimen (oli se `ci-main.yml`, `ci-feature.yml` tai mikä tahansa) viimeinen job on `report-summary`.
 
----
+**Säännöt:**
+- `needs:` sisältää **kaikki edeltävät jobit** — summary odottaa että kaikki on valmis (onnistui tai ei)
+- `if: always()` — ajetaan aina, vaikka pipeline olisi keskeytetty tai joku jobi failannut
+- `suites:` on välilyönnein eroteltu lista suiten nimistä (esim. `bats cucumber`). Tyhjä merkkijono sallittu jos testisuiteja ei ole.
+- Provider (`report-summary.yml`) hoitaa summaryn logiikan — reititin vain kutsuu
 
-## Konfiguraatiotiedosto (.gitea-env.conf)
+**Miksi aina:**
+- Gitea 1.27+ näyttää `GITHUB_STEP_SUMMARY`:n Actions UI:ssa. Ilman summarya pipeline näyttää epätäydelliseltä.
+- Summaryyn voidaan myöhemmin lisätä muutakin kuin testilinkkejä (build-artefaktit, deploy-tiedot).
+- Yhtenäinen rakenne jokaisessa pipeline-parissa vähentää kysymyksiä.
 
-Tiedosto on `key=value`-muotoinen (kuten `.env`). Kommentit ja tyhjät rivit sallittuja.
+YAML-malli: `REFERENCE.md`.
 
-### Single repo
-
-```ini
-# .gitea/workflows/gitea-env.conf
-GITEA_API_URL=https://gitea.example.com
-GIT_PAGES_URL=https://reports.example.com
-```
-
-### Docker-artifaktin buildaavat projektit
-
-```ini
-DOCKER_REGISTRY=gitea.example.com/myorg
-DOCKER_IMAGE_NAME=my-service
-DOCKER_UI_URL=https://gitea.example.com/myorg/-/packages/container
-#DOCKERFILE=Dockerfile.platform   # valinnainen, oletus Dockerfile
-```
-
-`DOCKER_UI_URL` ei sisällä image-nimeä — se on puhdas container-registryn osoite.
-Image-nimi lisätään automaattisesti URL:iin `docker-build-push.yml`:ssä.
-
-### Salaisuudet (Gitea Settings → Secrets)
-
-| Secret | Pakollinen |
-|---|---|
-| `GITEA_TOKEN` | Aina (Gitean sisäinen, automaattisesti saatavilla) |
-| `GIT_PAGES_PUBLISH_TOKEN` | Aina |
-| `DOCKER_USERNAME` | Vain jos buildaat kontteja |
-| `DOCKER_PASSWORD` | Vain jos buildaat kontteja |
-
----
-
-## Monorepo
-
-Monorepossa yhdessä repossa asuu useampi julkaistava komponentti. Jokaiselle komponentille
-oma conf-tiedosto `.gitea/workflows/<komponentti>.gitea-env.conf`, jossa on kaikki
-komponenttikohtainen tieto.
-
-### Suositus: komponentit omiin juurihakemistoihin
-
-On suositeltavaa sijoittaa jokaisen komponentin koko lähdekoodi omaan juuritason
-hakemistoonsa (`api/`, `frontend/`, `shared/`). Tämä helpottaa `paths:`-filtteröintiä,
-pitää komponentit selkeästi erillään, ja tekee repossa navigoinnista suoraviivaista.
-Tämä on kuitenkin vain suositus — ei pakottava sääntö.
-
-### Ongelmat ja ratkaisut
-
-| Ongelma | Ratkaisu |
-|---|---|
-| Monta komponenttia, yksi repo — mikä triggeröi? | `paths:`-filtteri: `push: { paths: ['<komponentti>/**'] }` |
-| Jokaisella komponentilla oma versio | `VERSION_FILE=<komponentti>/package.json` confissa |
-| Git-tägit sekaisin ellei nimiavaruutta | `GIT_TAG_PREFIX=<komponentti>/` confissa → tägi `<komponentti>/1.2.3` |
-| Eri julkaisutahdit | Riippumattomat CI-triggerit, omat versiopolut |
-
-### Komponenttikohtainen conf
-
-```ini
-# .gitea/workflows/<komponentti>.gitea-env.conf
-GITEA_API_URL=https://gitea.example.com
-GIT_PAGES_URL=https://reports.example.com
-DOCKER_REGISTRY=gitea.example.com/myorg
-DOCKER_IMAGE_NAME=<image-nimi>
-DOCKER_UI_URL=https://gitea.example.com/myorg/-/packages/container
-GIT_TAG_PREFIX=<komponentti>/
-# Jompikumpi — JSON (.version-kenttä) tai plain text:
-VERSION_FILE=<komponentti>/package.json
-#VERSION_FILE=<komponentti>/VERSION
-```
-
-### Monorepo reititin
-
-```yaml
-name: CI <Komponentti> Main
-on:
-  push:
-    branches:
-      - main
-    paths:
-      - '<komponentti>/**'
-
-jobs:
-  load-config:
-    uses: <owner>/gitea-ci-library/.gitea/workflows/config-provider.yml@v1
-    secrets: inherit
-    with:
-      config_path: .gitea/workflows/<komponentti>.gitea-env.conf
-
-  check-version:
-    needs: [load-config]
-    uses: <owner>/gitea-ci-library/.gitea/workflows/check-version.yml@v1
-    secrets: inherit
-    with:
-      env_json: ${{ needs.load-config.outputs.env_json }}
-
-  <testit>:
-    needs: [load-config, check-version]
-    if: needs.check-version.outputs.artifact_exists != 'true'
-    uses: ./.gitea/workflows/<komponentti>.<testi>.yml
-    secrets: inherit
-    with:
-      env_json: ${{ needs.load-config.outputs.env_json }}
-
-  build-push:
-    needs: [load-config, check-version, <testit>]
-    if: needs.check-version.outputs.artifact_exists != 'true'
-    uses: <owner>/gitea-ci-library/.gitea/workflows/docker-build-push.yml@v1
-    secrets: inherit
-    with:
-      env_json: ${{ needs.load-config.outputs.env_json }}
-      version: ${{ needs.check-version.outputs.version }}
-```
-
-### Version elinkaari per komponentti
-
-`GIT_TAG_PREFIX` takaa että eri komponenttien versiohistoria pysyy erillään.
-Git-tägi `<komponentti>/0.2.3` ei sekoitu toisen komponentin tägeihin.
-
-`check-version.yml` suodattaa ja laskee seuraavan patchin vain kyseisen
-komponentin etuliitteellä. Idempotenttius toimii komponenttikohtaisesti:
-jos commitilla on jo tägi, pipeline skipataan `if: artifact_exists != 'true'`.
-
-### Mitä EI kannata tehdä monorepossa
-
-- Älä aja kaikkia komponentteja samasta triggeristä — `paths:` pitää CI:t erillisinä
-- Älä käytä samaa versionhallintatiedostoa usealle komponentille
-- Älä anna monorepo-parametreja pipeline-overrideina — kaikki kuuluu conf-tiedostoon
-
----
-
-## Versionhallinta
-
-`check-version.yml` lukee version automaattisesti prioriteettijärjestyksessä:
-
-| # | Lähde | Formaatti |
-|---|---|---|
-| 1 | `VERSION_FILE` confissa | Määritelty polku |
-| 2 | `VERSION`-tiedosto (root) | Plain text |
-| 3 | `package.json` (root) | `.version`-kenttä |
-| 4 | `pom.xml` (root) | `<version>`-elementti |
-
-`major.minor` otetaan tästä. Patch lasketaan automaattisesti git-tageista.
-Esim. `VERSION` = `0.2`, tagit = `0.2.0`, `0.2.1` → seuraava `0.2.2`.
-
----
-
-## Branch protection (PR-gate)
-
-Gitean Settings → Branches → Add Rule:
-
-- **Branch:** `main`
-- **Enable Require Status Checks:** päälle
-- **Status checks:** valitse testijobien nimet
-
----
-
-## Provider-rajapinnat — referenssi
-
-### Workflowt
-
-| Workflow | Käyttötarkoitus |
-|---|---|
-| `config-provider.yml` | Lataa + validoi `.conf`, tuottaa `env_json` |
-| `check-version.yml` | Tarkistaa onko commit buildattu, laskee version |
-| `docker-build-push.yml` | Buildaa + puskea Docker-imagen, tagittaa commitin |
-| `report-summary.yml` | `GITHUB_STEP_SUMMARY`-taulukko raporttilinkeillä (Gitea 1.27+) |
-
-### Skriptit (kutsutaan `.ci/scripts/`-polun kautta)
-
-| Skripti | Käyttötarkoitus |
-|---|---|
-| `ci-report.sh` | Yhdistetty raportointi: julkaisee git-pagesiin ja asettaa commit-statuksen. Korvaa erilliset `publish-git-pages.sh` + `report-status.sh` -kutsut. Käyttö: `bash .ci/scripts/ci-report.sh "<kuvaus>" <context> <suite> ${{ job.status }}` |
-| `report-status.sh` | POSTaa commit-statuksen linkillä (kutsutaan `ci-report.sh`:n sisältä) |
-| `publish-git-pages.sh` | Julkaisee raporttihakemiston git-pagesiin (kutsutaan `ci-report.sh`:n sisältä) |
-| `ci-validate.sh` | Validoi `.conf`-tiedoston (kutsutaan `config-provider.yml`:stä) |
-
----
-
-## ADR-yhteenveto — consumerin kannalta oleelliset säännöt
+## 9. ADR-yhteenveto — consumerin kannalta oleelliset säännöt
 
 ### Reititin ei sisällä suorittavaa koodia (ADR 0010)
 
@@ -631,25 +173,18 @@ sisäiseen dogfood-käyttöön. Breaking changet kielletty — `v1`-rajapinta on
 ### Paikalliset `uses:` eivät käytä refiä
 
 Gitea act runner v1.0.8 muodostaa paikallisista `uses: ./.gitea/workflows/*.yml@main`-viittauksista
-epävalidin git-refin `main@<sha>`, joka aiheuttaa virheen `Revision invalid : reference must
-be defined once at the beginning`.
+epävalidin git-refin `main@<sha>`.
 
 Paikallisista `uses:`-direktiiveistä EI koskaan käytetä `@main`- tai muuta ref-päätettä:
 - `uses: ./.gitea/workflows/chart.helm-lint.yml`  ← oikein
 - `uses: ./.gitea/workflows/chart.helm-lint.yml@main` ← väärin
 
-Ilman refiä runner käyttää workflow'ta triggeröivästä commitista. Ulkoisten repojen
-viittauksissa (`niko/...@v1`) pääte pysyy. Nämä resolvoidaan eri reittiä ja toimivat oikein.
+Ilman refiä runner käyttää workflow'ta triggeröivästä commitista.
 
 ### Exit-koodi on ainoa onnistumisen mittari (ADR 0008)
 
 Ei pipeä (`|`) komennon perässä — se syö exit-koodin. Käytä redirectiä (`> file 2>&1`).
 
-### Commit-status vain raporttilinkille (ADR 0007)
-
-`ci-report.sh`-skriptiä käytetään VAIN kun on raportti linkitettäväksi.
-Tool-jobit (build, deploy) luottavat Gitean natiiviin job-statukseen.
-
 ### Providerin checkout ei kuulu consumerille
 
 Providerin scriptit haetaan `actions/checkout`-stepillä `.ci/`-polkuun.