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.5.0-faster-daily-loops.md

@@ -0,0 +1,57 @@
+# `4.5.0` Faster Daily Loops
+
+Status: Planned
+
+## Goal
+
+Make the day-to-day chat-host loop feel cheap enough that users reach for it
+for normal work, not only for special high-isolation tasks.
+
+## Public API Changes
+
+The product should add an explicit fast-path for repeated local use, such as:
+
+- a prewarm or prepare path for the recommended environment and runtime
+- a clearer fast reset or retry path for repeated repro-fix loops
+- visible diagnostics for cache, prewarm, or ready-state health
+
+The exact command names can still move, but the user-visible story needs to be:
+
+- set the machine up once
+- reconnect quickly
+- create or reset a workspace cheaply
+- keep iterating without redoing heavy setup work
+
+## Implementation Boundaries
+
+- optimize local-first loops on one machine before thinking about remote
+  execution
+- focus on startup, create, reset, and retry latency rather than queue
+  throughput
+- keep the fast path compatible with the repo-aware startup story and the
+  supported chat hosts
+- prefer explicit caching and prewarm semantics over hidden long-running
+  daemons
+
+## Non-Goals
+
+- no cloud prewarm service
+- no scheduler or queueing layer
+- no daemon requirement for normal daily use
+
+## Acceptance Scenarios
+
+- after the first setup, entering the chat-host path again does not feel like
+  redoing the whole product onboarding
+- reset and retry become cheap enough to recommend as the default repro-fix
+  workflow
+- docs can present `pyro` as a daily coding-agent tool, not only as a special
+  heavy-duty sandbox
+
+## Required Repo Updates
+
+- docs updated to show the recommended daily-use fast path
+- diagnostics and help text updated so the user can tell whether the machine is
+  already warm and ready
+- at least one repeat-loop smoke or benchmark-style verification scenario
+  added to prevent regressions in the daily workflow