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

1.9 KiB

Raw Blame History

`4.4.0` Opinionated Use-Case Modes

Status: Done

Goal

Stop making chat-host users think in terms of one giant workspace surface and let them start from a small mode that matches the job they want the agent to do.

Public API Changes

The chat entrypoint should gain named use-case modes, for example:

pyro mcp serve --mode repro-fix
pyro mcp serve --mode inspect
pyro mcp serve --mode cold-start
pyro mcp serve --mode review-eval

Modes should narrow the product story by selecting the right defaults for:

tool surface
workspace bootstrap behavior
docs and example prompts
expected export and review outputs

Parallel workspace use should come from opening more than one named workspace inside the same mode, not from introducing a scheduler or queue abstraction.

Implementation Boundaries

build modes on top of the existing workspace-core and workspace-full capabilities instead of inventing separate backends
keep the mode list short and mapped to the documented use cases
make modes visible from help text, host helpers, and recipe docs together
let users opt out to the generic workspace path when the mode is too narrow

Non-Goals

no user-defined mode DSL
no hidden host-specific behavior for the same mode name
no CI-style pipelines, matrix builds, or queueing abstractions

Acceptance Scenarios

a new user can pick one mode and avoid reading the full workspace surface before starting
the documented use cases map cleanly to named entry modes
parallel issue or PR work feels like "open another workspace in the same mode", not "submit another job"

Required Repo Updates

help text, README, install docs, integrations docs, and use-case recipes updated to teach the named modes
host-specific setup docs updated so supported hosts can start in a named mode
at least one smoke scenario proving a mode-specific happy path end to end

1.9 KiB Raw Blame History

4.4.0 Opinionated Use-Case Modes