feat(project): add project-aware invoke

[aidandaly24]

Description

Add agentcore project invoke for Runtimes and Harnesses declared by the project enclosing the current directory.

• resolve logical project resources to deployed IDs through the selected project backend and deployment target
• invoke project Runtimes with the template contract {"prompt": content}
• render Strands Runtime SSE contentBlockDelta events as streaming assistant text in headless and prompt-TUI invocation
• fail incomplete Strands streams when AgentCore emits an SSE error frame
• pass unsupported SSE through without buffering the complete response
• preserve exact Runtime wire responses with --json
• invoke project Harnesses with the existing user-message and transcript contract
• reuse the existing Runtime and Harness transports instead of introducing a third invoke path
• launch the existing interactive experiences when content is omitted
• add a Runtime prompt input mode while preserving direct Runtime JSON-console behavior
• document project invoke in the CLI and generated Runtime templates

Gateway project invoke and non-Strands response adapters are intentionally outside this PR.

The required refactor dependencies have landed:

• feat(templates): support rendering strands http template.  #2099 for the filtered Strands Runtime template event contract
• feat: persist minimal deploy state to deployed-state.json #2105 for the per-target deployed stack ARN
• feat: read project stack state live from CloudFormation #2112 for live CloudFormation stack reads

Related Issue

N/A

Documentation PR

N/A - documentation is included.

Type of Change

• Bug fix
• New feature
• Breaking change
• Documentation update
• Other

Testing

• bun test src: 2274 pass, 0 fail
• focused Inspector, project event parser/invoke, Runtime prompt response, and Runtime TUI suites:
  133 pass, 0 fail
• bun run typecheck
• bun run lint:check
• bun run format:check
• bun run secrets:check
• bun run build
• git diff --check

Live verification in account 603141041947, region us-west-2, using the retained InvokeMatrix827 project:

• root help exposes the project-only invoke shorthand while direct Runtime and Gateway invokes remain registered
• bare agentcore invoke showed type/name/protocol/source for ambiguous project Runtime/Harness rows and delegated each selection to its existing TUI
• a project Runtime with one live endpoint auto-opened; multiple endpoints remain in the qualifier picker
• top-level invoke outside a project failed before any Runtime or Harness service call
• picker-to-invoke transitions retained the same PTY process and alternate-screen buffer with no terminal flash
• project Runtime headless invoke returned exactly PROJECT_RUNTIME_FIXED_OK without SSE framing
• rendered Runtime output terminates before the status summary instead of joining response and status=...
• project Harness headless invoke returned PROJECT_HARNESS_FIXED_OK with end_turn
• the 120x40 TUI harness captured PROJECT_TUI_HARNESS_OK while the Runtime response was still streaming…
• the settled TUI frame reported complete · 22 bytes and returned to Ready
• the Runtime TUI leaves one blank row between the request payload and bold Response · ... heading
• the Harness TUI returned PROJECT_HARNESS_TUI_OK, end_turn, and a reusable session prompt

Checklist

• I have added tests that prove the feature works
• I have updated relevant documentation
• I have verified direct Runtime, Harness, and Gateway behavior remains green
• I have run live deployment and TUI verification
• Dependent changes have been merged and published

[agentcore-devx-automation]

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

[codecov-commenter]

Codecov Report

❌ Patch coverage is 96.97368% with 23 lines in your changes missing coverage. Please review.
✅ Project coverage is 97.22%. Comparing base (059e1a5) to head (54fc894).

Files with missing lines	Patch %	Lines
src/handlers/runtime/invoke/promptResponse.ts	89.10%	11 Missing ⚠️
src/handlers/project/invoke/index.tsx	96.65%	7 Missing ⚠️
src/handlers/project/invoke/screen.tsx	96.55%	5 Missing ⚠️

Additional details and impacted files

@@             Coverage Diff              @@
##           refactor    #2115      +/-   ##
============================================
- Coverage     97.24%   97.22%   -0.02%     
============================================
  Files           471      478       +7     
  Lines         28911    29593     +682     
============================================
+ Hits          28114    28773     +659     
- Misses          797      820      +23     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[agentcore-devx-automation]

AgentCore Harness Review

Verdict: Looks good

Nice split: the shared invokeRuntimeTarget / invokeHarnessTurn helpers cleanly refactor the existing handlers into reusable operations, the new project-level invoke composes those without duplication, and the resolveDeployedResource layering (manager → backend → deployment helpers) is easy to follow. Tests use real temp dirs + fake backends, and only mock at true I/O boundaries (readStack, per the guidelines).

One thing worth double-checking before this fully lights up end-to-end:

• src/core/project/backends/cdk/deployment.ts:28 looks up harnesses by CloudFormation export name ${stackName}-Harness-${resourceName}-Id. Scanning agentcore-l3-cdk-constructs, the harness constructs (AgentCoreHarnessEnvironment, AgentCoreHarnessRole, AgentCoreApplication) currently only emit Harness-<name>-RoleArn and Harness-<name>-ImageUri outputs — no Harness-<name>-Id. Runtime lookup will work today (AgentEnvironment.ts emits <agentName>-RuntimeId), but agentcore invoke --harness ... will always fail with the "not deployed" error until the L3 emits that export. If a coordinated L3 change is in flight this is fine; if not, this handler and its export-name contract will need to land together with the construct change (and ideally the runtime path in AgentEnvironment.ts should probably also be prefixed like -Runtime-<name>-Id for symmetry with Harness-<name>-Id, but that's a naming choice).

Not blocking — tests all pass with a fake backend, and if the harness export is a known follow-up this is just a heads-up. Everything else (validation, mutual-exclusion, --json requiring content, session-id length rule, bearer-token restricted to runtime, TUI launch with inputMode: "prompt", region override from the resolved target) reads correctly.

[agentcore-devx-automation]

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

[agentcore-devx-automation]

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

[agentcore-devx-automation]

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

[agentcore-devx-automation]

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

[agentcore-devx-automation]

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