# `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