GitLab Workspace Context Integration

Architecture in Disposable Sandboxes

Every GitLab Workspace provisioned on Oracle K3s for a Bluefly specialist identity includes native context tools:

GitLab Workspace Container (Oracle K3s)
  ├── glab CLI (v1.54+)
  ├── Orbit CLI (glab orbit remote + glab orbit local)
  ├── QMD (Query client over mounted/prebuilt BluCity-Docs corpus)
  ├── bd (Beads client connected to canonical Dolt DB)
  ├── Git (Configured with blucity_<role> email & username)
  └── Tailscale / Aperture Socket (Brokered AI provider connectivity)

Bootstrap Lifecycle in Workspace

1. Identity Mount: Workspace starts with ambient service account session.
2. Orbit Remote Discovery: Authenticates to GitLab ClickHouse graph as blucity_<role>.
3. Orbit Local Realization: Runs glab orbit local index . creating ~/.orbit/graph.duckdb.
4. QMD Mount Verification: Validates search availability across BluCity-Docs.
5. Agent Start: Claude/Codex/Cursor agent connects to local MCP servers (orbit-remote, orbit-local, qmd).

Relationship to other context sources

A GitLab Workspace is EXECUTION context, not source authority — see README.md §4. It mounts/proxies to the real authorities (GitLab, QMD, Orbit, Beads); it never becomes a second copy of any of them.