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
|
|
@ -37,6 +37,12 @@ The remaining UX friction for a technically strong new user is now narrower:
|
||||||
|
|
||||||
- the recommended chat-host onramp is now explicit, but human-mode file reads
|
- the recommended chat-host onramp is now explicit, but human-mode file reads
|
||||||
still need final transcript polish for copy-paste and chat logs
|
still need final transcript polish for copy-paste and chat logs
|
||||||
|
- the five use-case smokes now exist, but the advertised smoke pack is only as
|
||||||
|
trustworthy as its weakest scenario and exact recipe fidelity
|
||||||
|
- generic MCP guidance is strong, but Codex and OpenCode still ask the user to
|
||||||
|
translate the generic config into host-specific setup steps
|
||||||
|
- `workspace-core` is clearly the recommended profile, but `pyro mcp serve` and
|
||||||
|
`create_server()` still default to `workspace-full` for `3.x` compatibility
|
||||||
|
|
||||||
## Locked Decisions
|
## Locked Decisions
|
||||||
|
|
||||||
|
|
@ -60,6 +66,9 @@ The remaining UX friction for a technically strong new user is now narrower:
|
||||||
6. [`3.7.0` Handoff Shortcuts And File Input Sources](llm-chat-ergonomics/3.7.0-handoff-shortcuts-and-file-input-sources.md) - Done
|
6. [`3.7.0` Handoff Shortcuts And File Input Sources](llm-chat-ergonomics/3.7.0-handoff-shortcuts-and-file-input-sources.md) - Done
|
||||||
7. [`3.8.0` Chat-Host Onramp And Recommended Defaults](llm-chat-ergonomics/3.8.0-chat-host-onramp-and-recommended-defaults.md) - Done
|
7. [`3.8.0` Chat-Host Onramp And Recommended Defaults](llm-chat-ergonomics/3.8.0-chat-host-onramp-and-recommended-defaults.md) - Done
|
||||||
8. [`3.9.0` Content-Only Reads And Human Output Polish](llm-chat-ergonomics/3.9.0-content-only-reads-and-human-output-polish.md) - Done
|
8. [`3.9.0` Content-Only Reads And Human Output Polish](llm-chat-ergonomics/3.9.0-content-only-reads-and-human-output-polish.md) - Done
|
||||||
|
9. [`3.10.0` Use-Case Smoke Trust And Recipe Fidelity](llm-chat-ergonomics/3.10.0-use-case-smoke-trust-and-recipe-fidelity.md)
|
||||||
|
10. [`3.11.0` Host-Specific MCP Onramps](llm-chat-ergonomics/3.11.0-host-specific-mcp-onramps.md)
|
||||||
|
11. [`4.0.0` Workspace-Core Default Profile](llm-chat-ergonomics/4.0.0-workspace-core-default-profile.md)
|
||||||
|
|
||||||
Completed so far:
|
Completed so far:
|
||||||
|
|
||||||
|
|
@ -84,6 +93,20 @@ Completed so far:
|
||||||
- `3.9.0` added content-only workspace file and disk reads plus cleaner default human-mode
|
- `3.9.0` added content-only workspace file and disk reads plus cleaner default human-mode
|
||||||
transcript separation for files that do not end with a trailing newline.
|
transcript separation for files that do not end with a trailing newline.
|
||||||
|
|
||||||
|
Planned next:
|
||||||
|
|
||||||
|
- `3.10.0` makes the use-case recipe set fully trustworthy by requiring
|
||||||
|
`make smoke-use-cases` to pass cleanly, aligning recipe docs with what the
|
||||||
|
smoke harness actually proves, and removing brittle assertions against
|
||||||
|
human-mode output when structured results are already available.
|
||||||
|
- `3.11.0` adds exact host-specific onramps for Claude, Codex, and OpenCode so
|
||||||
|
a new chat-host user can copy one known-good config or command instead of
|
||||||
|
translating the generic MCP example by hand.
|
||||||
|
- `4.0.0` flips the default MCP profile from `workspace-full` to
|
||||||
|
`workspace-core` so the no-flag server entrypoint finally matches the
|
||||||
|
recommended docs path, while keeping explicit opt-in access to the full
|
||||||
|
advanced surface.
|
||||||
|
|
||||||
## Expected Outcome
|
## Expected Outcome
|
||||||
|
|
||||||
After this roadmap, the product should still look like an agent workspace, not
|
After this roadmap, the product should still look like an agent workspace, not
|
||||||
|
|
@ -98,5 +121,9 @@ The intended model-facing shape is:
|
||||||
- shells are readable in chat
|
- shells are readable in chat
|
||||||
- CLI handoff paths do not depend on ad hoc shell parsing
|
- CLI handoff paths do not depend on ad hoc shell parsing
|
||||||
- the recommended chat-host profile is obvious from the first MCP example
|
- the recommended chat-host profile is obvious from the first MCP example
|
||||||
|
- the documented smoke pack is trustworthy enough to use as a release gate
|
||||||
|
- major chat hosts have copy-pasteable MCP setup examples instead of only a
|
||||||
|
generic config template
|
||||||
- human-mode content reads are copy-paste safe
|
- human-mode content reads are copy-paste safe
|
||||||
|
- the default bare MCP server entrypoint matches the recommended narrow profile
|
||||||
- the five core use cases are documented and smoke-tested end to end
|
- the five core use cases are documented and smoke-tested end to end
|
||||||
|
|
|
||||||
|
|
@ -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