feat(project): add project-aware invoke - #2115
Conversation
|
Claude Security Review: no high-confidence findings. (run) |
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## refactor #2115 +/- ##
============================================
- Coverage 97.15% 97.14% -0.01%
============================================
Files 498 505 +7
Lines 33004 33555 +551
============================================
+ Hits 32065 32597 +532
- Misses 939 958 +19 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
There was a problem hiding this comment.
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:28looks up harnesses by CloudFormation export name${stackName}-Harness-${resourceName}-Id. Scanningagentcore-l3-cdk-constructs, the harness constructs (AgentCoreHarnessEnvironment,AgentCoreHarnessRole,AgentCoreApplication) currently only emitHarness-<name>-RoleArnandHarness-<name>-ImageUrioutputs — noHarness-<name>-Id. Runtime lookup will work today (AgentEnvironment.tsemits<agentName>-RuntimeId), butagentcore 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 inAgentEnvironment.tsshould probably also be prefixed like-Runtime-<name>-Idfor symmetry withHarness-<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.
f2c164c to
c6796be
Compare
|
Claude Security Review: no high-confidence findings. (run) |
|
Claude Security Review: no high-confidence findings. (run) |
|
Claude Security Review: no high-confidence findings. (run) |
|
Claude Security Review: no high-confidence findings. (run) |
|
Claude Security Review: no high-confidence findings. (run) |
AlexanderRichey
left a comment
There was a problem hiding this comment.
How does invoke work today? Do customers have to specify runtime or harness?
|
Claude Security Review: no high-confidence findings. (run) |
Hweinstock
left a comment
There was a problem hiding this comment.
Thanks for simplifying this one! Code looks good, few small things I noticed when playing around:
- the back doesn't seem to work on the invoke page. When i got to
project > invokein the TUI then pressesc, the TUI exits rather than goes back to the project commands. - I'm able to see resources that aren't yet deployed. if I click on them, I see, which isn't intuitive.
| @@ -122,6 +127,7 @@ type HarnessOptions = { | |||
| bootstrapError?: Error; | |||
| /** Whether CloudFormation still holds the target's stack. Defaults to present. */ | |||
| stackExists?: boolean; | |||
There was a problem hiding this comment.
would it always be true that stackExists represents whether stack is present?
| stack?: StackProbe; | ||
| resolveAccount?: AccountResolver; | ||
| loadBootstrapTemplate?: BootstrapTemplateLoader; | ||
| describeStack?: StackDescriber; |
There was a problem hiding this comment.
what exactly is the difference between StackProbe and StackDescriber?
There was a problem hiding this comment.
StackProbe just returns a boolean whereas StackDescriber returns the full stack. But you're right that it doesn't make much sense to have both of them. They should just share the existing underlying CFN reader/client.
| @@ -0,0 +1,48 @@ | |||
| import type { CoreOptions } from "../../../core/types"; | |||
There was a problem hiding this comment.
is this still breaking the dependency inversion by importing core from handlers? I see Alex approved, so perhaps this is an acceptable exception.
| │ ├── get # get an evaluator by id (type-agnostic) | ||
| │ ├── list # list evaluators (server-side paginated) | ||
| │ └── delete # delete an evaluator by id | ||
| ├── project # manage an AgentCore project |
There was a problem hiding this comment.
thanks for adding all of this!
|
Claude Security Review: no high-confidence findings. (run) |
|
Implemented the latest review feedback:
Verified with the full source suite ( |
Hweinstock
left a comment
There was a problem hiding this comment.
LGTM, thanks for addressing comments.
Noticed two small things, that could be future improvements.
When going to invoke in the TUI with no deployed resoruces, I see
No deployment targets are configured for project 'helloThere'. Add at least one to /local/home/hkobew/gh-repos/agentcore-cli/helloThere/agentcore/aws-targets.json, for example:
[{ "name": "default", "account": "111122223333", "region": "us-east-1" }]
I wonder if this should show something like "no invokable resources" rather than deploy error.
Also, I don't think this is specific to this PR but the invoke "resolving project" hangs when used outside of a project.

Description
Add project-aware invocation for Runtimes and Harnesses declared by the project enclosing the current directory.
agentcore project invokeas an interactive picker for deployed project Runtimes and Harnesses on the default targetagentcore project invoke runtime --name <name> --payload <payload>agentcore project invoke harness --name <name> --prompt <prompt>--nameto be omitted when the project declares exactly one resource of that typeThis PR intentionally does not define a project-specific Runtime payload or response contract. Runtime responses retain the existing raw invoke behavior, including raw SSE. Gateway project invoke remains outside this scope.
The project deployment prerequisites are already present on
refactor:Related Issue
N/A
Documentation PR
N/A - documentation is included.
Type of Change
Testing
bun test src:2560 pass, 0 fail70 pass, 0 failbun run typecheckbun run lint:checkbun run format:checkbun run secrets:checkbun run buildgit diff --checkLive verification in account
603141041947, regionus-west-2, using the retainedInvokeMatrix827project:--name, preserved the native raw SSE response, and returnedREBASED_RUNTIME_OK--name, preserved the transcript response, and returnedREBASED_HARNESS_OKChecklist