refactor(eval): park experimental eval-harness behind opt-in feature - #2
Conversation
…ature Default build no longer compiles the ~2000-LOC eval layer; enable with --features eval.
There was a problem hiding this comment.
Code Review
This pull request introduces an experimental, opt-in eval Cargo feature to gate the eval-harness functionality (including the eval module, associated CLI commands, and helper functions) in the harness-cli crate. The documentation in README.md and EVAL_HARNESS_README.md has been updated to reflect that these commands are no longer included in the default binary and must be built with --features eval. I have no feedback to provide.
Important
The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.
What
The eval-harness (~2000 LOC) is unused (0 rows in DB) yet advertised as a headline feature. This gates it behind an opt-in cargo feature so the default build excludes it, removing maintenance/confusion debt while keeping the code.
crates/harness-cli/Cargo.toml: added[features] eval = [](not in default).#[cfg(feature = "eval")]on:mod eval,Command::Eval, its dispatch arm, all 16Eval*arg structs +EvalAction, the 14run_*fns, 3 eval-only helpers, and eval-only imports.--features evalopt-in.Verify (all exit 0,
-D warnings)cargo build/clippy --release— eval subcommand ABSENT.cargo build/clippy --release --features eval— eval subcommand PRESENT.Commit