Architecture: Should the git-proxy module move from backend-ai-api to back...

Documentation for Sessions

🏗️ Architecture: Should the git-proxy module move from backend-ai-api to back...

Date: 2026-03-24
Time: 17:38:54 UTC
Session: gspace1-259.5
Agent: architecture
Confidence: 95%
Status: ✅ Documented

📋 Decision Context

Question:

Should the git-proxy module move from backend-ai-api to backend-vitto-api as recommended by S265.4?

Task: S259: Evaluate git-proxy placement and audit backend architecture

🎯 Decision Made

Chosen:

Keep git-proxy in backend-ai-api for now. Don't move it. The recommendation was based on a false premise (ai-api = MCP only) that contradicts reality (60+ controllers across 6 domains). Moving one controller without moving the 30+ others in the same situation is inconsistent. Instead, plan a dedicated backend consolidation session that moves all misplaced controllers at once.

Options Considered:

  1. Move git-proxy to vitto-api now (S265.4 recommendation)
  2. Keep in ai-api, plan future consolidation (chosen)
  3. Duplicate in both backends with feature flag
  4. Create a new backend-infrastructure-api for infra concerns

💭 Reasoning

  1. backend-ai-api has SandboxProxyController, HetznerController, BrowserController, DesktopController, ComputerUseController, WorkflowController, StudioRepoController — all non-MCP. GitProxy follows the same established pattern. 2) The env vars (SANDBOX_SERVER_URL, SANDBOX_API_KEY) are wired in ai-api, not vitto-api. Moving requires plumbing work. 3) The S265.4 agent never explored what else lives in ai-api — it assumed CLAUDE.md was complete. 4) The RIGHT fix is a planned consolidation of ~17 controllers from ai-api to vitto-api, not a one-off move. Spec and plan written to docs/superpowers/.

📁 Files Involved

🔗 Related

Auto-generated by MCP Smart Consolidation