Transform /mid-section-defect from TMTT-only backward analysis into a full-line bidirectional defect traceability center supporting all detection stations. Key changes: - Parameterized station detection: any workcenter group as detection station - Bidirectional tracing: backward (upstream attribution) + forward (downstream reject rates) - Dual query mode: date range OR LOT/工單/WAFER container-based seed resolution - Multi-select filters for upstream station, equipment model (RESOURCEFAMILYNAME), and loss reasons - Progressive 3-stage trace pipeline (seed-resolve → lineage → events) with streaming UI - Equipment model lookup via resource cache instead of SPECNAME - Session caching, auto-refresh, searchable MultiSelect with fuzzy matching - Remove legacy tmtt-defect module (fully superseded) - Archive openspec change artifacts Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
2.2 KiB
MODIFIED Requirements
Requirement: query-tool lineage tab SHALL load on-demand
The query-tool lineage tree SHALL auto-fire lineage API calls after lot resolution with concurrency-limited parallel requests and progressive rendering, while preserving on-demand expand/collapse for tree navigation.
The mid_section_defect profile SHALL support a direction parameter that controls lineage resolution direction: backward uses resolve_full_genealogy() (ancestors), forward uses resolve_forward_tree() (descendants).
useTraceProgress.js PROFILE_DOMAINS for mid_section_defect SHALL include 'upstream_history' for backward and ['upstream_history', 'downstream_rejects'] for forward. Domain selection SHALL be handled by the backend based on direction in params.
collectAllContainerIds() SHALL support forward direction by collecting descendants from children_map (instead of ancestors) when direction='forward' is present in params.
Scenario: Auto-fire lineage after resolve
- WHEN lot resolution completes with N resolved lots
- THEN lineage SHALL be fetched via
POST /api/trace/lineagefor each lot automatically - THEN concurrent requests SHALL be limited to 3 at a time to respect rate limits (10/60s)
- THEN response time SHALL be ≤3s per individual lot
Scenario: Multiple lots lineage results cached
- WHEN lineage data has been fetched for multiple lots
- THEN each lot's lineage data SHALL be preserved independently (not re-fetched)
- WHEN a new resolve query is executed
- THEN all cached lineage data SHALL be cleared
Scenario: Mid-section defect backward lineage
- WHEN profile is
mid_section_defectand direction isbackward - THEN lineage stage SHALL call
resolve_full_genealogy()to get ancestor container IDs - THEN
collectAllContainerIds()SHALL merge seed IDs with ancestor IDs
Scenario: Mid-section defect forward lineage
- WHEN profile is
mid_section_defectand direction isforward - THEN lineage stage SHALL call
resolve_forward_tree()to get descendant container IDs - THEN
collectAllContainerIds()SHALL merge seed IDs with descendant IDs fromchildren_map