Scoped workspaces

Start from work

Create a workspace from a repository issue, stack review, or other supported work entry point. The product should carry the repository, ref, task, and owner context into the workspace.

What a workspace contains

A useful workspace has:

• an explicit repository and starting ref;
• an owner and an access boundary;
• a lease or lifecycle state;
• source changes that can be inspected and reviewed;
• a cleanup or retention outcome.

The exact controls depend on the workspace type. Treat the product status as authoritative and do not manually delete a workspace directory to force cleanup.

Work inside the boundary

Run the CLI or agent against the workspace root. Keep commands, generated files, credentials, and network access within the permissions presented by the product. If a command needs access outside the workspace, stop and choose an approved path instead of widening the boundary informally.

Move work forward

The normal lifecycle is:

create → inspect → edit → validate → review → land → clean up

Draft source changes should remain recoverable until review. Do not call a workspace complete merely because a command exited successfully.

When a workspace is blocked

A blocked state can mean missing access, a source conflict, a stale lease, unavailable execution capacity, or a failed validation. Read the workspace and linked work-item status first. Capture the error and preserve the workspace when recovery or review needs the original state.