Skip to content

feat: support imperative eval recommendation command - #2111

Merged
jariy17 merged 3 commits into
refactorfrom
eval-recommendation
Aug 27, 2026
Merged

feat: support imperative eval recommendation command#2111
jariy17 merged 3 commits into
refactorfrom
eval-recommendation

Conversation

@nborges-aws

Copy link
Copy Markdown
Contributor

Description

Adds imperative command-line support for AgentCore evaluation recommendations:

  • eval recommendation start
  • eval recommendation get
  • eval recommendation list
  • eval recommendation delete

Summary of Changes

  • Supports SYSTEM_PROMPT_RECOMMENDATION and TOOL_DESCRIPTION_RECOMMENDATION recommendation types
  • start accepts recommendation configuration as inline JSON, a file:// path, or stdin (-) through SourceResolver class
  • Supports the service API fields for description, KMS key ARN, and tags
  • Adds the recommendation operations to EvalClient, the shared handler types, and TestCoreClient
  • Adds recorded golden fixtures covering the complete start, get, list, and delete flow

Type of Change

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

Testing

How have you tested the change?

Added unit tests and golden fixture tests exercising recommendation logic.

  • bun run test (2052 pass, 0 fail)
  • 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.

description: "get a recommendation by id",
flags: [flag("id", "the ID of the recommendation", z.string().optional())],
handle: async (ctx, flags) => {
if (!flags["id"]) throw new InputValidationError("required option '--id <id>' not specified");

@jariy17 jariy17 Aug 26, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we can definitely abstracted this so we have a common error message for this type of thing. OBO

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah I think marking flags as required and supporting it directly in the framework would be ideal, but likely OOS here.

Comment thread src/core/eval.tsx Outdated
}

async startRecommendation(
request: StartRecommendationRequest,

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We create our own types here because handlers define the interface for the core client. Even if it's a one-to-one mapping, we should still define our own type.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sure will update

Comment thread src/core/recommendation.test.tsx Outdated
@@ -0,0 +1,119 @@
import { describe, expect, test } from "bun:test";

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We don't need this. Use Golden tests please

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

are the handler tests sufficient? I think these are testing the same things at a lower level.

flag("tags", "tags as key=value (repeatable) or JSON object", z.array(z.string()).optional()),
],
handle: async (ctx, flags) => {
if (!flags["name"]) {

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

const requiredFlags: Array<[string, string]> = [
  ["name", "--name <name>"],
  ["type", "--type <type>"],
  ["recommendation-config", "--recommendation-config <recommendation-config>"],
];

for (const [key, usage] of requiredFlags) {
  if (!flags[key]) {
    throw new InputValidationError(`required option '${usage}' not specified`);
  }
}

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: we should use something like this.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure will add something like this

return call.args;
}

describe("eval recommendation command hierarchy", () => {

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

do we need these tests?

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1, I've seen these tests in other places, but they feel pretty low value. The tests on the handlers would fail if the hierarchy is incorrect. Also, what coverage do we get on the tests below that we don't get on the fixture based tests?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I added these tests to cover behavior the fixtures don't exercise. E.g. malformed json, exercising source resolver, etc. But consensus is against unit test so I've removed this + the other one entirely

description: "get a recommendation by id",
flags: [flag("id", "the ID of the recommendation", z.string().optional())],
handle: async (ctx, flags) => {
if (!flags["id"]) throw new InputValidationError("required option '--id <id>' not specified");

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah I think marking flags as required and supporting it directly in the framework would be ideal, but likely OOS here.

return (error as Error).name === "ResourceNotFoundException";
}

async function waitForTerminal(

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is there a way to leverage

export async function waitFor(
for these?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good call out I'll switch to use this util

return call.args;
}

describe("eval recommendation command hierarchy", () => {

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1, I've seen these tests in other places, but they feel pretty low value. The tests on the handlers would fail if the hierarchy is incorrect. Also, what coverage do we get on the tests below that we don't get on the fixture based tests?

status: "PENDING",
createdAt: new Date("2026-08-26T12:00:00.000Z"),
updatedAt: new Date("2026-08-26T12:00:00.000Z"),
} as StartRecommendationResponse;

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why do we need to cast here?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

N/A since test file was removed altogether

Comment thread src/core/recommendation.test.tsx Outdated
@@ -0,0 +1,119 @@
import { describe, expect, test } from "bun:test";

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

are the handler tests sufficient? I think these are testing the same things at a lower level.

@github-actions github-actions Bot added the size/l PR size: L label Aug 27, 2026
@agentcore-devx-automation agentcore-devx-automation Bot added the claude-security-reviewing Claude Code /security-review in progress label Aug 27, 2026
@agentcore-devx-automation

Copy link
Copy Markdown
Contributor

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

@agentcore-devx-automation agentcore-devx-automation Bot removed the claude-security-reviewing Claude Code /security-review in progress label Aug 27, 2026
@codecov-commenter

Copy link
Copy Markdown

Codecov Report

❌ Patch coverage is 97.70115% with 4 lines in your changes missing coverage. Please review.
✅ Project coverage is 97.41%. Comparing base (a1f2f32) to head (2783292).

Files with missing lines Patch % Lines
src/handlers/eval/recommendation/start/index.tsx 94.20% 4 Missing ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##           refactor    #2111    +/-   ##
==========================================
  Coverage     97.41%   97.41%            
==========================================
  Files           453      458     +5     
  Lines         27637    27810   +173     
==========================================
+ Hits          26922    27091   +169     
- Misses          715      719     +4     

☔ 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.

@jariy17
jariy17 merged commit c105d4f into refactor Aug 27, 2026
22 checks passed
@jariy17
jariy17 deleted the eval-recommendation branch August 27, 2026 16:29
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

size/l PR size: L

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants