fix(pause-online-insights): reject mismatched --name and --arn

[notgitika]

Summary

When both a config name argument and --arn were passed to agentcore pause online-insights / agentcore resume online-insights, the ARN silently won and the name was ignored. If the two referred to different configs, the wrong config was paused with no error.

Now resolveConfig cross-checks: if both are provided, the named config is looked up and its configId must match the ARN's. Mismatches return a clear error showing which config each side resolves to. Passing only one (or matching values) is unchanged.

Bug: "--arn and config name accept mismatched values without checking."

[agentcore-devx-automation]

Claude Security Review: no high-confidence findings. (run)

[github-actions]

Package Tarball

aws-agentcore-0.20.2.tgz

How to install

gh release download pr-1601-tarball --repo aws/agentcore-cli --pattern "*.tgz" --dir /tmp/pr-tarball
npm install -g /tmp/pr-tarball/aws-agentcore-0.20.2.tgz

[agentcore-cli-automation]

Nice targeted fix for a real footgun — silently picking the ARN when both were passed was the worst-of-both-worlds behavior. Two concerns worth addressing before merge around how the new cross-validation interacts with the --arn-without-project flow and how thoroughly it cross-checks the two inputs (details inline).

One side note (not introduced by this PR but now affects the new code path): in handlePauseResume, every resolution error is wrapped as ResourceNotFoundError at line 111. The mismatch error this PR adds is a validation/argument error, not a missing-resource error — there's a ValidationError class in src/lib/errors/types.ts that's a better fit and would give telemetry / error-classification downstream the right signal. Feel free to defer if you'd rather keep this PR scoped, but worth a follow-up.

[agentcore-cli-automation]

When both --arn and a config name are passed, this branch now calls resolveOnlineEvalConfig(options.name) → loadDeployedProjectConfig() unconditionally. But the command layer in src/cli/commands/pause/command.tsx deliberately skips requireProject() whenever --arn is present (lines 38–40 / 129–131):

if (!cliOptions.arn) {
  requireProject();
}

So a user running this outside a project directory with agentcore pause online-insights some-name --arn arn:... will now hit a ConfigNotFoundError from readProjectSpec() instead of either succeeding (pre-PR behavior) or getting a clear validation message. The throw falls through to the outer try/catch in command.tsx and surfaces as a generic Error: agentcore.json not found ..., which is confusing UX.

A few ways to fix:

1. In command.tsx, always call requireProject() when a name argument is provided, even alongside --arn. That makes the contract explicit: "if you pass a name, you must be in a project."
2. In resolveConfig here, catch the ConfigNotFoundError (or check for project presence first) and return a clearer error like "Cannot cross-check config name "X" against --arn: not inside a project. Pass only --arn, or run from a project directory."
3. Make the cross-check best-effort — if the project can't be loaded, silently fall through to the ARN-only path. (Partly defeats the purpose of the fix, so probably not preferred.)

Option (1) seems cleanest and matches user intent.

[agentcore-cli-automation]

Once the configIds match, this returns arnResolution, whose region comes from the ARN (or --region override). But nameResolution.region comes from the project's awsTargets entry for the deployed target. If those disagree, that's the same class of silent name-vs-ARN inconsistency this PR is closing on the configId axis — just on the region axis instead.

Consider also comparing nameResolution.region against arnResolution.region and rejecting (or warning) on mismatch. Otherwise the surface area of "silent disagreement between name and ARN" isn't fully closed.