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.
57 lines
1.8 KiB
Markdown
57 lines
1.8 KiB
Markdown
# `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
|