Lane telemetry: babysit-loop

[kyle-sexton]

Standing telemetry issue for the autonomous PR-merge-lane orchestrator (babysit-loop) on this repository.

Purpose

Each coordinator instance upserts one cycle-summary comment here, keyed by its instance ID, recording what it observed and what it did or deliberately did not do. This issue is a log, not a work item; it is not expected to close.

Reading this log

• One comment per instance ID. An instance edits its own comment on later cycles rather than adding new ones.
• Comments record read-only diagnosis by default. The lane does not merge dependency-manager PRs, and does not bypass any branch rule.
• Items needing a human decision are called out explicitly in the comment that found them.

No related issue: standing telemetry log, not a code change.

[kyle-sexton]

Cycle summary — instance ccr-session-babysit-loop-20260905

Cycle: 2026-09-06T06:51Z · lane babysit-loop · read-only, no merge attempted

Scope this cycle

PR	Author	Head SHA	Outcome
#30 build: bump actions/checkout 5.1.0 → 7.0.1	dependabot[bot]	5bd185d3	Diagnosed, held for human dependency decision

---

⚠️ MAJOR-VERSION BUMP — needs an explicit human acceptance decision

PR #30 is not a routine patch bump. It crosses two major versions of actions/checkout (v5 → v7) and carries an upstream breaking change to default fork-PR checkout behaviour:

• v7.0.0 — "Block checking out fork PR for pull_request_target and workflow_run" (actions/checkout#2454)
• v6.1.0 — [BREAKING] backport of allow-unsafe-pr-checkout (actions/checkout#2500), per the GitHub changelog on safer pull_request_target defaults

Assessed blast radius on this repository: currently nil. Both workflows were checked:

Workflow	Triggers	Affected by the v7 fork-checkout block?
.github/workflows/ci.yml	push, pull_request, merge_group, workflow_dispatch	No
.github/workflows/managed-files-guard.yml	pull_request	No

Neither workflow uses pull_request_target or workflow_run, which are the only triggers the v7 change restricts.

Corroborating evidence that v7.0.1 already works here: managed-files-guard.yml is already pinned to actions/checkout@3d3c42e5… (v7.0.1) on main today, and its managed-files-guard check passes on this very PR. So v7.0.1 is empirically running green in this repository already; PR #30 only brings ci.yml into line with it.

Standing caveat for the human: accepting this bump makes v7 semantics the repo default. Any future workflow added here that uses pull_request_target or workflow_run and needs to check out fork PR code will have to opt in explicitly via allow-unsafe-pr-checkout, and should not do so without a deliberate security review. That is a forward-looking constraint, not a present-day breakage.

---

Why mergeable_state = blocked — root cause found, and it is NOT the dependency hold

Diagnosis separated the advisory noise from the real gate:

1. needs-issue-linkage is ADVISORY here, not a gate. The org ci-gate ruleset requires exactly one context: ci-status (app 15368). There is no required pr-issue-linkage check on this repo. The CI log states this outright:

pr-contract: issue linkage is advisory in this repository; the step does not fail on it.

The label and the bot comment on #30 are therefore informational only. This matches the advisory-vs-gate distinction found on other repos' dependabot PRs this session.

2. The real blocker is a duplicate-workflow-run race, not a code or lane failure. Two CI runs were created on head SHA 5bd185d3 in the same second (21:14:54):

Run	Kind	Result
#44 (33992474869)	full run — all four lanes executed	✅ success; recorded ci-lanes status at 21:15:40
#45 (33992475013)	contract-only — lanes gated off (results: skipped skipped skipped skipped)	❌ failure at 21:15:04

Run #45 is contract-only, so it does not aggregate lanes; it reads back the ci-lanes commit status that the full run records. It looked for that status at 21:15:03 — roughly 37 seconds before run #44 wrote it — and fail-closed:

no successful ci-lanes status on 5bd185d3…; re-run the full workflow

The carry-forward-wait-seconds: 240 bounded wait in ci.yml exists precisely to absorb this race, but it did not engage: run #45 failed after ~1.1s, not after the 240s ceiling.

Substantive lane check: every real lane is green. Shell, PowerShell, Manifests, Docs, managed-files-guard and GitGuardian all pass on run #44, and the combined commit status is ci-lanes: success — All lanes passed. The PR is mergeable: true (no conflicts), commit signature verified, zero unresolved review threads, and the base ruleset requires zero approving reviews. The failing ci-status check run is a CI infrastructure artifact carrying no signal about the checkout bump.

The block persists because both ci-status check runs survive GitHub's filter=latest (they belong to different check suites), leaving the single required context ambiguous — one success, one failure.

Suggested remedy (not applied by this lane): re-run the failed contract-only run #45. The ci-lanes: success status it was racing for now exists on the SHA, so its carry-forward will resolve and the required context will go green. No new commit is needed.

---

🔧 Latent CI bug worth filing separately

The carry-forward wait resolves "earlier incomplete runs on the same head SHA" in a way that appears to break on an exact same-second created_at tie, so no earlier run is found and it fail-closes immediately instead of waiting.

Scanned the last 40 runs of this workflow. Every other multi-run SHA has runs at least one second apart and all resolved green — including chore/standards-sync at 21:49:30 / 21:49:31, where the wait worked correctly:

Head SHA	Runs	Gap	Outcome
5bd185d3 (PR #30, dependabot)	#44, #45	0s (tie)	❌ #45 failed
c178ed98 (standards-sync)	#46, #47	1s	✅ both green
090c2a30 (ci-perf)	#40–42	84s+	✅ all green

This is likely to recur on dependabot PRs specifically, because Dependabot opens the PR and applies its dependencies label effectively atomically, firing the opened (full) and labeled (contract-only) events in the same second. A strict "earlier than" comparison cannot order a tie.

Suggested hardening: make the ordering total by falling back to run_id/run_number when created_at ties, or treat any concurrent incomplete run on the same SHA (not only a strictly earlier one) as worth waiting for.

---

📝 Review defect in PR #30 that Dependabot will not fix

The diff updates the pin but leaves the explanatory comment above all four occurrences stale and now factually wrong:

# actions/checkout v5.1.0 — pinned to a full-length commit SHA because this
# org requires it; a tag or short SHA is rejected at "Set up job".
- uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1

The comment says v5.1.0; the SHA is v7.0.1. All four sites in ci.yml are affected. For contrast, managed-files-guard.yml annotates the same SHA correctly with a trailing # v7.0.1. If this bump is accepted, those four comments should be corrected in the same PR, and adopting the trailing # v7.0.1 convention would keep the version legible next to the pin.

---

Lane actions taken

• ✅ Claimed PR build: bump actions/checkout from 5.1.0 to 7.0.1 in the github-actions group #30 with a lane-claim marker pinned to head SHA 5bd185d3; claim released this cycle.
• ✅ Re-verified all state live (head SHA, mergeable state, check runs, commit statuses, rulesets, comments). No foreign lease and no activity in ~9.6h, so no yield was required.
• ✅ Created this telemetry issue (the repository had zero open issues).
• ⛔ No merge attempted by any route. babysit_merge.py holds dependency-manager-authored PRs in every tier absent an explicit human --allow-dependency, and this lane treats a major-version bump as warranting more caution than usual, not less.

Blocking on: the human's dependency-acceptance decision for a v5 → v7 major bump. Everything else on this PR is green and clean.

---

Generated by Claude Code