Review a feature before enabling it for real users. This prompt adds one feature flag and connects it to the Edgenivo Toolbar so teammates can inspect both states in preview deployments.
Open or import the application and identify the feature you want to gate. The handoff includes prompt text only; repository access, Edgenivo project access, and credentials must be available separately.
Expect a safe default, a preview override flow, and checks that flag states stay isolated between visitors. The prompt prepares the implementation locally and leaves production targeting and release decisions for a separate step.
Put one existing feature behind a feature flag and make both states reviewable in preview deployments through Edgenivo Toolbar. Read repository instructions and inspect the framework, package manager, flag provider, installed Flags SDK, environment configuration, authentication, and rendering/cache patterns. If the intended project is missing, ask me to open or import it. Ask which feature to gate if unclear. Reuse the existing provider and SDK integration. If none exists, propose a supported integration for this framework and explain required account setup before assuming it is available. Read installed-version documentation before choosing APIs. Use a descriptive flag name and a default that preserves current behavior. Keep the enabled branch scoped to the chosen feature. Evaluate flags on the server when they control server behavior, private data, or access to a server action. Enforce authorization independently of the flag, including direct requests to the underlying endpoint. A flag override must never grant permissions. Connect flag definitions and observed values to Flags Explorer using its documented integration. Protect discovery and override verification with the supported server-side mechanisms; keep secrets out of the browser bundle. Use Development and Preview configuration intentionally and leave Production targeting unchanged. Inspect credential scoping so a locally supplied key cannot accidentally select production settings. Do not create a general unauthenticated query parameter that enables features. Make preview overrides explicit and reversible. Document how a reviewer selects each state and clears the override. Keep the initial rendered state consistent with hydration and navigation. Inspect caching so one visitor’s override or user-specific evaluation cannot leak to another visitor, and describe any change to static rendering or cache behavior. Using existing test tools, cover the default, enabled state, cleared override, missing provider configuration, invalid override, direct unauthorized endpoint access, and two visitors with different states. Check keyboard access and loading/error behavior in both feature states. Run local checks and document any Toolbar interaction that needs an actual preview deployment. Proceed with local code and fixtures. Ask before provisioning services, changing shared environment variables, deploying, or changing production targeting. Report the implementation, actual checks and results, blocked checks, configuration and local run steps, preview review instructions, and remaining rendering or override limitations.