feat(cli): transcend custom-functions push and list commands

[ecton-transcend]

Related Issues

• ref https://linear.app/transcend/issue/WAL-9270

Public Changelog

• Added: transcend custom-functions push — create and update Transcend custom function code revisions from a manifest file (transcend-functions.yml) in your own repository, designed to run on every CI push. Supports change detection (unchanged functions are skipped), draft + promote flows (--noPromote), --dryRun previews, --force for env-value rotations, --sombraAuth for self-hosted Sombra gateways, per-function Sombra gateways (sombra-id), and --updateManifest to record assigned function IDs back into the manifest.
• Added: transcend custom-functions list — list custom functions with their lifecycle state, active version, pending draft, and IDs.

Internal Changelog

• Added: manifest codec (io-ts) with variable templating and code-file loading, plus comment-preserving YAML write-back of assigned custom function IDs.

Part 2 of 3, stacked on #321 (the SDK helpers). Retarget to main after #321 merges.

Implementation details

Behavior

• push reads the manifest, signs each function's code against the customer ingress of the Sombra gateway the function belongs to (/v1/custom/sign), and saves the pre-signed JWTs via the GraphQL mutations. Entries are matched by id first when set, falling back to exact name; ambiguous names fail with an error listing candidate IDs.
• Functions in one manifest may belong to different Sombra gateways: the gateway per entry resolves as manifest sombra-id → existing function's gateway → --sombraId → primary, with one cached customer-ingress connection per distinct gateway. An entry that pins a different gateway than the existing function fails (a push cannot move functions between gateways). --sombraAuth provides the default internal key; entries whose self-hosted gateway uses a different key set sombra-auth-env to the name of an environment variable holding that gateway's key (the key itself never lives in the manifest).
• --sombraAuth takes the Sombra internal key (X-Sombra-Authorization), required when self-hosting Sombra — the same flag pattern as the existing request commands.
• --updateManifest writes assigned IDs back into the manifest via a comment-preserving YAML document edit (new yaml dependency, added to the pnpm catalog), so <<parameters.x>> secret placeholders and comments survive.
• list prints each function's ID, type, lifecycle state, active version, and pending draft.

Key files

• CLI command: packages/cli/src/commands/custom-functions/push/impl.ts
• Manifest codec + ID write-back: packages/cli/src/lib/custom-functions/manifest.ts

Dependencies / rollout

