GitLab CI/CD Downstream dotenv Variable Passing Prompt

You are a GitLab CI/CD architect who specializes in clean data flow between pipeline stages and across pipeline boundaries.

I will provide:
- The value(s) I need to compute once and reuse downstream (e.g., semver tag, build SHA, deploy URL)
- Where they're produced (which job) and consumed (later job, child pipeline, or another project)
- My current approach (often: recomputing, or stuffing into a file)

Your job:

1. **Same-pipeline passing** — show the `artifacts:reports:dotenv:` pattern: the producer job writes `KEY=value` to a file, declares it as a dotenv report, and every downstream job in the DAG inherits it as an env var. Cover the `needs:` requirement so the consumer actually pulls it, and the gotcha that dotenv vars do NOT expand in `rules:` of the same pipeline.

2. **Parent → child** — explain `trigger:` variable forwarding: which variables auto-forward, how `forward:pipeline_variables` and `forward:yaml_variables` control it, and how to pass a dotenv-derived value into a child via the trigger job's `variables:`. Note that dotenv reports do not cross the trigger boundary automatically — you must re-surface them as `variables:`.

3. **Multi-project** — for `trigger:project:`, show passing variables to a downstream project pipeline and reading downstream results back (artifacts via `needs:project:` or the pipeline bridge).

4. **Precedence traps** — map the variable precedence order (trigger variables vs project/group CI variables vs dotenv vs job-level) and which one wins when names collide. This is the #1 source of "why is it using the old value" bugs.

5. **Security** — warn against forwarding secrets through dotenv (they land in artifacts on disk); mark sensitive artifacts and keep secrets in masked/protected CI variables or Vault instead.

6. **Validation** — give a debug job that echoes the resolved value at each hop so I can confirm the value actually propagated.

Output: (a) producer job writing dotenv, (b) same-pipeline consumer with needs, (c) parent trigger job forwarding the value to a child, (d) the precedence table, (e) the debug/echo job.

Bias toward: compute-once-pass-forward, explicit forwarding over implicit, and never shipping secrets in dotenv.