[ctawiah]

Context

A link of a repository source is reviewed and written in one command, and then the resource syncs. When the variation does not exist in LaunchDarkly, the plan stopped with an error that asked the user to create it in the UI first, because a descriptor has no upsert. When the config did not exist, the read of the config failed and stopped the whole plan, including every other variation of the project. Both cases are the first step of an adoption flow: the prompt lives in code and LaunchDarkly has nothing yet.

What changes

• link --upsert creates the resource in LaunchDarkly when it does not exist. For a variation it also creates the config when LaunchDarkly has none. The plan shows the row as create_server with the reason new, creates config "x", and the same --yes and --no-input flags apply, because the create asks nothing.
• --model-config-key gives the new variation a model config at its latest version, as add does. --mode sets the mode of a new config. Without it, the source decides: a message list makes a completion config, text makes an agent one. Both flags need --upsert and apply to a variation only.
• The intent of the link is not stored in the descriptor. It rides on the link run, and applies to the compiled resource of the link both before and after the descriptor is written, so the second read of the state plans the same create.
• A missing config is now a row of the plan, not a failure of the whole plan. The row names the config and the flag that creates it, and the other variations of the project are planned as before.
• A create of a linked resource needs no sync setting, because LaunchDarkly has nothing yet for a setting to govern. A server_canonical setting still refuses a create.
• A tool or skill link with --upsert creates the tool or skill through the same publish as a managed file with upsert.
• CreateConfig on the API client posts the key, the name, and the mode.

Design notes

• The create reuses the existing mechanics: Upsert on the compiled resource, chooseAction, the create path of applyServerChange, and the publish of the attachment resolver. The only new write is the config create, which runs right before the variation create and tolerates a 409 from a config that another working copy created after the plan.
• The config is created with no variation, and the variation create follows in the same apply. If the variation create fails, the empty config stays, and the next link --upsert finds it and creates the variation only.
• A managed variation file keeps its own upsert: true, and a missing config now works for it the same way.

Review focus

• Is the mode rule right: --mode, else the mode the source implies, else agent?
• Is an empty config after a failed variation create acceptable, or does the create need a rollback?

Verification

• go test ./...
• golangci-lint run ./...
• TestLinkUpsertCreatesTheConfigAndTheVariation, TestLinkUpsertCreatesTheVariationWithAModelConfig, TestLinkUpsertModeOverridesTheSourceMode, TestLinkWithoutUpsertNamesTheMissingConfig, TestLinkUpsertCreatesAMissingTool, TestCreateOfALinkedResourceNeedsNoSetting, TestClientCreatesConfig, and TestSourceLinkFlagsCarryTheUpsertIntent.

🤖 Generated with Claude Code