Every Rippling and Okta tool that interpolates an LLM-writable ID into its
request path now routes it through `safeUrlPathSegment` instead of a bare
`encodeURIComponent`.

`encodeURIComponent` is not sufficient. `.` and `..` are unreserved
characters, so `encodeURIComponent('..')` returns `'..'` verbatim, and the
WHATWG URL parser that `fetch` uses removes dot segments *after* decoding —
so `%2e%2e` is popped too. Only rejecting the value works:

    new URL('https://rest.ripplingapis.com/users/../workers/x').pathname
    // => '/workers/x'

Because these IDs are `visibility: 'user-or-llm'`, prompt injection controls
them, and a popped segment re-aims an authenticated request — the workspace's
Rippling bearer token or the org's Okta SSWS token still attached — at a
different resource, including on DELETE and on the Okta lifecycle endpoints
that deactivate a user or clear their sessions.

105 call sites across 88 tools are hardened, plus the server-side
`okta_update_group` read-modify-write in `lib/internal/okta/operations`,
whose `groupId` builds the URL for both the read and the `PUT`.

Two new suites enumerate the tools from their barrels, so a newly added
unguarded path param fails CI rather than shipping. Every assertion resolves
the built URL with `new URL(...)` — the same normalization `fetch` performs —
rather than string-matching the template output, because string matching is
what let this through. A `LEGITIMATE_IDS` list proves real Rippling UUIDs,
custom-object API names, Okta `00u…`/`00g…`/`0oa…` IDs, and email logins pass
through unchanged; no param visibility, subBlock ID, or behaviour for
legitimate input changes.

This is one batch of a larger path-safety sweep across the integration
catalog.

…a time

The suites enumerated tools and filled every string param with the same fuzz
value, then swallowed the throw:

    try { path = buildPath(tool, value) } catch { return }

So the first guarded param aborted the case and every sibling silently
stopped being tested. The reported "a new unguarded param fails CI" property
did not hold for any tool that already had one guard.

That is the common shape here, not an edge case: 15 of these tools put two
IDs in one path (`groupId` + `userId`, `appId` + `groupId`, `userId` +
`factorId`, `customObjectApiName` + `fieldApiName`, …). Reverting
`okta_remove_user_from_group`'s `userId` guard produced ZERO failures under
the old suite, because `groupId` is interpolated first and threw.

Both suites now enumerate (tool, param) pairs — 61 Rippling, 43 Okta,
accounting for every in-tool call site — and fuzz exactly one param while
each sibling holds its own distinct sentinel. Distinct sentinels are what
make a two-ID path attributable; one shared value would let a guard on
either param look like coverage of both. Two new assertions pin the
property: the pair count, and an explicit check that each two-ID tool
contributes two pairs.

The same revert now fails 5 assertions, all scoped to
`okta_remove_user_from_group / userId`, with the sibling `groupId` pair
still green.

No production code changes. The `okta_update_group` block is unchanged — it
already asserted the URL actually requested.

Both harnesses carried `type AnyTool = ToolConfig<any, any>` and a matching
`as any` on the `url(...)` call — inherited from the landed Vercel harness
they were modelled on, and flagged P2 on sibling PRs. CLAUDE.md is explicit:
no `any`.

The obvious replacement does not compile. `Object.values` over a barrel
yields a union across every member, and `ToolConfig` puts its param type in
the contravariant position of `request.url`, so no specific member is
assignable to a widened `ToolConfig<Record<string, unknown>, ToolResponse>`;
a bare `.filter` with a type guard intersects rather than replaces and leaves
the errors in place.

The barrel is therefore seeded as `Object.values<unknown>(...)`, which makes
the existing `isRipplingTool` / `isOktaTool` predicate the single narrowing
point — the `unknown` + type-guard form CLAUDE.md prescribes — and keeps a
cast out of every call site. `buildParams` returns `Record<string, unknown>`,
so `url(...)` needs no cast at all. A TSDoc block on each seed records why.

The `okta_update_group` block asserts a stubbed fetch rather than a
`ToolConfig`, so it never needed the alias; its two `as never` casts are gone
too, replaced by a declared `OktaUpdateGroupParams` and a typed mock
signature, which is what makes `mock.calls[0][0]` resolve.

