Thales Maciel
9b9b83ebeb
Extend the chat ergonomics roadmap now that the core workspace and MCP path are in place for the narrowed chat-host persona. Add the next planned phase around project-aware chat startup, host bootstrap and repair, reviewable agent output, opinionated use-case modes, and faster daily loops so the roadmap keeps pushing toward a repo-aware daily tool instead of a generic VM or SDK story. Document the constraints explicitly: optimize the MCP/chat-host path first, keep disk tools secondary, and take advantage of the current no-users-yet window to make breaking product-shaping changes when needed.
56 lines
1.9 KiB
Markdown
56 lines
1.9 KiB
Markdown
# `4.4.0` Opinionated Use-Case Modes
|
|
|
|
Status: Planned
|
|
|
|
## 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
|