fix(status): show 'No target configured' instead of empty '(target: )' in status header

[aidandaly24]

Description

agentcore status rendered an empty target label — AgentCore Status (target: ) — in the header when the project had no deployment target configured (e.g. a project freshly created with --defaults).

The default-path render at src/cli/commands/status/command.tsx:156 already had a || 'No target configured' fallback (added in #1068), but the runtime-status path at line 116 (agentcore status --runtime <id>) still rendered (target: {result.targetName}) with no fallback, leaving the same latent bug for that code path. handleProjectStatus / handleRuntimeLookup in action.ts return targetName: '' when no target is configured, so '' was being printed verbatim.

This PR:

• Adds an explicit empty-string check to the runtime-status header so it renders (target: No target configured) instead of (target: ) when no target is configured. Used result.targetName && result.targetName.length > 0 ? result.targetName : 'No target configured' because targetName is typed as string | undefined on RuntimeLookupResult and ?? does not catch the empty-string case the bug describes.
• Adds a regression test in src/cli/commands/status/__tests__/action.test.ts locking in the contract that handleProjectStatus returns targetName: '' when there are no configured targets — i.e. the value the JSX fallback depends on.

No refactor, no changes outside the status command, and no CDK changes (this is a pure CLI presentation bug).

Related Issue

Closes #985

Documentation PR

N/A — no user-facing docs change.

Type of Change

• Bug fix
• New feature
• Breaking change
• Documentation update
• Other (please describe):

Testing

How have you tested the change?

• I ran npm run test:unit and npm run test:integ
• I ran npm run typecheck
• I ran npm run lint
• If I modified src/assets/, I ran npm run test:update-snapshots and committed the updated snapshots

Checklist

• I have read the CONTRIBUTING document
• I have added any necessary tests that prove my fix is effective or my feature works
• I have updated the documentation accordingly
• I have added an appropriate example to the documentation to outline the feature, or no new docs are needed
• My changes generate no new warnings
• Any dependent changes have been merged and published

---

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the
terms of your choice.

[agentcore-cli-automation]

Thanks for the fix. I want to surface one concern before this is merged: the runtime-status render guard may be defending against a state that is not currently reachable, and the regression test doesn't actually cover the code change.

Nothing here is a correctness hazard — the change is safe and the fallback string matches the default path — but it's worth clarifying the contract in code or description so the next reader isn't misled about which bug lives where.

[agentcore-cli-automation]

handleRuntimeLookup in action.ts returns success: false early (lines 409–414) when awsTargets is empty, and on the success path selectedTargetName = options.targetName ?? targetNames[0]! (line 416) is guaranteed to be a non-empty string because targetNames.length > 0 is required to reach this point. So on the success branch that reaches this render, result.targetName cannot actually be empty or undefined today — this guard is purely defensive against a future refactor of handleRuntimeLookup.

That's not wrong, but it contradicts the PR description, which frames this as fixing "the same latent bug for that code path." There's no latent bug here right now — the reproducer in #985 (agentcore status with no --runtime) lands in the default path at line 157, which was already fixed in #1068.

Options:

1. Leave the guard as defense-in-depth but update the PR description (and maybe a code comment here) to say "defensive guard in case handleRuntimeLookup's contract changes" rather than claiming it fixes a latent bug.
2. Drop this render change entirely since the state is unreachable, and just keep the regression test on handleProjectStatus.
3. If you want the guard to mean something today, tighten RuntimeLookupResult.targetName from string | undefined to string (since the success path always provides it) — that removes the need for this check and makes the contract explicit.

[agentcore-cli-automation]

This test verifies the handleProjectStatus contract (empty targetName when no targets are configured), but the code change in this PR is on the runtime-status path that calls handleRuntimeLookup. So the test doesn't actually exercise the render line you modified.

It's a fine regression guard for the default-path fix that landed in #1068, but if the goal is to lock in the behavior that this PR changes, consider adding a test for handleRuntimeLookup or a rendering test for the runtime-status header — otherwise nothing in the test suite prevents a future regression of line 113–114.

Also, minor: this test is inside describe('handleProjectStatus — live enrichment', ...) but has nothing to do with live enrichment. Consider moving it to a more appropriate describe block (e.g. the existing handleProjectStatus block that covers target resolution).

[github-actions]

Coverage Report

Status	Category	Percentage	Covered / Total
🔵	Lines	43.19%	9034 / 20915
🔵	Statements	42.47%	9592 / 22585
🔵	Functions	40.02%	1558 / 3893
🔵	Branches	40.04%	5817 / 14527

Generated in workflow #2647 for commit e9bba99 by the Vitest Coverage Report Action

[jariy17]

PR Test Report (updated)

5 passed, 0 failed. Cosmetic fix verified: runtime-id render path now has the same "No target configured" fallback as the default status path; deployed happy path still renders "(target: )" normally.
Report: https://gistpreview.github.io/?d332790d40176b811829be189330630c/pr-agentcore-cli-1171-test-report.html