Architecture: How to make the spaceGuard FAST PATH safe for users with mul...

Documentation for Sessions

🏗️ Architecture: How to make the spaceGuard FAST PATH safe for users with mul...

Date: 2026-02-10
Time: 20:41:58 UTC
Session: gspace1-103.6
Agent: angular
Confidence: 75%
Status: ✅ Documented


📋 Decision Context

Question:

How to make the spaceGuard FAST PATH safe for users with multiple spaces?

Task: Prepare spaceGuard FAST PATH for multi-space users


🎯 Decision Made

Chosen:

Added a _knownSpaces Map cache to SpaceService that tracks slug/id → Space for every space loaded via initializeSpace() or setActiveSpace(). The FAST PATH now has 3 tiers: (1) slug matches current space → allow, (2) slug matches a known user space from cache → switch to it via setActiveSpace and allow, (3) unknown slug → redirect. Also added getKnownSpace(slugOrId) public method and cacheKnownSpace(space) private method.

Options Considered:

  1. knownSpaces Map cache in SpaceService (chosen)
  2. Check UserContextService.availableSpaces signal (has TODO, fake data)
  3. Check PermissionsService.getUserSpaces (returns IDs not slugs)
  4. Always fall through to full guard for authenticated users (crash risk)

💭 Reasoning

The SpaceSwitcher component calls setActiveSpace() BEFORE navigating, so the FAST PATH tier-1 handles normal space switching. But URL-based navigation (bookmarks, links) to another user space would hit the "unknown slug" path and redirect incorrectly. The knownSpaces cache solves this: as the user visits spaces, they get cached, and future URL navigations to those spaces are handled instantly without expensive full guard flow. IMPORTANT: This has only been tested with a single-space user. Multi-space testing is still required when a user has 2+ spaces to verify tier-2 (known space switch) works correctly.


📁 Files Involved


🔗 Related


Auto-generated by MCP Smart Consolidation