-
Notifications
You must be signed in to change notification settings - Fork 4
Description
Context
A prior OrbitDock session (od-ad2998ae-1d71-46cb-be7c-aee2daba045a, summary: Audit Clippy allows and policy) audited the current Rust #[allow(clippy::...)] usage across orbitdock-server.
That session found that we are relying on Clippy allows as an escape hatch in places where Clippy is actually pointing at real design problems.
The repo policy has already been tightened in AGENTS.md to say we should not add new #[allow(clippy::...)] directives without explicit approval.
Now we should start paying down the existing ones.
Findings
Current allow sites in orbitdock-server include these buckets:
clippy::too_many_arguments— dominant category by farclippy::large_enum_variantclippy::type_complexityclippy::needless_returnclippy::enum_variant_names
Representative hotspots from the audit:
orbitdock-server/crates/connector-claude/src/lib.rsorbitdock-server/crates/connector-core/src/transition.rsorbitdock-server/crates/cli/src/commands/session.rsorbitdock-server/crates/server/src/connectors/codex_rollout/runtime.rsorbitdock-server/crates/server/src/runtime/session_commands.rsorbitdock-server/crates/protocol/src/client.rsorbitdock-server/crates/protocol/src/server.rsorbitdock-server/crates/server/src/infrastructure/persistence/session_reads.rsorbitdock-server/crates/server/src/admin/hook_forward.rs
Task
Start the Clippy cleanup by removing existing #[allow(clippy::...)] directives where the underlying design fix is straightforward, and break out follow-up issues for any larger refactors.
Use Clippy's intent as the guide:
too_many_arguments→ introduce a params/config struct or other better API shapelarge_enum_variant→ box the large variant or reshape the enumtype_complexity→ add a named type alias or helper typeneedless_return→ simplify the code directlyenum_variant_names→ rename or reshape the enum if it is truly worth doing
Scope
This issue should focus on:
- auditing the current allow sites
- fixing the easy / high-confidence ones directly
- identifying which remaining allow sites deserve their own follow-up issues because they imply larger API or protocol refactors
Do not add new #[allow(clippy::...)] directives as part of this work.
Deliverable
Leave a short implementation note on the issue or in a linked doc/comment that includes:
- which allow sites were removed
- which allow sites remain
- which ones were split into follow-up issues and why
- the recommended next cleanup order
Acceptance Criteria
- Existing Clippy allow sites are audited from the current codebase, not guessed.
- Straightforward allow removals are fixed by improving the code instead of re-suppressing the lint.
- Larger refactors are broken into follow-up issues rather than ballooning this issue.
- The work follows the repo policy that Clippy warnings should drive better design, not be muted by default.
Notes
This issue comes directly from the context of session od-ad2998ae-1d71-46cb-be7c-aee2daba045a.
Metadata
Metadata
Assignees
Labels
Projects
Status