tiketit ja featuret vaihe 1

.gitea/workflows/ci.yml

@@ -0,0 +1,33 @@
+# .gitea/workflows/ci.yml — Kirjaston oma CI (eat your own dogfood)
+#
+# Tämä workflow on kirjaston ENSIMMÄINEN kuluttaja.
+# Jokainen push ajaa kirjaston omat reusable workflowt:
+# - feature-branch → ci-feature.yml
+# - master-branch → ci-master.yml
+#
+# Näin kirjasto testaa itse itsensä — sama mekanismi
+# kuin mitä mikropalvelut käyttävät.
+
+name: CI — gitea-ci-library
+
+on:
+  push:
+    branches: ["**"]
+  workflow_dispatch:
+
+jobs:
+  # --- Feature-branch: testit + raportit, ei konttia ---
+  feature:
+    if: github.ref != 'refs/heads/master'
+    uses: ./.gitea/workflows/ci-feature.yml
+    secrets: inherit
+    with:
+      config-file: ci-flow-values.yaml
+
+  # --- Master-branch: build + kontti + test flow ---
+  master:
+    if: github.ref == 'refs/heads/master'
+    uses: ./.gitea/workflows/ci-master.yml
+    secrets: inherit
+    with:
+      config-file: ci-flow-values.yaml

docs/tickets/0001-report-status-sh.md

@@ -0,0 +1,110 @@
+# Ticket 0001: `report-status.sh`
+
+**Vaihe:** 1/12
+**Status:** pending
+**Feature branch:** `feature/0001-report-status-sh`
+**TDD required:** Yes
+**Feature file required:** Yes
+
+**Required context:**
+- `docs/test-plan/tdd-guide.md`
+- `tests/features/0001-report-status.feature`
+- Skills: `tdd`, `implementation`, `clean-code`, `bash-script`
+
+---
+
+## TDD — Red-Green-Refactor
+
+### Red
+Kirjoita `tests/report-status.bats` ennen implementaatiota. Testi käyttää `tests/helpers/mock-api.sh` mock-Gitea API:a. Varmista:
+- `pending`-status POSTautuu oikein
+- `success`-status + `url` + `key`
+- `failure`-status
+- Cross-repo: `root_commit` + `root_repo` → status menee root-committiin
+- Virhetilanne: API palauttaa 500 → exit 1
+- Puuttuva `GITEA_API_URL` → exit 1 + virheviesti
+
+```bash
+bats tests/report-status.bats
+# Kaikki testit FAIL: skriptiä ei ole vielä
+```
+
+### Green
+Toteuta `scripts/report-status.sh`. Minimiversio: vain curl POST + virheenkäsittely.
+
+```bash
+bats tests/report-status.bats
+# Kaikki testit PASS
+```
+
+### Refactor
+Poista duplikaatio, paranna virheviestejä. Testit pysyvät vihreänä.
+
+## DoD (Definition of Done)
+- [ ] Cucumber: `@ticket-0001 and @mock` → kaikki skenaariot GREEN
+- [ ] `tests/report-status.bats` kaikki testit menevät läpi
+- [ ] `tests/helpers/mock-api.sh` palvelee mock-vastaukset
+- [ ] `scripts/report-status.sh` toteuttaa kaikki parametrit
+- [ ] Cross-repo-statusraportointi toimii
+
+---
+
+## Toiminto
+
+POSTaa build-statuksen Gitea REST APIin. Jokainen workflow-steppi kutsuu tätä skriptiä raportoidakseen tilansa Git-committiin.
+
+## Rajapinta
+
+```bash
+report-status.sh <state> <description> <url> [key] [root_commit] [root_repo]
+```
+
+| Parametri | Pakollinen | Kuvaus |
+|-----------|------------|--------|
+| `state` | Kyllä | `pending`, `success`, `failure`, `error` |
+| `description` | Kyllä | Ihmisluettava kuvaus |
+| `url` | Kyllä | Linkki buildiin tai raporttiin |
+| `key` | Ei | Uniikki avain. Oletus: `commit-{sha_short}` |
+| `root_commit` | Ei | Root-buildin commit (cross-repo-raportointi) |
+| `root_repo` | Ei | Root-buildin repo (cross-repo-raportointi) |
+
+## Gitea API -kutsu
+
+```
+POST /api/v1/repos/{owner}/{repo}/statuses/{sha}
+Authorization: token {GITEA_TOKEN}
+
+{
+  "state": "{state}",
+  "target_url": "{url}",
+  "description": "{description}",
+  "context": "{key}"
+}
+```
+
+## Ympäristömuuttujat
+
+- `GITEA_API_URL` — Org variable
+- `GITEA_TOKEN` — Org secret
+- `GITHUB_REPOSITORY` — Automaattinen
+- `GITHUB_SHA` — Automaattinen
+- `GITHUB_SERVER_URL` — Automaattinen
+- `GITHUB_RUN_ID` — Automaattinen
+
+## Verifiointi
+
+`bash scripts/report-status.sh success "Test OK" "https://example.com"` → mock-API palauttaa 201
+
+Kutsu cross-repo-parametreilla:
+
+```bash
+report-status.sh success "Deployed to staging" "https://gitea.example.com/helm-repo/commit/def456" "deploy-staging" "abc123" "services/temperature-store"
+```
+
+→ statusviesti ilmestyy root-committiin `abc123`
+
+## Viitteet
+
+- `docs/shared-scripts.md` — Rajapinnan määrittely
+- `docs/architecture.md` — Tietovuo 1: Commit-statusraportointi
+- `docs/design-rationale.md` — Periaate 1: Git-commit on universaali statusnäkymä

docs/tickets/0002-dispatch-workflow-sh.md

@@ -0,0 +1,95 @@
+# Ticket 0002: `dispatch-workflow.sh`
+
+**Vaihe:** 2/12
+**Status:** pending
+**Feature branch:** `feature/0002-dispatch-workflow-sh`
+**TDD required:** Yes
+**Feature file required:** Yes
+
+**Required context:**
+- `docs/test-plan/tdd-guide.md`
+- `tests/features/0002-dispatch-workflow.feature`
+- Skills: `tdd`, `implementation`, `clean-code`, `bash-script`
+
+---
+
+## TDD — Red-Green-Refactor
+
+### Red
+Kirjoita `tests/dispatch-workflow.bats` mock-Gitea API:a vasten:
+- Dispatch → API palauttaa 201
+- Poll: API palauttaa `running` 3 kertaa, sitten `completed` + `success` → exit 0
+- Poll: API palauttaa `completed` + `failure` → exit 1
+- Timeout: ylittää `timeout_minutes` → exit 124
+- Virheellinen target_repo → exit 1
+
+```bash
+bats tests/dispatch-workflow.bats
+# FAIL
+```
+
+### Green
+`scripts/dispatch-workflow.sh` — dispatch + poll-silmukka 10s välein.
+
+```bash
+bats tests/dispatch-workflow.bats
+# PASS
+```
+
+### Refactor
+Poista duplikaatio, tarkista edge caset. Testit vihreänä.
+
+## DoD
+- [ ] Cucumber: `@ticket-0002 and @mock` → kaikki skenaariot GREEN
+- [ ] `tests/dispatch-workflow.bats` — kaikki testit läpi
+- [ ] Dispatch, poll, ja timeout toimivat mock-API:a vasten
+- [ ] Exit-koodit: 0 (success), 1 (failure), 124 (timeout)
+
+---
+
+## Toiminto
+
+Dispatchaa workflow toisessa repossa ja pollaa sen valmistumista synkronisesti. Vastaa Jenkinsin `buildJob()`-semantiikkaa — kutsuja jää odottamaan kunnes dispatchattu workflow on valmis.
+
+## Rajapinta
+
+```bash
+dispatch-workflow.sh <target_repo> <workflow_file> <ref> <inputs_json> [timeout_minutes]
+```
+
+| Parametri | Pakollinen | Kuvaus |
+|-----------|------------|--------|
+| `target_repo` | Kyllä | `owner/repo` |
+| `workflow_file` | Kyllä | Workflow-tiedosto (esim. `test.yml`) |
+| `ref` | Kyllä | Branch |
+| `inputs_json` | Kyllä | JSON-objekti input-parametreina |
+| `timeout_minutes` | Ei | Oletus: 360 |
+
+## API-kutsut
+
+1. **Dispatch:** `POST /api/v1/repos/{target_repo}/actions/workflows/{workflow_file}/dispatches`
+2. **Etsi run:** `GET /api/v1/repos/{target_repo}/actions/runs?status=running`
+3. **Poll:** `GET /api/v1/repos/{target_repo}/actions/runs/{run_id}` (10s välein)
+4. **Lopetus:** `conclusion == "success"` → exit 0, muuten exit 1
+5. **Timeout:** `> timeout_minutes` → exit 124
+
+## Esimerkkikutsu
+
+```bash
+dispatch-workflow.sh "tests/integration" "test.yml" "main" \
+  '{"version":"1.2.3","tags":"@smoke","root_commit":"abc123","root_repo":"services/temperature-store"}'
+```
+
+## Verifiointi
+
+Mock-Gitea API, jossa:
+- `POST dispatches` → palauttaa 201
+- `GET runs` → palauttaa `status: running` 3 kertaa, sitten `status: completed, conclusion: success`
+
+Skripti pollaa ja palauttaa exit 0.
+
+## Viitteet
+
+- `docs/shared-scripts.md` — Rajapinnan määrittely
+- `docs/design-rationale.md` — Periaate 4: Deterministinen testigraafi
+- `docs/architecture.md` — Tietovuo 4: Test flow -ketjutus

