fix: force extension upgrade for pinned gh-aw installs

[Copilot]

Summary

Fixes the self-upgrade flow when gh-aw was installed as a pinned extension version.

Changes

• Call gh extension upgrade github/gh-aw --force during automatic extension upgrade
• Apply the same forced invocation for the retry path after rename workaround
• Add unit test coverage for the extension upgrade command args
• Update the extension upgrade test workflow comment to match runtime behavior

Validation

• go test -v -run "TestExtensionUpgradeArgs|TestNeedsRenameWorkaround|TestIsWindowsLockError" ./pkg/cli/
• make agent-finish (fails due to pre-existing repository-wide gosec findings in unrelated files)
• parallel_validation Code Review: success; CodeQL scan timed out per tool message

[github-actions]

✅ Smoke CI completed successfully!

[Copilot]

Pull request overview

Fixes gh-aw self-upgrade when the extension was installed with a pinned version by forcing gh extension upgrade to upgrade in-place.

Changes:

• Switch automatic extension upgrade and rename+retry path to call gh extension upgrade github/gh-aw --force via a shared helper.
• Add a unit test asserting the exact extension-upgrade CLI args used.
• Update the upgrade test workflow comment to reflect the --force behavior.

Show a summary per file

File	Description
pkg/cli/update_extension_check.go	Uses centralized extensionUpgradeArgs() (includes --force) for both initial and retry upgrade commands.
pkg/cli/update_extension_check_test.go	Adds a unit test to lock in the expected upgrade command arguments.
.github/workflows/upgrade-test.yml	Updates workflow documentation comment to match runtime invocation (--force).

Copilot's findings

Tip

Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

• Files reviewed: 3/3 changed files
• Comments generated: 1

[Copilot]

Since --force is required for pinned installs (as noted here), the Windows manual-upgrade guidance printed on lock errors (gh extension upgrade gh-aw) will still fail for pinned installs. Please update that user-facing command to include --force (and ideally keep the suggested command consistent with extensionUpgradeArgs).

[github-actions]

🤖 Smoke CI check — workflow run #24746370800 has been triggered for this pull request.

Generated by Smoke CI for issue #27679 · ● 155.6K · ◷

[github-actions]

🧪 Test Quality Sentinel Report

Test Quality Score: 70/100

⚠️ Acceptable — minor suggestion

Metric	Value
New/modified tests analyzed	1
✅ Design tests (behavioral contracts)	1 (100%)
⚠️ Implementation tests (low value)	0 (0%)
Tests with error/edge cases	0 (0%)
Duplicate test clusters	0
Test inflation detected	No
🚨 Coding-guideline violations	None

---

Test Classification Details

Test	File	Classification	Issues Detected
TestExtensionUpgradeArgs	pkg/cli/update_extension_check_test.go:227	✅ Design	No error cases (not applicable — pure value function)

---

Analysis Notes

TestExtensionUpgradeArgs verifies that extensionUpgradeArgs() returns the exact argument slice passed to gh extension upgrade, including the critical --force flag. This is a behavioral contract test — it directly enforces the invariant that pinned extension installs can be upgraded in-place. If this test were deleted, removing --force would be a silent regression.

Why edge-case score is 0: The function under test is a pure constant-returning function with no error paths; 0 edge-case tests is correct for this shape of code and is not a quality concern.

Build tag: ✅ //go:build !integration present on line 1
Assertion message: ✅ Descriptive message included — "upgrade command must force upgrades for pinned extensions"
Mock libraries: ✅ None

---

Language Support

Tests analyzed:

• 🐹 Go (*_test.go): 1 test — unit (//go:build !integration)
• 🟨 JavaScript (*.test.cjs, *.test.js): 0 tests

---

Verdict

✅ Check passed. 0% of new tests are implementation tests (threshold: 30%). The single new test TestExtensionUpgradeArgs enforces the behavioral contract that the --force flag is included in the upgrade command, which is the core correctness property of this fix.

📖 Understanding Test Classifications

Design Tests (High Value) verify what the system does:

• Assert on observable outputs, return values, or state changes
• Cover error paths and boundary conditions
• Would catch a behavioral regression if deleted
• Remain valid even after internal refactoring

Implementation Tests (Low Value) verify how the system does it:

• Assert on internal function calls (mocking internals)
• Only test the happy path with typical inputs
• Break during legitimate refactoring even when behavior is correct
• Give false assurance: they pass even when the system is wrong

Goal: Shift toward tests that describe the system's behavioral contract — the promises it makes to its users and collaborators.

References: §24746373706

🧪 Test quality analysis by Test Quality Sentinel · ● 578.8K · ◷

[github-actions]

✅ Test Quality Sentinel: 70/100. Test quality is acceptable — 0% of new tests are implementation tests (threshold: 30%). The single new test enforces the behavioral contract that --force is included in the upgrade command args.