Skip to content

code clean up / refactor #312

Description

@franciscojavierarceo

Summary

Several Rust files are large enough to make review and maintenance difficult, consistent with feedback from maintainers. Track a focused cleanup into cohesive modules with clear ownership and smaller review surfaces.

Proposed file-size policy

  • Prefer production files under 300 lines; 300–500 lines is reasonable for one clear responsibility.
  • Require a split or a documented exception above 500 production lines.
  • Prevent new oversized production files and growth of existing oversized files through a fast pre-commit/CI check with an explicit baseline.
  • Count inline tests separately and exclude generated code. Choose a separate test-file threshold before enforcing one.
  • Split by responsibility, not arbitrary line counts. Preserve public APIs, wire formats, behavior, and test coverage.

Production refactor checklist

Inventory at commit 6d038d12da167255861a71d22681930dd46f904b. Counts include comments and blank lines. Approximate production counts use the lines before the first top-level #[cfg(test)] mod tests section; these are triage measurements, not an AST-based enforcement implementation. Recount and confirm module boundaries when taking each item.

Entries are ordered by approximate production size; each should be refactored or given a documented cohesion-based exception.

Start with these boundaries

  • tool/tool_search.rs: separate request validation, loaded-definition/catalog state, and tool-call translation.
  • types/io/output.rs: group output-item types and conversions by item family, preserving the public exports and wire schema.
  • handler/websocket/responses.rs: review request parsing, admission/multiplexing, connection lifecycle, and outbound delivery boundaries.
  • executor/engine.rs: keep round orchestration, tool-loop control, and persistence ownership explicit; move responsibilities only to their architecture-defined owners.
  • auth.rs: review configuration, provider/JWKS fetching and caching, token verification, and HTTP middleware boundaries.

These are starting points for review, not predetermined module designs.

Large test and benchmark files — separate cleanup

The following files exceed 800 total lines and deserve a scenario-based organization review. This is a triage cutoff, not a proposed test-file enforcement limit. Preserve coverage and share fixtures only where that improves readability.

Completion criteria

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions