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.
960 B
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:
- Create one workspace per issue or branch with a human-friendly name and labels.
- Mutate each workspace independently.
- Rediscover the right workspace later with
workspace_list. - Update metadata when ownership or issue mapping changes.
- 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.”