1. Extend OpenAI mode to every target
`filesystem`, `git`, and `memory` should all have both deterministic and OpenAI-backed modes, with OpenAI selected by default when the key is available.
Scenario
Select which MCP workload you want to validate, then choose the deterministic or OpenAI-backed conversation mode when that target offers both.
Coverage matrix
Every target has a deterministic no-key path. OpenAI-backed paths are shown alongside them and become runnable automatically when the API key is present.
Mode cards
These are the concrete scenario variants for the selected target. Pick one to drive the step-by-step walkthrough below.
Conversation view
The right-side thread keeps the user and assistant turns readable while the left side remains the operational control panel.
Validation steps
Run each step manually. Open the dropdowns only when you want the low-level transport, workspace, or inference payloads.
What Next
The local validation flow is now strong enough to move from UI polish into higher-confidence external proof.
2. Repeat the same flow for `git`
After `filesystem`, validate the same transport and gateway thesis against a more realistic stateful target using repository operations.
3. Then validate `memory`
Use the same conversation and lifecycle harness to stress reconnect, restart, TTL, and continuity behavior where session semantics matter most.
4. Move to multi-container proof
Run client, gateway, and MCP servers as separate containers or hosts so the thesis is proven outside one local process boundary.