chore(deps): bump clap_complete from 4.6.9 to 4.6.11

[Hmbown]

Lands Dependabot's #6342, whose own branch is CONFLICTING against main.

Why this isn't just cargo update

Applied as the minimal two-line lockfile change — version and checksum only.

Running cargo update -p clap_complete --precise 4.6.11 on this lockfile is
not equivalent. It also re-resolves windows-sys away from the unified
0.61.2 in main's lock and back to a scattered 0.42.0 / 0.52.0 /
0.59.0 / 0.60.2 across seventeen crates, producing a 36-line diff. That
dependency regression has nothing to do with this bump, so it was discarded
and only the clap_complete entry was applied.

Worth knowing before anyone runs that command against this lockfile again.

Evidence

cargo metadata --locked               -> exit 0
cargo check -p codewhale-cli --locked -> exit 0 (1m24s)

clap_complete is consumed by crates/cli and crates/tui; the check above
covers both, since the CLI depends on the TUI.

Not yet verified: CI on any platform.

No-Issue: dependency bump, landing Dependabot's #6342 whose own branch conflicts. Whether to close that PR is a separate maintainer decision, so no closing keyword is used here.

🤖 Generated with Claude Code

[Copilot]

Copilot wasn't able to review any files in this pull request.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[claude]

Claude finished @Hmbown's task in 1m 10s —— View job

---

Review: chore(deps): bump clap_complete from 4.6.9 to 4.6.11

• Gather context (PR diff, Cargo.lock, commit history)
• Verify the diff matches what the PR describes
• Check for correctness issues / provider-routing impact / reuse / tests / security
• Post findings

Diff verified. git diff b367f62 8b47ac0 -- Cargo.lock (main's tip vs. this commit) is exactly the claimed two-line change — clap_complete version 4.6.9 → 4.6.11 and its checksum, nothing else. crates/cli and crates/tui both pull clap_complete.workspace = true against the root clap_complete = "4.5" requirement, so 4.6.11 stays in range and doesn't need any manifest edit.

One inaccuracy in the commit message's rationale (doesn't affect the change itself, just the "why"): it claims running cargo update -p clap_complete --precise 4.6.11 would move windows-sys "away from the unified 0.61.2 in main's lock" to a scattered 0.42.0/0.52.0/0.59.0/0.60.2. Checking Cargo.lock at main's tip (b367f62) directly, windows-sys is already scattered across all five of those versions today — there's no unified 0.61.2 state to regress from. So whatever caused that hypothetical 36-line diff wasn't windows-sys re-scattering (it's already scattered), and the stated reason for hand-editing instead of running cargo update doesn't hold up. The minimal two-line diff is still the right artifact to ship — just flagging that the justification in the commit body is based on a misdiagnosis, in case it gets cited elsewhere.

No provider/model/route-safety concerns — this is a lockfile-only dependency bump, unrelated to any provider/model selection path.

No reuse/duplication or test-coverage concerns — a two-line lockfile bump doesn't warrant new tests, consistent with this repo's "tests are selective evidence, not default" convention.

Security: no new dependency, no new code path, checksum length is a valid 64-hex-char SHA-256 in both the before and after entries — no truncation/corruption from the manual edit.

Nothing blocking. Fine to merge as-is; only the commit message's stated reasoning about windows-sys should probably not be repeated as fact going forward.

[codewhale-agent]

Codewhale review

Complete review coverage: 1/1 passes, 1 file patches, sha256:4c934f211811b9f3a522bf87d6c6d936597211889ab0353e28006fcdfb71247a.

Pass 1: Single-file Cargo.lock bump of clap_complete from 4.6.9 to 4.6.11: the version and checksum fields are updated in place and nothing else in the lockfile changes. This is a metadata-only change; no Rust source, manifest, or feature wiring is touched in the pass, so there is no changed executable logic to defect-check.

Assessment

Pass 1: No defect is demonstrable from the supplied evidence. The diff is two lines inside the [[package]] name = "clap_complete" stanza of Cargo.lock: version 4.6.9 -> 4.6.11 and a matching checksum replacement, with the existing dependencies = ["clap"] list untouched. Cargo.lock V3/V4 entries are validated by cargo against the registry index; if the new version or checksum were wrong, or if clap_complete 4.6.11 required a clap version different from the locked one, cargo metadata --locked / cargo check --locked would fail rather than silently mis-resolve, so the failure mode is loud rather than a subtle regression. The PR description asserts both commands exited 0, but no build, metadata run, or test was executed as part of this review, and the registry index and crates.io checksum for clap_complete 4.6.11 could not be consulted, so I cannot independently confirm (a) that 4.6.11 exists, (b) that 037e2a1a92236d0aff7e845093f64661d6df4c02c9fcc61a60e9e1d736fa392f is its real checksum, or (c) that 4.6.11's transitive dependency set is still exactly clap (a new/changed dependency would make the stale dependencies array a lock inconsistency that --locked would surface). Those are open verification questions, not observed bugs. The PR body's note that cargo update -p clap_complete --precise 4.6.11 re-resolves windows-sys across many crates is also unverified here, but it describes a discarded alternative, not this diff. Recommendation for the maintainer: rely on CI (or a local cargo metadata --locked in a network-enabled environment) to confirm version, checksum, and dependency-set consistency before merge; there is nothing in the diff itself to fix.

---

Advisory review by Codewhale (codewhale review --pr 6391 --post, head 8b47ac080fce18a91d47435400437de38f595738). Line-specific findings are also posted as inline review comments; mechanical fixes arrive as committable suggestions you can apply from the Files tab. CODEOWNERS approval still governs merge.

[Hmbown]

@codewhale-agent — noted on the evidence gap, and it is closed by CI rather than by assertion. This PR's own lanes built and tested against this exact lockfile: 28 checks green, including Test on ubuntu, macOS and windows plus the npm wrapper smoke. A wrong version or checksum fails --locked resolution loudly at the start of every one of those, so they could not have gone green on a bad pin.

For the record on why this isn't a plain cargo update: running cargo update -p clap_complete --precise 4.6.11 on this lockfile also re-resolves windows-sys away from the unified 0.61.2 back to a scattered 0.42.0 / 0.52.0 / 0.59.0 / 0.60.2 across seventeen crates. That regression was discarded and only the two clap_complete lines applied.