Clarify workspace-core as the chat-host onramp
Make the recommended MCP profile visible from the first help and docs pass without changing 3.x behavior. Rework help, top-level docs, public-contract wording, and shipped MCP/OpenAI examples so is the recommended first profile while stays the compatibility default for full-surface hosts. Bump the package and catalog to 3.8.0, mark the roadmap milestone done, and add regression coverage for the new MCP help and docs alignment. Validation included uv lock, targeted profile/help tests, make check, make dist-check, and a real guest-backed server smoke.
This commit is contained in:
parent
7a0620fc0c
commit
407c805ce2
17 changed files with 150 additions and 50 deletions
|
|
@ -85,7 +85,7 @@ uvx --from pyro-mcp pyro env list
|
|||
Expected output:
|
||||
|
||||
```bash
|
||||
Catalog version: 3.7.0
|
||||
Catalog version: 3.8.0
|
||||
debian:12 [installed|not installed] Debian 12 environment with Git preinstalled for common agent workflows.
|
||||
debian:12-base [installed|not installed] Minimal Debian 12 environment for shell and core Unix tooling.
|
||||
debian:12-build [installed|not installed] Debian 12 environment with Git and common build tools preinstalled.
|
||||
|
|
@ -233,6 +233,20 @@ After the CLI path works, you can move on to:
|
|||
- Python SDK: `from pyro_mcp import Pyro`
|
||||
- Demos: `pyro demo` or `pyro demo --network`
|
||||
|
||||
## Chat Host Quickstart
|
||||
|
||||
For most chat-host integrations, start with `workspace-core`:
|
||||
|
||||
```bash
|
||||
uvx --from pyro-mcp pyro mcp serve --profile workspace-core
|
||||
```
|
||||
|
||||
Use profile progression like this:
|
||||
|
||||
- `workspace-core`: recommended first profile for normal persistent chat editing
|
||||
- `vm-run`: one-shot-only integrations
|
||||
- `workspace-full`: advanced 3.x compatibility surface when the host truly needs shells, services, snapshots, secrets, network policy, or disk tools
|
||||
|
||||
## Stable Workspace
|
||||
|
||||
Use `pyro workspace ...` when you need repeated commands in one sandbox instead of one-shot `pyro run`.
|
||||
|
|
@ -280,7 +294,7 @@ the identifier programmatically, use `--id-only` for only the identifier or `--j
|
|||
workspace payload. Use `--seed-path`
|
||||
when the workspace should start from a host directory or a local `.tar` / `.tar.gz` / `.tgz`
|
||||
archive. Use `pyro workspace sync push` for later host-side changes to a started workspace. Sync
|
||||
is non-atomic in `3.7.0`; if it fails partway through, prefer `pyro workspace reset` to recover
|
||||
is non-atomic in `3.8.0`; if it fails partway through, prefer `pyro workspace reset` to recover
|
||||
from `baseline` or one named snapshot. Use `pyro workspace diff` to compare the current workspace
|
||||
tree to its immutable create-time baseline, `pyro workspace snapshot *` to capture named
|
||||
checkpoints, and `pyro workspace export` to copy one changed file or directory back to the host. Use
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue