refactor(add): swap harness to accept project schema directly instead of api shape.

[Hweinstock]

Problem

The existing convention of mirroring API shapes has some issues.

• evaluators experience diverges significantly from the APIs. (ex. this single API is responsible for multiple resources in the project).
• for customers looking at their agentcore.json, its not obvious what flags to pass.
• complexity in rejecting unsupported API fields.
• does not extend well to supporting update/edit in the future.

Solution

swap to mirroring the schemas directly. This approach is simpler (removes ~300 lines of mapping code from harness) and will extend better to agentcore project resources that have diverged from the API.

mirroring the schemas with json blobs also reduces the amount of flags significantly.

The PR also ports the harness tests to their own file.

Testing

Existing Unit Tests ported over.

Helping screen becomes:

Usage: agentcore project add harness [options]

adds a harness to the current project

Options:
  --name <name>                                          the name of the harness
  --execution-role-arn <execution-role-arn>              IAM role the harness assumes; a default role is created when omitted
  --system-prompt <system-prompt>                        the agent's system prompt
  --model <model>                                        model configuration (JSON)
  --tools <tools>                                        tools available to the agent (JSON)
  --skills <skills>                                      skills available to the agent (JSON)
  --allowed-tools <allowed-tools...>                     tool allowlist patterns (e.g. * or @serverName/toolName)
  --memory <memory>                                      memory configuration (JSON)
  --truncation <truncation>                              context truncation configuration (JSON)
  --network-mode <network-mode>                          network mode for the harness environment (PUBLIC or VPC)
  --network-config <network-config>                      VPC network configuration (JSON)
  --lifecycle-config <lifecycle-config>                  lifecycle configuration (JSON)
  --session-storage-path <session-storage-path>          mount path for session storage
  --efs-access-points <efs-access-points>                EFS access point configurations (JSON)
  --s3-access-points <s3-access-points>                  S3 access point configurations (JSON)
  --environment-variables <environment-variables>        environment variables (JSON object of key/value strings)
  --container-uri <container-uri>                        ECR container image URI
  --authorizer-type <authorizer-type>                    inbound authorizer type (AWS_IAM or CUSTOM_JWT)
  --authorizer-configuration <authorizer-configuration>  inbound authorizer configuration (JSON)
  --max-iterations <max-iterations>                      max agent loop iterations per invocation
  --max-tokens <max-tokens>                              max total output tokens per invocation
  --timeout-seconds <timeout-seconds>                    max duration in seconds per invocation
  --tags <tags>                                          tags to apply (JSON object of key/value strings)
  --dockerfile <dockerfile>                              path to local dockerfile to use as the container image for the harness
  -h, --help                                             display help for command

Notes

This does introduce a discoverability gap where customers need to know our project schemas, which means we'll need solid documentation here.

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 97.09%. Comparing base (33e2d2f) to head (2af765c).

Additional details and impacted files

@@             Coverage Diff              @@
##           refactor    #2034      +/-   ##
============================================
- Coverage     97.14%   97.09%   -0.05%     
============================================
  Files           382      382              
  Lines         22884    22581     -303     
============================================
- Hits          22231    21926     -305     
- Misses          653      655       +2     

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

nit: Make it into a CONST

[jariy17]

3. Tags differ from the shared convention

This command currently accepts only:

  --tags '{"team":"ml","env":"prod"}'

Other refactor-branch commands use parseTags, allowing both:

  --tags team=ml env=prod
  --tags '{"team":"ml","env":"prod"}'

They declare the flag as z.array(z.string()).optional() and convert the values into Record<string, string> with parseTags.

Should we support both? Even though the flags don't match in the imperative one, we should keep the tag conventions the same between both.

[Hweinstock]

I think to be consistent, we should swap it.

[notgitika]

OOS for here but when I was playing around with it I noticed it didn't have a parameterized help like we see in harness create --help. The JSON-valued flags are otherwise difficult to construct.

the help should document the harness spec shapes specifically, since they differ from the API shapes used by harness create.

can we discuss having that as a future improvement?

[notgitika]

Could we add --connections here? HarnessSpecSchema supports it but this handler currently doesn't

[Hweinstock]

AFAICT this isn't used in the old CLI so I left it out.