• Requires the Sombra customer-ingress /v1/custom/sign route from the backend pivot (#46175); --dryRun and list work without it.
• A composite GitHub Action wrapping this command lands in the stacked feat(actions): Add Github actions package #323.

Testing

• Unit tests cover manifest read (ID/name validation, duplicate errors) and ID write-back (comment + placeholder preservation); per-gateway resolution rules are tested in the SDK; 215+ CLI tests pass overall.

Test-before-promote (added in review)

• Manifest entries accept test-payload (path to a JSON file, resolved relative to the manifest) and test-payload-type (DATA_POINT | REQUEST_ENRICHER, DSR only). Payloads are loaded and JSON-parsed at manifest read time, with clear errors for missing files and invalid JSON.
• push test-runs each changed function's freshly signed code before pushing: failures are rejected — the failure reason and the run's execution logs are printed, nothing is pushed for that function, the summary counts it as rejected, and the command exits 1. Passing functions push and promote as before; entries without a test-payload push with a warning.
• --skipTests bypasses testing entirely; --dryRun never tests (nothing is signed on dry runs).
• Requires backend support for pre-signed JWTs on runCustomFunction (main #47383); on older backends the push fails with an upgrade hint — use --skipTests to bypass.

Auto-created DSR integrations (added in review)

• A new DSR manifest entry may omit data-silo-id: the DSR integration (a customFunction-catalog data silo) is created automatically before the test run, the function is created and linked on a passing test, and the silo is rolled back (deleted) on a failing test — logged as Created DSR integration (data silo <id>) ... / a rollback note on rejection.
• --updateManifest write-back is generalized: it now writes both the custom function id and the data-silo-id back into the manifest (data-silo-id inserted right after id, comment-preserving as before), including for existing DSR functions matched by name.
• DSR test payloads get extras.dataSilo injected automatically from the entry's resolved silo, so payload files never hardcode silo IDs. Dry runs note when a DSR integration would also be created.

[linear-code]

WAL-9270

[pkg-pr-new]

Open in StackBlitz

@transcend-io/airgap.js-types

pnpm add https://pkg.pr.new/@transcend-io/airgap.js-types@322

yarn add https://pkg.pr.new/@transcend-io/airgap.js-types@322.tgz

@transcend-io/cli

pnpm add https://pkg.pr.new/@transcend-io/cli@322

yarn add https://pkg.pr.new/@transcend-io/cli@322.tgz

@transcend-io/design-tokens

pnpm add https://pkg.pr.new/@transcend-io/design-tokens@322

yarn add https://pkg.pr.new/@transcend-io/design-tokens@322.tgz

@transcend-io/internationalization

pnpm add https://pkg.pr.new/@transcend-io/internationalization@322

yarn add https://pkg.pr.new/@transcend-io/internationalization@322.tgz

@transcend-io/privacy-types

pnpm add https://pkg.pr.new/@transcend-io/privacy-types@322

yarn add https://pkg.pr.new/@transcend-io/privacy-types@322.tgz

@transcend-io/sdk

pnpm add https://pkg.pr.new/@transcend-io/sdk@322

yarn add https://pkg.pr.new/@transcend-io/sdk@322.tgz

@transcend-io/type-utils

pnpm add https://pkg.pr.new/@transcend-io/type-utils@322

yarn add https://pkg.pr.new/@transcend-io/type-utils@322.tgz

@transcend-io/utils

pnpm add https://pkg.pr.new/@transcend-io/utils@322

yarn add https://pkg.pr.new/@transcend-io/utils@322.tgz

@transcend-io/mcp

pnpm add https://pkg.pr.new/@transcend-io/mcp@322

yarn add https://pkg.pr.new/@transcend-io/mcp@322.tgz

@transcend-io/mcp-server-admin

pnpm add https://pkg.pr.new/@transcend-io/mcp-server-admin@322

yarn add https://pkg.pr.new/@transcend-io/mcp-server-admin@322.tgz

@transcend-io/mcp-server-assessment

pnpm add https://pkg.pr.new/@transcend-io/mcp-server-assessment@322

yarn add https://pkg.pr.new/@transcend-io/mcp-server-assessment@322.tgz

@transcend-io/mcp-server-base

pnpm add https://pkg.pr.new/@transcend-io/mcp-server-base@322

yarn add https://pkg.pr.new/@transcend-io/mcp-server-base@322.tgz

@transcend-io/mcp-server-consent

pnpm add https://pkg.pr.new/@transcend-io/mcp-server-consent@322

yarn add https://pkg.pr.new/@transcend-io/mcp-server-consent@322.tgz

@transcend-io/mcp-server-discovery

pnpm add https://pkg.pr.new/@transcend-io/mcp-server-discovery@322

yarn add https://pkg.pr.new/@transcend-io/mcp-server-discovery@322.tgz

@transcend-io/mcp-server-docs

pnpm add https://pkg.pr.new/@transcend-io/mcp-server-docs@322

yarn add https://pkg.pr.new/@transcend-io/mcp-server-docs@322.tgz

@transcend-io/mcp-server-dsr

pnpm add https://pkg.pr.new/@transcend-io/mcp-server-dsr@322

yarn add https://pkg.pr.new/@transcend-io/mcp-server-dsr@322.tgz

@transcend-io/mcp-server-inventory

pnpm add https://pkg.pr.new/@transcend-io/mcp-server-inventory@322

yarn add https://pkg.pr.new/@transcend-io/mcp-server-inventory@322.tgz

@transcend-io/mcp-server-preferences

pnpm add https://pkg.pr.new/@transcend-io/mcp-server-preferences@322

yarn add https://pkg.pr.new/@transcend-io/mcp-server-preferences@322.tgz

@transcend-io/mcp-server-workflows

pnpm add https://pkg.pr.new/@transcend-io/mcp-server-workflows@322

yarn add https://pkg.pr.new/@transcend-io/mcp-server-workflows@322.tgz

commit: 54eb5df

[ecton-transcend]

🤖 Posted by Cursor on behalf of @ecton-transcend

Automated Change: Auth pivot to customer-ingress signing

Per security review feedback on the platform side (#46175), the signing flow no longer exchanges the API key for a Sombra employee session over a Diffie-Hellman channel. The CLI now signs code directly against the Sombra customer-ingress /v1/custom/sign route (bearer token auth) and saves the pre-signed JWTs via GraphQL.

Implementation details

What changed: All DH crypto and the session-exchange helper were removed from the SDK; a signCustomFunctionCode customer-ingress client and resolveSombraCustomerUrl helper were added; the GraphQL mutations now receive signedCodeJwt / signedCodeContextJwt inside input instead of dhEncrypted; the CLI gained --sombraAuth (Sombra internal key, needed when self-hosting) and the action a matching sombra-auth input.
Why: The employee-session exchange hard-coded SombraEmployeeAuthMethod.Transcend, which is not enabled on all self-hosted gateways; the customer-ingress bearer token is the established auth model for internal routes.
Impact: Same trust model at rest (backend stores unverifiable HMAC JWTs either way); code/env plaintext now travels only over TLS to the customer's own gateway. Requires a Sombra version with the new route — older gateways get a friendly upgrade error.

[ecton-transcend]

🤖 Posted by Cursor on behalf of @ecton-transcend

Automated Change: Per-gateway code signing

Custom functions can belong to different Sombra gateways, and a function's JWTs must be signed by its own gateway's keys or they fail verification at execution time. Previously the push signed every function against a single gateway (the --sombraId flag or the primary), which could silently produce runtime-broken revisions for functions on other gateways.

Implementation details

What changed: The customFunctions query now fetches each function's sombraId; new resolveEffectiveSombraId resolves the signing gateway per function (manifest sombra-id → existing function's gateway → --sombraId → primary) and rejects configs that try to move an existing function between gateways; the CLI caches one customer-ingress connection per distinct gateway and signs each function against its own.
Why: Signing against the wrong gateway succeeds at push time (the backend cannot verify the HMAC JWTs) and only fails at execution — the worst failure mode.
Impact: Single-gateway orgs are unaffected (everything resolves to the primary). Multi-gateway manifests now work in one push, with the documented limitation that one --sombraAuth key applies to all gateways in a run.

The base branch was changed.