egg/DashBoard
1
0
Fork 0
Code Issues Pull Requests Actions 2 Packages Projects Releases Wiki Activity
Files
519f8ae2f4db46ca4c643a4bba2e4abcbb263130
DashBoard/openspec/changes/trace-progressive-ui/specs/api-safety-hygiene/spec.md
egg 519f8ae2f4 feat(lineage): unified LineageEngine, EventFetcher, and progressive trace API 
Introduce a unified Seed→Lineage→Event pipeline replacing per-page Python
BFS with Oracle CONNECT BY NOCYCLE queries, add staged /api/trace/*
endpoints with rate limiting and L2 Redis caching, and wire progressive
frontend loading via useTraceProgress composable.

Key changes:
- Add LineageEngine (split ancestors / merge sources / full genealogy)
  with QueryBuilder bind-param safety and batched IN clauses
- Add EventFetcher with 6-domain support and L2 Redis cache
- Add trace_routes Blueprint (seed-resolve, lineage, events) with
  profile dispatch, rate limiting, and Redis TTL=300s caching
- Refactor query_tool_service to use LineageEngine and QueryBuilder,
  removing raw string interpolation (SQL injection fix)
- Add rate limits and resolve cache to query_tool_routes
- Integrate useTraceProgress into mid-section-defect with skeleton
  placeholders and fade-in transitions
- Add lineageCache and on-demand lot lineage to query-tool
- Add TraceProgressBar shared component
- Remove legacy query-tool.js static script (3k lines)
- Fix MatrixTable package column truncation (.slice(0,15) removed)
- Archive unified-lineage-engine change, add trace-progressive-ui specs

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
2026-02-12 16:30:24 +08:00

1.5 KiB
Raw Blame History

MODIFIED Requirements

Requirement: Staged trace API endpoints SHALL apply rate limiting

The /api/trace/seed-resolve, /api/trace/lineage, and /api/trace/events endpoints SHALL apply per-client rate limiting using the existing configured_rate_limit mechanism.

Scenario: Seed-resolve rate limit exceeded

  • WHEN a client sends more than 10 requests to /api/trace/seed-resolve within 60 seconds
  • THEN the endpoint SHALL return HTTP 429 with a Retry-After header

Scenario: Lineage rate limit exceeded

  • WHEN a client sends more than 10 requests to /api/trace/lineage within 60 seconds
  • THEN the endpoint SHALL return HTTP 429 with a Retry-After header

Scenario: Events rate limit exceeded

  • WHEN a client sends more than 15 requests to /api/trace/events within 60 seconds
  • THEN the endpoint SHALL return HTTP 429 with a Retry-After header

Requirement: Mid-section defect analysis endpoint SHALL internally use staged pipeline

The existing /api/mid-section-defect/analysis endpoint SHALL internally delegate to the staged trace pipeline while maintaining full backward compatibility.

Scenario: Analysis endpoint backward compatibility

  • WHEN a client calls GET /api/mid-section-defect/analysis with existing query parameters
  • THEN the response JSON structure SHALL be identical to pre-refactoring output
  • THEN existing rate limiting (6/min analysis, 15/min detail, 3/min export) SHALL remain unchanged
  • THEN existing distributed lock behavior SHALL remain unchanged