Fix CLI coverage update branch drift

[IlyaasK]

What

Fixes update-cli-coverage.yml so it no longer reuses the stale evergreen cli-coverage-update branch before running the Cursor CLI updater.

The workflow now:

• computes a per-SDK update branch, for example cli-coverage-v0.62.0
• clones kernel/cli fresh from main
• creates the update branch from fresh main
• reads the current CLI SDK pin with go list -m, not grep
• instructs Cursor to push/update the per-SDK branch instead of the old long-lived branch

Why

The existing workflow is currently failing before Cursor runs. It checks out the stale cli-coverage-update branch, tries to merge origin/main, ignores merge conflicts with || true, then reads a conflicted go.mod.

That produces two SDK versions:

v0.50.0
v0.58.0

GitHub then rejects the multiline output:

Invalid format 'v0.58.0'

Starting from fresh CLI main per SDK version removes the conflict drift and prevents old SDK pins from being carried forward.

Verification

• Parsed the workflow YAML with Ruby YAML.load_file
• Ran bash -n over each embedded run script after scrubbing GitHub expressions
• Ran git diff --check -- .github/workflows/update-cli-coverage.yml
• Verified go list -m -f '{{.Version}}' github.com/kernel/kernel-go-sdk returns a single SDK version in kernel/cli

---

Note

Low Risk
CI workflow and agent instructions only; no runtime product code, though push semantics changed for automation branches.

Overview
The Update CLI coverage workflow no longer reuses the long-lived cli-coverage-update branch. It derives a per-SDK branch (e.g. cli-coverage-v0.62.0), clones kernel/cli shallow from main, creates that branch fresh, and optionally fetches an existing remote branch of the same name—avoiding merge-conflicted go.mod and invalid multiline workflow outputs.

SDK version steps run earlier and emit the branch name; shell steps use set -euo pipefail and quoted $GITHUB_OUTPUT. The CLI’s current SDK pin is read with go list -m instead of grepping go.mod. The Cursor agent prompt now targets the versioned branch, forbids the old evergreen branch, and uses force-with-lease when pushing to an existing remote branch; PR creation/listing uses the per-SDK head branch instead of cli-coverage-update.

^{Reviewed by Cursor Bugbot for commit 5fa3793. Bugbot is set up for automated code reviews on this repo. Configure here.}

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit a85a94f. Configure here.}

[firetiger-agent]

Created a monitoring plan for this PR.

What this PR does: Refactors the automated CLI coverage workflow to create a fresh, per-SDK-version branch in kernel/cli on each SDK release, rather than accumulating changes on a single shared cli-coverage-update branch.

Intended effect:

• Workflow run status: baseline N/A (CI only); confirmed if the next push to kernel/kernel-go-sdk main produces a green Update CLI Coverage run and a new cli-coverage-<version> branch+PR in kernel/cli
• Branch naming: baseline was single cli-coverage-update branch; confirmed if new PRs in kernel/cli use the cli-coverage-<sdk-version> pattern

Risks:

• Step ordering failure — if the sdk-version step fails, all downstream steps (clone CLI, generate, commit) fail silently with missing-variable errors; alert if any run step shows branch output is empty in workflow logs
• go list -m version extraction — replacing grep+awk with go list -m for old SDK version lookup; alert if old_version is empty or incorrect in the Compute SDK diff step logs
• Branch name edge case — unusual SDK tag formats (e.g., with +build metadata) could produce a malformed or empty branch name; alert if git switch -c step fails with an invalid-ref error
• Force-with-lease conflict on concurrent merges — two near-simultaneous SDK merges could produce the same SHA-based branch name; alert if git push --force-with-lease step fails with a ref conflict

Status updates will be posted automatically on this PR as monitoring progresses.

View monitor