run should only be exposed when built in debug

[jamesadevine]

/plan Run is not a customer facing mode. It should only be used for debugging purposes. Like our other features --skip-integrity it should be gated behind cfg debug.

[github-actions]

✅ Issue Plan Maker completed successfully!

[github-actions]

Implementation Plan: Gate run behind #[cfg(debug_assertions)]

Objective

Prevent the run subcommand from appearing (or being callable) in release builds of ado-aw. It should behave exactly like --skip-integrity and --debug-pipeline — present only in debug builds, invisible in production binaries.

---

Scope

In scope:

• Gate Commands::Run { ... } variant in the Commands enum (src/main.rs)
• Gate mod run; module declaration (src/main.rs)
• Gate the Some(Commands::Run { .. }) => "run" arm in command_name match (src/main.rs)
• Gate the Commands::Run { ... } dispatch arm in the main match command block (src/main.rs)

Out of scope:

• Changes to src/run.rs itself (the module can stay as-is; the cfg gate on mod run; is sufficient to exclude it from release builds)
• Documentation changes (README already marks run as a local-dev command)
• Changing the behaviour of any other command

---

Work Breakdown

• 1. Gate the mod run; declaration

  // src/main.rs, line 14
  #[cfg(debug_assertions)]
  mod run;

• 2. Gate the Commands::Run { ... } variant

  // src/main.rs, line 132–154
  /// Run agent locally (local development mode).
  /// Only available in debug builds.
  #[cfg(debug_assertions)]
  Run {
      path: String,
      #[arg(long, env = "AZURE_DEVOPS_EXT_PAT")]
      pat: Option<String>,
      #[arg(long)]
      org: Option<String>,
      #[arg(long)]
      project: Option<String>,
      #[arg(long)]
      dry_run: bool,
      #[arg(long)]
      skip_mcpg: bool,
      #[arg(long)]
      output_dir: Option<PathBuf>,
  },

• 3. Gate the command_name match arm (src/main.rs, line 183)

  #[cfg(debug_assertions)]
  Some(Commands::Run { .. }) => "run",

• 4. Gate the dispatch arm (src/main.rs, lines 390–410)

  #[cfg(debug_assertions)]
  Commands::Run { path, pat, org, project, dry_run, skip_mcpg, output_dir } => {
      run::run(&run::RunArgs { ... }).await?;
  }

---

Validation Strategy

• Release build — command absent:

  cargo build --release
  ./target/release/ado-aw --help   # `run` must not appear
  ./target/release/ado-aw run      # must error "unrecognized subcommand"

• Debug build — command present:

  cargo build
  ./target/debug/ado-aw --help     # `run` must appear

• cargo test passes (no unused-import warnings from mod run in release profile; the run module uses items from the crate, so gating the mod declaration is the correct approach)
• cargo clippy clean in both profiles

---

Risks and Mitigations

Risk	Mitigation
mod run; gated but run.rs imports crate internals — dead code warnings in release	Confirmed: gating mod run; entirely suppresses compilation of the module in release. No warning expected.
command_name match becomes non-exhaustive in release build	The #[cfg(debug_assertions)] arm is simply absent; Rust sees the remaining arms as exhaustive. Confirmed pattern already used on skip_integrity/debug_pipeline.
Clippy dead_code on Run variant fields in debug builds	Not applicable — the variant and its dispatch arm are both gated together.

---

Dependencies and Assumptions

• Follows the exact same pattern already established for --skip-integrity and --debug-pipeline in src/main.rs (lines 37–45, 195–203).
• No changes needed to Cargo.toml or any profile configuration.
• src/run.rs itself is ~1200 lines and entirely self-contained; gating the mod declaration is sufficient.

Generated by Issue Plan Maker for issue #282 · ● 465.1K · ◷