docs/tickets/0003-push-reports-sh.md

@@ -0,0 +1,104 @@
+# Ticket 0003: `push-reports.sh`
+
+**Vaihe:** 3/12
+**Status:** pending
+**Feature branch:** `feature/0003-push-reports-sh`
+**TDD required:** Yes
+**Feature file required:** Yes
+
+**Required context:**
+- `docs/test-plan/tdd-guide.md`
+- `tests/features/0003-push-reports.feature`
+- Skills: `tdd`, `implementation`, `clean-code`, `bash-script`
+
+---
+
+## TDD — Red-Green-Refactor
+
+### Red
+Kirjoita `tests/push-reports.bats` mock-MinIO:a vasten:
+- `mc cp --recursive` kopioi oikeaan polkuun
+- URL-tulostus: `{MINIO_BASE}/{repo}/{commit_short}/{report_type}/index.html`
+- Raporttityypit: `cucumber`, `jacoco`, `junit`, `site`
+- `index_title`-parametri välittyy oikein
+- Lähdehakemistoa ei ole → exit 1
+
+```bash
+bats tests/push-reports.bats
+# FAIL
+```
+
+### Green
+`scripts/push-reports.sh` — mc cp + URL-tulostus + indeksipäivitys (`report-service/generate-index.sh`).
+
+```bash
+bats tests/push-reports.bats
+# PASS
+```
+
+### Refactor
+Poista duplikaatio, varmista mc-alias-konfigurointi.
+
+## DoD
+- [ ] Cucumber: `@ticket-0003 and @mock` → kaikki skenaariot GREEN
+- [ ] `tests/push-reports.bats` — kaikki testit läpi
+- [ ] Raportit kopioituvat oikeaan MinIO-polkuun
+- [ ] URL-tulostus deterministinen
+- [ ] Indeksisivut päivittyvät (`report-service/generate-index.sh`)
+
+---
+
+## Toiminto
+
+Puskaa testiraporttihakemiston MinIO:hon ja päivittää indeksisivut. Palauttaa URL:n, joka syötetään `report-status.sh`:lle commit-statusviestin `url`-kenttään.
+
+## Rajapinta
+
+```bash
+push-reports.sh <report_type> <source_dir> [index_title]
+```
+
+| Parametri | Pakollinen | Kuvaus |
+|-----------|------------|--------|
+| `report_type` | Kyllä | `cucumber`, `jacoco`, `junit`, `site` |
+| `source_dir` | Kyllä | Paikallinen hakemisto |
+| `index_title` | Ei | Näkyvä nimi indeksisivulla |
+
+## Toiminta
+
+1. `mc cp --recursive {source_dir} minio/reports/{repo}/{commit_short}/{report_type}/`
+2. Päivitä `/reports/{repo}/{commit_short}/index.html` — lisää linkki tähän raporttiin
+3. Päivitä `/reports/{repo}/index.html` — varmista että build on listalla
+4. Tulosta URL: `{MINIO_BASE_URL}/{repo}/{commit_short}/{report_type}/index.html`
+
+## URL-rakenne
+
+```
+{MINIO_BASE}/{repo_slug}/{commit_short}/{report_type}/index.html
+```
+
+## Ympäristömuuttujat
+
+- `MINIO_BASE_URL` — Org variable
+- `MINIO_ACCESS_KEY` — Org secret (alias: `mc`)
+- `MINIO_SECRET_KEY` — Org secret (alias: `mc`)
+- `GITHUB_REPOSITORY` — Automaattinen
+- `GITHUB_SHA` — Automaattinen (8 merkkiä)
+
+## Verifiointi
+
+```bash
+bash scripts/push-reports.sh cucumber target/cucumber-report "Cucumber Reports"
+# → https://reports.example.com/temperature-store/abc12345/cucumber/overview-features.html
+```
+
+Tarkista:
+- MinIO-bucketissa raportit oikeassa polussa
+- `/reports/temperature-store/abc12345/index.html` sisältää linkin
+- `/reports/temperature-store/index.html` sisältää buildin
+
+## Viitteet
+
+- `docs/shared-scripts.md` — Rajapinnan määrittely
+- `docs/report-hosting.md` — MinIO-konfiguraatio ja URL-rakenne
+- `docs/design-rationale.md` — Periaate 5: Raportit ovat selailtavia URL:n takana

docs/tickets/0004-tag-commit-sh.md

@@ -0,0 +1,98 @@
+# Ticket 0004: `tag-commit.sh`
+
+**Vaihe:** 4/12
+**Status:** pending
+**Feature branch:** `feature/0004-tag-commit-sh`
+**TDD required:** Yes
+**Feature file required:** Yes
+
+**Required context:**
+- `docs/test-plan/tdd-guide.md`
+- `tests/features/0004-tag-commit.feature`
+- Skills: `tdd`, `implementation`, `clean-code`, `bash-script`
+
+---
+
+## TDD — Red-Green-Refactor
+
+### Red
+Kirjoita `tests/tag-commit.bats` mock-Gitea API:a vasten:
+- `tag-commit.sh "1.2.3.42"` → POST `/api/v1/repos/{repo}/tags` palauttaa 201
+- Tagi-muoto sisältää `$GITHUB_RUN_NUMBER`
+- API palauttaa 409 (tag jo olemassa) → exit 1
+- Tyhjä versio → exit 1
+
+```bash
+bats tests/tag-commit.bats
+# FAIL
+```
+
+### Green
+`scripts/tag-commit.sh` — curl POST + virheenkäsittely.
+
+```bash
+bats tests/tag-commit.bats
+# PASS
+```
+
+### Refactor
+Varmista tagin oikeellisuus, virheilmoitukset.
+
+## DoD
+- [ ] Cucumber: `@ticket-0004 and @mock` → kaikki skenaariot GREEN
+- [ ] `tests/tag-commit.bats` — kaikki testit läpi
+- [ ] POST `/api/v1/repos/{repo}/tags` onnistuu
+- [ ] Virhetilanteet käsitellään (409, tyhjä versio)
+
+---
+
+## Toiminto
+
+Tagittaa commitin versiolla Gitea REST API:n kautta. Kutsutaan `ci-master.yml`:n docker-pushin onnistuttua. Tämän jälkeen `isContainerBuilt()` palauttaa `true` samalle commitille.
+
+## Rajapinta
+
+```bash
+tag-commit.sh <version>
+```
+
+## Gitea API -kutsu
+
+```
+POST /api/v1/repos/{owner}/{repo}/tags
+Authorization: token {GITEA_TOKEN}
+
+{
+  "tag_name": "{version}",
+  "message": "Build #{GITHUB_RUN_NUMBER}",
+  "target": "{GITHUB_SHA}"
+}
+```
+
+## Kutsuesimerkki
+
+```bash
+tag-commit.sh "1.2.3.$GITHUB_RUN_NUMBER"
+```
+
+## Ympäristömuuttujat
+
+- `GITEA_API_URL` — Org variable
+- `GITEA_TOKEN` — Org secret
+- `GITHUB_REPOSITORY` — Automaattinen
+- `GITHUB_SHA` — Automaattinen
+- `GITHUB_RUN_NUMBER` — Automaattinen
+
+## Verifiointi
+
+```bash
+bash scripts/tag-commit.sh "1.2.3.42"
+```
+
+→ `git tag` näyttää tagin commitilla (tai mock-API palauttaa 201)
+
+## Viitteet
+
+- `docs/shared-scripts.md` — Rajapinnan määrittely
+- `docs/config-model.md` — `isContainerBuild()`-mekanismi
+- `docs/design-rationale.md` — Periaate 1: Statusviestit committiin

