[dependency-drift] Runner fleet pins require review

[github-actions]

The daily official-source freshness check found reviewed pins that need an update PR.

Dependency	Pinned	Latest	Age (days)	Hard fail	Evidence
actions-runner	2.336.0	2.337.0	3	yes	source
repository-pin:melodic-software/ci-workflows	d26c750691b5498fab529d115b63f84aa7aecebe	87f19d4d9be2f4f9af72b4e4fce536bb38057281	9	no	source
syft	1.51.0	1.51.1	2	no	source
github-hosted-powershell	7.6.4	7.6.5	15	yes	source
github-hosted-gh	2.97.0	2.98.0	9	no	source
node-lts	24.19.0	24.20.0	4	no	source
go	1.26.6	1.27.0	10	no	source

Do not auto-merge these updates. Publish and promote a new compatibility pair only after CI, a rolling-host rollout, and independent review.

Last checked: 2026-08-30T09:58:01.5608899+00:00

[kyle-sexton]

In-session drain (2026-08-21): #291 merged the mechanical pins (setup-buildx-action 4.2.0→4.3.0, ci-workflows → v0.17.0 d26c750). This issue stays open as the standing drift evidence issue while Go 1.26.6 is held against 1.27.0 (golangci-lint v2.6.0 cannot lint go1.27; need ≥v2.13.0). Do not close it — the daily monitor would open a replacement issue. Next scheduled freshness run should rewrite the table to the Go row only. Hold record: release/dependency-drift-review.json.

[kyle-sexton]

This was generated by AI — automated lane telemetry.

Triage lane claiming this item for the current cycle (instance MELO-LAP-001-triage-202608230449). Lease TTL 60min. Dispatching /work-items:triage 283.

[kyle-sexton]

This was generated by AI during triage.

Triage outcome: briefed, human-gated

Type: Task
Priority: medium (assessed default — no row is flagged hard-fail, no imminent-deadline signal beyond routine)

Summary: Standing dependency-drift review; three pending pin updates await human sign-off (a cross-repo SHA pin, a runner-image/toolchain compatibility pair, and a Go minor held on a lint-compat blocker).

