Files

beabigegg 3bdc6ff1c9 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>

2026-01-10 22:13:43 +08:00

5.8 KiB

Raw Blame History

dashboard Specification

Purpose

TBD - created by archiving change add-dashboard-widgets. Update Purpose after archive.

Requirements

Requirement: Dashboard Statistics

The system SHALL display aggregated statistics showing the user's task overview.

Scenario: User views task statistics

Given: User is authenticated
When: User navigates to Dashboard
Then: System displays:
- Total tasks assigned to user
- Tasks due this week
- Overdue tasks count
- Completion rate percentage

The system SHALL display the current user's workload summary for the current week.

Scenario: User views personal workload

Given: User is authenticated
When: User views Dashboard
Then: System displays:
- Allocated hours vs capacity hours
- Load percentage with visual indicator
- Load level status (normal/warning/overloaded)

Requirement: Project Health Summary

The system SHALL display an aggregated project health summary.

Scenario: User views project health overview

Given: User is authenticated
When: User views Dashboard
Then: System displays:
- Total projects count
- Healthy/At-Risk/Critical breakdown
- Average health score
- Projects with blockers count

Requirement: Quick Actions

The system SHALL provide quick navigation links to common actions.

Scenario: User accesses quick actions

Given: User is authenticated
When: User views Dashboard
Then: System displays navigation links to:
- Spaces page
- Workload page
- Project Health page
- (Admin only) Audit page

Requirement: Dashboard API Endpoint

The backend SHALL provide a single aggregated endpoint for dashboard data.

Scenario: Frontend fetches dashboard data

Given: User is authenticated
When: Frontend requests GET /api/dashboard
Then: Backend returns:
- User task statistics
- Current week workload summary
- Project health summary
And: Response is optimized with single database query where possible

Requirement: Responsive Layout

The system SHALL provide a responsive user interface that adapts to different screen sizes for optimal usability.

Scenario: Mobile sidebar behavior

WHEN user accesses application on mobile device (width < 768px)
THEN sidebar is hidden by default
THEN hamburger menu button is visible in header
WHEN user taps hamburger menu
THEN sidebar slides in from left with backdrop overlay

Scenario: Table responsive behavior

WHEN user views task list on small screen
THEN table displays with horizontal scroll or switches to card layout
THEN all essential information remains accessible

Scenario: Touch-friendly interactions

WHEN user interacts with application on touch device
THEN all interactive elements have minimum 44x44 pixel tap targets
THEN sufficient spacing prevents accidental taps

Requirement: Complete Internationalization

The system SHALL support complete internationalization with no hardcoded text strings.

Scenario: Language switching

WHEN user changes language preference
THEN all UI text updates to selected language
THEN no untranslated strings remain visible

Scenario: Date and time localization

WHEN dates and times are displayed
THEN format follows user's locale preference
THEN relative times (e.g., "2 hours ago") are properly translated

Scenario: New component text

WHEN new UI components are added
THEN all text strings use i18n translation keys
THEN translations exist for all supported locales

Requirement: Standardized API Response Format

The system SHALL return all API responses in a consistent standardized format.

Scenario: Successful API response

WHEN API request succeeds
THEN response includes success=true
THEN response includes data field with result
THEN response includes timestamp field

Scenario: Error API response

WHEN API request fails
THEN response includes success=false
THEN response includes error_code field
THEN response includes message field with description

Requirement: API Versioning

The system SHALL support API versioning to enable backwards compatibility during upgrades.

Scenario: Versioned API endpoint

WHEN client calls /api/v1/tasks
THEN system routes to current version implementation
THEN response works with v1 client expectations

Scenario: Legacy API route

WHEN client calls /api/tasks (unversioned)
THEN system routes to default version
THEN response includes deprecation warning header

Requirement: Comprehensive Health Check

The system SHALL provide detailed health check endpoints for monitoring.

Scenario: All systems healthy

WHEN health check is called and all dependencies are available
THEN response includes status=healthy
THEN response includes checks object with database=ok, redis=ok

Scenario: Partial system failure

WHEN health check is called and Redis is unavailable
THEN response includes status=degraded
THEN response includes checks object with database=ok, redis=error

Requirement: Project Templates

The system SHALL support project templates to standardize project creation.

Scenario: Create project from template

WHEN user creates project selecting a template
THEN system copies TaskStatus definitions from template
THEN system copies CustomField definitions from template
THEN project is created with predefined structure

Scenario: Save project as template

WHEN user saves existing project as template
THEN system creates template with project's TaskStatus definitions
THEN system creates template with project's CustomField definitions
THEN template is available for future project creation

5.8 KiB Raw Blame History