Overview
crates/tools/src/main.rs declares a large number of mod …; lines for modules that are never wired into the CLI surface, never imported into another module that *is* wired, and never exposed through anything other than their own unit tests. This makes the API surface look bigger than it is, encourages new contributors to add features in the wrong place (those modules "look" canonical), and creates silent dependencies between orphaned modules and their internalized helpers. Tracking the exact dead modules and either wiring or deleting them consolidates the CLI and removes an easy category of bugs.
Evidence
The full mod …; list in main.rs:
mod environment_config;
mod secure_vault;
mod asset_issuing;
mod key_manager;
mod encrypted_vault;
mod keypair_manager;
mod signing_request;
mod response_handler;
mod worker_logger;
mod polling_scheduler;
mod campaign_totals;
mod withdrawal_audit;
mod withdrawal_limits;
And many of these modules are referenced by code IN main.rs only through "I haven't wired the public type into the dispatch":
use campaign_totals::… // nowhere
use withdrawal_audit::… // nowhere — even though `handle_account` could plausibly log
use worker_logger::… // nowhere
use polling_scheduler::…// nowhere
streaming_processor, failed_match_handler, certificate_pdf, blockchain_verification, and payment_fetcher are not even declared as sub-modules — they're independent files that may or may not be linked under default cargo features (grep against main.rs returns zero imports). This is the inverse problem: things exist that don't provide surface.
Impact
- New contributors see
cargo doc --open advertising dozens of public types and assume they are part of the CLI surface.
cargo test --package orbitchain-tools runs the dead modules' tests, which makes the test surface look bigger than it is and obscures real regressions.cargo clippy --workspace flags dead_code over time, polluting contributor signal.- Bug fixes and
public API surface of those modules is implicitly published; removing them later is an API break.
Recommended Approach
Two-track:
- Wire OR delete. Decide which of
streaming_processor, campaign_totals, withdrawal_audit, withdrawal_limits, worker_logger, polling_scheduler, failed_match_handler, certificate_pdf, blockchain_verification, payment_fetcher are intended public surface of the CLI and either land a small dispatch wiring (handle_history, handle_worker, etc.) or move them to a dev-tools feature flag or to a separate crate. Lower priority is to delete cleanly.
- Mark
#[allow(dead_code)] only with justification. If a module is kept for future work but not yet wired, document the intent in a // TODO: comment with a tracked issue so the git grep TODO and cargo clippy --fix flows remain useful.
Acceptance Criteria
Affected Files
crates/tools/src/main.rs- Various modules under
crates/tools/src/ (see body)
crates/tools/Cargo.toml (if feature flags are introduced)README.md (CLI features section reconciliation)
Overview
crates/tools/src/main.rsdeclares a large number ofmod …;lines for modules that are never wired into the CLI surface, never imported into another module that *is* wired, and never exposed through anything other than their own unit tests. This makes the API surface look bigger than it is, encourages new contributors to add features in the wrong place (those modules "look" canonical), and creates silent dependencies between orphaned modules and their internalized helpers. Tracking the exact dead modules and either wiring or deleting them consolidates the CLI and removes an easy category of bugs.Evidence
The full
mod …;list in main.rs:And many of these modules are referenced by code IN main.rs only through "I haven't wired the public type into the dispatch":
streaming_processor,failed_match_handler,certificate_pdf,blockchain_verification, andpayment_fetcherare not even declared as sub-modules — they're independent files that may or may not be linked under default cargo features (grepagainstmain.rsreturns zero imports). This is the inverse problem: things exist that don't provide surface.Impact
cargo doc --openadvertising dozens of public types and assume they are part of the CLI surface.cargo test --package orbitchain-toolsruns the dead modules' tests, which makes the test surface look bigger than it is and obscures real regressions.cargo clippy --workspaceflags dead_code over time, polluting contributor signal.publicAPI surface of those modules is implicitly published; removing them later is an API break.Recommended Approach
Two-track:
streaming_processor,campaign_totals,withdrawal_audit,withdrawal_limits,worker_logger,polling_scheduler,failed_match_handler,certificate_pdf,blockchain_verification,payment_fetcherare intended public surface of the CLI and either land a small dispatch wiring (handle_history,handle_worker, etc.) or move them to adev-toolsfeature flag or to a separate crate. Lower priority is to delete cleanly.#[allow(dead_code)]only with justification. If a module is kept for future work but not yet wired, document the intent in a// TODO:comment with a tracked issue so thegit grep TODOandcargo clippy --fixflows remain useful.Acceptance Criteria
main.rsOR the module is annotated#[doc(hidden)]main.rsactually dispatchescargo clippy --workspace --all-targets -- -D warningsdoes not produce leftover dead_code noise from these modules (and if it does, the noise goes into one of the open tracked issues)Affected Files
crates/tools/src/main.rscrates/tools/src/(see body)crates/tools/Cargo.toml(if feature flags are introduced)README.md(CLI features section reconciliation)