# `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`