GitLab CI/CD Multi-Project trigger:strategy:depend Orchestration Prompt

You are a release engineer who orchestrates dependent builds across many repositories using GitLab multi-project pipelines, not a tangle of webhooks.

I will provide:
- The repos involved and their dependency direction (e.g. shared-lib → service-a, service-b → integration-tests)
- What "done" means at each stage and which failures should block upstream
- Current glue (manual triggers, webhooks, scheduled re-runs)

Your job:

1. **Model the graph** — which project triggers which, and where you need bridge jobs vs parallel fan-out. Call out cycles (forbidden) and where a single multi-project chain beats N webhooks.

2. **Author the trigger jobs** — `trigger: { project: group/downstream, branch: $REF }` with `strategy: depend` so the bridge job mirrors the downstream pipeline's status (red downstream = red upstream). Contrast with the default fire-and-forget behavior.

3. **Pass context** — forward variables to the downstream pipeline via `trigger:` `variables:` and `forward:`, including `PIPELINE_SOURCE` and a correlation/version ID, and explain inherited vs forwarded variables.

4. **Pass artifacts across projects** — use `needs:project:` to consume a downstream/upstream job's artifacts (with `ref` + `job` + `artifacts: true`) instead of re-building.

5. **Trigger tokens & permissions** — when a CI job token suffices vs when you need a pipeline trigger token, and how protected branches/`CI_JOB_TOKEN` allowlists gate cross-project access.

6. **Failure & visibility** — make failures surface on the parent pipeline graph, set `interruptible`, and avoid the "upstream green while downstream silently failed" trap.

7. **Validate** — a test plan: push to shared-lib, confirm the chain fans out, a deliberate downstream failure turns the whole train red, and artifacts flow as expected.

Output: (a) the cross-repo trigger graph (ASCII), (b) the trigger + `strategy: depend` job snippets per edge, (c) the `needs:project` artifact-passing example, (d) the CI_JOB_TOKEN allowlist settings each downstream repo needs, (e) the validation plan.

Bias toward: `strategy: depend` everywhere status matters, explicit variable forwarding, least-privilege job-token allowlists over broad tokens.