Summary

cargo wdk should support passing --locked through to the underlying cargo build / cargo check invocations it spawns.

Motivation

The --locked flag is critical for reproducible builds. It ensures that Cargo.lock is respected exactly as committed, preventing any dependency resolution changes at build time. This matters for:

• CI/CD reproducibility — builds must be deterministic; without --locked, a CI run can silently pick up a different dependency version than what was tested locally, leading to hard-to-diagnose regressions.
• Security & supply-chain integrity — --locked guarantees that only audited, committed dependency versions are used. Without it, a compromised or yanked crate version could be silently substituted.
• Compliance with Cargo best practices — the Rust ecosystem strongly recommends --locked for production and release builds. Driver development, where correctness is safety-critical, should be no exception.
• Parity with cargo make workflows — existing CI pipelines (e.g., codeql.yml) already pass --locked via cargo make. As cargo wdk replaces cargo make, it must support the same flags to avoid workflow regressions.

Expected Behavior

When a user runs:

cargo wdk build --locked

The --locked flag is forwarded to the underlying cargo build invocation, so that Cargo.lock is enforced and the build fails if the lockfile is out of date.

Current Behavior

cargo wdk does not recognize or forward --locked, so there is no way to enforce lockfile-pinned builds through the cargo wdk interface.

Proposed Solution

Forward --locked (and ideally the related --frozen and --offline flags) from cargo wdk to the inner cargo commands it invokes. This is a passthrough — cargo wdk does not need to interpret the flag itself, only ensure it reaches cargo build / cargo check.

Impact

High — Blocks adoption of cargo wdk in CI pipelines that require deterministic, lockfile-enforced builds. This is a prerequisite for fully deprecating cargo make in WDR workflows.