Add post-4.0 chat product roadmap

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.

docs/roadmap/llm-chat-ergonomics/4.4.0-opinionated-use-case-modes.md

@@ -0,0 +1,56 @@
+# `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