wk folders update cannot move a folder to a new parent

[Abhishek-Bhatta]

Behavior

wk folders update <id> --name <new> can rename a folder or project, but there's
no way to move a folder to a different parent. internal/commands/folder.go
only registers a --name flag, and folderService.Update() in
internal/api/folders.go only ever sends {"name": name} to PUT /folders/{id}.

Verified against the live API

PUT /folders/{id} accepts a parent_id field and actually performs the move:

curl -X PUT .../api/folders/32091444 -d '{"parent_id": 32091445}'
→ {"id":32091444,...,"parent_id":32091445,...}   # 200, applied

Confirmed with wk folders list --parent <new-parent> showing the folder
correctly nested afterward, and a recipe inside it (folder_id unchanged)
transitively moved along with its containing folder.

So this is the exact same endpoint wk already calls for rename. The client
just never sends the second field.

Fix

Adding wk folders move <id> --parent <id> as its own command, mirroring
wk recipes move (a separate explicit opt-in from update, same reasoning:
update shouldn't relocate something as a side effect). Already implemented
and tested locally, PR incoming.

[Abhishek-Bhatta]

Hi @zaynelt

One of the use cases I had was moving files around locally and then agreeing on a folder structure/layout before I push these back onto Workato. In the process, I wanted to rename and reparent some folders, along with the recipes inside them. I found that reparenting folders wasn't possible.

This also brings up a broader philosophical question: do we ever want to accept local structure and layout as something that should have eventual consistency with the server? I read a previous ADR that indicated otherwise, but I wanted to reorganize things locally, and then do a push for the server to reflect local state. This way, I can be sure that the layout I have is the layout others have too. What are your thoughts on this topic?

[zaynelt]

@Abhishek-Bhatta, addressing the first part of your comment re: your use case of re-name and re-parent--that makes total sense and feels like unfinished functionality in #93. I will proceed with the suggested path of adding support for *parentId to the method before merging.

On the second question, which ADR indicated the opposite? I think there are a couple scenarios the ADRs were trying to address that we would want to avoid an agent conflating (which the ADR language may have been imprecise about)--each with different ramifications. One is "I have a pre-existing local state that I want to push to a greenfield environment", and the CLI does support that. The use case I believe you are bringing up (which I believe is the gap we do not have adequate designs for now) is "I have a local state on my machine now that contains a massive set of changes I need the server to match because I reorganized a bunch of [stuff]". I would definitely be interested in figuring out how to support the latter use case--ensuring artifacts move vs become duplicated, etc.

[zaynelt]

Landed in #93 — see comment there for the shape. wk folders update <id> --parent <id> reparents (optionally combined with --name), reusing the existing Update endpoint/method rather than a separate Move. Closing once #93 merges.