46741 frontend [ Configuration ] Migrate Frontend to Runtime Environment Variables

[EBirkenfeld]

1. Description (Problem)

All frontend feature flags and environment variables (CAPTCHA, BILLING, AI, SIGNUP, SENTRY_DSN, Firebase config, etc.) were injected at webpack build time via DefinePlugin + dotenv. This meant:

• Any variable change (e.g., toggling Billing) required a full Docker image rebuild and redeploy.
• On Railway/production the container ran npm run build-client:prod at startup — rebuild on every restart (30–60 sec delay).
• Impossible to change feature flags via the deployment dashboard on-the-fly.

Where it manifested: frontend container cold-start time, inability to manage features through Railway Dashboard.

2. Context

• Part of the CI/CD pipeline optimization initiative to bring infrastructure to production-grade level.
• Backend already uses runtime .env — frontend was the only service with a build-time dependency on env vars.
• On Railway, changing an env var in the Dashboard triggers an automatic redeploy; but since the JS bundle build happened at container startup, this added 30–60 seconds of downtime per variable change.
• Related to ticket #46741.

3. Solution

Two-layer env var reading architecture:

1. SSR layer (server): getConfig() on the Node.js server reads process.env and builds a JSON object __pneumaticConfig, including a new featureFlags block — passed to the client via a <script> tag in HTML.
2. Client layer: All process.env.X calls in enviroment.ts replaced with getEnvVar(key), which first checks window.__pneumaticConfig.config.featureFlags[key], then falls back to process.env[key] (for SSR/dev).
3. Webpack: DefinePlugin now only injects NODE_ENV and MCS_RUN_ENV — the only variables actually needed at build time.
4. Docker: Webpack build moved to Dockerfile RUN layer (cached by Docker layer cache). Container start command simplified to pm2-runtime start pm2.json.

4. Implementation Details

File	Changes
frontend/src/public/constants/enviroment.ts	Added getEnvVar() function. All 30 variables migrated from process.env.X to getEnvVar('X'). Added envSentryRelease export.
frontend/src/public/utils/getConfig.ts	Added featureFlags block (30 keys) to SSR config. Updated IBrowserConfig interface. Added featureFlags to common.json exposedToBrowser.
frontend/src/public/utils/initSentry.ts	SENTRY_RELEASE read via envSentryRelease instead of process.env.SENTRY_RELEASE.
frontend/webpack.config.js	Removed dotenv import and bulk process.env injection via DefinePlugin. Only NODE_ENV and MCS_RUN_ENV remain.
frontend/Dockerfile	Added RUN NODE_ENV=production npx webpack (build at image build time). Added CMD ["pm2-runtime", "start", "pm2.json"].
docker-compose.yml / docker-compose.src.yml	Command changed from sh -c "npm run build-client:prod && pm2-runtime start pm2.json" to pm2-runtime start pm2.json.
frontend/config/common.json	Added "featureFlags" to exposedToBrowser array.

Contract: New field featureFlags: Record<string, string | undefined> in IBrowserConfig. Non-breaking — all existing fields preserved.

5. What to Test

5.1 Unit Tests (enviroment.test.ts)

getEnv — resolution priority

Env variable	Expected result
LANGUAGE_CODE set in both featureFlags and process.env	Returns value from featureFlags (priority over process.env)
HOST missing from both featureFlags and process.env	Returns undefined
SENTRY_DSN set in process.env only, featureFlags empty	Falls back to process.env value
BACKEND_URL set in process.env, __pneumaticConfig absent	Falls back to process.env value
WSS_URL set in process.env, config has no featureFlags key	Falls back to process.env value

Boolean feature flags (!== 'no' pattern)

Each flag follows the same contract: undefined → true, "no" → false, any other value → true.

Env variable	undefined	"no"	"yes" / other
CAPTCHA → isEnvCaptcha	true	false	true
GOOGLE_AUTH → isEnvGoogleAuth	true	false	—
MS_AUTH → isEnvMsAuth	true	false	—
SSO_AUTH → isEnvSSOAuth	true	false	—
SIGNUP → isEnvSignup	true	false	—
BILLING → isEnvBilling	true	false	—
AI → isEnvAi	true	false	—
PUSH → isEnvPush	true	false	—
STORAGE → isEnvStorage	true	false	—
ANALYTICS → isEnvAnalytics	true	false	—

