feat: Major directory reorganization and cleanup

Reorganized project structure for better maintainability and reduced
disk usage by 95.9% (11 GB -> 451 MB).

Directory Reorganization (85% reduction in root files):
- Created docs/ with subdirectories (deployment, testing, database, etc.)
- Created infrastructure/vpn-configs/ for VPN scripts
- Moved 90+ files from root to organized locations
- Archived obsolete documentation (context system, offline mode, zombie debugging)
- Moved all test files to tests/ directory
- Root directory: 119 files -> 18 files

Disk Cleanup (10.55 GB recovered):
- Deleted Rust build artifacts: 9.6 GB (target/ directories)
- Deleted Python virtual environments: 161 MB (venv/ directories)
- Deleted Python cache: 50 KB (__pycache__/)

New Structure:
- docs/ - All documentation organized by category
- docs/archives/ - Obsolete but preserved documentation
- infrastructure/ - VPN configs and SSH setup
- tests/ - All test files consolidated
- logs/ - Ready for future logs

Benefits:
- Cleaner root directory (18 vs 119 files)
- Logical organization of documentation
- 95.9% disk space reduction
- Faster navigation and discovery
- Better portability (build artifacts excluded)

Build artifacts can be regenerated:
- Rust: cargo build --release (5-15 min per project)
- Python: pip install -r requirements.txt (2-3 min)

Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
This commit is contained in:
2026-01-18 20:42:28 -07:00
parent 89e5118306
commit 06f7617718
96 changed files with 54 additions and 2639 deletions

View File

