Summary

• Adds --format=json support to vercel integration add for the auto-provision path (FF_AUTO_PROVISION_INSTALL=1)
• On success, writes structured JSON to stdout with resource, integration, product, installation, billing plan, dashboard URL, SSO URLs, project connection status, and warnings
• Refactors postProvisionSetup to return a PostProvisionSetupResult object instead of just an exit code

How agents use this (stream separation)

The Vercel CLI already separates streams per Unix convention:

• stdout (fd 1): primary data — JSON result
• stderr (fd 2): everything else — spinners, status messages, errors, prompts

When a human runs the command, they see both streams interleaved on the terminal. When an agent runs it, it captures them separately:

# Agent captures stdout (JSON) and stderr (diagnostics) separately
output=$(vercel integration add neon --format=json 2>/tmp/stderr.log)
exit_code=$?

if [ $exit_code -eq 0 ]; then
  echo "$output" | jq .resource.id    # parse JSON from stdout
else
  cat /tmp/stderr.log                  # read error details from stderr
fi

The agent determines success/failure from the exit code (0 = success, 1 = error), not by parsing output. Intermediate messages (spinners, "Installing...", "Provisioning...") go to stderr and don't interfere with the JSON on stdout.

Output contract

Example JSON output

{
  "resource": {
    "id": "res_xxx",
    "name": "neon-blue-river",
    "status": "available",
    "externalResourceId": "ext_xxx"
  },
  "integration": { "id": "int_xxx", "slug": "neon", "name": "Neon" },
  "product": { "id": "prod_xxx", "slug": "neon-postgres", "name": "Neon Postgres" },
  "installation": { "id": "inst_xxx" },
  "billingPlan": { "id": "plan_xxx", "name": "Free", "type": "subscription" },
  "dashboardUrl": "https://vercel.com/team/~/stores/integration/res_xxx",
  "ssoUrl": {
    "integration": "https://vercel.com/api/marketplace/sso?teamId=...&integrationConfigurationId=inst_xxx",
    "resource": "https://vercel.com/api/marketplace/sso?teamId=...&integrationConfigurationId=inst_xxx&resource_id=ext_xxx"
  },
  "project": { "id": "prj_xxx", "name": "my-app" },
  "environments": ["production", "preview", "development"],
  "envPulled": true,
  "warnings": []
}

All top-level keys are always present — billingPlan and project are null (not omitted) when absent.

Design decisions

1. Errors to stderr, not stdout — consistent with Unix convention and all other integration subcommands (list, open, balance, remove, discover)
2. Partial failures return exit code 0 with warnings — if the resource was provisioned (the primary action), that's success. Connection or env-pull failures are reported in the warnings array
3. Terms acceptance works normally in JSON mode — terms browser flow writes to stderr, doesn't interfere with JSON on stdout
4. Legacy path rejects --format — only the auto-provision code path supports JSON; the legacy flow errors with a clear message
5. SSO URLs included — both integration-level and resource-level SSO links via buildSSOLink(), no extra API calls needed
6. Shared env pull warning constant — ENV_PULL_FAILED_MESSAGE used by both postProvisionSetup and the JSON warnings builder

Test plan

• --format=json outputs valid JSON to stdout on success (no project context)
• JSON includes project: null when no project is linked
• JSON includes project, environments, envPulled when connected to a project
• JSON includes ssoUrl.integration and ssoUrl.resource
• Partial failure: connect fails → JSON with warnings, exit code 0
• Partial failure: env pull fails → JSON with warning, exit code 0
• Pre-provisioning error → no JSON on stdout, exit code 1
• Invalid --format=xml → error, exit code 1
• Without --format, behavior unchanged (no JSON on stdout)
• --format filtered from help when auto-provision FF is off
• All 277 tests pass (including formatDynamicExamples coverage test)

🤖 Generated with Claude Code