Add chat-first workspace roadmap
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.
This commit is contained in:
parent
287f6d100f
commit
dbb71a3174
9 changed files with 326 additions and 4 deletions
|
|
@ -0,0 +1,52 @@
|
|||
# `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
|
||||
Loading…
Add table
Add a link
Reference in a new issue