refactor: extract ui-extensions-sdk

[maxy-shpfy]

TL;DR

Introduces @tangent/ui-extensions-sdk as the canonical package for authoring Tangle UI extensions, replacing the internal @tangent/bundle-ui specifier. All component wire contracts, bridge types, the shared esbuild helper, and a new ui-extensions CLI are consolidated into this package.

What changed?

A new packages/ui-extensions-sdk workspace package is introduced with the following structure:

• src/types.ts — the HostBridge, HostFetchInput, HostRequestInit, HostResponse, UICommand, and BundleUiKind types, previously inlined in apps/web/src/features/bundle-ui/types.ts, are now the single source of truth here.
• src/contracts/ — all per-component zod schemas (TAG, attributes, events) and the shared enums.ts / events.ts are moved from apps/web/src/features/bundle-ui/components/*/ into this package and consumed via @tangent/ui-extensions-sdk/contracts/<name> subpath imports.
• src/components.ts — typed stub components whose prop types are derived directly from the zod contracts, giving authors full autocomplete without coupling to the web runtime.
• src/host.ts — the typed host bridge object.
• src/build.ts — a shared buildUiComponent helper (and UiComponentBuildError) that both the server's fileAgentBundleStore and the new CLI use, ensuring local builds are identical to server-side upload compilation. The explicit external list prevents workspace-symlinked packages from being inlined.
• src/cli.ts — a ui-extensions binary with build, typecheck, and init subcommands for local extension development.
• tsconfig.author.json — a self-contained tsconfig preset authors extend.

The web app's bundle-ui.worker.ts now registers @tangent/ui-extensions-sdk in the worker module map alongside a legacy alias for @tangent/bundle-ui, so bundles compiled before the rename continue to resolve correctly. The Vite alias and tsconfig.json path mapping in apps/web are updated from @tangent/bundle-ui to @tangent/ui-extensions-sdk, using a regex alias so subpath imports (e.g. contracts/*) still resolve to the real package rather than the bridge stub.

The server's fileAgentBundleStore now calls buildUiComponent from the SDK instead of invoking esbuild directly, and surfaces UiComponentBuildError details in the validation error message.

How to test?

• Run pnpm --filter @tangent/ui-extensions-sdk typecheck and pnpm --filter @tangent/ui-extensions-sdk lint to validate the new package.
• Run pnpm --filter @tangent/server test to exercise the upload → compile path end-to-end.
• Run the CLI against the in-repo example: pnpm --filter @tangent/ui-extensions-sdk cli build ../../examples/tangle-oss and pnpm --filter @tangent/ui-extensions-sdk cli typecheck ../../examples/tangle-oss.
• Load the dev harness in apps/web/public/bundle-ui-harness/ and confirm the sample component (which now imports from @tangent/ui-extensions-sdk) renders correctly.
• Upload a bundle with a UI component through the server and verify it compiles and renders without error.
• Upload or load a bundle compiled against the old @tangent/bundle-ui specifier and confirm it still resolves via the legacy alias.

Why make this change?

Previously the component contracts, bridge types, and esbuild configuration were split across the web app's internal feature directory with no public surface for extension authors. This meant local builds could diverge from server-side compilation, there was no way to type-check an extension outside the monorepo, and the @tangent/bundle-ui name gave no indication it was an authoring SDK. Consolidating everything into @tangent/ui-extensions-sdk gives authors a single, versioned package with full typing, a CLI that mirrors the server's build exactly, and a clear contract boundary between the SDK, the host runtime, and the worker — with no risk of the two sides drifting.

[maxy-shpfy]

• poc: csom as remote agent #64
• feat: remote agents #63
• refactor: extract ui-extensions-sdk #62 👈 (View in Graphite)
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.