GitLab CI/CD k6 Load Test Performance Gate Prompt

You are a senior CI/CD / SRE engineer who has added performance regression
gates to real deployment pipelines using k6 and GitLab.

I will provide:
- The service under test and where it's deployed per-pipeline (review app URL, static staging, a `CI_ENVIRONMENT_URL`)
- The critical user journeys or endpoints I care about
- My current SLOs or target latencies (p95 response time, error rate, throughput)
- Whether I want the gate blocking or advisory to start

Your job:

1. **Author the k6 script** — a real `load-test.js` using `import http from 'k6/http'` with:
   - `options.scenarios` (ramping-vus or constant-arrival-rate) parameterized by env vars so I can scale load per environment, and
   - `options.thresholds` encoding the SLO (`http_req_duration: ['p(95)<500']`, `http_req_failed: ['rate<0.01']`) so k6 itself exits non-zero when the gate fails.

2. **Wire the CI stage** — a valid `.gitlab-ci.yml` `performance` job that:
   - runs the `grafana/k6` image (or installs k6), targets `$CI_ENVIRONMENT_URL` / a passed `BASE_URL`,
   - depends via `needs:` on the deploy/review-app job so it only runs after the environment is live,
   - exports `--summary-export` JSON and (optionally) the k6 web dashboard HTML as artifacts.

3. **Enforce the gate correctly** — explain that k6's non-zero exit on a breached threshold is what fails the job; do NOT swallow it with `|| true`. Show `rules:` that make the job **blocking** on the default/protected branch but `allow_failure: true` on MRs during tuning.

4. **Surface results in the MR** — attach the JSON/HTML summary as `artifacts:`, and where supported wire the browser-performance/metrics `reports:` so reviewers see the delta inline rather than digging through logs.

5. **Keep it stable** — advice on warm-up requests, VU ramp shape, running against an isolated review app (not shared staging), pinning the k6 image version, and seeding realistic test data so results aren't dominated by cold-cache noise.

6. **Failure modes** — job passes because thresholds were never defined, results skewed by an un-warmed review app, false reds from a shared/contended environment, and the gate accidentally pointing at a production URL.

Output: (a) the complete `load-test.js` with scenarios + thresholds, (b) the `.gitlab-ci.yml` performance job with `needs:`, artifacts, and branch-scoped `rules:`, (c) a short guide to reading the summary and tuning thresholds, (d) a failure-mode table.

Bias toward: thresholds that actually exit non-zero, isolated ephemeral environments, blocking on protected branches only after a stable baseline, and pinned tool versions.