Add next chat UX roadmap milestones
Capture the next UX pass after the workspace-core readiness review so the roadmap reflects the remaining friction a new chat-host user still feels. Add milestones for trustworthy use-case smoke coverage, host-specific Claude/Codex/OpenCode MCP onramps, and the planned 4.0 default flip to workspace-core so the bare server entrypoint finally matches the recommended path. This is a docs-only roadmap update based on the live use-case review and integration validation, with the full advanced surface kept as an explicit opt-in rather than the default.
This commit is contained in:
parent
22d284b1f5
commit
d05fba6c15
4 changed files with 192 additions and 0 deletions
|
|
@ -0,0 +1,54 @@
|
|||
# `3.10.0` Use-Case Smoke Trust And Recipe Fidelity
|
||||
|
||||
Status: Planned
|
||||
|
||||
## Goal
|
||||
|
||||
Make the documented use-case pack trustworthy enough to act like a real release
|
||||
gate for the advertised chat-first workflows.
|
||||
|
||||
## Public API Changes
|
||||
|
||||
No new core API is required in this milestone.
|
||||
|
||||
The user-visible change is reliability and alignment:
|
||||
|
||||
- `make smoke-use-cases` should pass cleanly on a supported host
|
||||
- each smoke scenario should verify the same user-facing path the recipe docs
|
||||
actually recommend
|
||||
- smoke assertions should prefer structured CLI, SDK, or MCP results over
|
||||
brittle checks against human-mode text formatting when both exist
|
||||
|
||||
## Implementation Boundaries
|
||||
|
||||
- fix the current repro-plus-fix drift as part of this milestone
|
||||
- keep the focus on user-facing flow fidelity, not on broad internal test
|
||||
harness refactors
|
||||
- prefer exact recipe fidelity over inventing more synthetic smoke-only steps
|
||||
- if the docs say one workflow is canonical, the smoke should exercise that same
|
||||
workflow directly
|
||||
|
||||
## Non-Goals
|
||||
|
||||
- no new workspace capability just to make the smoke harness easier to write
|
||||
- no conversion of the product into a CI/reporting framework
|
||||
- no requirement that every README transcript becomes a literal byte-for-byte
|
||||
golden test
|
||||
|
||||
## Acceptance Scenarios
|
||||
|
||||
- `make smoke-use-cases` passes end to end on a supported host
|
||||
- the repro-plus-fix smoke proves the documented patch path without relying on
|
||||
fragile human-output assumptions
|
||||
- each use-case recipe still maps to one real guest-backed smoke target
|
||||
- a maintainer can trust a red smoke result as a real user-facing regression,
|
||||
not just harness drift
|
||||
|
||||
## Required Repo Updates
|
||||
|
||||
- use-case smoke scenarios audited and corrected to follow the canonical docs
|
||||
- any brittle human-output assertions replaced with structured checks where
|
||||
possible
|
||||
- docs updated if a recipe or expected output changed during the alignment pass
|
||||
- at least one release/readiness note should point to the smoke pack as a
|
||||
trustworthy verification path once this lands
|
||||
|
|
@ -0,0 +1,56 @@
|
|||
# `3.11.0` Host-Specific MCP Onramps
|
||||
|
||||
Status: Planned
|
||||
|
||||
## Goal
|
||||
|
||||
Remove the last translation step for major chat hosts by shipping exact,
|
||||
copy-pasteable MCP setup guidance for the hosts users actually reach for.
|
||||
|
||||
## Public API Changes
|
||||
|
||||
No core runtime or workspace API change is required in this milestone.
|
||||
|
||||
The main user-visible additions are host-specific integration assets and docs:
|
||||
|
||||
- Claude setup should have a first-class maintained example
|
||||
- Codex should have a first-class maintained example
|
||||
- OpenCode should have a first-class maintained example
|
||||
- the integrations docs should show the shortest working path for each host and
|
||||
the same recommended `workspace-core` profile
|
||||
|
||||
## Implementation Boundaries
|
||||
|
||||
- keep the underlying server command the same:
|
||||
`pyro mcp serve --profile workspace-core`
|
||||
- treat host-specific configs as thin wrappers around the same MCP server
|
||||
- cover both package-without-install and already-installed variants where that
|
||||
materially improves copy-paste adoption
|
||||
- keep generic MCP config guidance, but stop forcing users of major hosts to
|
||||
translate it themselves
|
||||
|
||||
## Non-Goals
|
||||
|
||||
- no client-specific runtime behavior hidden behind host detection
|
||||
- no broad matrix of every MCP-capable editor or agent host
|
||||
- no divergence in terminology between host examples and the public contract
|
||||
|
||||
## Acceptance Scenarios
|
||||
|
||||
- a Claude user can copy one shipped example and connect without reading generic
|
||||
MCP docs first
|
||||
- a Codex user can copy one shipped example or exact `codex mcp add ...` command
|
||||
- an OpenCode user can copy one shipped config snippet without guessing its MCP
|
||||
schema shape
|
||||
- the README and integrations docs point to those host-specific examples from
|
||||
the first integration pass
|
||||
|
||||
## Required Repo Updates
|
||||
|
||||
- new shipped config examples for Codex and OpenCode
|
||||
- README, install docs, and integrations docs updated to point at the new host
|
||||
examples
|
||||
- at least one short host-specific quickstart section or example command for
|
||||
each supported host family
|
||||
- runnable or documented verification steps that prove the shipped examples stay
|
||||
current
|
||||
|
|
@ -0,0 +1,55 @@
|
|||
# `4.0.0` Workspace-Core Default Profile
|
||||
|
||||
Status: Planned
|
||||
|
||||
## Goal
|
||||
|
||||
Make the default MCP entrypoint match the product's recommended chat-first path
|
||||
instead of preserving a wider compatibility surface by default.
|
||||
|
||||
## Public API Changes
|
||||
|
||||
This is an intentional breaking default change for the next major release:
|
||||
|
||||
- `pyro mcp serve` should default to `workspace-core`
|
||||
- `create_server()` should default to `profile="workspace-core"`
|
||||
- `Pyro.create_server()` should default to `profile="workspace-core"`
|
||||
|
||||
The full advanced surface remains available through explicit opt-in:
|
||||
|
||||
- `pyro mcp serve --profile workspace-full`
|
||||
- `create_server(profile="workspace-full")`
|
||||
- `Pyro.create_server(profile="workspace-full")`
|
||||
|
||||
## Implementation Boundaries
|
||||
|
||||
- keep all three profile names unchanged
|
||||
- do not remove `workspace-full`
|
||||
- make the default flip explicit in docs, changelog, help text, and migration
|
||||
notes
|
||||
- keep bare `vm-run` available as the smallest one-shot profile
|
||||
|
||||
## Non-Goals
|
||||
|
||||
- no silent removal of advanced workspace capabilities
|
||||
- no attempt to infer a profile from the client name
|
||||
- no `3.x` backport that changes the current default behavior
|
||||
|
||||
## Acceptance Scenarios
|
||||
|
||||
- a bare `pyro mcp serve` command now exposes the recommended narrow profile
|
||||
- a bare `create_server()` or `Pyro.create_server()` call matches that same
|
||||
default
|
||||
- advanced hosts can still opt into `workspace-full` explicitly with no loss of
|
||||
functionality
|
||||
- docs no longer need to explain that the recommended path and the default path
|
||||
are different
|
||||
|
||||
## Required Repo Updates
|
||||
|
||||
- help text, public contract, README, install docs, and integrations docs
|
||||
revised to reflect the new default
|
||||
- migration note explaining the default change and the explicit
|
||||
`workspace-full` opt-in path
|
||||
- examples audited so they only mention `--profile workspace-core` when the
|
||||
explicitness is useful rather than compensating for the old default
|
||||
Loading…
Add table
Add a link
Reference in a new issue