egg/PROJECT-CONTORL
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
679b89ae4c9f56e6233b75c14de430a276c8310c
PROJECT-CONTORL/openspec/specs/dashboard/spec.md
beabigegg 679b89ae4c feat: implement security, error resilience, and query optimization proposals 
Security Validation (enhance-security-validation):
- JWT secret validation with entropy checking and pattern detection
- CSRF protection middleware with token generation/validation
- Frontend CSRF token auto-injection for DELETE/PUT/PATCH requests
- MIME type validation with magic bytes detection for file uploads

Error Resilience (add-error-resilience):
- React ErrorBoundary component with fallback UI and retry functionality
- ErrorBoundaryWithI18n wrapper for internationalization support
- Page-level and section-level error boundaries in App.tsx

Query Performance (optimize-query-performance):
- Query monitoring utility with threshold warnings
- N+1 query fixes using joinedload/selectinload
- Optimized project members, tasks, and subtasks endpoints

Bug Fixes:
- WebSocket session management (P0): Return primitives instead of ORM objects
- LIKE query injection (P1): Escape special characters in search queries

Tests: 543 backend tests, 56 frontend tests passing

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2026-01-11 18:41:19 +08:00

6.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: 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