Additional: AI = "yes" in process.env but "no" in featureFlags → isEnvAi = false (featureFlags wins)

String variables

Env variable	Expected result
SSO_PROVIDER = "okta"	envSSOProvider = "okta"
HOST = "https://app.pneumatic.app"	envHost = "https://app.pneumatic.app"
ANALYTICS_ID = "UA-12345"	envAnalyticsId = "UA-12345"
RECAPTCHA_SITE_KEY = "site-key-123"	envRecaptchaSiteKey = "site-key-123"
GOOGLE_CLIENT_ID = "google-id-123"	envGoogleClientId = "google-id-123"
SENTRY_RELEASE = "v1.2.3"	envSentryRelease = "v1.2.3"

envDevMode

Env variable	Expected result
NODE_ENV = "development"	envDevMode = true
NODE_ENV = "production"	envDevMode = false

envFirebase

Env variable	Expected result
All FIREBASE_* vars set in process.env	envFirebase object populated with all 8 fields
All FIREBASE_* vars set in featureFlags	envFirebase reads from featureFlags (priority)

5.2 Manual / Integration Tests

Preconditions

• Dev environment with Docker (docker-compose) or Railway staging.
• Access to Railway Dashboard (for env var change testing).
• Browser with DevTools.

Docker build & startup

Scenario	Expected result
docker-compose build frontend	Webpack builds during the build phase (logs show Compile is done!)
docker-compose up frontend	Container starts instantly — no webpack build at runtime
docker-compose build frontend without .env file	Build succeeds (webpack no longer depends on env vars)

SSR config injection

Scenario	Expected result
Open app → DevTools → Console → window.__pneumaticConfig.config.featureFlags	Object with 30 keys, values match container env vars
DevTools → Elements → find <script> with __pneumaticConfig	featureFlags block is present in HTML

Feature flags — UI Behavior Testing

How to test: deploy the branch to dev. Verify in 3 rollouts:

1. All flags ON → verify behavior per the "Flag = ON" row
2. All flags OFF → verify behavior per the "Flag = OFF" row
3. Combination scenarios (if needed)

Flag logic: !== 'no' — if the value is "no" → flag is disabled. If "yes" or absent (undefined) → flag is enabled.

BILLING

Value	Expected UI Behavior	Where to Verify
yes	After registration → redirect to card details page (Stripe Checkout /collect-payment-details). Without payment, the user cannot access the product. In the profile menu (avatar → dropdown) the "Pricing" and "Customer Portal" items are visible	1) Register a new user 2) Check profile dropdown in top-right corner
no	After registration → user lands directly in the product (home /), without a payment page. In the profile dropdown, "Pricing" and "Customer Portal" items are absent	1) Register a new user 2) Check profile dropdown

SIGNUP

Value	Expected UI Behavior	Where to Verify
yes	On the Login page, a "Not a member? Register" link is visible at the bottom. On Forgot Password, a registration link is visible. The /register route is accessible and renders the registration form	/login → link at bottom; /forgot-password → link; /register directly
no	On Login, the "Not a member? Register" link is hidden. On Forgot Password — no registration link. Navigating directly to /register → page does not render (404 or redirect)	/login; /forgot-password; /register directly in address bar

GOOGLE_AUTH

Value	Expected UI Behavior	Where to Verify
yes	On Login and Register, the "Sign in with Google" button is visible. In the Team Invites popup, the Google Contacts tab is visible	/login; /register; Settings → Team → Invite → popup
no	The "Sign in with Google" button is hidden on Login and Register. In Team Invites, the Google tab is hidden	/login; /register; Team Invites

MS_AUTH

Value	Expected UI Behavior	Where to Verify
yes	On Login and Register, the "Sign in with Microsoft" button is visible. In Team Invites, the Microsoft Contacts tab is visible	/login; /register; Team Invites
no	The "Sign in with Microsoft" button is hidden. In Team Invites, the Microsoft tab is hidden	/login; /register; Team Invites

SSO_AUTH + SSO_PROVIDER

