Skip to content

docs(plans): how to make "New workspace from this one" functional - #232

Draft
pythonlearner1025 wants to merge 1 commit into
webapp/disable-workspace-clone-buttonfrom
plans/workspace-clone-functional
Draft

docs(plans): how to make "New workspace from this one" functional#232
pythonlearner1025 wants to merge 1 commit into
webapp/disable-workspace-clone-buttonfrom
plans/workspace-clone-functional

Conversation

@pythonlearner1025

Copy link
Copy Markdown
Member

Draft — a plan to review, not code to merge. Follow-up to #231, which comments
the footer verb out. Based on that branch so the diff is the doc alone; retarget
to main once #231 lands.

Adds plans/WORKSPACE-CLONE.md.

The short version

The server side of cloning is already real and already tested
performWorkspaceCreate inherits the source's default machine type, agent rule,
repo list and connection ceiling, and test/workspace-clones.test.ts pins the
create, the repos + cloneFromWorkspaceId refusal and the private-repo 409.
What is unfinished is the browser flow around it. The plan lists six defects,
each grounded at the line that causes it:

  1. A finished clone leaves the source armed. cloneFromWorkspaceId is
    cleared on cancel and nowhere else, so the next plain create — the rail "+",
    the first-workspace prompt, a retry — opens titled New workspace from "the
    old one"
    and silently clones it.
  2. The source's default machine type never inherits. The dialog always sends
    its own selection, so the server's ?? source.default_machine_type_id branch
    is unreachable from this UI.
  3. The inherited agent rule is invisible and cannot be cleared. The picker
    shows "no rule" while the server inherits one.
  4. Nothing tells the person what carries over — or that members and
    credentials do not.
  5. The private-repo 409 is a dead end. The connect link lives in the repo
    picker, which clone mode hides, and the connect draft carries no clone source,
    so leaving to connect drops you into a plain create.
  6. The verb is offered to people who cannot use it. onClone is passed
    unconditionally while creating a workspace is org-admin only.

Defect 1 misfires from every other create entry point too, so it is worth
fixing whether or not the button ever comes back.

What the plan asks reviewers to decide

Three product questions in §4, because they change the work rather than follow
from it: whether members and credentials keep staying out of a clone, whether a
clone is a one-shot copy rather than a link to its source, and whether the
details footer is the right entry point at all.

§3 lists the tests that must be green before the button is uncommented,
including the end-to-end that does not exist in any form today: footer → create
dialog carrying the source → the exact body the client sends.

🤖 Generated with Claude Code

PR #231 comments the footer verb out. This is the plan for bringing it
back: the six browser-side defects that make it not work today, each
grounded at the line that causes it, the order to fix them in, the tests
that must exist before the button is uncommented, and the three product
decisions the work needs answered first.

The server side is not the problem and the plan says so — the clone,
its inherit set and its refusals are already covered by
test/workspace-clones.test.ts. Everything between the footer button and
api.createWorkspace is what has no test, which is how a finished clone
leaving its source armed for the next create went unnoticed.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants