Document the post-3.1 milestones needed to make the stable workspace product feel natural in chat-driven LLM interfaces. Add a follow-on roadmap for model-native file ops, workspace naming and discovery, tool profiles, shell output cleanup, and use-case recipes with smoke coverage. Link it from the README, vision doc, and completed workspace GA roadmap so the next phase is explicit. Keep the sequence anchored to the workspace-first vision and continue to treat disk tools as secondary rather than the main chat-facing surface.
1.6 KiB
1.6 KiB
3.3.0 Workspace Naming And Discovery
Status: Planned
Goal
Make multiple concurrent workspaces manageable from chat without forcing the user or model to juggle opaque IDs.
Public API Changes
Planned additions:
pyro workspace create ... --name NAMEpyro workspace create ... --label KEY=VALUEpyro workspace listpyro workspace update WORKSPACE_ID [--name NAME] [--label KEY=VALUE] [--clear-label KEY]- matching Python SDK methods:
list_workspacesupdate_workspace
- matching MCP tools:
workspace_listworkspace_update
Implementation Boundaries
- keep workspace IDs as the stable machine identifier
- treat names and labels as operator-friendly metadata and discovery aids
- surface last activity, expiry, service counts, and summary metadata in
workspace list - make name and label metadata visible in create, status, and list responses
Non-Goals
- no scheduler or queue abstractions
- no project-wide branch manager
- no hidden background cleanup policy beyond the existing TTL model
Acceptance Scenarios
- a user can keep separate workspaces for two issues or PRs and discover them again without external notes
- a chat agent can list active workspaces, choose the right one, and continue work after a later prompt
- review and evaluation flows can tag or name workspaces by repo, bug, or task intent
Required Repo Updates
- README and install docs that show parallel named workspaces
- examples that demonstrate issue-oriented workspace naming
- smoke coverage for at least one multi-workspace flow