docs/tickets/0005-report-service-index-generation.md

@@ -0,0 +1,112 @@
+# Ticket 0005: `report-service/` — indeksigenerointi
+
+**Vaihe:** 5/12
+**Status:** pending
+**Feature branch:** `feature/0005-report-service-index-generation`
+**TDD required:** Yes
+**Feature file required:** Yes
+
+**Required context:**
+- `docs/test-plan/tdd-guide.md`
+- `tests/features/0005-report-index.feature`
+- Skills: `tdd`, `implementation`, `clean-code`, `bash-script`
+
+---
+
+## TDD — Red-Green-Refactor
+
+### Red
+Kirjoita `tests/generate-index.bats`:
+- Projektin indeksi: `generate-index.sh temperature-store abc12345 "2024-06-08 14:30" "master" "success"` → HTML sisältää rivin `abc12345`
+- Buildin indeksi: sisältää linkit raportteihin + "Back to builds"
+- Useampi build: uusin ensin listassa
+- Status: `success` → ✅, `failure` → ❌
+- Tyhjä status → ei generoida riviä
+
+```bash
+bats tests/generate-index.bats
+# FAIL
+```
+
+### Green
+`report-service/generate-index.sh` — staattinen HTML-generaattori.
+
+```bash
+bats tests/generate-index.bats
+# PASS
+```
+
+### Refactor
+Varmista HTML-valiidius, edge-caset (puuttuvat parametrit).
+
+## DoD
+- [ ] Cucumber: `@ticket-0005 and @mock` → kaikki skenaariot GREEN
+- [ ] `tests/generate-index.bats` — kaikki testit läpi
+- [ ] Projektin indeksi lista buildit aikajärjestyksessä
+- [ ] Buildin indeksi lista raportit linkkeinä
+- [ ] "Back to builds" -navigaatio
+- [ ] Status-emoji ✅/❌
+
+---
+
+## Toiminto
+
+Staattisten HTML-indeksisivujen generointi MinIO:hon. Kaksi tasoa:
+
+1. **Projektin build-indeksi** (`/reports/{repo}/index.html`): lista buildeista aikajärjestyksessä
+2. **Buildin raportti-indeksi** (`/reports/{repo}/{commit_short}/index.html`): lista raporteista linkkeinä
+
+## Build-indeksin sisältö
+
+```html
+<!DOCTYPE html>
+<html lang="en">
+<head>
+  <meta charset="UTF-8">
+  <title>{repo_slug} — Build Reports</title>
+  <style>
+    body { font-family: monospace; }
+    .pass { color: green; }
+    .fail { color: red; }
+  </style>
+</head>
+<body>
+  <h1>{repo_slug}</h1>
+  <ul>
+    <li><span class="pass">✅</span> <a href="abc12345/index.html">abc12345</a> — 2024-06-08 14:30 — master</li>
+    <li><span class="fail">❌</span> <a href="def67890/index.html">def67890</a> — 2024-06-07 10:15 — feature/xyz</li>
+  </ul>
+</body>
+</html>
+```
+
+## Raportti-indeksin sisältö
+
+```html
+<a href="../index.html">&larr; Back to builds</a>
+<h2>Build abc12345</h2>
+<ul>
+  <li><a href="cucumber/overview-features.html">Cucumber Reports</a></li>
+  <li><a href="jacoco/index.html">JaCoCo Coverage</a></li>
+  <li><a href="site/index.html">Maven Site</a></li>
+</ul>
+```
+
+## Sijainti
+
+- `report-service/generate-index.sh` — generoi tai päivittää indeksit
+- Kutsutaan `push-reports.sh`:sta (Ticket 0003)
+
+## Verifiointi
+
+```bash
+bash report-service/generate-index.sh temperature-store abc12345 "2024-06-08 14:30" "master" "success"
+```
+
+→ `/reports/temperature-store/index.html` sisältää rivin `abc12345`
+→ `/reports/temperature-store/abc12345/index.html` validi HTML
+
+## Viitteet
+
+- `docs/report-hosting.md` — Indeksisivujen määrittely
+- `docs/requirements.md` — UC3: Kehittäjä selaa projektin build-historiaa

docs/tickets/0006-ci-feature-yml.md

@@ -0,0 +1,108 @@
+# Ticket 0006: `ci-feature.yml` (reusable workflow)
+
+**Vaihe:** 6/12
+**Status:** pending
+**Feature branch:** `feature/0006-ci-feature-yml`
+**TDD required:** Yes
+**Feature file required:** Yes
+
+**Required context:**
+- `docs/test-plan/tdd-guide.md`
+- `tests/features/0006-ci-feature.feature`
+- Skills: `tdd`, `implementation`, `clean-code`
+
+---
+
+## TDD — Red-Green-Refactor + Dogfood
+
+### Red
+Ennen workflow'ta, kirjoita validointitestit (`tests/workflows.bats`):
+- YAML-skeema: kaikki vaaditut `inputs` määritelty
+- `concurrency`-ryhmä estää rinnakkaiset ajot
+- `uses:`-viittaukset oikeisiin skripteihin
+
+```bash
+bats tests/workflows.bats
+# FAIL: workflow-tiedostoa ei ole
+```
+
+### Green
+Toteuta `gitea/workflows/ci-feature.yml`.
+
+```bash
+bats tests/workflows.bats
+# PASS: YAML validi, skeema täsmää
+```
+
+### Dogfood
+Lisää kutsu `gitea/workflows/ci.yml`:stä:
+
+```yaml
+feature:
+  if: github.ref != 'refs/heads/master'
+  uses: ./gitea/workflows/ci-feature.yml@main
+```
+
+Jokainen push feature-branchiin ajaa `ci-feature.yml`:n.
+
+## DoD
+- [ ] Cucumber: `@ticket-0006 and @mock` → kaikki skenaariot GREEN
+- [ ] `tests/workflows.bats` — YAML-validointi läpi
+- [ ] Kaikki stepit määritelty: start → unit-test → code-coverage → publish-html → end
+- [ ] `concurrency` estää rinnakkaiset ajot samalle branchille
+- [ ] Dogfood: kirjaston oma CI käyttää tätä workflow'ta
+- [ ] Statusviestit raportoivat jokaisen stepin tilan
+
+---
+
+## Toiminto
+
+Feature-branchin CI-workflow. Kutsuu `report-status.sh` ja `push-reports.sh` (Ticket 0001 ja 0003).
+
+## Trigger
+
+`workflow_call` (reusable workflow)
+
+## Inputs
+
+| Parametri | Pakollinen | Kuvaus |
+|-----------|------------|--------|
+| `config-file` | Kyllä | Polku `ci-flow-values.yaml`:aan |
+| `maven-image` | Ei | Maven-kontti (esim. `maven:3.9-eclipse-temurin-21`) |
+| `node-image` | Ei | Node-kontti (npm-projektit) |
+
+## Steppit
+
+```
+start → unit-test → code-coverage → publish-html → end
+```
+
+| Steppi | Skripti | Status |
+|--------|---------|--------|
+| `start` | `report-status.sh pending "Building..."` | INPROGRESS |
+| `unit-test` | Projektin oma testiajo | — |
+| `code-coverage` | JaCoCo / vastaava | — |
+| `publish-html` | `push-reports.sh cucumber; push-reports.sh jacoco` | — |
+| `end` | `report-status.sh success/failure` | Lopullinen status |
+| `fail` (catch) | `report-status.sh failure` | FAILURE |
+
+## Concurrency
+
+```yaml
+concurrency:
+  group: feature-${{ github.ref }}
+  cancel-in-progress: false
+```
+
+## Verifiointi
+
+Simuloi paikallisesti (act-runner tai manuaalinen steppien ajo):
+1. `report-status.sh pending` → commitin status = pending
+2. Testit ajetaan
+3. `push-reports.sh` → raportit MinIO:ssa
+4. `report-status.sh success` → statusviesti + URL
+
+## Viitteet
+
+- `docs/workflows.md` — `ci-feature.yml` — Feature-branch
+- `docs/architecture.md` — Järjestelmäkaavio

