DashBoard/openspec/specs/full-vite-page-modularization/spec.md

Purpose

Define stable requirements for full-vite-page-modularization.

Requirements

Requirement: Major Pages SHALL be Managed by Vite Modules

The system SHALL provide Vite-managed module entries for all in-scope modernization routes under shell-first governance, including admin surfaces /admin/pages and /admin/performance as governed targets. Deferred routes (/tables, /excel-query, /query-tool, /mid-section-defect) are excluded from this phase's required module-governance completeness.

Scenario: In-scope module governance completeness

• WHEN modernization route coverage is validated for this phase
• THEN every in-scope route SHALL have deterministic module-governance metadata and ownership mapping

Scenario: Deferred route exclusion in this phase

• WHEN completeness validation executes for this phase
• THEN deferred routes SHALL be excluded from mandatory pass criteria

Requirement: Build Pipeline SHALL Produce Backend-Served Assets

Vite build output for in-scope modernization routes MUST be emitted into backend static paths and validated at release time. Missing required in-scope assets SHALL fail release gates instead of relying on runtime fallback behavior.

Scenario: Build artifact readiness for in-scope routes

• WHEN frontend build is executed for release
• THEN required in-scope route artifacts SHALL be present in configured backend static dist paths
• THEN missing required artifacts SHALL fail readiness checks

Scenario: Deferred route fallback posture unchanged in this phase

• WHEN deferred routes are evaluated in this phase
• THEN existing fallback posture SHALL not block this phase's completion

Requirement: Vite Page Modules SHALL Reuse Shared Chart and Query Building Blocks

Page entry modules MUST consume shared chart/query/drawer utilities for common behaviors.

Scenario: Common chart behavior across pages

• WHEN multiple report pages render equivalent chart interactions
• THEN the behavior MUST be provided by shared Vite modules rather than duplicated page-local implementations

Requirement: Modularization MUST Preserve Established Navigation and Drill-Down Semantics

Refactoring into Vite modules and SPA shell routing SHALL not alter existing route paths, query semantics, and drill-down entry points.

Scenario: User follows existing drill-down path

• WHEN the user navigates from summary page to detail views
• THEN the resulting flow and parameter semantics MUST match the established baseline behavior

Scenario: Direct detail route remains valid

• WHEN users open existing detail routes directly with query parameters (e.g., /wip-detail?workcenter=..., /hold-detail?reason=...)
• THEN route-level behavior MUST remain compatible with established baseline expectations

Requirement: Module Boundaries SHALL Support Frontend Compute Expansion

Vite module structure MUST keep compute logic decoupled from DOM wiring so additional backend-to-frontend computation shifts can be added safely.

Scenario: Adding a new frontend-computed metric

• WHEN a new metric is migrated from backend to frontend
• THEN the metric logic MUST be integrated through shared compute modules without rewriting page routing structure

Requirement: WIP Report Pages SHALL Be Served by Vite Modules

The system SHALL provide Vite entry bundles for WIP overview and WIP detail pages, with template-level asset resolution.

Scenario: WIP module asset available

• WHEN the built asset exists in backend static dist
• THEN the page MUST load behavior from the corresponding Vite module entry

Scenario: WIP module asset unavailable

• WHEN the built asset is not present
• THEN the page MUST retain equivalent behavior through explicit inline fallback logic

Requirement: Vite Modules MUST Preserve Legacy Handler Compatibility

Vite report modules SHALL expose required global handlers for existing inline entry points until event wiring is fully migrated.

Scenario: Inline-triggered handler compatibility

• WHEN a template control invokes existing global handler names
• THEN the migrated module MUST provide compatible callable handlers without runtime scope errors

Requirement: Hold Detail Page SHALL Be Served by a Vite Module

The system SHALL provide a dedicated Vite entry bundle for the hold-detail report page.

Scenario: Hold-detail module asset exists

• WHEN /hold-detail is rendered and hold-detail.js exists in static dist
• THEN the page MUST load behavior from the Vite module entry

Scenario: Hold-detail module asset missing

• WHEN /hold-detail is rendered and the module asset is unavailable
• THEN the page MUST remain operational through explicit inline fallback logic

Requirement: WIP Modules SHALL Reuse Shared Autocomplete and Filter Query Utilities

WIP overview and WIP detail Vite entry modules SHALL use shared frontend core utilities for autocomplete request construction and cross-filter behavior.

Scenario: Cross-filter autocomplete parity across WIP pages

• WHEN users type in workorder/lot/package/type filters on either WIP overview or WIP detail pages
• THEN both pages MUST generate equivalent autocomplete request parameters and return behaviorally consistent dropdown results

Scenario: Shared utility change propagates across both pages

• WHEN autocomplete mapping rules are updated in the shared core module
• THEN both WIP overview and WIP detail modules MUST consume the updated behavior without duplicated page-local logic edits