[violetaGitHub]

What does this pull request do?

Creating an xlink now checks it in and loads its files, so its folder shows the other repository's files at once.

Current behavior

New xlink… created a pending xlink whose folder stayed empty. To see its files the user had to check it in, then update, and a workspace update finds the workspace up to date and loads nothing, so in practice the files didn't come until someone else checked in.

Behavior with this pull request

• The dialog's button reads Create and check in, and the dialog takes a comment ("Add xlink " when none is typed). The xlink is checked in alone, as its own changeset; other pending changes stay pending. Its files show at once.
• When a step after cm xlink fails, the dialog still closes (the xlink exists) and the toast says what it is now and what to do: not checked in (it's in Changes), or checked in without its files (with a Load its files action).
• Files offers Load its files on a checked-in xlink whose folder it listed empty, e.g. one checked in from Changes.
• If changes had to be put aside to load the files and don't come back cleanly, "Welcome back" offers them as "put aside to load an xlink".

How it was implemented

• No cm command loads a pending xlink: cm fills its folder only from the server's tree. A root cm update after the checkin says "up to date" (it goes the switch-to-last way); cm update <xlink folder> loads it.
• XlinksApi.create (an operation now) runs cm xlink (query), then cm checkin <xlink> --all --dependencies -commentsfile (checkinArgs, execute), then loadXlink (main/workspace/loadXlink.ts): cm update <xlink> --machinereadable --noinput --dontmerge (loadXlinkArgs, execute). Three commands when nothing gets in the way.
• Updating a folder, cm checks the whole workspace for pending changes and does what client.conf's PendingChangesOnSwitchAction says: unset (the default), it updates and leaves them; set to Shelve, it would shelve/undo/merge them itself, which --machinereadable turns into a refusal. On a refusal loadXlink follows switchApproach: undo unchanged checkouts; leave a merge alone; or put the changes aside as a switch does (automatic shelve recorded with the new ShelvedChangesReason 'xlink', undo, moveNewItemsAside, load, putShelvedChangesBack). cm failing before the shelve gives back what cm update said; the app's own "Check them in first" errors stay.
• CreatedXlink (loaded / notCheckedIn / notLoaded) resolves instead of throwing once cm xlink succeeded; createdXlinkMessage and loadedXlinkMessage word the endings; unloadedXlinkOf decides when Files offers Load its files; XlinksApi.load / loadXlinkFiles run it.
• Refactor: changesPutBackError is shared with shelveBlockedAndUpdate.
• Dropped: checking in and running a root update (loads nothing); letting cm shelve on its own (the app never does, as with switch); writing to client.conf (the app never writes cm's config).

Behavior changes

• Creating an xlink publishes a changeset at once (the button says so).
• While an xlink is created or its files load, the operation blocks other workspace operations as an update does, and the Incoming chip shows "Updating".
• No progress bar while files load: --forcedetailedprogress is turned off by --machinereadable (documented).
• With cm set to shelve pending changes, its first refused cm update shows in red in the status bar, as other recoveries inside the main process already do.
• Load its files shows only once Files has listed the xlink's folder (opened it): an unread listing tells nothing, and updating a loaded xlink's folder could move part of the workspace.

Checklist

• npm run typecheck and npm test pass (7,839). New tests cover: loadXlink over playAlongWorkspace (updates the folder alone; refusal → shelve/undo/load/merge back; reads pending changes once; changes that don't come back are left changes with reason 'xlink'; unchanged checkouts; merge in progress; failures before and after the shelve); the service's commands and CreatedXlink mapping (xlinksService.test.ts); the dialog's comment and words; the endings; the menu decision; "Welcome back" and Shelves wording.
• Seen working in the app (development build, local-server sandbox scripts/sandboxes/xlinks.sh, cm set to Shelve, README.md pending): created and checked in as changeset 3 with its files; Load its files on an xlink checked in by cm; both themes, a narrow window, a clean console; command log counted.
• npm run e2e: not run; smoke creates no xlinks and the change touches no startup or navigation.
• Other areas reached: "Welcome back", Shelves and restore wording for the new reason; playAlongWorkspace learned cm update.
• Reviewed in a clean context, twice. Fixed: recovery copy named steps that don't load files (→ XlinksApi.load, menu entry, toast action); the "Welcome back" reason; cm named in copy; shelve errors hidden; claims about server failures; tests for the mapping and the single status read; record mode; refresh list; doc wrap. Declined: one shared "shelve aside" skeleton for switch, update and xlink (they shelve different changes, write different records and steps; only the put-back error was shared); a progress bar (see above); marking cm's expected refusal as handled from the main process (no such channel exists today). Noted: commit cacd0798 changes XlinksApi.create before 3ade145a updates its caller, so it doesn't typecheck alone; 161b651b's message carries two changes; some docs landed in their own commits.
• docs/features/xlinks.md describes creating, loading and the cm commands; docs/features/shelves-and-switching.md names the new flow.

Fixed issues

None.

🤖 Generated with Claude Code