docs/tickets/0007-deploy-yml.md

@@ -0,0 +1,112 @@
+# Ticket 0007: `deploy.yml` (reusable workflow)
+
+**Vaihe:** 7/12
+**Status:** pending
+**Feature branch:** `feature/0007-deploy-yml`
+**TDD required:** Yes
+**Feature file required:** Yes
+
+**Required context:**
+- `docs/test-plan/tdd-guide.md`
+- `tests/features/0007-deploy.feature`
+- Skills: `tdd`, `implementation`, `clean-code`
+
+---
+
+## TDD — Red-Green-Refactor + Dogfood
+
+### Red
+Validointitesti (`tests/workflows.bats`):
+- `workflow_dispatch`-inputit määritelty: `environment`, `version`, `root_commit`, `root_repo`, `root_build_url`
+- YAML-päivityksen testi: `yq` muuttaa `container.version`-arvon
+- Cross-repo-statusraportoinnin testi
+
+```bash
+bats tests/workflows.bats
+# FAIL
+```
+
+### Green
+Toteuta `gitea/workflows/deploy.yml`.
+
+```bash
+bats tests/workflows.bats
+# PASS
+```
+
+### Dogfood
+Lisää kutsu `gitea/workflows/ci.yml`:stä (käytetään master-flow'n test flow -ketjussa).
+
+## DoD
+- [ ] Cucumber: `@ticket-0007 and @mock` → kaikki skenaariot GREEN
+- [ ] `tests/workflows.bats` — workflow-validointi läpi
+- [ ] YAML-arvo päivittyy `yq`:lla: `container.version: <new_value>`
+- [ ] `git commit` + `git push` Helm-repoon
+- [ ] Cross-repo-status: Helm-commit + root-commit molemmat raportoitu
+- [ ] Dogfood: oma CI voi dispatchata tämän
+
+---
+
+## Toiminto
+
+GitOps-deployment: lukee Helm-values-YAML:n, päivittää `container.version`-arvon, committaa ja pushaa. Raportoi cross-repo-statuksen.
+
+## Trigger
+
+`workflow_dispatch` (aina dispatchataan toisesta workflow'sta)
+
+## Inputs (dispatch-parametrit)
+
+| Parametri | Kuvaus |
+|-----------|--------|
+| `environment` | Ympäristön nimi (korvaa `{.environment}`) |
+| `version` | Uusi konttiversio |
+| `root_commit` | Mikropalvelun commit josta deploy käynnistyi |
+| `root_repo` | Mikropalvelun repo |
+| `root_build_url` | URL mikropalvelun buildiin |
+
+## Steppit
+
+```
+start → read-yaml → update-value → commit → push → report-cross-repo → end
+```
+
+| Steppi | Toiminto |
+|--------|----------|
+| `read-yaml` | Lue `{projectFolder}/{fileName}` (korvaa `{.environment}`) |
+| `update-value` | `yq` tai vastaava: aseta `{property}` = `{version}` |
+| `commit` | `git add` + `git commit -m "deploy {version} to {environment}"` |
+| `push` | `git push origin HEAD:master` |
+| `report-cross-repo` | `report-status.sh` — raportoi molempiin suuntiin |
+
+## Cross-repo-raportointi
+
+```bash
+# Helm-repon committiin: mistä deploy tuli
+report-status.sh success "from {root_commit}" "{root_build_url}" "from" "$GITHUB_SHA" "$GITHUB_REPOSITORY"
+
+# Mikropalvelun committiin: deployattu
+report-status.sh success "deployed to {environment}" "{helm_commit_url}" "deploy-{environment}" "$ROOT_COMMIT" "$ROOT_REPO"
+```
+
+## Concurrency
+
+```yaml
+concurrency:
+  group: deploy-${{ github.repository }}-${{ inputs.environment }}
+  cancel-in-progress: false
+```
+
+## Verifiointi
+
+Dispatchaa mock-inputeilla:
+1. YAML-arvo päivittyy oikein (esim. `container.version: 1.2.3.42` → `1.2.3.43`)
+2. Commit ja push onnistuvat
+3. Statusviesti ilmestyy Helm-repon commitille: "from abc123"
+4. Statusviesti ilmestyy mikropalvelun commitille: "deployed to staging"
+
+## Viitteet
+
+- `docs/workflows.md` — `deploy.yml` — GitOps-deployment
+- `docs/architecture.md` — Tietovuo 2: Cross-repo traceability
+- `docs/config-model.md` — Deployment-konfiguraatio

docs/tickets/0008-test-yml.md

@@ -0,0 +1,117 @@
+# Ticket 0008: `test.yml` (reusable workflow)
+
+**Vaihe:** 8/12
+**Status:** pending
+**Feature branch:** `feature/0008-test-yml`
+**TDD required:** Yes
+**Feature file required:** Yes
+
+**Required context:**
+- `docs/test-plan/tdd-guide.md`
+- `tests/features/0008-test-flow.feature`
+- Skills: `tdd`, `implementation`, `clean-code`
+
+---
+
+## TDD — Red-Green-Refactor + Dogfood
+
+### Red
+Validointitesti (`tests/workflows.bats`):
+- Kaikki `workflow_dispatch`-inputit: `environment`, `version`, `tags`, `root_commit`, `root_repo`, `deploy_commit`, `deploy_repo`
+- `version-check` käyttää `check-version.sh` (Ticket 0011)
+- Cross-repo-raportointi: 3 suuntaa (test → test-repo, test → root, test → deploy)
+
+```bash
+bats tests/workflows.bats
+# FAIL
+```
+
+### Green
+Toteuta `gitea/workflows/test.yml`.
+
+```bash
+bats tests/workflows.bats
+# PASS
+```
+
+### Dogfood
+Lisää kutsu `gitea/workflows/ci.yml`:stä.
+
+## DoD
+- [ ] Cucumber: `@ticket-0008 and @mock` → kaikki skenaariot GREEN
+- [ ] `tests/workflows.bats` — workflow-validointi läpi
+- [ ] Version check -steppi kytketty (`check-version.sh`)
+- [ ] Cross-repo-statusraportointi 3 suuntaan
+- [ ] Dogfood: kirjaston CI käyttää tätä test flow'ssa
+
+---
+
+## Toiminto
+
+Test flow -steppi. Dispatchataan deploy-workflow'n jälkeen. Ajaa testit, puskaa raportit MinIO:hon ja raportoi statuksen kolmeen committiin.
+
+## Trigger
+
+`workflow_dispatch` (dispatchataan `ci-master.yml`:stä)
+
+## Inputs (dispatch-parametrit)
+
+| Parametri | Kuvaus |
+|-----------|--------|
+| `environment` | Testiympäristö |
+| `version` | Testattava konttiversio |
+| `tags` | Cucumber-tagit |
+| `versionApiUrl` | URL version tarkistukseen |
+| `versionCheckScript` | Polku version check -skriptiin |
+| `root_commit` | Mikropalvelun commit |
+| `root_repo` | Mikropalvelun repo |
+| `deploy_commit` | Helm-repon commit |
+| `deploy_repo` | Helm-repo |
+
+## Steppit
+
+```
+start → version-check → run-tests → push-reports → report-cross-repo → end
+```
+
+| Steppi | Toiminto |
+|--------|----------|
+| `version-check` | `check-version.sh` — varmista oikea versio ympäristössä |
+| `run-tests` | Projektin oma testiajo |
+| `push-reports` | `push-reports.sh` — raportit MinIO:hon |
+| `report-cross-repo` | `report-status.sh` — kolmeen committiin |
+
+## Cross-repo-raportointi (3 suuntaa)
+
+```bash
+# 1. Testi-repon oma commit
+report-status.sh success "Tests OK" "$REPORT_URL" "test-{name}" "$GITHUB_SHA" "$GITHUB_REPOSITORY"
+
+# 2. Mikropalvelun commit (root)
+report-status.sh success "Tests OK ({name})" "$REPORT_URL" "test-{name}" "$ROOT_COMMIT" "$ROOT_REPO"
+
+# 3. Helm-repon commit
+report-status.sh success "tested v{version}" "$REPORT_URL" "tested-{name}" "$DEPLOY_COMMIT" "$DEPLOY_REPO"
+```
+
+## Concurrency
+
+```yaml
+concurrency:
+  group: test-${{ inputs.environment }}
+  cancel-in-progress: false
+```
+
+## Verifiointi
+
+Dispatchaa mock-inputeilla:
+1. `version-check` epäonnistuu → exit 1, status = "Version mismatch"
+2. Testit ajetaan onnistuneesti
+3. Raportit MinIO:ssa, URL:t oikein
+4. Statusviestit kaikissa kolmessa commitissa
+
+## Viitteet
+
+- `docs/workflows.md` — `test.yml` — Test flow -steppi
+- `docs/config-model.md` — Test flow -konfiguraatio, version check
+- `docs/requirements.md` — UC6: Testi-insinööri näkee mitä konttia testattiin

docs/tickets/0009-ci-master-yml.md

@@ -0,0 +1,144 @@
+# Ticket 0009: `ci-master.yml` (reusable workflow)
+
+**Vaihe:** 9/12
+**Status:** pending
+**Feature branch:** `feature/0009-ci-master-yml`
+**TDD required:** Yes
+**Feature file required:** Yes
+
+**Required context:**
+- `docs/test-plan/tdd-guide.md`
+- `tests/features/0009-ci-master.feature`
+- Skills: `tdd`, `implementation`, `clean-code`
+
+---
+
+## TDD — Red-Green-Refactor + Dogfood
+
+### Red
+Validointitesti (`tests/workflows.bats`):
+- Kaikki `workflow_call`-inputit: `config-file`, `maven-image`, `docker-image`
+- `isContainerBuilt`-check: git-tagin mukaan
+- Docker-labelien injektointi
+- Test flow -ketjutus: `dispatch-workflow.sh` kutsutaan jokaiselle `test-flow`-stepille
+- `continueToTestFlow`-steppi skip-vaihtoehdolla
+
+```bash
+bats tests/workflows.bats
+# FAIL
+```
+
+### Green
+Toteuta `gitea/workflows/ci-master.yml`.
+
+```bash
+bats tests/workflows.bats
+# PASS
+```
+
+### Dogfood
+Kirjaston oma `ci.yml` kutsuu `ci-master.yml`:ä master-branchille.
+
+## DoD
+- [ ] Cucumber: `@ticket-0009 and @mock` → kaikki skenaariot GREEN
+- [ ] `tests/workflows.bats` — workflow-validointi läpi
+- [ ] `isContainerBuilt`-check toimii: `git tag --points-at HEAD`
+- [ ] Docker-labelit injektoitu: `git.commit`, `build.date`, `version`
+- [ ] Test flow -ketju dispatchaa jokaisen stepin järjestyksessä
+- [ ] Dogfood: kirjaston oma master-build käyttää tätä
+- [ ] Kaikki skriptit (0001–0004) integroitu workflow'hun
+
+---
+
+## Toiminto
+
+Master-branchin CI-workflow. Orkestroi koko build-test-deploy -ketjun: buildaa kontin, tagittaa commitin, ketjuttaa test flow'n `ci-flow-values.yaml`-konfiguraation mukaan.
+
+## Trigger
+
+`workflow_call` (reusable workflow)
+
+## Inputs
+
+| Parametri | Pakollinen | Kuvaus |
+|-----------|------------|--------|
+| `config-file` | Kyllä | Polku `ci-flow-values.yaml`:aan |
+| `maven-image` | Ei | Maven-kontti |
+| `docker-image` | Ei | Docker-in-Docker image |
+
+## Steppit
+
+```
+start
+  → isContainerBuilt? ──kyllä──→ skip build, continueToTestFlow
+  → ei
+  → unit-test → quality-gate → build-jar → build-docker → push-docker
+  → tag-commit → continueToTestFlow → publish-html → end
+```
+
+| Steppi | Skripti / Toiminto |
+|--------|-------------------|
+| `start` | `report-status.sh pending "Building..."` |
+| `isContainerBuilt` | `git tag --points-at HEAD` — onko jo buildattu? |
+| `unit-test` | Projektin oma testiajo |
+| `quality-gate` | SonarQube quality gate -pollaus |
+| `build-jar` | `mvn package` / `gradle build` |
+| `build-docker` | `docker build` + Docker-labelit |
+| `push-docker` | `docker push` → Gitea Packages |
+| `tag-commit` | `tag-commit.sh {version}` |
+| `continueToTestFlow` | `dispatch-workflow.sh` jokaiselle test-flow -stepille |
+| `publish-html` | `push-reports.sh` — Maven Site + muut |
+| `end` | `report-status.sh success/failure` |
+
+## Test flow -ketjutus
+
+```yaml
+# ci-flow-values.yaml — test-flow-taulu
+test-flow:
+  - deploy: development
+    wait: true
+  - test:
+      name: "integration fast"
+      repo: tests/integration
+      workflow: test.yml
+      ref: main
+      tags: "@temperature and not @slow"
+  - deploy: staging
+    wait: true
+  - test:
+      name: e2e
+      repo: tests/e2e
+      workflow: test.yml
+      ref: main
+```
+
+Workflow iteroi `test-flow`-taulun ja kutsuu `dispatch-workflow.sh` jokaiselle stepille:
+
+```bash
+for step in test-flow; do
+  dispatch-workflow.sh {step.repo} {step.workflow} {step.ref} '{...inputs...}'
+done
+```
+
+## Concurrency
+
+```yaml
+concurrency:
+  group: master-${{ github.repository }}
+  cancel-in-progress: false
+```
+
+## Verifiointi
+
+Simuloi koko master flow paikallisesti:
+1. `isContainerBuilt` = false → build kontti
+2. `tag-commit.sh` → tagi ilmestyy commitille
+3. `isContainerBuilt` = true uusinta-ajossa → build skipataan
+4. `dispatch-workflow.sh` kutsuu deploy → test → e2e ketjun
+5. Kaikki statusviestit näkyvät oikeissa commiteissa
+
+## Viitteet
+
+- `docs/workflows.md` — `ci-master.yml` — Master / release-branch
+- `docs/config-model.md` — `isContainerBuild()`, Docker-labelit, test-flow-taulukko
+- `docs/design-rationale.md` — Periaate 7: Cross-repo commit traceability

docs/tickets/0010-report-service-retention-cronjob.md

@@ -0,0 +1,130 @@
+# Ticket 0010: `report-service/` — retention CronJob
+
+**Vaihe:** 10/12
+**Status:** pending
+**Feature branch:** `feature/0010-report-service-retention-cronjob`
+**TDD required:** Yes
+**Feature file required:** No
+
+**Required context:**
+- `docs/test-plan/tdd-guide.md`
+- Skills: `tdd`, `implementation`, `clean-code`, `bash-script`
+
+---
+
+## TDD — Red-Green-Refactor
+
+### Red
+Kirjoita `tests/retention-cleanup.bats` mock-MinIO:a ja mock-Gitea API:a vasten:
+- `retention-cleanup.sh --dry-run` listaa poistettavat objektit
+- Yli 90 vrk vanha feature-build → merkitään poistettavaksi
+- Tagattu commit → ei merkitä poistettavaksi
+- `keepMin`: 3 uusinta säilyy branchista
+- ConfigMap-pohjainen retention: `retention.yaml` luetaan oikein
+
+```bash
+bats tests/retention-cleanup.bats
+# FAIL
+```
+
+### Green
+Toteuta `report-service/retention-cleanup.sh` + `CronJob.yaml` + `ConfigMap.yaml`.
+
+```bash
+bats tests/retention-cleanup.bats
+# PASS
+```
+
+### Refactor
+Parametrisoi retention-säännöt, paranna lokitusta.
+
+## DoD
+- [ ] `tests/retention-cleanup.bats` — kaikki testit läpi
+- [ ] `report-service/retention-cleanup.sh` toimii --dry-run-tilassa
+- [ ] `report-service/CronJob.yaml` — schedule `0 3 * * *`
+- [ ] `report-service/ConfigMap.yaml` — retention.yaml oikea muoto
+- [ ] Aika-, branch-, tagi- ja keepMin-säännöt toimivat
+
+---
+
+## Toiminto
+
+Kubernetes CronJob, joka ajaa siivousskriptin päivittäin. Skripti lukee ConfigMap-pohjaisen retention policyn ja poistaa vanhentuneet raportit MinIO:sta.
+
+## Artefaktit
+
+### `report-service/retention-cleanup.sh`
+
+Skripti joka:
+1. Listaa kaikki bucketin objektit (`mc ls --recursive`)
+2. Parsii polusta `repo_slug` ja `commit_short`
+3. Hakee Gitea API:sta commitin metadata (`GET /api/v1/repos/{owner}/{repo}/commits/{sha}` → branch, onko tagattu)
+4. Soveltaa ConfigMapin retention-sääntöjä
+5. Poistaa vanhentuneet (`mc rm`)
+
+### ConfigMap
+
+```yaml
+apiVersion: v1
+kind: ConfigMap
+metadata:
+  name: minio-report-retention
+data:
+  retention.yaml: |
+    rules:
+      - branch: "master"
+        maxAgeDays: 365
+        keepMin: 20
+      - branch: "feature/*"
+        maxAgeDays: 90
+        keepMin: 5
+      - tagged: true
+        maxAgeDays: -1   # ei koskaan
+        keepMin: -1
+      - default:
+        maxAgeDays: 90
+        keepMin: 3
+```
+
+### CronJob
+
+```yaml
+apiVersion: batch/v1
+kind: CronJob
+metadata:
+  name: minio-report-cleanup
+spec:
+  schedule: "0 3 * * *"  # kerran päivässä klo 03:00
+  jobTemplate:
+    spec:
+      template:
+        spec:
+          containers:
+          - name: cleanup
+            image: minio/mc:latest
+            command: ["/scripts/retention-cleanup.sh"]
+            volumeMounts:
+            - name: config
+              mountPath: /etc/retention
+            - name: script
+              mountPath: /scripts
+          volumes:
+          - name: config
+            configMap:
+              name: minio-report-retention
+          - name: script
+            configMap:
+              name: minio-cleanup-script
+```
+
+## Verifiointi
+
+1. Aja `retention-cleanup.sh` --dry-run → listaa poistettavat objektit
+2. Tarkista: yli 90 vrk vanha feature-build → merkitään poistettavaksi
+3. Tarkista: tagattu commit → ei merkitä poistettavaksi
+4. Tarkista: `keepMin`-säännön tuorein 3 säilyy
+
+## Viitteet
+
+- `docs/report-hosting.md` — Retention policy
+- `docs/architecture.md` — `report-service/`-moduuli

docs/tickets/0011-check-version-sh.md

@@ -0,0 +1,103 @@
+# Ticket 0011: `check-version.sh` (Fibonacci-backoff)
+
+**Vaihe:** 11/12
+**Status:** pending
+**Feature branch:** `feature/0011-check-version-sh`
+**TDD required:** Yes
+**Feature file required:** Yes
+
+**Required context:**
+- `docs/test-plan/tdd-guide.md`
+- `tests/features/0011-check-version.feature`
+- Skills: `tdd`, `implementation`, `clean-code`, `bash-script`
+
+---
+
+## TDD — Red-Green-Refactor
+
+### Red
+Kirjoita `tests/check-version.bats` mock-API:a vasten:
+- Mock palauttaa oikean version 5. yrityksellä → exit 0
+- Mock ei koskaan palauta oikeaa versiota → exit 1 (MAX_RETRIES täyttyy)
+- Fibonacci-välit: 1 2 3 5 8 13 ... (tarkista sleep-kutsut)
+- API ei vastaa (timeout) → exit 1
+- Tyhjä URL → exit 1
+
+```bash
+bats tests/check-version.bats
+# FAIL
+```
+
+### Green
+Toteuta `scripts/check-version.sh` Fibonacci-backoffilla.
+
+```bash
+bats tests/check-version.bats
+# PASS
+```
+
+### Refactor
+Varmista curl-aikakatkaisu, paranna lokitusta.
+
+## DoD
+- [ ] Cucumber: `@ticket-0011 and @mock` → kaikki skenaariot GREEN
+- [ ] `tests/check-version.bats` — kaikki testit läpi
+- [ ] Fibonacci-sekvenssi: 1 2 3 5 8 13 21 34 55 89
+- [ ] Maksimiaika ~231 s, MAX_RETRIES=10
+- [ ] Exit 0: versio löytyi, exit 1: ei löytynyt
+
+---
+
+## Toiminto
+
+Pollaa ympäristössä deployatun konttiversion API:a Fibonacci-backoffilla, kunnes haluttu versio on havaittu. Kutsutaan `test.yml`:n `version-check`-stepistä ennen testien ajoa.
+
+## Rajapinta
+
+```bash
+check-version.sh <version_api_url> <expected_version>
+```
+
+- Exit 0: versiot täsmäävät
+- Exit 1: versiota ei löytynyt `MAX_RETRIES` yrityksen jälkeen
+
+## Fibonacci-sekvenssi
+
+```
+1s → 2s → 3s → 5s → 8s → 13s → 21s → 34s → 55s → 89s
+```
+
+Maksimiaika: ~231 sekuntia (1+2+3+5+8+13+21+34+55+89).
+
+## Pseudokoodi
+
+```bash
+MAX_RETRIES=10
+FIB=(1 2 3 5 8 13 21 34 55 89)
+
+for i in $(seq 1 $MAX_RETRIES); do
+  ACTUAL=$(curl -s "$URL" | jq -r '.version // empty')
+  if [ "$ACTUAL" = "$EXPECTED" ]; then
+    echo "Version match: $ACTUAL"
+    exit 0
+  fi
+  echo "Attempt $i/$MAX_RETRIES: $ACTUAL != $EXPECTED, waiting ${FIB[$i-1]}s..."
+  sleep ${FIB[$i-1]}
+done
+
+echo "Version mismatch after $MAX_RETRIES attempts"
+exit 1
+```
+
+## Verifiointi
+
+Mock-API, jossa:
+1. Pyyntö 1–4 → `{"version": "1.2.3.41"}` (vanha versio)
+2. Pyyntö 5 → `{"version": "1.2.3.42"}` (odotettu versio)
+
+Skripti pollaa ja löytää oikean version 5. yrityksellä → exit 0.
+
+## Viitteet
+
+- `docs/config-model.md` — Version check (Fibonacci-backoff)
+- `docs/workflows.md` — `test.yml` version-check-steppi

docs/tickets/0012-integration-testing.md

@@ -0,0 +1,45 @@
+# Ticket 0012: Integraatiotestaus koko ketjulle
+
+**Vaihe:** 12/12
+**Status:** pending
+**Feature branch:** `feature/0012-integration-testing`
+**TDD required:** Yes
+**Feature file required:** Yes (kaikki tikettien 0001–0011 feature filet, `@real`-skenaariot)
+
+**Required context:**
+- `docs/test-plan/tdd-guide.md`
+- Kaikki `tests/features/0001–0011-*.feature` — tikettien 0001–0011 feature filet
+- Skills: `tdd`, `implementation`, `clean-code`
+
+---
+
+## TDD — E2E `@real` -verifiointi
+
+Tiketti 0012 ajaa tikettien 0001–0011 feature filejen `@real`-skenaariot oikeaa testiympäristöä vasten. Se ei luo uusia skenaarioita — se verifioi jo määritellyt skenaariot todellisessa ympäristössä.
+
+Feature filet: `tests/features/0001–0011-*.feature` (luotu tiketeissä 0001–0011).
+
+### Toiminto
+
+1. Vaihda mock-URL:t oikean testiympäristön URL:eihin
+2. Aja kaikki `@real`-skenaariot:
+
+```bash
+cucumber tests/features/ --tags @real
+```
+
+Skenaariot jotka eivät ole `@real`-tägättyjä skipataan automaattisesti.
+
+### DoD
+
+- [ ] Cucumber: kaikki `@real`-skenaariot GREEN oikeaa ympäristöä vasten
+- [ ] Bats: kaikki aiemmat testit edelleen GREEN
+- [ ] Toteutus: mock→real -konfiguraatio olemassa
+- [ ] Refactor: ei duplikaatiota, virheenkäsittely kunnossa
+
+## Viitteet
+
+- `docs/tickets/0001–0011` — Tiketit joiden featuret ajetaan
+- `docs/requirements.md` — UC1–UC7
+- `docs/architecture.md` — Järjestelmäkaavio + tietovuot
+- `docs/test-plan/tdd-guide.md`

tests/features/ci-pipeline.feature

@@ -0,0 +1,70 @@
+Feature: CI pipeline
+  As a developer
+  I want automated CI pipelines for feature and master branches
+  So that every commit is tested and master builds produce deployable artifacts
+
+  # ---------------------------------------------------------------------------
+  # Ticket 0006: ci-feature.yml — Feature branch CI workflow
+  # ---------------------------------------------------------------------------
+
+  Background:
+    Given the project has a CI configuration file in its repository
+
+  @ticket-0006 @mock @wip @real
+  Scenario: Feature branch runs unit tests and publishes reports
+    When a commit is pushed to a feature branch
+    Then the unit tests are executed
+    And the test reports are published
+    And each step reports its status to the commit
+
+  @ticket-0006 @mock @wip @real
+  Scenario: Feature branch reports failure when tests do not pass
+    When tests fail on a feature branch
+    Then the commit shows a failure status with a link to the test results
+
+  @ticket-0006 @mock @wip @real
+  Scenario: Feature branch does not build a container image
+    Given a commit is pushed to a feature branch
+    When the CI pipeline runs
+    Then no container image is built or pushed
+
+  @ticket-0006 @mock @wip
+  Scenario: Only one pipeline runs at a time for the same feature branch
+    When a new commit is pushed to a feature branch while a pipeline is already running
+    Then the existing pipeline continues and the new one waits
+
+  # ---------------------------------------------------------------------------
+  # Ticket 0009: ci-master.yml — Master branch CI workflow
+  # ---------------------------------------------------------------------------
+
+  @ticket-0009 @mock @wip @real
+  Scenario: Master branch builds and pushes a container image
+    When a commit is pushed to the master branch
+    Then the container image is built with version labels
+    And the image is pushed to the container registry
+    And the commit is tagged with the build version
+
+  @ticket-0009 @mock @wip @real
+  Scenario: Master branch skips container build if already built
+    When a commit on the master branch is already tagged with a build version
+    And a new pipeline is triggered for the same commit
+    Then the container build is skipped
+    And the pipeline proceeds to reporting and test flow
+
+  @ticket-0009 @mock @wip @real
+  Scenario: Master branch runs the full test flow chain after a successful build
+    When the container build and push succeed on the master branch
+    Then the deployment to the first environment is dispatched
+    And after deployment succeeds the integration tests are dispatched
+    And the end-to-end tests run as the final step in the chain
+
+  @ticket-0009 @mock @wip @real
+  Scenario: Master branch stops the test flow chain when a step fails
+    When a step in the test flow chain fails
+    Then the remaining steps are not executed
+    And the commit shows a failure status pointing to the failed step
+
+  @ticket-0009 @mock @wip
+  Scenario: Only one master pipeline runs at a time for the same project
+    When a new commit is pushed to master while a pipeline is already running
+    Then the existing pipeline continues and the new one waits

tests/features/commit-status.feature

@@ -0,0 +1,72 @@
+Feature: Commit status visibility
+  As a developer
+  I want to see build and deployment statuses on commits
+  So that I know the state of each commit at a glance
+
+  Background:
+    Given a project repository exists in Gitea
+    And a commit has been pushed to the repository
+
+  # ---------------------------------------------------------------------------
+  # Ticket 0001: report-status.sh — Build status reporting to commits
+  # ---------------------------------------------------------------------------
+
+  @ticket-0001 @mock @wip @real
+  Scenario: Build step reports pending status to commit
+    When a build step starts executing
+    Then the commit shows a pending status with a description of the step
+
+  @ticket-0001 @mock @wip @real
+  Scenario: Build step reports successful completion with a result link
+    When a build step completes successfully and reports its results
+    Then the commit shows a success status with a clickable link to the results
+
+  @ticket-0001 @mock @wip @real
+  Scenario: Build step reports failure when tests do not pass
+    When a build step fails
+    Then the commit shows a failure status with a description of what went wrong
+
+  @ticket-0001 @mock @wip @real
+  Scenario: Multiple build steps report distinct statuses on the same commit
+    When several build steps each report their own status to the same commit
+    Then each status appears under a unique label on the commit
+
+  @ticket-0001 @mock @wip @real
+  Scenario: Deployment step reports status back to the source commit
+    When a deployment finishes for a commit that originated from another repository
+    Then the source commit shows the deployment status alongside the build status
+
+  @ticket-0001 @mock @wip
+  Scenario: Status reporting is interrupted when the build system cannot be reached
+    When a build step tries to report status but the build system is unavailable
+    Then the pipeline fails with a clear error message
+
+  # ---------------------------------------------------------------------------
+  # Ticket 0004: tag-commit.sh — Version tagging on commits
+  # ---------------------------------------------------------------------------
+
+  @ticket-0004 @mock @wip @real
+  Scenario: Build tags a commit with a version number after a successful docker push
+    When a container image is built and pushed successfully
+    Then the commit receives a version tag that includes the build number
+
+  @ticket-0004 @mock @wip @real
+  Scenario Outline: Tagging a commit with a specific version
+    When a build completes with version "<version>"
+    Then the commit is tagged with "<version>"
+
+    Examples:
+      | version   |
+      | 1.2.3.42  |
+      | 2.0.0.1   |
+      | 0.1.0.15  |
+
+  @ticket-0004 @mock @wip
+  Scenario: Tagging fails when the same version tag already exists on the commit
+    When a build tries to tag a commit with a version that is already tagged
+    Then the tagging fails with a notification that the tag already exists
+
+  @ticket-0004 @mock @wip
+  Scenario: Tagging fails when no version is provided
+    When a build tries to tag a commit without specifying a version
+    Then the tagging fails with an error

tests/features/deployment.feature

@@ -0,0 +1,45 @@
+Feature: Deployment
+  As a developer
+  I want automated GitOps deployments to environments
+  So that container versions are deployed consistently and the chain is traceable
+
+  Background:
+    Given a container image has been built and pushed
+    And a Helm configuration repository exists
+
+  # ---------------------------------------------------------------------------
+  # Ticket 0007: deploy.yml — GitOps deployment workflow
+  # ---------------------------------------------------------------------------
+
+  @ticket-0007 @mock @wip @real
+  Scenario: Deploy a container version to a staging environment
+    When a deployment is dispatched to the staging environment with a new version
+    Then the Helm configuration is updated with the new container version
+    And the change is committed and pushed to the configuration repository
+
+  @ticket-0007 @mock @wip @real
+  Scenario: Deploy a container version to the production environment
+    When a deployment is dispatched to the production environment with a new version
+    Then the Helm configuration is updated with the new container version
+    And the change is committed and pushed to the configuration repository
+
+  @ticket-0007 @mock @wip @real
+  Scenario: Deployment reports its source back to the originating commit
+    When a deployment completes successfully
+    Then the originating commit shows a deployed status with a link to the deployment commit
+
+  @ticket-0007 @mock @wip @real
+  Scenario: Deployment configuration commit shows where the deploy came from
+    When a deployment commit is created in the configuration repository
+    Then the configuration commit shows a trace status linking back to the source commit
+
+  @ticket-0007 @mock @wip @real
+  Scenario: Developer navigates from source commit to deployment commit and back
+    When a developer views the source commit
+    Then they can click a deploy status to navigate to the deployment commit
+    And from the deployment commit they can navigate back to the source commit
+
+  @ticket-0007 @mock @wip
+  Scenario: Only one deployment runs at a time for the same environment
+    When a new deployment is dispatched to an environment that already has one in progress
+    Then the existing deployment continues and the new one waits

tests/features/report-browsing.feature

@@ -0,0 +1,76 @@
+Feature: Report browsing
+  As a developer
+  I want to browse test reports and build history in a web browser
+  So that I can review test results, compare builds, and navigate between reports
+
+  Background:
+    Given a project has completed at least one build
+    And the build reports are accessible through the report storage
+
+  # ---------------------------------------------------------------------------
+  # Ticket 0003: push-reports.sh — Pushing test reports to storage
+  # ---------------------------------------------------------------------------
+
+  @ticket-0003 @mock @wip @real
+  Scenario: Push Cucumber test report after a successful test run
+    When a test run produces a Cucumber report
+    Then the report is stored and accessible at a permanent web address
+
+  @ticket-0003 @mock @wip @real
+  Scenario: Push code coverage report after analysis
+    When a build generates a code coverage report
+    Then the coverage report is stored and accessible at a permanent web address
+
+  @ticket-0003 @mock @wip @real
+  Scenario Outline: Push different types of test artifacts
+    When a build produces a "<report_type>" report
+    Then the report is stored under its own section in the build's report listing
+
+    Examples:
+      | report_type |
+      | Cucumber    |
+      | JaCoCo      |
+      | JUnit       |
+      | Maven Site  |
+
+  @ticket-0003 @mock @wip @real
+  Scenario: Report push updates the build report index
+    When a report is pushed to storage
+    Then the build's report listing includes a link to the new report with its display name
+
+  @ticket-0003 @mock @wip
+  Scenario: Report push fails when the source report directory does not exist
+    When a build tries to push a report but the report directory is missing
+    Then the pipeline fails with a clear error
+
+  # ---------------------------------------------------------------------------
+  # Ticket 0005: report-service/ — HTML index generation for report browsing
+  # ---------------------------------------------------------------------------
+
+  @ticket-0005 @mock @wip @real
+  Scenario: Developer sees a list of all builds for a project
+    When a developer opens the project build history page
+    Then all builds are listed in chronological order with the newest first
+    And each build shows its short commit identifier, date, branch, and status
+
+  @ticket-0005 @mock @wip @real
+  Scenario: Developer navigates into a specific build to see its reports
+    When a developer clicks on a build in the project build history
+    Then a page opens showing all reports available for that build as clickable links
+
+  @ticket-0005 @mock @wip @real
+  Scenario: Build listing shows success or failure status with a clear indicator
+    When a build has completed
+    Then the build listing shows a success indicator for passing builds
+    And a failure indicator for failing builds
+
+  @ticket-0005 @mock @wip @real
+  Scenario: Developer can navigate back from a build report listing to the project build history
+    When a developer is viewing the reports of a specific build
+    Then a navigation link leads back to the project build history page
+
+  @ticket-0005 @mock @wip @real
+  Scenario: Developer opens two builds side by side to compare reports
+    When a developer views two different builds in separate browser tabs
+    Then both builds show their respective report listings
+    And the developer can compare which tests passed or failed between the builds

tests/features/test-execution.feature

@@ -0,0 +1,92 @@
+Feature: Test execution
+  As a test engineer
+  I want integration and end-to-end tests to run automatically after deployment
+  So that I can verify the deployed version works correctly
+
+  Background:
+    Given a deployment has completed in the target environment
+    And the test project repository exists with test definitions
+
+  # ---------------------------------------------------------------------------
+  # Ticket 0002: dispatch-workflow.sh — Dispatching and polling workflows
+  # ---------------------------------------------------------------------------
+
+  @ticket-0002 @mock @wip @real
+  Scenario: Dispatch a test workflow and wait for its completion
+    When a test workflow is dispatched to a test project
+    Then the pipeline waits until the test workflow finishes
+    And the pipeline continues only after receiving a success result
+
+  @ticket-0002 @mock @wip @real
+  Scenario: Dispatch fails when the dispatched test workflow fails
+    When a test workflow is dispatched and the tests fail
+    Then the calling pipeline reports failure
+
+  @ticket-0002 @mock @wip
+  Scenario: Dispatch times out when the test workflow takes too long
+    When a test workflow is dispatched but does not finish within the allowed time
+    Then the calling pipeline reports a timeout error
+
+  # ---------------------------------------------------------------------------
+  # Ticket 0011: check-version.sh — Version polling with Fibonacci backoff
+  # ---------------------------------------------------------------------------
+
+  @ticket-0011 @mock @wip @real
+  Scenario: Target version is eventually found after a few retries
+    When the deployed version in the environment does not match the expected version initially
+    And the version check is retried with increasing wait times
+    Then the version eventually matches and the test flow proceeds
+
+  @ticket-0011 @mock @wip
+  Scenario: Target version is never found within the maximum retries
+    When the deployed version keeps returning a different version than expected
+    And the maximum number of retries is reached
+    Then the version check fails with a version mismatch error
+
+  @ticket-0011 @mock @wip
+  Scenario: Version check fails when the version endpoint cannot be reached
+    When the version API endpoint is not responding
+    Then the version check fails with an error
+
+  # ---------------------------------------------------------------------------
+  # Ticket 0008: test.yml — Test flow execution and cross-repo reporting
+  # ---------------------------------------------------------------------------
+
+  @ticket-0008 @mock @wip @real
+  Scenario: Test flow verifies the deployed version before running tests
+    When a test flow is triggered
+    Then the version of the running container is checked against the expected version
+    And tests proceed only after the version matches
+
+  @ticket-0008 @mock @wip @real
+  Scenario: Test flow executes tests and publishes reports
+    When tests are executed as part of the test flow
+    Then the test reports are published to the report storage
+    And the reports are accessible through the browse interface
+
+  @ticket-0008 @mock @wip @real
+  Scenario: Test flow reports results to the test project commit
+    When tests complete
+    Then the test project commit shows a test status with a link to the report
+
+  @ticket-0008 @mock @wip @real
+  Scenario: Test flow reports results back to the source commit
+    When tests complete for a source commit
+    Then the source commit shows which tests were run and a link to the results
+
+  @ticket-0008 @mock @wip @real
+  Scenario: Test flow reports the tested version on the deployment commit
+    When tests complete
+    Then the deployment commit shows which version was tested and a link to the test results
+
+  @ticket-0008 @mock @wip @real
+  Scenario: Developer traces the full chain from source commit through deployment to test results
+    When a developer views the source commit
+    Then they can follow the deployment status to the deployment commit
+    And from the deployment commit they can follow the test status to the test results
+    And from the test results they can navigate back to the source commit
+
+  @ticket-0008 @mock @wip @real
+  Scenario: Developer sees which container version was tested on the test project commit
+    When a developer views the test project commit
+    Then the commit shows the tested container version and the source commit it originated from