Architecture: How should GitLab repos be organized to clearly separate spa...

Documentation for Sessions

🏗️ Architecture: How should GitLab repos be organized to clearly separate spa...

Date: 2026-03-10
Time: 21:50:56 UTC
Session: gspace1-200.10
Agent: backend
Confidence: 92%
Status: ✅ Documented


📋 Decision Context

Question:

How should GitLab repos be organized to clearly separate spaces and universes?

Task: S200.9: Fix GitLab repo naming and slug propagation


🎯 Decision Made

Chosen:

3-layer fix: (1) Add spaceSlug/universeSlug to ModuleGenRequest interface — eliminate all as any casts, (2) Never use universeId as fallback for universeSlug — use plan.systemName instead, preventing repo names like universe-chrome-space-1 that confuse space with universe, (3) 403 fallback bakes space-slug into repo name (gograb-{space}--universe-{universe}) preventing cross-space collisions in flat personal namespace

Options Considered:

  1. Add space-slug inside repo file paths (rejected — redundant, repo IS the boundary)
  2. Bake space-slug into repo name in personal namespace fallback (chosen)
  3. Single monorepo per space with all universes (rejected — too coupled)

💭 Reasoning

Root cause: ModuleGenRequest had no spaceSlug/universeSlug fields. All slug access was via as any casts that silently returned undefined, causing cascading fallbacks. The worst: tool-registry.service.ts line 1329 used spaceId as universeId fallback, so the repo was named universe-chrome-space-1 (space slug used as universe name). The GitLab GROUP already provides space isolation (gograb-{spaceSlug}), so the repo name should ONLY reflect the universe/project. Additionally, the 403 personal-namespace fallback lost all space isolation, so we now include the full gograb-{spaceSlug}--universe-{universeSlug} in the repo name for that case.


📁 Files Involved


🔗 Related


Auto-generated by MCP Smart Consolidation