egg/DashBoard
1
0
Fork 0
Code Issues Pull Requests Actions 2 Packages Projects Releases Wiki Activity
Files
9a4e08810b0a2252652af6b43180275fec739caa
DashBoard/openspec/changes/archive/2026-02-10-hold-history-dashboard/specs/vue-vite-page-architecture/spec.md
egg 9a4e08810b feat(hold-history): add Hold 歷史績效 Dashboard with trend, pareto, duration, and detail views 
New independent report page based on DWH.DW_MES_HOLDRELEASEHISTORY providing
historical hold/release performance analysis. Includes daily trend with Redis
caching, reason Pareto with click-to-filter, duration distribution with
click-to-filter, multi-select record type filter (new/on_hold/released),
workcenter-group mapping via memory cache, and server-side paginated detail
table. All 32 backend tests passing.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
2026-02-10 18:03:08 +08:00

2.7 KiB
Raw Blame History

MODIFIED Requirements

Requirement: Vite config SHALL support Vue SFC and HTML entry points

The Vite build configuration SHALL support Vue Single File Components alongside existing vanilla JS entries.

Scenario: Vue plugin coexistence

  • WHEN vite build is executed
  • THEN Vue SFC (.vue files) SHALL be compiled by @vitejs/plugin-vue
  • THEN existing vanilla JS entry points SHALL continue to build without modification

Scenario: HTML entry point

  • WHEN a page uses an HTML file as its Vite entry point
  • THEN Vite SHALL process the HTML and its referenced JS/CSS into static/dist/
  • THEN the output SHALL include <page-name>.html, <page-name>.js, and <page-name>.css

Scenario: Chunk splitting

  • WHEN Vite builds the project
  • THEN Vue runtime SHALL be split into a vendor-vue chunk
  • THEN ECharts modules (including TreemapChart, BarChart, LineChart) SHALL be split into the existing vendor-echarts chunk
  • THEN chunk splitting SHALL NOT affect existing page bundles

Scenario: Migrated page entry replacement

  • WHEN a vanilla JS page is migrated to Vue 3
  • THEN its Vite entry SHALL change from JS file to HTML file (e.g., src/wip-overview/main.js → src/wip-overview/index.html)
  • THEN the original JS entry SHALL be replaced, not kept alongside

Scenario: Hold Overview entry point

  • WHEN the hold-overview page is added
  • THEN vite.config.js input SHALL include 'hold-overview': resolve(__dirname, 'src/hold-overview/index.html')
  • THEN the build SHALL produce hold-overview.html, hold-overview.js, and hold-overview.css in static/dist/

Scenario: Hold History entry point

  • WHEN the hold-history page is added
  • THEN vite.config.js input SHALL include 'hold-history': resolve(__dirname, 'src/hold-history/index.html')
  • THEN the build SHALL produce hold-history.html, hold-history.js, and hold-history.css in static/dist/

Scenario: Shared CSS import across migrated pages

  • WHEN multiple migrated pages import a shared CSS module (e.g., wip-shared/styles.css)
  • THEN Vite SHALL bundle the shared CSS into each page's output CSS
  • THEN shared CSS SHALL NOT create a separate shared chunk that requires additional HTTP requests

Scenario: Shared composable import across module boundaries

  • WHEN a migrated page imports a composable from another shared module (e.g., hold-history imports useAutoRefresh from wip-shared/)
  • THEN the composable SHALL be bundled into the importing page's JS output
  • THEN cross-module imports SHALL NOT create unexpected shared chunks