[cchu-ld]

Summary
This PR adds PlanSetup, which decides every setup step before setup writes to AWS. It reads AWS and returns a plan for the IAM roles, the agent space, the account association, the operator app, and the MCP server. It writes nothing. Nothing calls it yet, and main's Setup still runs. The next PR runs the plan.

Requirements

• I have added test coverage for new or changed functionality
• I have followed the repository's pull request submission guidelines
• I have validated my changes against all supported platform versions

Related issues

None.

Describe the solution you've provided

• Problem: Setup wrote to AWS as it went. It created the IAM roles before it looked at the agent space. You could not see what it would change before it changed it.
  • Solution: PlanSetup reads AWS and returns a SetupPlan. The plan has one step each for the IAM roles, the agent space, the account association, the operator app, and the MCP server. PlanSetup writes nothing.
• Problem: A plan with a step and a separate text line for each part can disagree. For example, a connect plan said No change for the operator app, but its step kept the current sign-in.
  • Solution: SetupPlan holds only the steps. Text describes them, so the printed plan always comes from the steps. In a connect plan, the app step keeps the current sign-in, because the run reports it, and Text says No change. MCPSkip is the step for a run in which the user gave no token.
• Problem: Setup called EnableOperatorApp on every run with the default iam sign-in. On a reused space, this changed a sign-in that someone had set up.
  • Solution: If the operator app of a reused space is on, the plan keeps its sign-in, unless AuthFlowSet is true. The plan reads the app with appState.
• Problem: FindAgentSpace reused the first space with the name. With two spaces of the same name, the choice was not predictable.
  • Solution: If two spaces have the name, the plan stops and asks for --agent-space-id. With --new-agent-space, the plan does not create a space with a name that a space in the region uses. A connect plan needs an existing space, so it stops if no space matches. A connect plan never creates a space, so --new-agent-space does not make a used name an error there. An empty name matches no space.
• Problem: --mcp-service-id accepted any registered MCP server, so setup could connect a server that is not a LaunchDarkly MCP server.
  • Solution: The server must serve the LaunchDarkly endpoint, or the endpoint that you pass with --mcp-endpoint. Setup finds a LaunchDarkly MCP server by its endpoint everywhere else, because the name is the choice of the customer. For a server at another endpoint, the plan stops and names --mcp-endpoint for a LaunchDarkly MCP server that you host.

Nothing calls PlanSetup yet. main's Setup still runs. The next PR runs the plan. The plan is stricter than Setup: it stops on two spaces with one name, and on --new-agent-space with a used name, where Setup takes the first space or creates a second one. The next PR replaces Setup with the plan, so the printed plan matches what runs. The plan line for a reused MCP server shows the name of that server in AWS. The plan line for a sign-in change names the current sign-in, for example Change the operator app sign-in from IAM to IdP. The tests in plan_test.go check each plan decision.

Describe alternatives you've considered

None.

Additional context

Testing: go test ./... and golangci-lint pass on this branch.

🤖 Generated with Claude Code

---

Note

Overview
Adds PlanSetup, a read-only dry-run that inspects AWS and returns a SetupPlan (agent space, IAM roles, account association, operator app, MCP server) before any writes. Human-readable output comes from SetupPlan.Text(), which is derived from the structured steps so connect vs full-provision plans stay consistent.

Planning behavior is stricter and more conservative than today’s Setup: duplicate agent space names require --agent-space-id; connect mode never creates spaces; operator app sign-in is kept on reused spaces unless AuthFlowSet (explicit --auth-flow); --mcp-service-id must point at a LaunchDarkly MCP server at the expected (or --mcp-endpoint) URL, with replace flows naming affected spaces via spacesWith. findMCPService / checkMCPServiceID and lookup helpers support that validation.

Adds plan_test.go and extends test fakes (spaceLinks on ListAssociations). Setup is unchanged and nothing in production calls PlanSetup yet—intended for a follow-up PR to execute the plan.

^{Reviewed by Cursor Bugbot for commit 7121d9c. Bugbot is set up for automated code reviews on this repo. Configure here.}

[cchu-ld]

bugbot run

[cursor]

Cursor Bugbot has reviewed your changes using default effort and found 2 potential issues.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, have a team admin enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 57a42ab. Configure here.}

[Andrewjeska]

Three notes on the plan representation and --mcp-service-id validation.

1. SetupPlan carries parallel structured + string schemas

SetupPlan has twin fields for each step — structured (Space, App, Link, MCP, RoleSteps) and pre-formatted (AgentSpace, OperatorApp, Association, MCPServer, Roles). If the renderer in #921 reads strings and tests read structs, they can diverge without failing anything. Consider making the plan purely structured and giving the step types a String()/describe() the renderer calls, so there's one source of truth.

2. Connect mode makes plan.App and plan.OperatorApp disagree

Connect mode sets plan.App.Action = AppKeep but keeps the real Flow/URL from appState, while plan.OperatorApp is overwritten to "No change". If a future consumer trusts plan.App.Flow, it gets different information than the string. Either zero the whole AppStep or compute the string from it.

3. checkMCPServiceID doesn't verify the service is a LaunchDarkly MCP

checkMCPServiceID only verifies the ID names some registered MCP server, not that it's a LaunchDarkly one. If the user passes an unrelated service's ID, the plan accepts it and setup later associates the wrong MCP server. Match on name/endpoint (or at minimum warn when it diverges).

via LD Research 🤖

[cchu-ld]

@Andrewjeska, thanks! All three points are fixed.

1. Parallel schemas: SetupPlan now holds only the structured steps (Space, Link, RoleSteps, App, AuthFlow, MCP). The text fields are gone. plan.Text() builds every printed line from the steps, so the printed plan and the steps cannot disagree. The renderer in feat: ask which agent space to use and confirm the setup plan #922 and the tests read the lines through Text(). feat: ask which agent space to use and confirm the setup plan #922 also wrote its own "Skip MCP server" line after the user pressed Enter at the token prompt. It now sets a new MCPSkip step, and RunPlan in feat: run the setup plan #921 skips the MCP server for that step. Commits: ee9853aa (feat: plan the AWS setup steps #928), 680bbba0 (feat: run the setup plan #921), ff6c1363 (feat: ask which agent space to use and confirm the setup plan #922).

2. Connect mode: The fix for point 1 also fixes this. In a connect plan, App.Action is AppKeep, and App.Flow stays the current sign-in, because ConnectPlan reports it in operatorAppEnabled. Text() derives "No change" or "No change. The operator app is off" from that step, so the line and the step agree. TestPlanTextOfAConnectPlan covers both cases.

3. --mcp-service-id: The server must now serve the LaunchDarkly endpoint, or the endpoint passed with --mcp-endpoint. Setup already finds a LaunchDarkly MCP server by its endpoint everywhere else, because the customer chooses the name. For a server at another endpoint, the plan stops. This is a behavior change. Before, --mcp-service-id alone could point at a self-hosted server on another endpoint. That case now needs --mcp-endpoint too. The README says so. Commit ee9853aa.

This reply is from Claude.