feat: implement 8 OpenSpec proposals for security, reliability, and UX improvements

## Security Enhancements (P0)
- Add input validation with max_length and numeric range constraints
- Implement WebSocket token authentication via first message
- Add path traversal prevention in file storage service

## Permission Enhancements (P0)
- Add project member management for cross-department access
- Implement is_department_manager flag for workload visibility

## Cycle Detection (P0)
- Add DFS-based cycle detection for task dependencies
- Add formula field circular reference detection
- Display user-friendly cycle path visualization

## Concurrency & Reliability (P1)
- Implement optimistic locking with version field (409 Conflict on mismatch)
- Add trigger retry mechanism with exponential backoff (1s, 2s, 4s)
- Implement cascade restore for soft-deleted tasks

## Rate Limiting (P1)
- Add tiered rate limits: standard (60/min), sensitive (20/min), heavy (5/min)
- Apply rate limits to tasks, reports, attachments, and comments

## Frontend Improvements (P1)
- Add responsive sidebar with hamburger menu for mobile
- Improve touch-friendly UI with proper tap target sizes
- Complete i18n translations for all components

## Backend Reliability (P2)
- Configure database connection pool (size=10, overflow=20)
- Add Redis fallback mechanism with message queue
- Add blocker check before task deletion

## API Enhancements (P3)
- Add standardized response wrapper utility
- Add /health/ready and /health/live endpoints
- Implement project templates with status/field copying

## Tests Added
- test_input_validation.py - Schema and path traversal tests
- test_concurrency_reliability.py - Optimistic locking and retry tests
- test_backend_reliability.py - Connection pool and Redis tests
- test_api_enhancements.py - Health check and template tests

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

openspec/changes/archive/2026-01-10-add-backend-reliability/specs/document-management/spec.md

@@ -0,0 +1,46 @@
+## ADDED Requirements
+
+### Requirement: Storage Path Validation
+The system SHALL validate file storage configuration on startup to ensure reliability.
+
+#### Scenario: Valid NAS storage path
+- **WHEN** application starts with valid UPLOAD_DIR configuration
+- **THEN** system verifies path exists and is writable
+- **THEN** system logs confirmation of storage configuration
+
+#### Scenario: Invalid storage path
+- **WHEN** application starts with invalid or inaccessible UPLOAD_DIR
+- **THEN** system logs error with specific issue (not found, not writable)
+- **THEN** system falls back to local storage with warning
+
+#### Scenario: Storage health check
+- **WHEN** health check endpoint is called
+- **THEN** response includes storage availability status
+- **THEN** response includes available disk space if accessible
+
+### Requirement: Notification Delivery Reliability
+The system SHALL ensure notification delivery even during temporary Redis failures.
+
+#### Scenario: Redis temporarily unavailable
+- **WHEN** Redis publish fails due to connection error
+- **THEN** system queues message in local memory
+- **WHEN** Redis connection recovers
+- **THEN** system retries queued messages
+
+#### Scenario: Queue overflow prevention
+- **WHEN** local message queue exceeds maximum size
+- **THEN** oldest messages are dropped
+- **THEN** system logs warning about dropped messages
+
+### Requirement: Task Deletion Safety
+The system SHALL warn users when deleting tasks with unresolved blockers.
+
+#### Scenario: Delete task with active blockers
+- **WHEN** user attempts to delete task with unresolved blockers
+- **THEN** system returns warning with blocker count
+- **THEN** user must confirm or use force_delete flag
+
+#### Scenario: Force delete with blockers
+- **WHEN** user force deletes task with blockers
+- **THEN** system auto-resolves all blockers with "task deleted" reason
+- **THEN** system proceeds with task deletion