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.
This commit is contained in:
parent
999fe1b23a
commit
9b9b83ebeb
6 changed files with 313 additions and 6 deletions
|
|
@ -0,0 +1,56 @@
|
|||
# `4.1.0` Project-Aware Chat Startup
|
||||
|
||||
Status: Planned
|
||||
|
||||
## Goal
|
||||
|
||||
Make "current repo to disposable sandbox" the default story for the narrowed
|
||||
chat-host user, without requiring manual workspace seeding choreography first.
|
||||
|
||||
## Public API Changes
|
||||
|
||||
The chat entrypoint should gain one documented project-aware startup path:
|
||||
|
||||
- `pyro mcp serve` should accept an explicit local project source, such as the
|
||||
current checkout
|
||||
- the product path should optionally support a clean-clone source, such as a
|
||||
repo URL, when the user is not starting from a local checkout
|
||||
- the first useful chat turn should not depend on manually teaching
|
||||
`workspace create ... --seed-path ...` before the host can do real work
|
||||
|
||||
Exact flag names can still change, but the product needs one obvious "use this
|
||||
repo" path and one obvious "start from that repo" path.
|
||||
|
||||
## Implementation Boundaries
|
||||
|
||||
- keep host crossing explicit; do not silently mutate the user's checkout
|
||||
- prefer local checkout seeding first, because that is the most natural daily
|
||||
chat path
|
||||
- preserve existing explicit sync, export, diff, and reset primitives rather
|
||||
than inventing a hidden live-sync layer
|
||||
- keep the startup story compatible with the existing `workspace-core` product
|
||||
path
|
||||
|
||||
## Non-Goals
|
||||
|
||||
- no generic SCM integration platform
|
||||
- no background multi-repo workspace manager
|
||||
- no always-on bidirectional live sync between host checkout and guest
|
||||
|
||||
## Acceptance Scenarios
|
||||
|
||||
- from a repo root, a user can connect Claude Code, Codex, or OpenCode and the
|
||||
first workspace starts from that repo without extra terminal choreography
|
||||
- from outside a repo checkout, a user can still start from a documented clean
|
||||
source such as a repo URL
|
||||
- the README and install docs can teach a repo-aware chat flow before the
|
||||
manual terminal workspace flow
|
||||
|
||||
## Required Repo Updates
|
||||
|
||||
- README, install docs, first-run docs, integrations docs, and public contract
|
||||
updated to show the repo-aware chat startup path
|
||||
- help text updated so the repo-aware startup path is visible from `pyro` and
|
||||
`pyro mcp serve --help`
|
||||
- at least one recipe and one real smoke scenario updated to validate the new
|
||||
startup story
|
||||
|
|
@ -0,0 +1,53 @@
|
|||
# `4.2.0` Host Bootstrap And Repair
|
||||
|
||||
Status: Planned
|
||||
|
||||
## Goal
|
||||
|
||||
Make supported chat hosts feel one-command to connect and easy to repair when a
|
||||
local config drifts or the product changes shape.
|
||||
|
||||
## Public API Changes
|
||||
|
||||
The CLI should grow a small host-helper surface for the supported chat hosts:
|
||||
|
||||
- `pyro host connect claude-code`
|
||||
- `pyro host connect codex`
|
||||
- `pyro host print-config opencode`
|
||||
- `pyro host doctor`
|
||||
- `pyro host repair HOST`
|
||||
|
||||
The exact names can still move, but the product needs a first-class bootstrap
|
||||
and repair path for Claude Code, Codex, and OpenCode.
|
||||
|
||||
## Implementation Boundaries
|
||||
|
||||
- host helpers should wrap the same `pyro mcp serve` entrypoint rather than
|
||||
introduce per-host runtime behavior
|
||||
- config changes should remain inspectable and predictable
|
||||
- support both installed-package and `uvx`-style usage where that materially
|
||||
reduces friction
|
||||
- keep the host helper story narrow to the current supported hosts
|
||||
|
||||
## Non-Goals
|
||||
|
||||
- no GUI installer or onboarding wizard
|
||||
- no attempt to support every possible MCP-capable editor or chat shell
|
||||
- no hidden network service or account-based control plane
|
||||
|
||||
## Acceptance Scenarios
|
||||
|
||||
- a new Claude Code or Codex user can connect `pyro` with one command
|
||||
- an OpenCode user can print or materialize a correct config without hand-writing
|
||||
JSON
|
||||
- a user with a stale or broken local host config can run one repair or doctor
|
||||
flow instead of debugging MCP setup manually
|
||||
|
||||
## Required Repo Updates
|
||||
|
||||
- new host-helper docs and examples for all supported chat hosts
|
||||
- README, install docs, and integrations docs updated to prefer the helper
|
||||
flows when available
|
||||
- help text updated with exact connect and repair commands
|
||||
- runnable verification or smoke coverage that proves the shipped host-helper
|
||||
examples stay current
|
||||
|
|
@ -0,0 +1,54 @@
|
|||
# `4.3.0` Reviewable Agent Output
|
||||
|
||||
Status: Planned
|
||||
|
||||
## Goal
|
||||
|
||||
Make it easy for a human to review what the agent actually did inside the
|
||||
sandbox without manually reconstructing the session from diffs, logs, and raw
|
||||
artifacts.
|
||||
|
||||
## Public API Changes
|
||||
|
||||
The product should expose a concise workspace review surface, for example:
|
||||
|
||||
- `pyro workspace summary WORKSPACE_ID`
|
||||
- `workspace_summary` on the MCP side
|
||||
- structured JSON plus a short human-readable summary view
|
||||
|
||||
The summary should cover the things a chat-host user cares about:
|
||||
|
||||
- commands run
|
||||
- files changed
|
||||
- diff or patch summary
|
||||
- services started
|
||||
- artifacts exported
|
||||
- final workspace outcome
|
||||
|
||||
## Implementation Boundaries
|
||||
|
||||
- prefer concise review surfaces over raw event firehoses
|
||||
- keep raw logs, diffs, and exported files available as drill-down tools
|
||||
- summarize only the sandbox activity the product can actually observe
|
||||
- make the summary good enough to paste into a chat, bug report, or PR comment
|
||||
|
||||
## Non-Goals
|
||||
|
||||
- no full compliance or audit product
|
||||
- no attempt to summarize the model's hidden reasoning
|
||||
- no remote storage backend for session history
|
||||
|
||||
## Acceptance Scenarios
|
||||
|
||||
- after a repro-fix or review-eval run, a user can inspect one summary and
|
||||
understand what changed and what to review next
|
||||
- the summary is useful enough to accompany exported patches or artifacts
|
||||
- unsafe-inspection and review-eval flows become easier to trust because the
|
||||
user can review agent-visible actions in one place
|
||||
|
||||
## Required Repo Updates
|
||||
|
||||
- public contract, help text, README, and recipe docs updated with the new
|
||||
summary path
|
||||
- at least one host-facing example showing how to ask for or export the summary
|
||||
- at least one real smoke scenario validating the review surface end to end
|
||||
|
|
@ -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
|
||||
57
docs/roadmap/llm-chat-ergonomics/4.5.0-faster-daily-loops.md
Normal file
57
docs/roadmap/llm-chat-ergonomics/4.5.0-faster-daily-loops.md
Normal file
|
|
@ -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
|
||||
Loading…
Add table
Add a link
Reference in a new issue