Architectural and code duplication improvements #38
Description
The classified codebase contains several architectural and code‑quality issues that could hinder maintainability and future development. Key problems include very large modules, duplicated logic and technical debt in the form of TODO placeholders. The most obvious problems are described below.
- Monolithic front‑end components
• GameInterface.tsx is ~3 100 lines long and combines many unrelated responsibilities (capability toggles, media capture, to‑do list management, progression logic, chat handling, knowledge retrieval, etc.). For example, it defines a UltraSimpleButtons component with an inline capabilityMap and toggling logic , then later in the same file implements multiple media capture functions (startCameraCapture, startScreenCapture, startMicrophoneCapture) and a stopMediaStream function . Each of these functions performs similar logic—requesting media streams, handling errors and updating state—but they live in the same huge file rather than in reusable hooks or utilities. This “god component” design violates the single‑responsibility principle and makes the UI difficult to test or reason about.
• The TauriService.ts module is ~1 200 lines and aggregates responsibilities ranging from chat messaging to knowledge management, file imports/exports, model downloads and container control. It holds multiple listeners, caches, and interacts directly with localStorage and sessionStorage . This centralised service becomes a single point of failure and is hard to extend or mock for testing.
Recommendation: Split GameInterface.tsx into smaller components (e.g., a MediaCapture hook, a CapabilityToggle component, separate to‑do and knowledge panels) and extract the repeated media‑capture logic into reusable hooks. Divide TauriService.ts into domain‑specific services (chat, goals/todo, file management, model management) to enforce separation of concerns.
- Large back‑end modules and duplicated error‑handling
• lib.rs in the Tauri backend is ~1 400 lines and mixes many unrelated Tauri commands—message routing, container restart logic, model provider queries and even a comprehensive startup test. Functions like send_message_to_agent and route_message_to_agent both implement similar logic to handle failed requests: they detect connection errors, restart the agent container and retry the operation  . Duplicating this recovery code in multiple functions makes maintenance error‑prone.
• The container/manager.rs file is ~3 200 lines and implements container runtime abstraction, dynamic port detection, health monitoring, log streaming and model download progress. Even basic port‑selection logic is repeated separately for PostgreSQL, Ollama and the agent port  instead of being handled by a helper function. Similar duplication likely exists between Docker and Podman implementations for container commands (pulling images, running containers, etc.). This file effectively acts as a monolithic “god manager”.
Recommendation: Extract common error‑handling (e.g., restart‑and‑retry logic) into helper functions. Break lib.rs into smaller modules grouping related commands. Refactor the container manager to separate concerns (e.g., one module for port detection, one for health monitoring, one for model management) and employ traits to share logic between Podman and Docker clients.
- Technical debt and placeholders
• The codebase contains numerous TODO comments and placeholder implementations. For example, the security utilities for encryption/decryption simply use Base64 encoding with a TODO to implement proper cryptography ; the update_agent_configuration command returns a dummy success message because the real endpoint does not exist ; and get_available_providers returns hard‑coded mock provider data . Such temporary implementations may leak into production if not addressed.
• Hard‑coded values, such as the room ID "ce5f41b4-fe24-4c01-9971-aecfed20a6bd" and agent ID "2fbc0c27-50f4-09f2-9fe4-9dd27d76d46f" in lib.rs , reduce flexibility and should be moved to configuration.
• The run_startup_hello_world_test function in lib.rs executes a sequence of health checks and message tests with emoji‑prefaced status messages . While useful for debugging, embedding such a verbose test in production code contributes to cruft.
Recommendation: Track TODOs in the issue tracker and replace placeholder logic with real implementations. Move hard‑coded identifiers to configuration files or environment variables. Limit debugging or test code to dedicated test modules or feature flags.
- Other architectural concerns
• Port‑checking duplication: In PortConfig::find_available_ports, the logic to detect and select alternative ports for PostgreSQL, Ollama and the agent is written three times with similar loops . A helper function (e.g., find_free_port(default_port, fallback_ports)) would reduce duplication.
• Media capture duplication: The media‑stream functions in GameInterface.tsx each request a stream and handle errors in the same way . A generic startMediaCapture(kind: 'camera' | 'screen' | 'microphone') could encapsulate the repeated code, returning appropriate constraints.
• Security utils are incomplete: SecurityUtils includes placeholders for encryption/decryption and uses simple DOM sanitization . Proper cryptographic handling should be added and cross‑site scripting protections reviewed.
By addressing these duplication and architectural issues—splitting up large modules, removing cruft, centralising common logic and completing TODO items—the maintainability and robustness of the project will improve significantly.