Thales Maciel
dbb71a3174
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.
52 lines
1.6 KiB
Markdown
52 lines
1.6 KiB
Markdown
# `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 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
|