Track future Rust lint hardening #5

Context

This issue now tracks Rust lint hardening for Agentics. It originally tracked dead_code_pub_in_binary, but the repo has since adopted several higher-impact lints that are available in the current toolchain.

Agentics runs API, CLI, worker, Docker runner, quota, storage, and challenge review code. Lints should therefore prioritize safety, explicit API boundaries, async correctness, and numeric/resource-limit correctness over broad style-only lint groups.

Implemented

The following lint hardening is now implemented and passes:

cargo clippy --workspace --all-targets -- -D warnings
cargo fmt --all --check

Commits:

• 46ae9a5 enforced the baseline hardening pass: unsafe_code, unreachable_pub, let_underscore_drop, clone_on_ref_ptr, dbg_macro, todo, unimplemented, panic_in_result_fn, and unused_async.
• 02dc3b3 enforced explicit-import and checked-cast lints: allow_attributes_without_reason, wildcard_imports, enum_glob_use, cast_possible_truncation, cast_possible_wrap, and cast_sign_loss.
• 8c6c4c9 enforced missing_debug_implementations and future_not_send.

Rationale for the latest additions:

• missing_debug_implementations: config, API state, worker state, DTO wrappers, and storage implementations should be debuggable for operational failures and integration debugging.
• future_not_send: async helpers, handlers, and worker paths should avoid accidentally capturing non-Send values across await points because Axum/Tokio code is expected to remain thread-safe.

Future Candidates

dead_code_pub_in_binary

Status: defer until the active Rust toolchain exposes it.

Rationale: this is useful for executable crates because accidental pub items in binaries often signal unclear module boundaries. It is less relevant for library crates, where pub is part of the external API surface.

Adoption plan once available:

[workspace.lints.rust]
dead_code_pub_in_binary = "warn"

Then audit binary crates first: backend/api-server, backend/worker, backend/integration-tests, and frontends/agentics-cli. Prefer making findings private or pub(crate) instead of adding allows.

References:

• PR: Lint unused pub items in binary crates rust-lang/rust#149509
• Tracking discussion: Consider pub items in binary crates dead code if not used in the crate (i.e., treating it like pub(crate)) rust-lang/rust#74970
• Lint declaration: https://github.com/rust-lang/rust/blob/0e5924a4a0b57f2c6bc8cac93f59281e68541a91/compiler/rustc_lint_defs/src/builtin.rs#L793-L822

manual_let_else

Status: optional style cleanup after core protocol code settles.

Rationale: Agentics has validation-heavy code where let ... else can make failure paths clearer. This is readability-oriented, so it should not block higher-priority security or protocol work.

missing_errors_doc and missing_panics_doc

Status: consider only for scoped public APIs, especially backend/shared.

Rationale: these are useful for public library contracts, but too noisy workspace-wide. They should be introduced after module boundaries and public API surfaces are stable enough that the docs are meaningful.

too_many_lines

Status: use as an advisory refactor signal, not a hard gate yet.

Rationale: large files such as the runner should be split by responsibility, but enabling this globally before the refactor would create noisy CI failures instead of useful pressure.

unused_crate_dependencies

Status: consider package-by-package later.

Rationale: the workspace has mixed lib/bin/test targets, so this lint can produce false positives if enabled globally. It may still be useful after each crate's target graph is reviewed.

Not Planned Globally

• print_stdout / print_stderr: the CLI intentionally prints user-facing output.
• Blanket pedantic, restriction, or nursery lint groups: too broad for this repo; continue cherry-picking lints with clear product and operations value.