Value	Expected UI Behavior	Where to Verify
SSO_AUTH=yes, SSO_PROVIDER=auth0	On Login and Register, the "Sign in with SSO" button is visible. Clicking it → redirect to Auth0. If all 3 OAuth providers are enabled — an "or" divider is visible between OAuth buttons and the email/password form	/login; /register
SSO_AUTH=yes, SSO_PROVIDER=okta	On Login and Register, the "Sign in with SSO" button is visible. Clicking it → redirect to Okta	/login; /register
SSO_AUTH=no	SSO button is hidden. If Google and MS are also no → the "or" divider is also hidden, only the email/password form is displayed	/login; /register

CAPTCHA

Value	Expected UI Behavior	Where to Verify
yes	On Register (if the backend returns showCaptcha: true) → the reCAPTCHA widget is displayed. Without completing the captcha, the Submit button is disabled. On public forms — same behavior	/register; public form (via forms subdomain)
no	reCAPTCHA is not displayed on Register or public forms. The form submits without captcha	/register; public form

AI

Value	Expected UI Behavior	Where to Verify
yes	On the Templates page, the "Generate with AI" card is visible (AI+ icon). Clicking it → opens the AI template generation modal	/templates → first card
no	The "Generate with AI" card is hidden. Only the "Create template" card (manual creation) is visible	/templates

PUSH

Value	Expected UI Behavior	Where to Verify
yes	When loading any internal page (after login) → the browser requests push notification permission (Firebase Messaging)	Log in → check for browser permission prompt
no	The browser does NOT request notification permission. Firebase is not initialized	Log in → no permission prompt

STORAGE

Value	Expected UI Behavior	Where to Verify
yes	File uploads work — avatar, task attachments are uploaded to Google Cloud	Profile → upload avatar; Task → attach a file
no	When attempting to upload a file → a warning notification (yellow toast) with a storage error message appears. The file is not uploaded	Profile → attempt to upload avatar; Task → attempt to attach a file

ANALYTICS

Value	Expected UI Behavior	Where to Verify
yes	The Intercom widget (support chat) is visible in the bottom-right corner. In DevTools Network → requests to Segment and Intercom are present	Any page after login → bottom-right corner
no	No Intercom widget. No requests to Segment/Intercom in Network	Any page after login

---

Combination Scenarios (Rollout 3 — if needed)

#	Flag Combination	Expected UI Behavior	Where to Verify
1	BILLING=yes + SIGNUP=no	Self-registration is not possible (no Register link, route unavailable). But if a user is created via invite → after first login → redirect to Stripe Checkout	Invite a new user → they log in
2	GOOGLE_AUTH=yes + MS_AUTH=no + SSO_AUTH=no	On Login/Register — only the Google button. The "or" divider is visible (at least 1 OAuth is enabled)	/login, /register
3	GOOGLE_AUTH=no + MS_AUTH=no + SSO_AUTH=no	No OAuth buttons, no "or" divider. Only the email + password form	/login, /register
4	BILLING=no + ANALYTICS=no + PUSH=no	Self-hosted mode. Registration → straight into the product. No Intercom, no push, no Stripe	Full flow: registration → working with the product
5	AI=yes + STORAGE=no	"Generate with AI" button on Templates is visible and works. But uploading task attachments → warning, file is not uploaded	/templates + task with attachment

---

Connectivity Smoke Test (flag-independent)

Env Variable	Expected UI Behavior	How to Verify
BACKEND_URL	API requests go to the correct URL	DevTools → Network → any request to /api/
WSS_URL	WebSocket connections established (Notifications, Tasks, Workflows)	DevTools → Network → WS → should show active connection
SENTRY_DSN	Sentry is initialized	DevTools → Console → no Sentry init errors
SENTRY_RELEASE	Passed to Sentry as the release version	DevTools → Console → Sentry.getCurrentHub().getClient().getOptions().release
LANGUAGE_CODE	Interface is in the correct language (en/ru)	Visual — text is in the expected language

---

General Smoke Path (minimum verification)

1. ✅ Open /login → verify presence/absence of OAuth buttons
2. ✅ Register a user → verify redirect (Stripe or straight to product)
3. ✅ Log in → verify Intercom / Push permission prompt
4. ✅ Navigate to Templates → verify AI button
5. ✅ Upload an avatar → verify Storage
6. ✅ DevTools → Network → WS → verify connection
7. ✅ window.__pneumaticConfig.config.featureFlags in Console → verify all 30 keys

Connectivity