Why a human must act: established precedent on this exact recurring issue (see #72's escalation and its follow-up gate-audit, and #233) treats dependency-pin and checksum bumps as a reserved human-floor category regardless of how mechanical the diff looks — the autonomous lane cannot judge supply-chain trust in a new upstream SHA/artifact, and a runner-image bump specifically needs a rolling-host rollout plus independent review, not just a green CI run. Nothing about this cycle's rows changes that precedent.

Current state (evidence table as refreshed by the daily freshness check at 2026-08-23T04:54:09Z):

• repository-pin:melodic-software/ci-workflows d26c750 → 0f8176e, age 1 day, no hard fail — cross-repo SHA pin; whoever decides should read what landed in that commit range, since the SHA alone carries no semantics.
• github-hosted-powershell 7.6.4 → 7.6.5, age 8 days, no hard fail — part of the runner-image compatibility pair; needs a rolling-host rollout, not just a review PR.
• go 1.26.6 → 1.27.0, age 3 days, no hard fail — held per the 2026-08-21 note: golangci-lint v2.6.0 cannot lint go1.27; needs golangci-lint ≥ v2.13.0 first. Worth re-checking golangci-lint's current release before deciding whether the blocker still holds.

Decision a human must make: per row, bump now / hold / fold into the next reviewed compatibility pair — plus sign-off on the ci-workflows SHA range and the runner-image rollout specifically.

Out of scope for this triage pass: no auto-merge of any row from this issue. Do not close this issue while pins remain outstanding — the 2026-08-21 note is explicit that closing while unresolved rows exist would cause the daily monitor to open a duplicate.

Decomposition considered, declined: evaluated splitting the three pending rows into separate work items. Declined — this issue is a recurring, bot-refreshed evidence tracker (same pattern as #72 and #233): the daily freshness-check bot rewrites this single issue's body with the current pin table each run, and separate issues would fall outside that refresh mechanism. Recommend continuing the existing in-session-drain pattern instead (as in #291): file a scoped work item only for the row(s) a human actually decides to act on.

No groundwork dispatch (research/interview) was needed beyond this pass — the evidence table was refreshed minutes before this triage and the open questions are supply-chain/rollout judgment calls, not missing information an agent can resolve.

Labels applied: Task (type), priority: medium, status: ready, needs-human. No raw-intake marker was present on this item to clear.

[kyle-sexton]

This was generated by AI — automated drain lane, 2026-08-27.

Cycle 2026-08-27: three review-only PRs prepared, nothing merged, this issue deliberately left open

An automated lane worked all three rows of the current drift table. It merged nothing and closed nothing, because docs/releases.md ("Freshness policy") says "never auto-merge controller, runner, image, toolchain, Scale Set Client, Action, or release changes" and "a passing drift check is necessary but is not promotion approval", this issue carries needs-human, and the 2026-08-21 note above says explicitly not to close it. Each PR carries the do-not-merge label, so its hard gate check fails by design — removing that label is the sign-off action.

Row	PR	Change	Fleet rollout
repository-pin:melodic-software/ci-workflows	#309	v0.17.0 (d26c750) → v0.17.2 (0f8176e), all 21 uses: refs	No
go	#310	1.26.6 → 1.27.0, + lint contract to golangci-lint v2.13.1	Yes
github-hosted-powershell	#311	7.6.4 → 7.6.5 in the worker image	Yes

Merge order is not optional: #309 → #310 → #311. #309 is a hard prerequisite (it brings golangci-lint 2.13.1 into the shared go-quality lane; older golangci-lint refuses to lint a go1.27 module). #311 must go last, because #310 rewrites release/dependency-drift-review.json wholesale and would otherwise silently regress #311's merged decision back to "proposed". Details are in each PR body.

The Go hold is released, and the clock matters

The 2026-08-21 hold's recorded exit condition is met: golangci-lint v2.13.0 shipped go1.27 support on 2026-08-19 and v2.13.1 followed on 2026-08-20. The coupled qualification that hold asked for was performed, not assumed — under go1.27.0: build, vet, 15/15 test packages, the Windows cross-compile, go mod verify, and govulncheck all pass, and golangci-lint v2.13.1 reports 0 issues, matching the v2.12.2 baseline. The feared errcheck/exhaustruct delta surfaces nothing here. All three PRs are green in CI apart from the intentional do-not-merge gate.

Timing worth knowing: the Go row's 14-day hard fail trips on the 2026-09-03 scheduled run.

Two observations about the drift table itself

Surfacing, not fixing:

1. go1.26.7 is invisible in the table. Test-DependencyFreshness.ps1 reports "latest" as the newest stable release overall, so the row shows only 1.27.0 — but the age is computed from the earliest unadopted tag, which is go1.26.7. Both published 2026-08-19, so taking 1.26.7 instead of 1.27.0 would move the drift date by about two hours and buy nothing. There is no cheap partial move on this row.
2. The ci-workflows row can never clear. Test-DependencyFreshness.ps1:214 compares the pin against ci-workflows' default_branch HEAD, which is untagged (e3d93da at the last run, already 49c6b08 now), while the reviewed-pin contract targets published release tags. The table's "Latest" for this row is therefore not a valid bump target, and the row will keep reporting drift after build(deps): bump ci-workflows to v0.17.2 #309 merges — expected under the partial-drain rule, but the evidence link invites bumping to an untagged commit.

Decision needed

Per row: sign off (remove do-not-merge, merge in the stated order) / hold / fold into the next reviewed compatibility pair. #310 and #311 both feed compatibility.json, so merging them promotes nothing on its own — publication and the rolling-host rollout remain a separate operator runbook, and this lane did not touch any runner host.

This issue stays open. dependency-drift.yml reconciles it itself: it closes it when hasDrift is false and otherwise refreshes whichever matching issue is currently state: 'open'. It never reopens a closed one, so a manual close while rows remain outstanding produces a duplicate.