Workflows and WORKFLOW.md State set -euo pipefail Where the Hub Requires set -Eeuo pipefail

[ptr727]

Summary

This repository's workflows and its WORKFLOW.md both state set -euo pipefail, while the hub's WORKFLOW.md D9.3 requires set -Eeuo pipefail and the hub's own caller stubs use it. Carrying the workflow-ci-contract Skill in #334 makes the divergence visible, since the Skill states the hub's rule inside a repository whose files state the other one.

Raised by Copilot on #334 against .github/skills/workflow-ci-contract/SKILL.md:26. The Skill is carried at declared fidelity and is not this repository's to edit, so the fix belongs on this repository's own side.

Current state

$ grep -rn 'set -euo pipefail' .github/workflows/ | wc -l
9
$ grep -n 'D9.3' WORKFLOW.md
- **D9.3** Bash `run:` blocks start `set -euo pipefail`; multi-line `if:` uses `>-`.

Against the hub at a9afa1d:

$ grep -n 'D9.3' WORKFLOW.md
217:- **D9.3** Bash `run:` blocks start `set -Eeuo pipefail`. Multi-line `if:` uses `>-`.

-E makes an ERR trap inherit into functions, subshells, and command substitutions. Without it a trap set at the top of a run: block silently does not fire in those contexts.

Why it is not fixed in #334

Seven of the nine sites are in build-release-task.yml, validate-task.yml, and run-codegen-pull-request-task.yml, which the workflow-adoption PR deletes outright in favour of the hub-hosted tasks. The remaining two are in test-pull-request.yml and merge-bot-pull-request.yml, which that same PR rewrites as caller stubs carrying the hub's set -Eeuo pipefail. WORKFLOW.md is carried whole from the hub in the same PR, which brings D9.3 with it.

Fixing the sites in #334 would edit files that PR deletes.

Closing condition

The workflow-adoption PR merges, and grep -rn 'set -euo pipefail' .github/workflows/ returns nothing.