gmakstutis/LightRAG
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
LightRAG/specs/001-multi-workspace-server/checklists/requirements.md
Clément THOMAS 62b2a71dda feat(api): add multi-workspace server support for multi-tenant deployments 
Enable a single LightRAG server instance to serve multiple isolated workspaces
via HTTP header-based routing. This allows multi-tenant SaaS deployments where
each tenant's data is completely isolated.

Key features:
- Header-based workspace routing (LIGHTRAG-WORKSPACE, X-Workspace-ID fallback)
- Process-local pool of LightRAG instances with LRU eviction
- FastAPI dependency (get_rag) for workspace resolution per request
- Full backward compatibility - existing deployments work unchanged
- Strict multi-tenant mode option (LIGHTRAG_ALLOW_DEFAULT_WORKSPACE=false)
- Configurable pool size (LIGHTRAG_MAX_WORKSPACES_IN_POOL)
- Graceful shutdown with workspace finalization

Configuration:
- LIGHTRAG_DEFAULT_WORKSPACE: Default workspace (falls back to WORKSPACE)
- LIGHTRAG_ALLOW_DEFAULT_WORKSPACE: Require explicit header when false
- LIGHTRAG_MAX_WORKSPACES_IN_POOL: Max concurrent workspace instances (default: 50)

Files:
- New: lightrag/api/workspace_manager.py (core multi-workspace module)
- New: tests/test_multi_workspace_server.py (17 unit tests)
- New: render.yaml (Render deployment blueprint)
- Modified: All route files to use get_rag dependency
- Updated: README.md, env.example with documentation

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude <noreply@anthropic.com>
2025-12-01 12:07:22 +01:00

2.9 KiB
Raw Blame History

Specification Quality Checklist: Multi-Workspace Server Support

Purpose: Validate specification completeness and quality before proceeding to planning Created: 2025-12-01 Feature: spec.md Status: All checks passed

Content Quality

  • No implementation details (languages, frameworks, APIs)
    • Verified: No mention of Python, FastAPI, asyncio, or specific libraries
  • Focused on user value and business needs
    • Verified: User stories frame from SaaS operator, API client developer, existing user perspectives
  • Written for non-technical stakeholders
    • Verified: Requirements use business language (workspace, tenant, isolation) not code terms
  • All mandatory sections completed
    • Verified: User Scenarios, Requirements, Success Criteria all present and populated

Requirement Completeness

  • No [NEEDS CLARIFICATION] markers remain
    • Verified: Zero markers in specification
  • Requirements are testable and unambiguous
    • Verified: Each FR has specific, verifiable conditions (e.g., "alphanumeric, hyphens, underscores, 1-64 characters")
  • Success criteria are measurable
    • Verified: SC-001 through SC-007 include specific metrics (5 seconds, 10ms, 50 instances, 100% isolation)
  • Success criteria are technology-agnostic (no implementation details)
    • Verified: Criteria focus on observable outcomes, not internal implementation
  • All acceptance scenarios are defined
    • Verified: 15 acceptance scenarios across 5 user stories
  • Edge cases are identified
    • Verified: 5 edge cases with expected behaviors documented
  • Scope is clearly bounded
    • Verified: Focused on server-level multi-workspace; leverages existing core isolation
  • Dependencies and assumptions identified
    • Verified: Assumptions section documents 4 key assumptions

Feature Readiness

  • All functional requirements have clear acceptance criteria
    • Verified: 22 functional requirements, each testable
  • User scenarios cover primary flows
    • Verified: P1 stories cover isolation and routing; P2 covers compatibility; P3 covers operations
  • Feature meets measurable outcomes defined in Success Criteria
    • Verified: SC maps directly to FR and user stories
  • No implementation details leak into specification
    • Verified: No code patterns, library names, or implementation hints

Validation Result

PASSED - All 16 checklist items pass validation.

Notes

  • Specification is ready for /speckit.plan phase
  • No clarifications needed - requirements are complete and unambiguous
  • Constitution alignment verified:
    • Principle I (API Backward Compatibility): Addressed by FR-014, FR-015, FR-016, US3
    • Principle II (Workspace Isolation): Core focus of US1, FR-011 through FR-013
    • Principle III (Explicit Configuration): Addressed by FR-020, FR-021, FR-022
    • Principle IV (Test Coverage): SC-007 requires automated isolation tests