fix(dev): skip redundant deploy when TUI deploy already succeeded

[jesseturner21]

Summary

• Bug: After deploying a harness project via the interactive TUI (agentcore deploy), running agentcore dev would always redeploy even with no changes
• Root cause: The TUI deploy flow (useDeployFlow.ts) wrote deployed state but never stored the deployHash. When agentcore dev called canSkipDeploy, the stored hash was undefined, so the hash comparison always failed.
• Fix: Compute and store deployHash in the TUI deploy flow after buildDeployedState, matching the existing behavior in handleDeploy (used by the CLI -y path)

Test plan

• npm run build passes
• All 214 deploy-related unit tests pass
• Pre-commit hooks (eslint, prettier, typecheck, secretlint) pass
• Manual: create harness project → agentcore deploy (TUI) → agentcore dev → verify "No changes detected — skipping deploy" message appears
• Manual: create harness project → agentcore deploy (TUI) → modify harness.json → agentcore dev → verify deploy triggers

[agentcore-devx-automation]

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

[github-actions]

Package Tarball

aws-agentcore-0.15.0.tgz

How to install

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

[github-actions]

Coverage Report

Status	Category	Percentage	Covered / Total
🔵	Lines	35%	10665 / 30463
🔵	Statements	34.35%	11328 / 32970
🔵	Functions	29.97%	1808 / 6032
🔵	Branches	28.99%	6730 / 23212

Generated in workflow #3327 for commit ac693a1 by the Vitest Coverage Report Action

[agentcore-cli-automation]

Reviewed the fix end-to-end against the existing actions.ts (CLI -y) path and the canSkipDeploy/computeProjectDeployHash implementations.

The change is small, focused, and correct:

• The deployHash is computed and assigned to targetState.resources.deployHash before writeDeployedState (line 349), mirroring the behavior in src/cli/commands/deploy/actions.ts (lines 551–584).
• All subsequent post-deploy writeDeployedState calls in useDeployFlow.ts (lines 368, 448, 507, 538, 579) use the read-modify-write pattern against the on-disk state, so they preserve the deployHash written at line 349.
• buildDeployedState rebuilds targetState.resources fresh and does not carry forward deployHash from existingState, so the explicit assignment after buildDeployedState is necessary and correct.
• The try/catch making hash computation best-effort matches the existing pattern in actions.ts.
• canSkipDeploy is gated on projectSpec.runtimes.length === 0, so this only takes effect for harness-only projects, which is what the bug report describes.

Two non-blocking observations (not requesting changes):

1. useDeployFlow.ts still has no unit/integration test file, so this fix isn't covered by an automated test. The new logic is small and structurally identical to the tested actions.ts path, so I don't think a test is required to land this — but useDeployFlow is getting large and is now silently relied on by the dev-deploy skip behavior. Worth considering follow-up coverage.
2. Minor stylistic difference vs. actions.ts: there, the hash is computed before buildDeployedState; here it's computed after. Functionally equivalent (buildDeployedState doesn't touch any of the hashed files), so not worth changing.

LGTM.