feat(webapp): admin UI for global and org-level feature flag overrides

[nicktrn]

Adds a dialog to the admin orgs page for viewing and editing per-org feature flag overrides. Flags are introspected from the catalog so the UI stays in sync with available flags automatically. Also adds a new tab for global flags.

Refactors featureFlags.server.ts to split catalog definition (shared) from server-only runtime (flags(), makeSetMultipleFlags). The shared module exports flag metadata and validation so both the UI and API routes can use it without pulling in server dependencies.

Org-level modal:

Global flags confirmation modal:

[changeset-bot]

⚠️ No Changeset found

Latest commit: 607af80

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[coderabbitai]

Note

Reviews paused

It looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the reviews.auto_review.auto_pause_after_reviewed_commits setting.

Use the following commands to manage reviews:

• @coderabbitai resume to resume automatic reviews.
• @coderabbitai review to trigger a single review.

Use the checkboxes below for quick actions:

• ▶️ Resume reviews
• 🔍 Trigger review

Walkthrough

This PR adds full admin feature-flag management: a new client dialog component (FeatureFlagsDialog) and reusable FlagControls, a global admin route (/admin/feature-flags) with loader/action, and a new org-level API (admin.api.v2.orgs.$organizationId.feature-flags). It extracts FEATURE_FLAG and validation helpers into a new v3/featureFlags.ts module, updates many imports to the new module, replaces several Prisma findUnique calls with findFirst, and adds json-stable-stringify as a dependency.

Estimated code review effort

🎯 4 (Complex) | ⏱️ ~50 minutes

🚥 Pre-merge checks | ✅ 2 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 20.00% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title accurately summarizes the main change: adding admin UI for feature flag overrides at both global and org levels.
Description check	✅ Passed	The description provides context, implementation details, and includes visual examples, but lacks some template sections (issue closure, checklist, testing details, changelog).

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch feat/admin-feature-flags

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[0ski]

Nice, that's going to be useful!

[devin-ai-integration]

Devin Review found 1 new potential issue.

View 12 additional findings in Devin Review.

[devin-ai-integration]

🚩 getFlagControlType relies on Zod internal _def.typeName for z.coerce.boolean()

The getFlagControlType function at apps/webapp/app/v3/featureFlags.ts:73-85 checks schema._def.typeName === "ZodBoolean" to detect boolean flags. All boolean flags in the catalog use z.coerce.boolean() rather than z.boolean(). In Zod 3.22+, z.coerce.boolean() creates a ZodBoolean with coerce: true, so _def.typeName should still be "ZodBoolean". However, this relies on Zod internals (_def.typeName) which are not part of the public API and could change between versions. The project pins Zod at 3.25.76. If the internal representation changed in this version (part of the Zod 3→4 transition), all boolean flags would incorrectly be classified as "string" type controls in the admin UI. Worth verifying with a quick runtime test.

---

Was this helpful? React with 👍 or 👎 to provide feedback.