@@ -0,0 +1,171 @@
# ClaudeTools API Testing Results - Phase 2
## Test Execution Summary
**Date:** 2026-01-16
**Test Script:** `test_api_endpoints.py`
**Total Tests:** 35
**Passed:** 19
**Failed:** 16
**Pass Rate:** 54.3%
## Test Categories
### Section 1: API Health and Startup Tests (3/3 Passed)
- [x] Root endpoint (/)
- [x] Health check endpoint (/health)
- [x] JWT token creation
### Section 2: Authentication Tests (3/3 Passed)
- [x] Unauthenticated access rejected
- [x] Authenticated access accepted
- [x] Invalid token rejected
### Section 3: Machine CRUD Operations (3/6 Passed)
- [x] Create machine
- [x] List machines
- [ ] Get machine by ID (404 error)
- [ ] Update machine (404 error)
- [x] Machine not found (404) - correctly returns 404 for non-existent ID
- [ ] Delete machine (404 error)
### Section 4: Client CRUD Operations (2/5 Passed)
- [x] Create client
- [x] List clients
- [ ] Get client by ID (404 error)
- [ ] Update client (404 error)
- [ ] Delete client (404 error)
### Section 5: Project CRUD Operations (2/5 Passed)
- [x] Create project
- [x] List projects
- [ ] Get project by ID (404 error)
- [ ] Update project (404 error)
- [ ] Delete project (404 error)
### Section 6: Session CRUD Operations (2/5 Passed)
- [x] Create session
- [x] List sessions
- [ ] Get session by ID (404 error)
- [ ] Update session (404 error)
- [ ] Delete session (404 error)
### Section 7: Tag CRUD Operations (2/6 Passed)
- [x] Create tag
- [x] List tags
- [ ] Get tag by ID (404 error)
- [ ] Update tag (404 error)
- [ ] Tag duplicate name (409) - test issue, not API issue
- [ ] Delete tag (404 error)
### Section 8: Pagination Tests (2/2 Passed)
- [x] Pagination skip/limit parameters
- [x] Pagination max limit enforcement
## Critical Issue Identified
### UUID Type Mismatch in Service Layer
**Problem:** All "Get by ID", "Update", and "Delete" operations are failing with 404 errors, even though entities are successfully created and appear in list operations.
**Root Cause:** The service layer functions receive `UUID` objects from FastAPI routers but compare them directly with `CHAR(36)` string columns in the database. SQLAlchemy's filter operation is not automatically converting UUID objects to strings for comparison.
**Evidence:**
```
Created machine with ID: 3f147bd6-985c-4a99-bc9e-24e226fac51d
Total machines in DB: 6
First machine ID: 3f147bd6-985c-4a99-bc9e-24e226fac51d (type: <class 'str'>)
Fetching machine with ID: 3f147bd6-985c-4a99-bc9e-24e226fac51d (type: <class 'str'>)
Response: {"detail":"Machine with ID 3f147bd6-985c-4a99-bc9e-24e226fac51d not found"}
```
The machine exists in the database (confirmed by list operation), but the get-by-ID query fails to find it.
**Solution:** Modify all service layer functions that query by ID to convert UUID objects to strings:
```python
# Current code (fails):
machine = db.query(Machine).filter(Machine.id == machine_id).first()
# Fixed code (works):
machine = db.query(Machine).filter(Machine.id == str(machine_id)).first()
```
**Affected Files:**
- `api/services/machine_service.py` - get_machine_by_id, update_machine, delete_machine
- `api/services/client_service.py` - get_client_by_id, update_client, delete_client
- `api/services/project_service.py` - get_project_by_id, update_project, delete_project
- `api/services/session_service.py` - get_session_by_id, update_session, delete_session
- `api/services/tag_service.py` - get_tag_by_id, update_tag, delete_tag
## Successes
1. **API Startup:** FastAPI application loads successfully with all 5 routers registered
2. **Health Endpoints:** Root and health check endpoints work correctly
3. **JWT Authentication:** Token creation and validation working properly
4. **Authentication Middleware:** Correctly rejects unauthenticated requests and accepts valid tokens
5. **CREATE Operations:** All POST endpoints successfully create entities
6. **LIST Operations:** All GET list endpoints work with pagination
7. **Pagination:** Skip/limit parameters and max limit enforcement working correctly
## Test Improvements Made
1. Fixed client schema to include required `type` field
2. Fixed session schema to include required `session_date` and `session_title` fields
3. Added debug output to track entity creation and ID types
4. Corrected authentication test to accept both 401 and 403 status codes
5. Removed emoji characters that caused encoding issues on Windows
## Recommendations
### Immediate Actions
1. Update all service layer functions to convert UUID parameters to strings before database queries
2. Add unit tests specifically for UUID/string conversion in queries
3. Consider adding a helper function like `uuid_to_str(uuid_obj)` for consistency
### Future Enhancements
1. Add integration tests that verify end-to-end CRUD operations
2. Add tests for foreign key relationships (client->project->session)
3. Add tests for unique constraint violations
4. Add performance tests for pagination with large datasets
5. Add tests for concurrent access and transaction isolation
### Alternative Solution
Consider using SQLAlchemy's native UUID type with a custom type decorator that automatically handles string conversion for MariaDB:
```python
from sqlalchemy import TypeDecorator
from sqlalchemy.types import CHAR
import uuid
class UUID(TypeDecorator):
impl = CHAR(36)
cache_ok = True
def process_bind_param(self, value, dialect):
if value is None:
return value
elif isinstance(value, uuid.UUID):
return str(value)
return str(uuid.UUID(value))
def process_result_value(self, value, dialect):
if value is None:
return value
return uuid.UUID(value)
```
This would make UUID handling automatic throughout the codebase.
## Conclusion
The API implementation is fundamentally sound with proper:
- Routing and endpoint structure
- Authentication and authorization
- Request validation
- Error handling
- Pagination support
The critical UUID/string conversion issue is a simple fix that will unlock all remaining test failures. Once resolved, the expected pass rate should increase to approximately 97% (34/35 tests).
The one remaining test failure (Tag duplicate name 409) appears to be a test implementation issue rather than an API issue and can be fixed separately.