Verified with a temporary tsconfig overriding `exclude`, then deleted:
`apps/sim/tsconfig.json` excludes `**/*.test.ts`, so `bun run type-check`
does not cover these files and CI would not have caught the errors this
change fixes. Zero behavioural effect — 2723 tests still pass.

cubic's P3 was right: the `covers both IDs on every two-ID path` guard
listed only 2 of Rippling's 7 two-ID tools, so a regression that dropped
`codrId` or `externalId` from `PATH_PARAM_PAIRS` would still pass it — the
`>= 60` floor is far too loose to notice a handful of missing pairs.

The Rippling list now names all 7. Okta's list was already complete at 8,
but both files were relying on a hand-maintained literal that nothing
forced to stay in sync with reality — exactly the defect one level up.

So each suite also gains a `names every tool that interpolates two guarded
params` assertion that derives the two-ID set from `PATH_PARAM_PAIRS` and
compares it to the expected list with `toEqual`. That fails in both
directions: a tool that stops contributing two pairs, and a newly added
two-ID tool nobody listed.

Verified both guards actually fail by simulating the drift cubic
described — truncating `rippling_get_custom_object_record` to a single
pair turns both assertions red.

2723 -> 2725 tests. No production code changes.

Rippling: `purchase_order__c`, `amount__c`, and `procurement__c` replace three
invented API names. They come from Rippling's published OpenAPI document at
`developer.rippling.com/docs/rest-beta.yaml`, which I fetched and checked
(776,028 bytes, HTTP 200). The `__c` suffix is the part worth pinning — the
invented names did not have it, so the suite was not exercising the shape
Rippling actually documents. That same document contains no `pattern:`
constraint anywhere (verified: grep count 0), so Rippling publishes no
character set for IDs at all, and the TSDoc now says so.

Okta: the ID list is unchanged, and its TSDoc now states plainly that these
are realistic shapes rather than quoted documentation, because Okta's
published parameter descriptions type every ID as a bare `string`.

It also records a genuine open question rather than burying it. The previous
`encodeURIComponent` emitted `%2F` for a login containing `/`, and `%2F`
survives URL normalization intact — `/api/v1/users/a%2Fb` stays one segment.
`safeUrlPathSegment` refuses that value instead. So for the nine `{id}`
endpoints documented as accepting "An ID, login, or login shortname", a
`/`-bearing login that Okta may previously have resolved is now rejected.
Whether Okta ever resolved it could not be confirmed from any reachable
source.

Deliberately not worked around. `%2F` is not itself a traversal vector —
only literal `.`/`..` and their percent-encoded spellings are removed by the
parser, which I verified directly — so the separator check is defense in
depth, not the load-bearing half of the fix, and it lives in shared
`@/tools/url-path` consumed by every integration. Narrowing it is that
module's decision, not one to make from the Okta tools.

No production code changes.

…nown

The previous commit recorded the `/`-bearing-login case as an unresolved
open question, on the grounds that no reachable Okta source addressed it.
That was wrong, and the note is now a documented fact with a line reference.

Okta's OpenAPI description for `GET /api/v1/users/{id}` says:

  "When fetching a user by `login` or `login shortname`, URL encode the
  request parameter to ensure that special characters are escaped properly.
  Logins with a `/` character can only be fetched by `id` due to URL issues
  with escaping the `/` character."

Percent-encoding is exactly what the old `encodeURIComponent` did, and
exactly what Okta documents as not working. So refusing the value is not a
lost capability — the old code produced a request Okta cannot serve, and a
named error beats the 404 it earned.

The text is genuinely hard to reach, which is what made it look absent: the
developer portal renders those pages client-side and returns an empty shell
to a plain fetch, and the generated SDK markdown carries only the parameter
descriptions, not the operation description that holds this sentence. It
survives only in the OpenAPI document the official Go SDK is generated from
— `okta/okta-sdk-golang`,
`.generator/okta-management-APIs-oasv3-noEnums-inheritance.yaml` (HTTP 200,
2,258,877 bytes), line 22166, under the path declared at line 22154.

No production code changes.