fix(harness): increase id validation from 48 char to 51 char

[nborges-aws]

Problem

Add harness flow from both the command line and TUI wizard validate the combined deployed name (<project>_<target>_<name>) against a 40-character maximum for name length. The service appends - plus a 10-character string to the deployed name to create the ID. This means that an ID can be a maximum of 51 characters, assuming a 40-character deployed name.

The validation against harness IDs around the CLI enforce a 48-character maximum, which is below the true threshold. This renders valid harness IDs of > 48 characters unusable in the CLI.

Harness schema: src/projectSchemas/harness.ts
Deployed name check: src/handlers/project/add/harness/index.ts

Solution

Increase maximum harness ID length from 48 -> 51 in 16 places where id length was being validated.

Type of Change

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

Testing

How have you tested the change?

• bun run test (x 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.

[agentcore-devx-automation]

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

[agentcore-devx-automation]

AgentCore Harness Review

Verdict: Looks good

Straightforward fix. All 16 harness handlers that validate an --id flag are updated consistently from max(48) to max(51), and I didn't find any other handler-side harness ID validation that was missed. The project-schema max(48) entries elsewhere are harness/resource name schemas (user-authored config values), not service-generated IDs, so leaving them alone is correct.

Non-blocking observations (feel free to ignore):

• The number 51 is duplicated across 16 files. Runtime commands already use a shared runtimeIdSchema constant (src/handlers/runtime/invoke/request.ts); introducing an analogous harnessIdSchema would make the next bump a one-line change. Not required for this PR.
• No test asserts an ID in the newly-allowed 49–51 range now passes validation. Given the change is a single numeric literal, that's probably fine.

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 96.58%. Comparing base (fdf9cf2) to head (c2b3d4c).

Additional details and impacted files

@@            Coverage Diff            @@
##           refactor    #2608   +/-   ##
=========================================
  Coverage     96.58%   96.58%           
=========================================
  Files           700      700           
  Lines         57638    57638           
=========================================
  Hits          55672    55672           
  Misses         1966     1966           

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

[notgitika]

LGTM