fix(tui): gate imperative mutations and execution screens

[aidandaly24]

Description

Prevent standalone mutation and execution screens from bypassing imperative-commands through project status or nested TUI navigation. The TUI now checks registered commands before mounting those screens and hides unavailable actions, restoring them when enabled. Project invocation and read-only inspection remain available, but project chat cannot switch into exec mode or select an account-wide Runtime while the flag is off.

Related Issue

Refs #2400. Follow-up to #2396; separate from #2401 and #2402.

Documentation PR

Not applicable: this makes the existing internal feature gate consistent across CLI and TUI entry points.

Type of Change

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

Testing

3,614 tests passed with 98.00% line coverage. Focused regressions cover disabled routes, action visibility, project CLI-to-TUI invocation, shell handoff, and project Runtime target switching. Existing menu/help tests and resource fixtures are reused instead of duplicated.

Test-process-only fault injection confirmed the retained tests fail when route gating, the exec toggle guard, or Runtime target restrictions are bypassed. Production code is unchanged by this test consolidation.

The built Node CLI was also checked with the TUI harness against an existing deployed project: Harness and Runtime execution actions disappear with the flag off and return with it on; read-only navigation and Escape back to status remain functional. This live check was read-only.

• I ran bun test
• I ran the relevant end-to-end tests with bun run test:e2e, or explained why they are not applicable
• I ran bun run typecheck
• I ran bun run lint:check
• I ran bun run format:check
• I ran bun run build
• If I modified src/assets/, I updated affected snapshots with bun test <test-file> --update-snapshots and committed them

AWS deployment E2E tests are not applicable: no deployment logic or SDK request semantics changed. Execution gates were tested through the real CLI/Root with injected Core clients. No assets changed.

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

Nice piece of defense-in-depth. The CommandGate sits above the imperative screens so an unavailable command can't mount its screen and fire off get*/list*/invoke* before Root has a chance to redirect. A few things I verified while reviewing:

• resolveCommand walking down from the root and comparing against commandPath(command).join("/") correctly returns false when any ancestor group (e.g. runtime) is pruned by imperative-commands, so isCommandAvailable is sound both for the gate and for the action filters in harness/get, runtime/get, and runtime/endpoint/get.
• The isProjectInvoke carve-out is scoped tightly (3-segment path, child location, harness|runtime, launcher rooted at agentcore/invoke/<family>), so a project-invoke launch cannot smuggle access into harness/exec/:id, runtime/shell/:id, harness/update/:id, etc. The new tests in CommandGate.test.tsx cover that surface (including the negative cases across siblings/verbs).
• GatewayCreateScreen's added gateway.name() === "gateway" guard prevents the CLI-help fallback from firing when resolveCommand truncates to the agentcore root — the ProjectResourceCreateScreen guidance is what shows instead, and it does no I/O.
• Read-only siblings (harness/runtime/gateway/memory get/list/version/endpoint) intentionally remain ungated, and there's explicit coverage that they still hit Core with the parent group off.
• Runtime create / memory create / gateway create routes don't need a gate because their route elements are informational-only (ProjectResourceCreateScreen / gateway-create branch), which the tests confirm.

No blockers.

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 97.25%. Comparing base (7d8f74d) to head (51d9436).
⚠️ Report is 3 commits behind head on refactor.

Additional details and impacted files

@@            Coverage Diff            @@
##           refactor    #2403   +/-   ##
=========================================
  Coverage     97.25%   97.25%           
=========================================
  Files           612      613    +1     
  Lines         41019    41032   +13     
=========================================
+ Hits          39893    39906   +13     
  Misses         1126     1126           

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

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