feat(frontend): feature flag compute

[abcxff]

Description

Please include a summary of the changes and the related issue. Please also include relevant motivation and context.

Type of change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update

How Has This Been Tested?

Please describe the tests that you ran to verify your changes.

Checklist:

• My code follows the style guidelines of this project
• I have performed a self-review of my code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes

[railway-app]

🚅 Deployed to the rivet-pr-5098 environment in rivet-frontend

Service	Status	Web	Updated (UTC)
ladle	✅ Success (View Logs)	Web	May 23, 2026 at 8:19 pm
frontend-cloud	✅ Success (View Logs)	Web	May 23, 2026 at 8:18 pm
frontend-inspector	❌ Build Failed (View Logs)	Web	May 23, 2026 at 8:16 pm
website	✅ Success (View Logs)	Web	May 23, 2026 at 8:16 pm
kitchen-sink	❌ Build Failed (View Logs)	Web	May 23, 2026 at 8:16 pm
mcp-hub	🕒 Building (View Logs)	Web	May 23, 2026 at 8:15 pm

[abcxff]

• feat(frontend): feature flag compute #5098 👈 (View in Graphite)
• main

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

[claude]

PR #5098 Review: feat(frontend): feature flag compute

Overview

This PR introduces a new compute feature flag that gates the Rivet Compute (managed pool) UI — namespace deployments, logs, actor deployment-logs tab, and the Rivet provider option in onboarding/Add Provider. The flag is opt-in even on cloud (not default-on), set per-environment via VITE_FEATURE_FLAGS. It also includes documentation improvements to rivet-compute.mdx.

---

Issues

1. Rule-of-Hooks violation in layout.tsx (biome-ignore suppression)

function DeploymentsLink() {
    if (!features.compute) {
        return null;
    }
    // biome-ignore lint/correctness/useHookAtTopLevel: guarded by build constant
    const provider = useCloudNamespaceDataProvider();
    // biome-ignore lint/correctness/useHookAtTopLevel: guarded by build constant
    const { data } = useSuspenseQuery(...)
}

The biome-ignore comments correctly suppress the lint rule, and the rationale (guarded by build constant) is sound if features.compute is truly a compile-time constant. However, the adjacent comment text explains what the suppression is for but not why it's safe — it's safe because features.compute is evaluated at module load time from VITE_FEATURE_FLAGS and never changes at runtime. The existing pattern in actors-actor-details.tsx already uses this same convention, so it's consistent, but it requires care if this pattern spreads. Worth confirming nothing can make features.compute dynamic at runtime.

2. Unexplained field rename in upsert-deployment-frame.tsx

- minCount: 0,
- maxCount: 100_000,
+ maxConcurrentActors: 10000,

This changes two separate fields (minCount + maxCount) to one (maxConcurrentActors), and drops the numeric separator convention (100_000 → 10000). The PR description doesn't explain this change. It looks like an API schema update but is buried in a feature-flag PR without context. If this matches a backend API change it should be mentioned. If minCount: 0 is being silently dropped, confirm the default is handled server-side.

3. PR description is unfilled boilerplate

The PR description is the default template with every checkbox unchecked and no summary. For a multi-file change affecting routing, feature flags, onboarding flow, and docs, a brief description of what changed and how it was tested would be helpful.

---

Minor Notes

• Feature flag definition (features.ts): compute: isEnabled("compute") && platform correctly enforces the platform prerequisite as documented.
• Query enabled guards (actors-grid.tsx): Adding enabled: features.compute to managed pool queries is the right pattern — no unnecessary API calls when the feature is off.
• Route beforeLoad redirects (deployments.tsx, logs.tsx): Clean guard using throw redirect() consistent with the CLAUDE.md routing conventions.
• Provider filter (getting-started.tsx): features.compute || option.name !== 'rivet' logic is correct. The col-span-2 py-5 layout class is also properly gated, so layout won't break when the Rivet card is absent.
• Default provider useEffect (getting-started.tsx ~line 494): The early return if (!features.compute) return; prevents auto-selecting "rivet" as default provider when compute is off. Confirm this is the intended UX — with no default, the user must manually pick a provider.
• Docs fix (rivet-compute.mdx): Correcting "Rivet Cloud" → "Rivet Compute" and updating the code example from startRunner() to serve()/handler() is a good standalone improvement.
• Flag docs (.claude/reference/feature-flags.md): The note that compute is opt-in even on cloud is clear and follows the doc style.

---

Summary

The feature flag implementation is clean and consistent with the project's established patterns. The main things to address: (1) explain the upsert-deployment-frame.tsx API field rename, and (2) confirm the no-default-provider UX when compute is off is intentional. The biome-ignore hook suppression is acceptable given the build-constant rationale but should stay limited to this pattern.

[abcxff]

Merge activity

• May 23, 8:21 PM UTC: A user started a stack merge that includes this pull request via Graphite.
• May 23, 8:21 PM UTC: @abcxff merged this pull request with Graphite.