terminal_jarvis/api/mod.rs
1//! Terminal Jarvis Remote API Framework
2//!
3//! **STATUS: FUTURE-USE MODULE** - Represents "positive technical debt"
4//!
5//! This module implements a comprehensive API framework designed for future remote service
6//! integration. Currently marked with #[allow(dead_code)] as it represents a forward
7//! investment in the Terminal Jarvis architecture.
8//!
9//! # PLANNED IMPLEMENTATION ROADMAP
10//!
11//! ## Phase 1 (v1.0.0): Local API Server
12//! - REST API for local Terminal Jarvis management
13//! - Tool status monitoring and control endpoints
14//! - Configuration management via HTTP
15//! - Authentication state tracking and management
16//! - WebSocket support for real-time updates
17//!
18//! ## Phase 2 (v1.1.0): Remote Service Integration
19//! - Connection to Terminal Jarvis cloud services
20//! - Centralized tool management across devices
21//! - Shared configuration synchronization
22//! - Remote tool execution capabilities
23//! - Cross-device session management
24//!
25//! ## Phase 3 (v1.2.0): Advanced Platform Features
26//! - Multi-user environments and permissions
27//! - Enterprise deployment support
28//! - Custom plugin marketplace integration
29//! - Advanced analytics and monitoring dashboard
30//! - Workflow automation and scripting API
31//!
32//! # CURRENT IMPLEMENTATION
33//!
34//! The framework provides three core components:
35//!
36//! - **[`ApiBase`](api_base::ApiBase)**: Base configuration with timeout and retry logic
37//! - **[`ApiClient`](api_client::ApiClient)**: HTTP client abstraction with error handling
38//! - **[`ToolApi`](api_tool_operations::ToolApi)**: Tool-specific operations framework
39//!
40//! # ARCHITECTURE JUSTIFICATION
41//!
42//! This forward-looking design ensures Terminal Jarvis can evolve into a comprehensive
43//! platform without breaking changes. The modular structure allows incremental
44//! implementation while maintaining backward compatibility.
45//!
46//! The API framework follows these principles:
47//! - **Extensibility**: Easy to add new endpoints and operations
48//! - **Reliability**: Built-in retry logic and error handling
49//! - **Performance**: Async-first design with connection pooling
50//! - **Security**: Authentication and authorization ready
51//!
52//! # DEPENDENCIES
53//!
54//! - `reqwest`: HTTP client with async support
55//! - `serde_json`: JSON serialization for API payloads
56//! - `anyhow`: Unified error handling
57//!
58//! # MAINTENANCE NOTES
59//!
60//! - Keep #[allow(dead_code)] annotations until Phase 1 implementation begins
61//! - Update this documentation as implementation progresses
62//! - Preserve API contracts to ensure future compatibility
63//! - Consider API versioning strategy before Phase 1 implementation
64
65#![allow(unused_imports)]
66#![allow(dead_code)]
67
68pub mod api_base;
69pub mod api_client;
70pub mod api_tool_operations;
71
72// Re-export main types for backward compatibility
73pub use api_base::{routes, ApiBase};
74pub use api_client::ApiClient;
75pub use api_tool_operations::{ToolApi, ToolMetadata};