Seven GOVERNANCE.md and carried-skill claims the shipped workflows falsify

[ptr727]

Seven claims in GOVERNANCE.md "Workflow YAML Conventions" and in the carried skills tree are false against the shipped files, or state a rule a reader cannot act on. Found by the whole-unit canonical passes on PR #1198 and deferred out of it, whose scope was WORKFLOW.md section 4's contract claims.

Both surfaces are carried, so every fleet repository reads them.

GOVERNANCE.md "Workflow YAML Conventions"

1. The concurrency exception describes a file that does none of it.

.github/workflows/publish-release.yml ... publishes shared ref-independent artifacts (both branches' Docker tags/caches and GitHub releases) on schedule/dispatch regardless of the triggering ref

This repository's publish-release.yml triggers on workflow_dispatch only, sets dockerhub: false and every enable_* false, and pushes no Docker tags or caches. The schedule and the tags live in a downstream Docker repository's stub. The same sentence says both exceptions "record the rationale inline in their header comment", and this file records the dispatch-serialization rationale only.

2. cancel-in-progress: false does not deliver the guarantee claimed for it.

requires each event to run to completion in arrival order ... The global group + queueing serializes every publish run to completion.

GitHub keeps at most one in-progress plus one pending run per concurrency group and cancels the previously pending run when a newer one queues. Three rapid events on one bot pull request drop the middle run, and a third publish dispatch silently cancels the queued second one rather than running it to completion.

3. The step-name rule admits no exception and this repository breaks it.

every step's name: ends in step ... There is no un-suffixed exception.

.github/workflows/validate-task.yml:316 carries name: Upload coverage to Codecov step (Python). Nothing enforces the rule mechanically, so the absolute wording and the shipped canonical content disagree. Either the rule admits a trailing parenthetical disambiguator or that step is renamed.

4. The multi-image buildcache bullet names a mechanism nothing demonstrates.

plus the base image's own tag and inline cache

"inline cache" appears nowhere else in the repository, no type=inline and no BUILDKIT_INLINE_CACHE, and the base-image build is a caller-owned hook with no hub default. The same bullet says a multi-image repository uses a per-image tag, where build-docker-task.yml hard-codes the tag and varies the repository instead, which is what its own example shows.

5. Two rules cover surfaces they do not name.

The trigger enumeration for entry-point workflows omits pull_request_target, the sole trigger of this repository's own merge-bot-pull-request.yml, so that file is classified as neither reusable nor entry-point and the filename and name-suffix rules reach it as nothing. The action-pinning rule prescribes a # vX.Y.Z comment, while every hub-task pin in the fleet carries a release tag with no v, and the naming rules say nothing about the composite actions under .github/actions/**, whose shipped names match none of the stated suffixes.

6. The "every bash surface" enumeration cannot be followed on two of them.

every bash surface, a multi-line run: block and every committed .sh script alike, starts with set -Eeuo pipefail

Two committed shell surfaces are neither: .husky/pre-commit is #!/bin/sh carrying only set -e, and the catalog/ pre-commit snippet carries no set line. For a #!/bin/sh script the rule cannot be followed at all, since set -E and pipefail are not POSIX and abort under dash. Read literally the rule also puts the set line above the shebang, which breaks the script; the shell-codestyle skill settles that it sits after the shebang and header comment. WORKFLOW.md section 2 carries the same wording, so the fix belongs at both.

The carried skills tree

7. operational-vs-release-workflow states three things the tree contradicts. Its "Orchestration vs. build" section says the aggregator wiring is changes -> smoke-build -> check-workflow-status, which is one of the two shipped stub shapes and not the one a no-build repository carries; calls that wiring "verbatim" where spec/files.json grades the file interface; and names a merge-bot branch prefix (merge-upstream-version) that exists only as a job name in one downstream repository's carried workflow, where the task's own default is upstream-version.

Related

#1200 covers WORKFLOW.md section 4, #1201 its section 5 audit procedure, #1199 the live pytest --cov defect.

[ptr727]

Rolled up per #1315 into the unit tracker(s) #1348, #1367: every finding this issue enumerates appears there as a numbered line naming this issue. Closing as a duplicate of those trackers so no finding is lost and this bundle stops being a unit of work.