egg/PROJECT-CONTORL
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
a78d8788656d862613eab50f61d1597047d5c526
PROJECT-CONTORL/openspec/specs/dashboard/spec.md
beabigegg 35c90fe76b feat: implement 5 QA-driven security and quality proposals 
Implemented proposals from comprehensive QA review:

1. extend-csrf-protection
   - Add POST to CSRF protected methods in frontend
   - Global CSRF middleware for all state-changing operations
   - Update tests with CSRF token fixtures

2. tighten-cors-websocket-security
   - Replace wildcard CORS with explicit method/header lists
   - Disable query parameter auth in production (code 4002)
   - Add per-user WebSocket connection limit (max 5, code 4005)

3. shorten-jwt-expiry
   - Reduce JWT expiry from 7 days to 60 minutes
   - Add refresh token support with 7-day expiry
   - Implement token rotation on refresh
   - Frontend auto-refresh when token near expiry (<5 min)

4. fix-frontend-quality
   - Add React.lazy() code splitting for all pages
   - Fix useCallback dependency arrays (Dashboard, Comments)
   - Add localStorage data validation in AuthContext
   - Complete i18n for AttachmentUpload component

5. enhance-backend-validation
   - Add SecurityAuditMiddleware for access denied logging
   - Add ErrorSanitizerMiddleware for production error messages
   - Protect /health/detailed with admin authentication
   - Add input length validation (comment 5000, desc 10000)

All 521 backend tests passing. Frontend builds successfully.

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2026-01-12 23:19:05 +08:00

7.7 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

Requirement: My Workload Widget

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

Requirement: Code Splitting

The application SHALL use code splitting with React.lazy() to reduce initial bundle size and improve load times.

Scenario: Initial page load

  • WHEN user navigates to application
  • THEN only core framework and current route are loaded
  • AND other routes are loaded on demand

Scenario: Route-based splitting

  • WHEN user navigates to a different page
  • THEN that page's code chunk is loaded dynamically
  • AND loading fallback is displayed during load

Requirement: LocalStorage Data Validation

User data loaded from localStorage SHALL be validated before use to prevent crashes from corrupted data.

Scenario: Corrupted localStorage data

  • WHEN localStorage contains malformed user JSON
  • THEN invalid data is cleared
  • AND user is redirected to login page
  • AND no application crash occurs

Scenario: Valid localStorage data

  • WHEN localStorage contains valid user JSON
  • THEN user is authenticated from stored data
  • AND application loads normally

Requirement: Error Boundary Protection

The frontend application SHALL gracefully handle component render errors without crashing the entire application.

Scenario: Component error contained

  • WHEN a render error occurs in a dashboard widget
  • THEN only that widget SHALL display an error state
  • AND other widgets SHALL continue to function normally

Scenario: User-friendly error display

  • WHEN a component fails to render
  • THEN users SHALL see a friendly error message
  • AND users SHALL have an option to retry or report the issue

Scenario: Error logging

  • WHEN a render error is caught by an Error Boundary
  • THEN the error details SHALL be logged for debugging
  • AND error context (component stack) SHALL be captured

Scenario: Recovery option

  • WHEN a user sees an error fallback UI
  • AND the user clicks "Retry"
  • THEN the failed component SHALL attempt to re-render