Make concurrent workspaces easier to rediscover and resume without relying on opaque IDs alone. Add optional workspace names, key/value labels, workspace list, and workspace update across the CLI, Python SDK, and MCP surface, and persist last_activity_at so list ordering reflects real mutating activity. Update the stable contract, install/first-run docs, roadmap, and Python workspace example to teach the new discovery flow, and validate it with focused manager/CLI/API/server coverage plus uv lock, make check, make dist-check, and a real multi-workspace smoke for create, list, update, exec, reorder, and delete.
53 lines
1.6 KiB
Markdown
53 lines
1.6 KiB
Markdown
# `3.3.0` Workspace Naming And Discovery
|
|
|
|
Status: Done
|
|
|
|
## 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 NAME`
|
|
- `pyro workspace create ... --label KEY=VALUE`
|
|
- `pyro workspace list`
|
|
- `pyro workspace update WORKSPACE_ID [--name NAME] [--label KEY=VALUE] [--clear-label KEY]`
|
|
- matching Python SDK methods:
|
|
- `list_workspaces`
|
|
- `update_workspace`
|
|
- matching MCP tools:
|
|
- `workspace_list`
|
|
- `workspace_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
|
|
- public contract, CLI help, and examples that show `workspace list` and `workspace update`
|