fix(create): use harness-first language when project already exists

[tejaskash]

Problem

When a user runs agentcore create inside an existing project, the existing-project-error screen tells them only:

Use add agent to create a new agent in the existing project.

As part of the harness GA cutover, the create experience is harness-first. This message should lead with add harness.

Change

One file — src/cli/tui/screens/create/CreateScreen.tsx (the existing-project-error phase). The message now reads:

A project already exists at this location.
Found: <path>

Use add harness to add a harness to the existing project.
Or use add agent to add a code-based agent.

Unconditional — no isPreviewEnabled() branch — matching the post-merge GA state where there's a single CLI and harness is a first-class create option. This is consistent with the harness-first voice already used in the create-type picker in the same screen (Harness (recommended)).

This is the only place this message exists; the CLI flag path (validate.ts) only checks folder-name collisions and has no equivalent message.

Addresses the "harness-first language" action item (#4) in the Harness GA plan.

⚠️ Ordering dependency

add harness is still preview-gated today:

// src/cli/primitives/registry.ts
export const harnessPrimitive = isPreviewEnabled() ? new HarnessPrimitive() : undefined;

This message is only correct once harness is ungated for all builds — i.e. it must land with or after the __PREVIEW__ / isPreviewEnabled removal work. It should not ship to the latest npm tag before that gating is removed, or a GA build would point users at an add harness command that doesn't exist in that build.

Testing

• npm run typecheck ✅
• eslint (pre-commit) ✅ / prettier ✅
• create.test.ts — 16/16 pass
• Rendered live in the TUI harness on a preview build (target state): both lines display correctly when running create from inside an existing project.

[agentcore-devx-automation]

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

[github-actions]

Package Tarball

aws-agentcore-0.20.1.tgz

How to install

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

[github-actions]

Coverage Report

Status	Category	Percentage	Covered / Total
🔵	Lines	36.92%	13501 / 36559
🔵	Statements	36.21%	14356 / 39642
🔵	Functions	31.49%	2310 / 7335
🔵	Branches	30.69%	8917 / 29052

Generated in workflow #3724 for commit 6891012 by the Vitest Coverage Report Action

[agentcore-cli-automation]

Tiny, focused message change — implementation is correct. My only concern is the ordering dependency you've flagged in the PR description: the PR points users at add harness unconditionally, but on main that command is still preview-gated, and a release from main runs npm run build (not build:preview) so __PREVIEW__ = false and harnessPrimitive ends up undefined (registry.ts:26). A GA user hitting the existing-project-error screen would be told to run a command that isn't registered in their build. Left an inline comment with options.

[agentcore-cli-automation]

The PR description correctly calls out that this is only safe once add harness is ungated, but the change as written doesn't enforce that — the message renders the same regardless of __PREVIEW__. Today on main:

• src/cli/primitives/registry.ts:26 — harnessPrimitive = isPreviewEnabled() ? new HarnessPrimitive() : undefined
• src/cli/cli.ts:131-132 only registers commands for primitives in ALL_PRIMITIVES, so add harness is not registered in GA builds
• .github/workflows/release.yml runs npm run build (GA, __PREVIEW__ = false) when releasing from main to npm latest

So if this PR merges to main and a latest release happens before harness is ungated, GA users will land on the existing-project-error screen, follow the instruction to run agentcore add harness, and hit error: 'harness' is not a valid subcommand.

A few ways to address:

1. Gate the message on isPreviewEnabled() — show the new harness-first wording only in preview builds, keep the existing "Use add agent…" wording in GA. When the harness ungating PR lands and removes isPreviewEnabled() from registry.ts, it can also remove this branch and leave just the new message. Most defensive option, makes this PR independently safe to merge.
2. Hold the PR and merge it as part of (or immediately after) the harness ungating PR, with a release-branch coordination so a latest build never goes out with this message but without add harness registered.
3. Add a guard at registration time so the message is sourced from whether harnessPrimitive is defined (e.g. import harnessPrimitive and conditionally render the harness line). Same effect as option 1 but keyed off the actual registration rather than the build flag.

Option 1 or 3 would let this land independently of release sequencing.