Tracker: `.agents/skills/workflow-ci-contract/SKILL.md`

[ptr727]

Tracker for .agents/skills/workflow-ci-contract/SKILL.md. Filed under #1315's roll-up of the open prose backlog: every pre-existing finding a whole-unit read raises against this file is listed here once, one line each, naming the unit and the pull request it came from, so the finding is not lost and no pull request carries it as a block. A new pre-existing finding on this file is appended here rather than filed as its own issue.

1. "Publishes come from a code-affecting bot push to main, a manual dispatch of main or develop, or the main-only weekly Docker schedule, while a publisher whose only trigger is workflow_dispatch (releaseTrigger: dispatch-only) reaches the dispatch alone" names a key and value with no stated home, since nothing in the skill says which file or registry declares releaseTrigger. [SKILL.md > The Core Behavioral Spine] (Carry WORKFLOW.md Section 4 Into workflow-ci-contract as an Include #1385)
2. "the release-create step skips when the tag exists and is refreshed only on a dispatch" gives "the release-create step" as the elided subject of "is refreshed", where D4.4 says a dispatch refreshes the release, so read literally the clause states something false about the step. [SKILL.md > The Core Behavioral Spine] (Carry WORKFLOW.md Section 4 Into workflow-ci-contract as an Include #1385)
3. "The merge-bot is the first, and docs/reusable-workflows.md in the hub carries the model, the hook contract, and the phase each workflow migrates in." carries no noun for "the first", and the doc it points at organizes its rollout as Stages and never uses "phase". [SKILL.md > How the Contract Is Read] (Carry WORKFLOW.md Section 4 Into workflow-ci-contract as an Include #1385)
4. "Until a workflow's phase ships, its copy is graded as below." is stale, since every stage's hub task has shipped, and it gives no rule for the reached case while "as below" names no bullet. [SKILL.md > How the Contract Is Read] (Carry WORKFLOW.md Section 4 Into workflow-ci-contract as an Include #1385)
5. "Build leaves (the build-<target> tasks) are repo-owned." flattens WORKFLOW.md's "repo-owned in shape", and the target-curation bullet's instruction to edit the build-<target> job and its needs: entries cannot be followed in a repo that reaches the hub's build-release task. [SKILL.md > How the Contract Is Read] (Carry WORKFLOW.md Section 4 Into workflow-ci-contract as an Include #1385)

[ptr727]

One more from #1385's later read of the same unit, numbered on from item 5.

6. "Build leaves (the build-<target> tasks) are repo-owned." calls the leaves "tasks" where the previous bullet and docs/reusable-workflows.md "Layers" use "task" for a hub-hosted workflow_call reusable workflow, and the same bullet then calls the same thing "the build-<target> job", so the word contradicts the unit's own vocabulary under the carried model and the reached model alike. [SKILL.md > How the Contract Is Read] (Carry WORKFLOW.md Section 4 Into workflow-ci-contract as an Include #1385)

[ptr727]

Ten more from a #1311 second-round pass (complete-brief whole-unit read, opus tier, no PR — read-only) over the whole SKILL.md file, numbering continuing the list above. The reviewer confirmed items 1-6 all still present, unchanged, verbatim, without re-deriving any of them, and separately confirms the caveat already on this issue: the brief was tagged against "The Core Behavioral Spine" and "How the Contract Is Read" only, and the section this issue is nominally filed against, "Style Rules", had never actually been reviewed — items 15-16 below are what that gap held.

7. "Two layers" (the Core Behavioral Spine) says "a leaf receives ref/branch/smoke", true of only one of the two leaf shapes the same bullet distinguishes (workflow-layer vs. composite-action leaf). Verified in the tree: build-docker-task.yml (a workflow-layer leaf) takes ref; build-release-task.yml's build-nuget/build-pypi jobs (composite-action leaves) take no ref input at all and check out ref: ${{ needs.get-version.outputs.GitCommitId }} instead. A reader asserting ref "in the layer that declares it," as the same sentence instructs, would assert it on a layer that does not declare it. [SKILL.md > The Core Behavioral Spine] (Why the Backlog Grows: Prose Review Has No Fixed Point, and a Plan to Keep the Rigor Without It #1311 second round)
8. The same bullet's "build-<target> job" token does not exist for one of the four targets in the hub's own file: the .NET target's job is dotnet-publish, not build-dotnet-publish (build-release-task.yml jobs are dotnet-publish, build-nuget, build-pypi, build-docker). enable_<target> holds for all four; build-<target> holds for three. [SKILL.md > The Core Behavioral Spine] (Why the Backlog Grows: Prose Review Has No Fixed Point, and a Plan to Keep the Rigor Without It #1311 second round)
9. The spine hardcodes "main, a manual dispatch of main or develop, or the main-only weekly Docker schedule" two sentences before the same bullet requires "The gate's branch literal, the prerelease expression, and version.json's publicReleaseRefSpec each name the repo's actual default branch, and a divergence among the three is a defect" — a repo whose default branch isn't main gets a trigger rule in literals the same bullet forbids assuming. [SKILL.md > The Core Behavioral Spine] (Why the Backlog Grows: Prose Review Has No Fixed Point, and a Plan to Keep the Rigor Without It #1311 second round)
10. "After Any Workflow Edit"'s "actionlint still runs on it in CI" overclaims against the file's own declared scope: the frontmatter and "How the Contract Is Read" both cover editing "a workflow or a composite action", but actionlint's targets in this repo (scripts/docker_lint.py) are .github/workflows/*.yml/*.yaml only — a composite-action edit gets no actionlint, though the section heading and the sentence's bare "it" invite the reader to assume it does. [SKILL.md > After Any Workflow Edit] (Why the Backlog Grows: Prose Review Has No Fixed Point, and a Plan to Keep the Rigor Without It #1311 second round)
11. The frontmatter description names four one-line-diff hazards this file exists to catch — "SHA pinning, the ruleset-bound aggregator name, smoke gating on uploads, and retention-days" — and the body never mentions retention-days at all, and never states the aggregator's name is ruleset-bound (only that "one required aggregator gates the merge"). Two of the four advertised hazards are undocumented in the body a reader loads on the strength of that description. [SKILL.md > (frontmatter) / The Core Behavioral Spine] (Why the Backlog Grows: Prose Review Has No Fixed Point, and a Plan to Keep the Rigor Without It #1311 second round)
12. "The Core Behavioral Spine"'s PR-never-publishes sentence ("a paths-filter smoke-builds only changed targets, the caller's own job reaching the reusable validator, or the replacement it points its aggregator at, always runs, and one required aggregator gates the merge") cannot be parsed with confidence: "the replacement" names no antecedent for what it replaces, "it" has two candidate antecedents ("the caller" / "the caller's own job"), and "always runs" sits far enough from its subject to misread as governing the paths-filter. This is the file's single most load-bearing sentence. [SKILL.md > The Core Behavioral Spine] (Why the Backlog Grows: Prose Review Has No Fixed Point, and a Plan to Keep the Rigor Without It #1311 second round)
13. "How the Contract Is Read"'s "The release tags the built commit's SHA (GitCommitId), never a branch name" is ambiguous with the same bullet's "a clean X.Y.Z" / "X.Y.Z-g<sha>" version naming and with "the release-create step skips when the tag exists" — read literally it says the tag name is the SHA, where the intended sense is the tagged commitish. [SKILL.md > How the Contract Is Read] (Why the Backlog Grows: Prose Review Has No Fixed Point, and a Plan to Keep the Rigor Without It #1311 second round)
14. Citation style for D-numbers is inconsistent within the file: one bullet cites "D5 in references/d-guarantees.md" with a stated home, while the "Two layers" bullet ends "(D6.4)" with no home given at all — dangling for a reader who has not also read the section that supplies it. [SKILL.md > The Core Behavioral Spine] (Why the Backlog Grows: Prose Review Has No Fixed Point, and a Plan to Keep the Rigor Without It #1311 second round)
15. "Style Rules"'s own two-sentence body ("GOVERNANCE.md "Workflow YAML Conventions" keeps the style rules, and the comment-and-doc-style Skill keeps the line-ending policy ... Read both before editing a workflow or a composite action") names three referents (two GOVERNANCE.md sections plus one Skill) and "both" resolves to none of the possible pairs unambiguously. This is the section this issue is filed against, and it had not previously been reviewed at all. [SKILL.md > Style Rules] (Why the Backlog Grows: Prose Review Has No Fixed Point, and a Plan to Keep the Rigor Without It #1311 second round)
16. "Style Rules" under-describes the GOVERNANCE.md section it names as its whole content: it says "Workflow YAML Conventions" keeps "the style rules," but the file cites that same section twice more, for rules that are not style — "Validate at entry: GOVERNANCE.md "Workflow YAML Conventions" keeps the rule" and, for cleanup, "keeps the consume-then-delete rule, the condition that gates the delete, and the blanket-delete ban." A reader entering at "Style Rules" is told that section is the style home and would not look there for a behavioral guarantee. [SKILL.md > Style Rules] (Why the Backlog Grows: Prose Review Has No Fixed Point, and a Plan to Keep the Rigor Without It #1311 second round)

Two items also picked up new supporting evidence this round, not new numbers. Item 5 ("Build leaves ... are repo-owned"): the Docker leaf refutes the unqualified claim outright — build-docker is uses: $/.github/workflows/build-docker-task.yml, a hub task reached through $/, with its own needs: list living in the hub file, not repo-owned in any sense. Item 6 (task/job vocabulary contradiction): the contradiction is internal to this file alone — the same bullet that later says "the build-<target> job" uses "task" in the reserved hub-hosted sense four sentences earlier ("reached as a hub-hosted workflow_call task", "A hub task reaches its own actions and sibling tasks through $/"), so it does not require fetching docs/reusable-workflows.md to prove.

[ptr727]

New finding: "The Core Behavioral Spine" and references/test-methodology.md are hand-authored copies

Raised by whole-unit reviews during #1390, and it is the evidence for PR 5 of the #1311
sequence.

AGENTS.md already requires the opposite: "A Skill that needs a rule's full text to work in
isolation carries it as a generated include from the rule's home rather than as a copy, per the
skill-lifecycle Skill, so the text cannot drift undetected."

Only references/d-guarantees.md complies, carrying WORKFLOW.md section 4 through an include
region. "The Core Behavioral Spine" restates the same contract by hand, and
references/test-methodology.md restates section 5 by hand, the latter openly describing its
own status as "read this as an index into them rather than as the sweep itself".

They have already drifted, and in both directions at once, which is what makes this a defect
rather than a redundancy:

• This file's "Style Rules" says "Read both before editing a workflow or a composite
  action." WORKFLOW.md section 2 says "Read the style rules before editing a workflow." The
  skill is wider than its source.
• This file's spine says build leaves are "repo-owned". WORKFLOW.md says "repo-owned in
  shape". The skill is narrower than its source, and its target-curation instructions
  cannot be followed for a hub-reached leaf.

A reviewer reading either surface alone cannot tell which is current, and nothing fails when
they disagree, since neither is checked by build_dist.py --check.

Note one genuine tension to resolve rather than assume away. Two independent reviewers split on
whether naming composite actions is correct: one called WORKFLOW.md section 2's narrower
scope a defect, the other showed that naming them claims territory CODESTYLE.md holds, since
.github/actions/prose-gate/prose_lint.py is the real 78 KB implementation (scripts/prose_lint.py
is a ten-line shim) and is linted by ruff and on the mypy path. Converting these surfaces to
generated includes settles which text is authoritative, and does not by itself answer what that
text should say.