Thales Maciel
d0cf6d8f21
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.
56 lines
1.9 KiB
Markdown
56 lines
1.9 KiB
Markdown
# `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
|