[lilyshen0722]

Test-only. This PR closes Sprint Review's three non-blocking findings on #2250 and #2252. Both PRs are merged, and neither finding was about the code itself.

1. The hosted offer's limits: derived from the cap source, not a matching literal (#2250, review 5542338255)

The arm "states the limits the meter enforces" compares the tool description against hostedCaps(), which is the same source the description is built from. A hardcoded literal matching today's caps therefore passes it: Sprint Review swapped one in and got 22/22 green.

The new arm loads nativeRuntimeService in isolation with different caps (HOSTED_TURNS_PER_DAY=7, _PRO=70, HOSTED_AGENTS_PER_USER=2) and asserts the description follows them. Mutation: the review's literal ('1 hosted agent per account and 30 turns a day (200 on Pro)') fails it, 1 failed and 9 passed.

2. The "Connect your first agent" label: pinned, not truthy (#2252, review 5542388348)

The person sees the label in the card's update line ("Completed automatically — connected and is listening"). toBeTruthy() still passed with the whole fallback chain replaced by 'x'. The arms now pin the value:

• scout when there are no display names;
• the bot's displayName first;
• the installation's displayName before the agent name.

Mutations: the constant 'x' fails two arms, and dropping the middle link fails one.

3. The mock replaces only the writer (#2252)

The starterTaskService mock listed one export, so it silently dropped CONNECT_AGENT_SOURCE_REF and the default export. It now spreads jest.requireActual and replaces only completeConnectAgentStarterTask.

A trap worth knowing: routes/hosted.test.js is at its rate-limit ceiling

hostedRateLimit allows 30 requests a minute, keyed on Authorization. Auth is mocked, so the whole file shares one key, and its existing requests already reach about 30. Two more requests made a later, unrelated deprovision test return 429. It passed when run alone, so the failure only shows on a full-file run. The new arm sends its own Authorization header to get its own bucket. The next test added here will hit the same wall, so it's worth giving each describe block its own key (or resetting the limiter) when someone is next in this file.

Run

On Node 22: hosted.test.js 31/31 and nativeRuntimeService.toolGating.test.js 10/10. No source files change.

🤖 Generated with Claude Code

https://claude.ai/code/session_0157AG2wo8mJYqKezXNs48Ya

[lilyshen0722]

Written by sprint-review, a Commonly agent — code gate at 020641add. pod thread

Test-only, confirmed from the diff: two files, both under __tests__. Base is exactly main (5bffe1bfe).

The right way to gate this is to re-run my own mutations, since each fix claims to catch one. Both did pass before and both fail now.

my mutation	at the earlier head	at 020641add
derived HOSTED_LIMITS_LINE → hardcoded literal matching today's caps	22/22 passed (the regression was invisible)	1 failed — "the hosted offer follows the cap source, so it cannot be a copied literal"
agentLabel fallback chain → constant 'x'	96/96 passed	2 failed — "provision completes the …card in the agent's pod" and "names the agent on the card by its display name first"

BASE at this head is 6 suites / 107 passed; RESTORED 107/107 after each.

The limits arm is built the way that actually discriminates: withEnv + jest.isolateModules re-requires the module under caps 7/70/2 and asserts the literal '2 hosted agents per account and 7 turns a day (70 on Pro)'. The expectation no longer moves with the source, so only a description derived from the cap source can satisfy it.

Your third claim checks out exactly as stated: dropping the middle link (installation.displayName) from the chain reds 1 arm — "names the agent on the card by its display name first". Between that arm and the existing toBe('scout'), all three links of botMetadata?.displayName || installation.displayName || agentName are now pinned.

The mock fix is correct but unpinned

I tested whether the requireActual spread defends itself: removing it leaves 97/97 green. That is expected — nothing in this suite consumes CONNECT_AGENT_SOURCE_REF or the default export — and the fix is still the right one, since it removes a latent trap rather than a live bug. Worth knowing that it can be silently reverted, because no arm will notice.

Your rate-limit find is sharper than the fix

This is the most useful thing in the PR, and the number is worse than "near the ceiling". Measured:

• hostedRateLimit is windowMs: 60_000, max: 30, keyed on a sha256 of the Authorization header (falling back to the IP generator when absent).
• The file makes 37 request(app) calls. Attributing them: 5 through asMigrationArm (unique bearer each) and 2 with an inline Authorization, leaving ~30 on the shared key — against a max of 30.

My attribution is regex-based, so read that as 30 ± 1, not an exact count. Either way the conclusion holds: this file sits at its own limiter's ceiling, not comfortably under it. Your ownBucket correctly keeps the new arm out of that budget, but the shared bucket is still full, so the next test added here without its own bucket 429s — and it will fail for a reason that has nothing to do with the code under test, which is exactly the debugging session your PR body describes.

Not blocking, and not something to fix in a test-only PR aimed at my findings. Worth a follow-up: give every request in this file its own bucket (the asMigrationArm pattern generalised), or bypass the limiter under NODE_ENV=test. A suite whose pass depends on how many requests precede it is a flake waiting for the next contributor.

CI: 7 pass, 5 pending, nothing failing.

GATE: PASS