Env variable	Expected result
WSS_URL	WebSocket connections (Notifications, Tasks, Workflows) established
BACKEND_URL	API requests go to the correct URL
SENTRY_DSN	Sentry.init called with correct DSN
SENTRY_RELEASE	Passed to Sentry release field

Edge cases

Scenario	Expected result
SSR context (typeof window === 'undefined')	getEnv falls back to process.env, no errors
__pneumaticConfig not loaded (JS error before hydration)	getEnv falls back safely, app doesn't crash

Local development

Scenario	Expected result
npm run dev	HMR works, variables from .env file available via process.env fallback

5.3 What Was NOT Tested

• Mobile devices (responsive) — not in scope.
• Locales (en/ru) — not affected.
• Production — testing in dev/staging only.
• Load testing — not performed.
• Public Forms separate entrypoint (forms.tsx) — behavior unchanged, but smoke-test recommended.

6. Affected Areas (Dependencies)

The enviroment.ts module is imported in 20+ files. Key consumers:

Component/Module	What to verify
commonRequest.ts	API requests use envBackendURL — requests go to correct URL
workflows/saga.ts, tasks/saga.ts, notifications/saga.ts	WebSocket via envWssURL — connections established
auth/saga.ts	Billing flow via isEnvBilling
settings/reducer.ts	Language via envLanguageCode
MainLayout.tsx	Analytics and Push via isEnvAnalytics, isEnvPush
TopNav.tsx	Billing UI via isEnvBilling
TeamInvitesPopup.tsx	Google/MS Auth via isEnvGoogleAuth, isEnvMsAuth
User.tsx	Signup link via isEnvSignup
Login.tsx, Register.tsx, ForgotPassword.tsx, ResetPassword.tsx	Captcha and auth providers
PublicForm.tsx	Feature flags in public forms
uploadFiles.ts	Storage via isEnvStorage
initSentry.ts	Sentry DSN and Release
analytics.ts	Analytics toggle

Minimum smoke-test: log in → open Dashboard → verify WebSocket → create workflow → open public form.

7. Refactoring

Scale: medium — core configuration module affected.

• enviroment.ts — complete mechanism replacement (30 variables), but exported API unchanged (same names, same types). Consumers require no changes.
• webpack.config.js — removed dotenv, simplified DefinePlugin.
• Dockerfile + docker-compose — moved build from runtime to build-time.

Additional testing: Ensure all 20+ consumers of enviroment.ts receive correct values. Smoke-test critical paths (see section 6).

8. Commits

• 7a5601a7 — 46741 feat(frontend): migrate environment variables to runtime config

9. Release Notes

Frontend environment variables migrated from build-time webpack injection to SSR runtime config. Feature flags are now served via window.__pneumaticConfig and can be changed via deployment dashboard without rebuilding the Docker image. Container startup time reduced by eliminating runtime webpack builds.

---

Note

^{Cursor Bugbot is generating a summary for commit 7723849. Configure here.}

Note

[!NOTE]

1. Description (Problem)

All frontend feature flags and environment variables (CAPTCHA, BILLING, AI, SIGNUP, SENTRY_DSN, Firebase config, etc.) were injected at webpack build time via DefinePlugin + dotenv. This meant:

• Any variable change (e.g., toggling Billing) required a full Docker image rebuild and redeploy.
• On Railway/production the container ran npm run build-client:prod at startup — rebuild on every restart (30–60 sec delay).
• Impossible to change feature flags via the deployment dashboard on-the-fly.

Where it manifested: frontend container cold-start time, inability to manage features through Railway Dashboard.

2. Context

• Part of the CI/CD pipeline optimization initiative to bring infrastructure to production-grade level.
• Backend already uses runtime .env — frontend was the only service with a build-time dependency on env vars.
• On Railway, changing an env var in the Dashboard triggers an automatic redeploy; but since the JS bundle build happened at container startup, this added 30–60 seconds of downtime per variable change.
• Related to ticket #46741.

3. Solution

Two-layer env var reading architecture:

1. SSR layer (server): getConfig() on the Node.js server reads process.env and builds a JSON object __pneumaticConfig, including a new featureFlags block — passed to the client via a <script> tag in HTML.
2. Client layer: All process.env.X calls in enviroment.ts replaced with getEnvVar(key), which first checks window.__pneumaticConfig.config.featureFlags[key], then falls back to process.env[key] (for SSR/dev).
3. Webpack: DefinePlugin now only injects NODE_ENV and MCS_RUN_ENV — the only variables actually needed at build time.
4. Docker: Webpack build moved to Dockerfile RUN layer (cached by Docker layer cache). Container start command simplified to pm2-runtime start pm2.json.

4. Implementation Details

File	Changes
frontend/src/public/constants/enviroment.ts	Added getEnvVar() function. All 30 variables migrated from process.env.X to getEnvVar('X'). Added envSentryRelease export.
frontend/src/public/utils/getConfig.ts	Added featureFlags block (30 keys) to SSR config. Updated IBrowserConfig interface. Added featureFlags to common.json exposedToBrowser.
frontend/src/public/utils/initSentry.ts	SENTRY_RELEASE read via envSentryRelease instead of process.env.SENTRY_RELEASE.
frontend/webpack.config.js	Removed dotenv import and bulk process.env injection via DefinePlugin. Only NODE_ENV and MCS_RUN_ENV remain.
frontend/Dockerfile	Added RUN NODE_ENV=production npx webpack (build at image build time). Added CMD ["pm2-runtime", "start", "pm2.json"].
docker-compose.yml / docker-compose.src.yml	Command changed from sh -c "npm run build-client:prod && pm2-runtime start pm2.json" to pm2-runtime start pm2.json.
frontend/config/common.json	Added "featureFlags" to exposedToBrowser array.

Contract: New field featureFlags: Record<string, string | undefined> in IBrowserConfig. Non-breaking — all existing fields preserved.

5. What to Test

5.1 Unit Tests (enviroment.test.ts)

getEnv — resolution priority

Env variable	Expected result
LANGUAGE_CODE set in both featureFlags and process.env	Returns value from featureFlags (priority over process.env)
HOST missing from both featureFlags and process.env	Returns undefined
SENTRY_DSN set in process.env only, featureFlags empty	Falls back to process.env value
BACKEND_URL set in process.env, __pneumaticConfig absent	Falls back to process.env value
WSS_URL set in process.env, config has no featureFlags key	Falls back to process.env value

Boolean feature flags (!== 'no' pattern)

Each flag follows the same contract: undefined → true, "no" → false, any other value → true.

Env variable	undefined	"no"	"yes" / other
CAPTCHA → isEnvCaptcha	true	false	true
GOOGLE_AUTH → isEnvGoogleAuth	true	false	—
MS_AUTH → isEnvMsAuth	true	false	—
SSO_AUTH → isEnvSSOAuth	true	false	—
SIGNUP → isEnvSignup	true	false	—
BILLING → isEnvBilling	true	false	—
AI → isEnvAi	true	false	—
PUSH → isEnvPush	true	false	—
STORAGE → isEnvStorage	true	false	—
ANALYTICS → isEnvAnalytics	true	false	—

Additional: AI = "yes" in process.env but "no" in featureFlags → isEnvAi = false (featureFlags wins)

String variables

Env variable	Expected result
SSO_PROVIDER = "okta"	envSSOProvider = "okta"
HOST = "https://app.pneumatic.app"	envHost = "https://app.pneumatic.app"
ANALYTICS_ID = "UA-12345"	envAnalyticsId = "UA-12345"
RECAPTCHA_SITE_KEY = "site-key-123"	envRecaptchaSiteKey = "site-key-123"
GOOGLE_CLIENT_ID = "google-id-123"	envGoogleClientId = "google-id-123"
SENTRY_RELEASE = "v1.2.3"	envSentryRelease = "v1.2.3"

envDevMode

Env variable	Expected result
NODE_ENV = "development"	envDevMode = true
NODE_ENV = "production"	envDevMode = false

envFirebase

Env variable	Expected result
All FIREBASE_* vars set in process.env	envFirebase object populated with all 8 fields
All FIREBASE_* vars set in featureFlags	envFirebase reads from featureFlags (priority)

5.2 Manual / Integration Tests

Preconditions

• Dev environment with Docker (docker-compose) or Railway staging.
• Access to Railway Dashboard (for env var change testing).
• Browser with DevTools.

Docker build & startup

