feat(frontend): add durable streams service to onboarding and namespace settings

[NicholasKissel]

Follow-up to #5633.

• Add a Services section to the onboarding product picker with Durable Streams, including a "Connect to Durable Streams" step and agent prompt
• Add Durable Streams to the "Add a component" picker, linking to the integration docs
• Rename the namespace landing "Actors" heading to "Components"
• Add a Services tab to namespace settings that lists Durable Streams, shows whether it is connected, and links to the docs for setup
• Add the official Durable Streams mark in monochrome, rendered on a neutral tile

[railway-app]

🚅 Deployed to the actors-pr-5688 environment in rivet-frontend

Service	Status	Web	Updated
frontend-cloud	😴 Sleeping (View Logs)	Web	Sep 10, 2026 at 12:58 am UTC
kitchen-sink	😴 Sleeping (View Logs)	Web	Sep 10, 2026 at 12:56 am UTC
frontend-inspector	😴 Sleeping (View Logs)	Web	Sep 10, 2026 at 12:53 am UTC
ladle	✅ Success (View Logs)	Web	Sep 10, 2026 at 12:46 am UTC
mcp-hub	✅ Success (View Logs)	Web	Sep 10, 2026 at 12:45 am UTC
website	❌ Build Failed (View Logs)	Web	Sep 10, 2026 at 12:45 am UTC

[the-company-company]

🟠 1 medium-severity finding

_{Reviewed commit c3365d7.}

[the-company-company]

🟠 Medium · Connected status ignores services beyond the first build page

buildsQueryOptions() is an infinite query with a page size of 10, but this component neither prefetches all pages nor calls fetchNextPage. Its selected builds value therefore only contains the first page. In namespaces with more than 10 actor names, a registered durableStream name on a later cursor page is reported as “Not connected.”

Fetch all pages for this membership check, or add a targeted actor-name existence query rather than deriving it from the first page.

[claude]

Review

Nicely scoped feature addition — the "Services" concept is threaded consistently through the product picker, onboarding stepper, and settings drawer, and the new agent prompt has solid test coverage in agent-prompts.test.ts.

Findings

1. features.compute is the wrong gate for "is this Rivet Cloud" (frontend/src/app/compute-deploy.tsx:98-105)

export function useDurableStreamsServiceUrl(): string | undefined {
	const namespace = useEngineCompatDataProvider().engineNamespace;
	if (!features.compute) return undefined;
	return getDurableStreamsServiceUrl(getRivetRunUrl(namespace));
}

features.compute is documented in frontend/src/lib/features.ts:33-36 as gating "the Rivet Compute (managed pool) UI: namespace deployments, logs, and the Rivet provider option," and is defined as isEnabled("compute") && platform — i.e. it can be false on a cloud namespace that simply doesn't have the compute flag turned on. Reusing it here to decide whether a managed Durable Streams URL exists conflates two unrelated features.

This is also inconsistent with how the rest of this same PR draws the cloud/OSS line: ServicesTabBody in settings-drawer.tsx correctly checks features.platform to decide between EngineNamespaceServices and CloudServicesTabBody. So on a cloud namespace where platform is true but compute is off, the Services tab renders the cloud path, but useDurableStreamsServiceUrl (shared between onboarding and this same Services tab via DurableStreamsConnect) still returns undefined and falls through to DurableStreamsSelfHosted, telling the user to docker run a worker with RIVET_ENDPOINT (an admin credential) even though they're on Rivet Cloud and a managed URL actually exists. Suggest gating on features.platform instead, matching ServicesTabBody's own choice.

2. "Connected" detection hardcodes an external package's internal actor name with no shared source of truth (frontend/src/app/settings-pages/namespace-services.tsx:24-28)

const SERVICES = [
	{
		product: getProduct("durable-streams"),
		actorNames: ["durableStream"],
	},
];

The dashboard's only signal for "is Durable Streams connected to this namespace" is whether an actor build literally named durableStream shows up (builds.some((build) => service.actorNames.includes(build.id)) — confirmed build.id is the actor name string here, not a UUID, so the comparison itself is correct). That name lives in the separate @rivet-dev/services package, and nothing here (comment, shared constant, or test) ties the two together. If that package ever renames its actor, this indicator silently and permanently reads "Not connected" with no error surfaced. Worth a comment pointing at the source of truth, and ideally a shared constant or a test that fails loudly if the two drift.

Minor

• Verified every <ProductMark> call site was updated to pass the new required section prop — no missed callers.
• DurableStreamsSelfHosted displays the admin secret (RIVET_ENDPOINT) inline in a docker run command without masking, but that matches the existing precedent for the same secret elsewhere in getting-started.tsx, so it's not a new regression.

🤖 Generated with Claude Code