[TheGreatAxios]

Summary

After T7 (#753), the onboarding page drove install over stock routes but never supplied myraDeploy to convergeNeedsList, so every fresh hub landed on the "Myra is absent" gap screen. This wires the converge loop the owner ruled on: authenticate → mint the primary tenant if needed → resolve whether it already has a usable model offering (inherited, or a previous run of this flow) → ask the operator for a provider credential only when it doesn't. No hub changes, no seed logic, everything over stock routes.

Deploy-source variant chosen, and why

WorkflowDefinitionSource has two variants (registry, asset). Neither of the "obvious" choices actually installs today for @corbits/assistant-workflow:

• registry (the ticket's stated default): the package is private: true and unpublished to any registry — CL-8151's job, not done yet. Selecting it today would just move the failure from "no myraDeploy" to "registry has nothing to resolve."
• asset + package.format: "source" (git-pushed codebase, what packages/onboarding's seedTenant and the e2e harness use): the pusher (createGitWorkflowPusher) shells out to a system git binary and node:fs/node:child_process — fundamentally unavailable to a browser SPA. workflows/assistant's own package also exports builder functions (buildAssistantWorkflow), not a default-exported WorkflowDefinition, so even a hub-side push of the real package wouldn't satisfy the source-tree installer's shape today.

What does work, fully client-side, over plain fetch, no git protocol, no hub change: asset + package.format: "tarball". PUT /api/tenants/:id/assets/:assetId/tarballs/:filename takes raw npm-shaped tarball bytes over a stock REST route. myra-deploy.ts:

• Ensures a package-registry asset exists (409-then-list, same idempotency pattern as ensureWorkflowAsset).
• Hand-builds the exact WorkflowDefinition JSON buildAssistantWorkflow would produce — not by calling that function (importing @corbits/assistant-workflow directly pulls in @intx/workflow/@intx/agent's Node-bound runtime, confirmed by a failed apps/web build), but from plain data split into a new browser-safe subpath, @corbits/assistant-workflow/prompt (system prompt, tool-package pins, ids — zero runtime imports).
• Packs it into an npm-shaped tarball with a small hand-rolled USTAR writer plus the browser's own CompressionStream("gzip"), and PUTs it in.
• Maps the operator's offering pick to the exact WorkflowDeployInput (buildMyraDeployInput, the one piece with real logic — unit tested).

Credential/offering step

provider-connect-step.tsx is the one prompt this flow asks for, and only when needed: three providers (Anthropic, OpenAI, Google), each mapping to one canonical model, so connecting a provider mints exactly one offering with no separate "which model" pick. A tenant that already resolves a catalog offering (inherited, or a previous run) skips this screen entirely — resolveExistingOffering mirrors resolveRealSourceOfferingIds's "lowest priority wins the default" rule.

Other changes

• needs-converge.ts's HubTenant/TenantShape now parses the domain field the stock tenant route already returns (needed to derive Myra's trigger address assistant@<domain>) — no hub change, the field was already there.
• Deleted the test asserting the pre-CL-8154 "surfaces the myra-deploy gap" behavior; replaced with one asserting the new credential-connect landing.

Verified

• bun run typecheck, bun run lint, bun run check:structural all clean (0 fail; report-error/ui-vocabulary/web-tailwind-utilities all ok).
• bun run build in apps/web succeeds (confirmed the naive approach — importing @corbits/assistant-workflow directly, and the bare @corbits/workflows entry point — fails the build by pulling in Node-only code; both are now routed through browser-safe subpaths).
• Unit tests: apps/web/src/myra-deploy.test.ts (new, the offering→deploy-input mapping), plus the full apps/web suite and workflows/assistant's suite pass.

Not verified: a live end-to-end walkthrough (scripts/e2e/browser/walkthrough.ts or driving the real stack with HUB_DATA_DIR=$(mktemp -d)) against a running hub+sidecar — I did not have time in this session to boot the full stack and confirm the sidecar actually resolves and runs a tarball-sourced package-registry asset end to end. The route contracts (PUT .../tarballs/:filename, extractTarballPackageJSON's tar-tail matching, InstallAndApproveAssetTarballArgs) are read from source, not exercised live. This is the one open risk in this PR and should be driven by hand or via CI's e2e suite before considering CL-8154 fully closed.

Test plan

• bun run typecheck
• bun run lint
• bun run check:structural
• bun test (apps/web, workflows/assistant)
• Live walkthrough against a running hub+sidecar (not done this session — see note above)

https://claude.ai/code/session_01RweuMUskU2nvcFhdckc7EG

[linear-code]

CL-8154