[oschaaf]

What

Every fleet pipeline other than pipeline-pr.yml now opens with a hosted job event-guard. It refuses:

• any event outside the pipeline's allowed list (merge_group is allowed in none of them);
• a ref under refs/heads/gh-readonly-queue/ and any ref outside the pipeline's allowed refs (off-ref pushes and dispatches);
• a workflow_dispatch made by github-actions[bot] (a dispatch made with a workflow token);
• a pull request from a fork or from another repository.

The changes job of pipeline-pr.yml also gets two steps before the fork guard step: it refuses a push on any ref other than refs/heads/master and refs/heads/ci-dev (the queue's temporary branch included) and a dispatch made by github-actions[bot]. The gate pins both steps.

Every fleet job reaches event-guard through needs (root jobs need it directly; in the release pipelines the root ref-guard job does), so a refusal skips the whole fleet.

Why

In a merge_group run the caller ci.yml comes from the queued tree, so a queued tree can call any allow-listed fleet pipeline, and it can produce push and workflow_dispatch events of its own. This narrows that boundary. It does not close it: the policy stays that no fork or Dependabot pull request is added to the merge queue, and the ci-dev copies of the pipelines gain the guards only when ci-dev is next pushed from a master-based branch that carries them.

Pipelines, allowed events and refs

• pipeline-full.yml: push, workflow_dispatch, pull_request; refs/heads/master, refs/heads/ci-dev, refs/pull/*/merge (caller: push to master, dispatch with full: true, ci:full label)
• pipeline-nightly.yml: schedule, workflow_dispatch; refs/heads/master
• pipeline-tidy-sweep.yml: workflow_dispatch; refs/heads/master
• pipeline-release-module.yml, gate-cpanel-smoke.yml, gate-iis-msi-upgrade.yml: push, workflow_dispatch; refs/tags/*, refs/heads/master (dry runs)

Gate

The workflow-shape gate has a rule event-guard: the job text and both lists are pinned per pipeline, and every fleet job must reach the job through needs. Job keys (if, needs, runs-on, continue-on-error, uses) match quoted or with whitespace before the colon. Each job's if: is normalised (multi-line forms joined, a plain value continuing on every line indented more than its key, a #-led line in a block scalar kept as content; lowercased, whitespace collapsed, the space before a function's ( removed). For every job on a needs path between the guard and a fleet job (and fleet jobs whose if: the routing-guard rule does not pin), an if: that contains always(, failure(, cancelled(, success( (unless the whole if: is a bare success()), ||, ! (any negation, != included) or == false must be exactly needs.event-guard.result == 'success' && (<inner>), with <inner> one balanced parenthesised group that does not mention event-guard; the job must need event-guard, and a block scalar holding the condition must strip its final newline. Otherwise the gate rejects the job by name. This also rejects some safe forms, such as needs.event-guard.result != 'failure'. Any other if: is accepted as today (GitHub adds success() implicitly unless the expression names a status function). The gate also refuses YAML anchors and aliases on a job or a job-level key other than steps: and env:, and any <<: merge key, since it cannot resolve them. The release lane's fan-in jobs and hosted twins on the vendor, linux, nginx, el8 and el10 paths now need event-guard and carry their conditions in that form.

Landing order

Stacked on the queue fork guard branch (ci/queue-fork-guard); lands after that PR. These pipelines cannot be exercised on the dev ref; they are validated by the next push run, nightly, a release dry run and a dispatch of each gate workflow.