thaloco/pyro-mcp
1
Fork 0
Code Pull requests Releases Packages Activity Actions
pyro-mcp/docs/roadmap/llm-chat-ergonomics/4.5.0-faster-daily-loops.md
Thales Maciel 663241d5d2 Add daily-loop prepare and readiness checks 
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`.
2026-03-13 21:17:59 -03:00

1.8 KiB
Raw Blame History

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