pyro-mcp/docs/use-cases/parallel-workspaces.md
Thales Maciel d0cf6d8f21 Add opinionated MCP modes for workspace workflows
Introduce explicit repro-fix, inspect, cold-start, and review-eval modes across the MCP server, CLI, and host helpers, with canonical mode-to-tool mappings, narrowed schemas, and mode-specific tool descriptions on top of the existing workspace runtime.

Reposition the docs, host onramps, and use-case recipes so named modes are the primary user-facing startup story while the generic no-mode workspace-core path remains the escape hatch, and update the shared smoke runner to validate repro-fix and cold-start through mode-backed servers.

Validation: UV_OFFLINE=1 UV_CACHE_DIR=.uv-cache uv run pytest --no-cov tests/test_api.py tests/test_server.py tests/test_host_helpers.py tests/test_public_contract.py tests/test_cli.py tests/test_workspace_use_case_smokes.py; UV_OFFLINE=1 UV_CACHE_DIR=.uv-cache make check; UV_OFFLINE=1 UV_CACHE_DIR=.uv-cache make dist-check; real guest-backed make smoke-repro-fix-loop smoke-cold-start-validation outside the sandbox.
2026-03-13 20:00:35 -03:00

960 B

Parallel Isolated Workspaces

Recommended mode: repro-fix

Recommended startup:

pyro host connect codex --mode repro-fix

Smoke target:

make smoke-parallel-workspaces

Use this flow when the agent needs one isolated workspace per issue, branch, or review thread and must rediscover the right one later.

Chat-host recipe:

  1. Create one workspace per issue or branch with a human-friendly name and labels.
  2. Mutate each workspace independently.
  3. Rediscover the right workspace later with workspace_list.
  4. Update metadata when ownership or issue mapping changes.
  5. Delete each workspace independently when its task is done.

The important proof here is operational, not syntactic: names, labels, list ordering, and file contents stay isolated even when multiple workspaces are active at the same time. Parallel work still means “open another workspace in the same mode,” not “pick a special parallel-work mode.”