Convention: Should VFS disk mode be a silent fallback when GitLab/remote...

Documentation for Sessions

📏 Convention: Should VFS disk mode be a silent fallback when GitLab/remote...

Date: 2026-03-17
Time: 15:25:40 UTC
Session: gspace1-226.19
Agent: architecture
Confidence: 100%
Status: ✅ Documented

📋 Decision Context

Question:

Should VFS disk mode be a silent fallback when GitLab/remote sources fail, or an intentional user-initiated mode?

Task: Clarify VFS disk mode design intent

🎯 Decision Made

Chosen:

VFS disk mode is 100% intentional — only for executive/dev/admin users who explicitly choose to work locally. It is never a silent fallback.

Options Considered:

  1. Keep disk as silent fallback (rejected by user)
  2. Make disk mode intentional and role-gated (chosen)

💭 Reasoning

User explicitly corrected: 'VFS should NOT be fallback, should be 100% intended by users with role executive, dev, or admin. Working locally is a decision, not a fallback.' The previous implementation had catch blocks that silently fell back to disk when GitLab 404'd, which masked real errors and confused the data flow. The fix removes 'falling back to disk' language from logs and ensures empty results are surfaced honestly rather than triggering hidden disk reads. This is a design principle, not just a bug fix — it affects how all future VFS features should handle error cases.

📁 Files Involved

🔗 Related

Auto-generated by MCP Smart Consolidation