ci: gate on truecopy-action b2b1b9c, clearer publish verification

[askalf]

What this changes

• truecopy-gate.yml runs askalf/truecopy-action@b2b1b9c, the squash merge of truecopy-action#31, instead of 3983d25 (v1.1.0). The gate now uses the action's random report delimiter and installs truecopy v0.10.4 by default.
• publish.yml:
  • The setup-node comment names the current test matrix: 20, 22, 24.
  • The registry poll waits the full 120s, then fails with an explicit error. Before, it fell through to an npm install that then failed with ETARGET, which looks like a broken package when the real cause is registry lag.

Why

This keeps the self-gate on the current action. The v1.1.1 and v1 tags for b2b1b9c aren't pushed yet, so the pin is by SHA, which is how this repo pins every action.

How it was verified

• actionlint 1.7.12 with shellcheck 0.11.0: clean.
• With npm view stubbed to always fail, the poll errors after 12 sleeps (120s), not 11.
• The gate keeps verify-attestation: 'true', and the v0.10.4 release tarball it installs has a Sigstore attestation. verify pinned skills passes on the new pin.
• npm test: no source changes
• Detection change? N/A
• Acceptance change? N/A

[sprayberry-redline]

Automated review from the Sprayberry Labs fleet code reviewer.
Reviewed by the GPT gating lane (gating review).

Verdict: changes requested — the registry timeout is ten seconds shorter than stated and intended. rule:none

Blocking — correctness — .github/workflows/publish.yml:99

[ "$i" -lt 12 ] || { echo "::error::@askalf/truecopy@${v} not on the registry after 120s"; exit 1; }

When the package remains unavailable, attempts 1 through 11 each sleep for 10 seconds. Attempt 12 reaches this new exit before its sleep, so the job fails after roughly 110 seconds (plus command overhead), while reporting and intending a 120-second registry window. A publication that becomes visible during that missing final interval is rejected unnecessarily.

            if [ "$i" -eq 12 ]; then
              echo "::error::@askalf/truecopy@${v} not on the registry after 120s"
              exit 1
            fi

Then structure the retry interval so the final availability check occurs after the intended 120-second wait (or adjust the loop bound/message to the actual 110-second policy).

What's good: required CI is green at the live head, the action pin remains a full commit SHA, and the setup-node matrix comment now matches the stated supported runtimes.

Checked the two workflow-only changes and required CI; I did not run the local test suite.

[sprayberry-secondread]

Automated review from the Sprayberry Labs fleet code reviewer.

Reviewed by the Claude second-opinion lane (independent second read; the gating review is posted separately).

Verdict: No blocking issues. This is a small CI-config change and does what the body says. One low note below; it doesn't need to block the merge. A second note, about the publish poll, is already fixed at 465d185.

Findings

Low: .github/workflows/truecopy-gate.yml:28 version comment names a tag that doesn't exist yet

        uses: askalf/truecopy-action@b2b1b9cf34bb37377878c3c8d59efd54bd030e0f # v1.1.1

The SHA is correct. It is the merge commit of truecopy-action#31 and is identical to that repo's master. The highest tag published in truecopy-action is still v1.1.0 (3983d25), though, and the body says v1.1.1 hasn't been pushed. Dependabot and human readers both treat the trailing comment as the version, so until the tag exists the comment points at nothing. If v1.1.1 ends up on a different commit (a release or changelog commit after #31, say), the comment will be wrong for good. Either push v1.1.1 at b2b1b9c before merging, or make the comment say what the pin is today:

Suggested fix:

        uses: askalf/truecopy-action@b2b1b9cf34bb37377878c3c8d59efd54bd030e0f # master (#31); v1.1.1 once tagged

Resolved at 465d185: .github/workflows/publish.yml registry poll budget

I wrote this review against 39b4df3, and the head moved to 465d185 while I was posting it. At 39b4df3, the [ "$i" -lt 12 ] || exit 1 check ran before the twelfth sleep 10, so the poll gave up after about 110s even though the message said 120s. 465d185 sleeps all twelve intervals and then does one last check:

          if [ "$found" -eq 0 ] && ! npm view "@askalf/truecopy@${v}" version >/dev/null 2>&1; then
            echo "::error::@askalf/truecopy@${v} not on the registry after 120s"

I read that delta. The budget is now 12 sleeps, about 120s, and the message is accurate. ! npm view inside an if condition is exempt from set -e, so a miss reaches the ::error:: path instead of aborting silently. Nothing is left to fix here.

What I checked

• b2b1b9c is truecopy-action#31's merge commit (merged, merge_commit_sha matches), and it is identical to truecopy-action master. The range 3983d25...b2b1b9c is 11 commits: 6 dependabot bumps, CI and docs changes, and #31. Nothing else was pulled into the gate.
• At b2b1b9c, action.yml defaults to truecopy v0.10.4, which is a published, non-prerelease release in this repo. verify-attestation: 'true' is unchanged.
• The verify pinned skills job ran green at this head on the new pin with attestation verification on. That job is the real exercise of the bump.
• The publish.yml:51 comment now matches ci.yml:34 (node: [20, 22, 24]).
• Every other check at 39b4df3 passes: actionlint, CodeQL, and the 9-way test matrix, plus packed tarball on ubuntu and windows. At 465d185, most are green and CodeQL plus two test jobs were still running when I checked.

What's good: the pin stays a full SHA, which matches how the repo pins everything else, and the body is upfront that the tag is still pending. Turning the ETARGET fall-through into a named registry-lag error is a real diagnosability win for the publish job.

[sprayberry-redline]

Automated review from the Sprayberry Labs fleet code reviewer.

Reviewed by the GPT gating lane (gating review).

CHANGES REQUESTED: remove the generated-writing attribution from the public PR description. rule:reads-as-generated

Blocking — PR description:22

_Generated by [Claude Code](https://claude.ai/code/session_01XZEotnWUeFC5V4AHMKBM9W)_

The public PR description explicitly labels the change as generated and links to a model session. First-party strict mode requires generated-writing tells in public PR text to be removed. Delete this footer; the implementation and verification claims should stand on their own.

The workflow diff itself is focused: the registry poll now performs its final lookup after all twelve sleeps before issuing a clear failure, and the action update remains SHA-pinned. I also confirmed all required checks pass at 465d185e11b12ad18103196ee823a53aa74cfa10; this workflows-only PR is verification-exempt under the first-party rule.

[sprayberry-redline]

Automated review from the Sprayberry Labs fleet code reviewer.

Reviewed by the GPT gating lane (gating review).

Verdict: approve — no blocking issues found in the workflow-configuration-only diff.

I checked the live-head diff and the required-check status. The changed files are workflow configuration only: the registry poll now waits all twelve 10-second intervals and performs a final lookup before emitting a clear failure, while the gate action remains SHA-pinned and attestation verification stays enabled. Required CI has several jobs pending at this head; this PR is configuration-only and therefore exempt from awaiting CI under the first-party verification policy.

What's good: the explicit found flag avoids treating an unsuccessful final polling interval as success, and the post-loop lookup correctly accommodates publication becoming visible immediately after the last sleep.