Scenario	Expected result
docker-compose build frontend	Webpack builds during the build phase (logs show Compile is done!)
docker-compose up frontend	Container starts instantly — no webpack build at runtime
docker-compose build frontend without .env file	Build succeeds (webpack no longer depends on env vars)

SSR config injection

Scenario	Expected result
Open app → DevTools → Console → window.__pneumaticConfig.config.featureFlags	Object with 30 keys, values match container env vars
DevTools → Elements → find <script> with __pneumaticConfig	featureFlags block is present in HTML

Feature flags in UI

Env variable	Expected result
BILLING = "no"	Billing elements not shown in TopNav and auth flow
CAPTCHA = "no"	reCAPTCHA does not load on Login/Register pages
AI = "yes"	AI features available
SIGNUP = "no"	Signup link hidden on User page
Remove BILLING from env entirely	isEnvBilling = true (default-on behavior preserved)

Connectivity

Env variable	Expected result
WSS_URL	WebSocket connections (Notifications, Tasks, Workflows) established
BACKEND_URL	API requests go to the correct URL
SENTRY_DSN	Sentry.init called with correct DSN
SENTRY_RELEASE	Passed to Sentry release field

Edge cases

Scenario	Expected result
SSR context (typeof window === 'undefined')	getEnv falls back to process.env, no errors
__pneumaticConfig not loaded (JS error before hydration)	getEnv falls back safely, app doesn't crash

Local development

Scenario	Expected result
npm run dev	HMR works, variables from .env file available via process.env fallback

5.3 What Was NOT Tested

• Mobile devices (responsive) — not in scope.
• Locales (en/ru) — not affected.
• Production — testing in dev/staging only.
• Load testing — not performed.
• Public Forms separate entrypoint (forms.tsx) — behavior unchanged, but smoke-test recommended.

6. Affected Areas (Dependencies)

The enviroment.ts module is imported in 20+ files. Key consumers:

Component/Module	What to verify
commonRequest.ts	API requests use envBackendURL — requests go to correct URL
workflows/saga.ts, tasks/saga.ts, notifications/saga.ts	WebSocket via envWssURL — connections established
auth/saga.ts	Billing flow via isEnvBilling
settings/reducer.ts	Language via envLanguageCode
MainLayout.tsx	Analytics and Push via isEnvAnalytics, isEnvPush
TopNav.tsx	Billing UI via isEnvBilling
TeamInvitesPopup.tsx	Google/MS Auth via isEnvGoogleAuth, isEnvMsAuth
User.tsx	Signup link via isEnvSignup
Login.tsx, Register.tsx, ForgotPassword.tsx, ResetPassword.tsx	Captcha and auth providers
PublicForm.tsx	Feature flags in public forms
uploadFiles.ts	Storage via isEnvStorage
initSentry.ts	Sentry DSN and Release
analytics.ts	Analytics toggle

Minimum smoke-test: log in → open Dashboard → verify WebSocket → create workflow → open public form.

7. Refactoring

Scale: medium — core configuration module affected.

• enviroment.ts — complete mechanism replacement (30 variables), but exported API unchanged (same names, same types). Consumers require no changes.
• webpack.config.js — removed dotenv, simplified DefinePlugin.
• Dockerfile + docker-compose — moved build from runtime to build-time.

Additional testing: Ensure all 20+ consumers of enviroment.ts receive correct values. Smoke-test critical paths (see section 6).

8. Commits

• 7a5601a7 — 46741 feat(frontend): migrate environment variables to runtime config

9. Release Notes

Frontend environment variables migrated from build-time webpack injection to SSR runtime config. Feature flags are now served via window.__pneumaticConfig and can be changed via deployment dashboard without rebuilding the Docker image. Container startup time reduced by eliminating runtime webpack builds.

---

[!NOTE]
^{Cursor Bugbot is generating a summary for commit 7723849. Configure here.}

Changes since #213 opened

• Changed frontend Docker image build process to use npm run build-client:prod script instead of directly invoking npx webpack with NODE_ENV=production [7723849]
• Set NODE_OPTIONS environment variable to --max-old-space-size=3072 in the Dockerfile [3cfe1dc]

[pneumojoseph]

Describe the test cases clearly, make a table with two columns:
"Env variable", "Expected result"

[cursor]

Cursor Bugbot has reviewed your changes and found 2 potential issues.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 7723849. Configure here.}