feat: archive filter strategy change and optimize reject-history filters

openspec/specs/reject-history-page/spec.md

@@ -4,7 +4,7 @@
 TBD - created by archiving change reject-history-query-page. Update Purpose after archive.
 ## Requirements
 ### Requirement: Reject History page SHALL provide filterable historical query controls
-The page SHALL provide a filter area for date range and major production dimensions to drive all report sections.
+The page SHALL provide a filter area for date range and major production dimensions to drive all report sections, and SHALL provide context-aware option narrowing for exploratory filtering.
 
 #### Scenario: Default filter values
 - **WHEN** the page is first loaded
@@ -23,6 +23,21 @@ The page SHALL provide a filter area for date range and major production dimensi
 - **THEN** it SHALL include reason filter control
 - **THEN** it SHALL include `WORKCENTER_GROUP` filter control
 
+#### Scenario: Draft filter options are interdependent
+- **WHEN** user changes draft values for `WORKCENTER_GROUP`, `package`, `reason`, or policy toggles
+- **THEN** option candidates for reason/workcenter-group/package SHALL reload under the current draft context
+- **THEN** unavailable combinations SHALL NOT remain in selectable options
+
+#### Scenario: Policy toggles affect option scope
+- **WHEN** user changes policy toggles (including excluded-scrap and material-scrap switches)
+- **THEN** options and query results SHALL use the same policy mode
+- **THEN** option narrowing SHALL remain consistent with backend exclusion semantics
+
+#### Scenario: Invalid selected values are pruned
+- **WHEN** narrowed options no longer contain previously selected values
+- **THEN** invalid selections SHALL be removed automatically before query commit
+- **THEN** apply/query SHALL only send valid selected values
+
 ### Requirement: Reject History page SHALL expose yield-exclusion toggle control
 The page SHALL let users decide whether to include policy-marked scrap in yield calculations.
 
@@ -139,4 +154,3 @@ The page SHALL keep the same semantic grouping across desktop and mobile layouts
 - **WHEN** viewport width is below responsive breakpoint
 - **THEN** cards and chart panels SHALL stack in a single column
 - **THEN** filter controls SHALL remain operable without horizontal overflow
-

openspec/specs/report-filter-strategy/spec.md

@@ -0,0 +1,58 @@
+# report-filter-strategy Specification
+
+## Purpose
+Define cross-report filter strategy governance, including exploratory-page interdependent filtering baselines.
+
+## Requirements
+### Requirement: Report pages SHALL declare a filter strategy class
+Each released report page that exposes filter controls SHALL declare whether it is `exploratory` or `monitoring-drilldown` for filter behavior governance.
+
+#### Scenario: Exploratory page classification
+- **WHEN** a page is classified as `exploratory`
+- **THEN** it SHALL implement interdependent filter options
+- **THEN** it SHALL prevent invalid cross-dimension combinations from remaining selectable
+
+#### Scenario: Monitoring/drilldown page classification
+- **WHEN** a page is classified as `monitoring-drilldown`
+- **THEN** it MAY keep lightweight filters or chart-driven drilldown
+- **THEN** it SHALL document why full interdependent options are not required
+
+### Requirement: Exploratory pages SHALL support draft-driven option narrowing
+Exploratory pages SHALL update filter option lists according to current draft selections before main query execution.
+
+#### Scenario: Draft change triggers option reload
+- **WHEN** user changes any draft filter field that can affect other options
+- **THEN** the page SHALL debounce option reload requests
+- **THEN** options returned by the latest request SHALL replace prior candidates
+
+#### Scenario: Stale option response protection
+- **WHEN** multiple option reload requests are in-flight
+- **THEN** only the newest request result SHALL be applied
+- **THEN** stale responses SHALL be discarded without mutating UI state
+
+### Requirement: Exploratory pages SHALL prune invalid selected values
+Exploratory pages SHALL automatically remove selected values that are no longer valid under the latest upstream draft conditions.
+
+#### Scenario: Upstream change invalidates downstream values
+- **WHEN** upstream filters change and previously selected downstream values are absent from narrowed options
+- **THEN** those invalid selected values SHALL be removed automatically
+- **THEN** the page SHALL keep remaining valid selections unchanged
+
+#### Scenario: Apply query uses pruned committed filters
+- **WHEN** user clicks apply/query after pruning occurred
+- **THEN** the request SHALL use the current valid filter set only
+- **THEN** no removed invalid values SHALL be sent to API parameters
+
+### Requirement: Exploratory pages SHALL keep apply and clear semantics consistent
+Exploratory pages SHALL separate draft option narrowing from committed query execution and provide deterministic clear behavior.
+
+#### Scenario: Apply commits current filter state
+- **WHEN** user clicks apply/query
+- **THEN** all data sections SHALL reload using the same committed filter set
+- **THEN** URL state SHALL synchronize with committed filters only
+
+#### Scenario: Clear resets to defaults
+- **WHEN** user clicks clear
+- **THEN** filters SHALL reset to documented defaults
+- **THEN** option candidates SHALL reload for the default state
+- **THEN** data sections SHALL reload from the default state

openspec/specs/resource-history-page/spec.md

@@ -84,8 +84,8 @@ The page SHALL allow users to specify time range and aggregation granularity.
 - **THEN** summary and detail APIs SHALL be called in parallel
 - **THEN** all 4 charts, KPI cards, and detail table SHALL update with results
 
-### Requirement: Resource History page SHALL support multi-select filtering
-The page SHALL provide multi-select dropdown filters for workcenter groups and families.
+### Requirement: Resource History page SHALL support multi-select filtering
+The page SHALL provide multi-select dropdown filters for workcenter groups and families, and SHALL support interdependent narrowing with machine options and selected-value pruning.
 
 #### Scenario: Multi-select dropdown
 - **WHEN** user clicks a multi-select dropdown trigger
@@ -93,13 +93,25 @@ The page SHALL provide multi-select dropdown filters for workcenter groups and f
 - **THEN** "Select All" and "Clear All" buttons SHALL be available
 - **THEN** clicking outside the dropdown SHALL close it
 
-#### Scenario: Filter options loading
-- **WHEN** the page loads
-- **THEN** workcenter groups and families SHALL load from `GET /api/resource/history/options`
-
-#### Scenario: Equipment type checkboxes
-- **WHEN** user toggles a checkbox (生產設備, 重點設備, 監控設備)
-- **THEN** the next query SHALL include the corresponding filter parameter
+#### Scenario: Filter options loading
+- **WHEN** the page loads
+- **THEN** workcenter groups and families SHALL load from `GET /api/resource/history/options`
+- **THEN** machine candidates SHALL be derivable before first query from loaded option resources
+
+#### Scenario: Upstream filters narrow downstream options
+- **WHEN** user changes upstream filters (`workcenterGroups`, `families`, equipment-type flags)
+- **THEN** machine options SHALL be recomputed to only include matching resources
+- **THEN** narrowed options SHALL be reflected immediately in filter controls
+
+#### Scenario: Invalid selected machines are pruned
+- **WHEN** upstream filters change and selected machines are no longer valid
+- **THEN** invalid selected machine values SHALL be removed automatically
+- **THEN** remaining valid selected machine values SHALL be preserved
+
+#### Scenario: Equipment type checkboxes
+- **WHEN** user toggles a checkbox (生產設備, 重點設備, 監控設備)
+- **THEN** the next query SHALL include the corresponding filter parameter
+- **THEN** option narrowing SHALL also honor the same checkbox conditions
 
 ### Requirement: Resource History page SHALL support CSV export
 The page SHALL allow users to export the current query results as CSV.