Thales Maciel
663241d5d2
Make the local chat-host loop explicit and cheap so users can warm the machine once instead of rediscovering environment and guest setup on every session. Add cache-backed daily-loop manifests plus the new `pyro prepare` flow, extend `pyro doctor --environment` with warm/cold/stale readiness reporting, and add `make smoke-daily-loop` to prove the warmed repro-fix reset path end to end. Also fix `python -m pyro_mcp.cli` to invoke `main()` so the new smoke and `dist-check` actually exercise the CLI module, and update the docs/roadmap to present `doctor -> prepare -> connect host -> reset` as the recommended daily path. Validation: `uv lock`, `UV_OFFLINE=1 UV_CACHE_DIR=.uv-cache make check`, `UV_OFFLINE=1 UV_CACHE_DIR=.uv-cache make dist-check`, and `UV_OFFLINE=1 UV_CACHE_DIR=.uv-cache make smoke-daily-loop`.
57 lines
1.8 KiB
Markdown
57 lines
1.8 KiB
Markdown
# `4.5.0` Faster Daily Loops
|
|
|
|
Status: Done
|
|
|
|
## 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 now adds an explicit fast-path for repeated local use:
|
|
|
|
- `pyro prepare [ENVIRONMENT] [--network] [--force] [--json]`
|
|
- `pyro doctor --environment ENVIRONMENT` daily-loop readiness output
|
|
- `make smoke-daily-loop` to prove the warmed machine plus reset/retry story
|
|
|
|
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 now show the recommended daily-use fast path
|
|
- diagnostics and help text now show whether the machine is already warm and
|
|
ready
|
|
- the repo now includes `make smoke-daily-loop` as a repeat-loop verification
|
|
scenario for the daily workflow
|