Port existing Feature Flag implementation into Cellix

[noce-nick]

Summary

Add the initial feature flag infrastructure to Cellix and Owner Community so application code can load and evaluate feature flags at runtime.

The implementation should follow the existing approach used in applications such as CVHP, EFDO, or PWY, while refactoring the implementation as needed to make it suitable for reuse within the Cellix framework.

This task is limited to making feature flag values available to frontend and backend runtime logic. No existing functionality is required to be controlled by feature flags as part of this task.

Requirements

Feature Flag Configuration

• Add a feature flag JSON file to the repository for local development.
• Define a clear, strongly typed structure for the feature flag configuration.
• Populate the local feature flag file with the standard maintenance-related feature flags currently used throughout our enterprise applications.

At a minimum, the local feature flag configuration must include the following entries:

Staff Portal

• MAINTENANCE_MSG_SYSTEM_UI_STAFF_PORTAL
• MAINTENANCE_MSG_IMPENDING_UI_STAFF_PORTAL
• MAINTENANCE_IMPENDING_TIMESTAMP_UI_STAFF_PORTAL
• MAINTENANCE_START_TIMESTAMP_UI_STAFF_PORTAL
• MAINTENANCE_END_TIMESTAMP_UI_STAFF_PORTAL
• MAINTENANCE_UPCOMING_UI_STAFF_PORTAL

Community Portal

• MAINTENANCE_MSG_SYSTEM_UI_COMMUNITY_PORTAL
• MAINTENANCE_MSG_IMPENDING_UI_COMMUNITY_PORTAL
• MAINTENANCE_IMPENDING_TIMESTAMP_UI_COMMUNITY_PORTAL
• MAINTENANCE_START_TIMESTAMP_UI_COMMUNITY_PORTAL
• MAINTENANCE_END_TIMESTAMP_UI_COMMUNITY_PORTAL
• MAINTENANCE_UPCOMING_UI_COMMUNITY_PORTAL

These feature flags are not required to affect application behavior as part of this task. They only need to be available for future runtime consumption.

Deployed Feature Flag Configuration

For deployed environments, feature flags should be loaded from a JSON file hosted in the application's public Azure Blob Storage container, following the existing enterprise application convention.

The deployed feature flag filename should follow the format:

<APP_CODE>_Feature_Flag_<ENV>.json

For Owner Community, this resolves to:

OCM_Feature_Flag_PROD.json

The implementation should follow the existing approach used by CVHP, EFDO, or PWY. Creation of the deployed feature flag file is outside the scope of this task.

Frontend

Implement the necessary frontend infrastructure to:

• Load feature flags during application startup.
• Make feature flags available throughout the application at runtime.
• Provide a strongly typed mechanism for retrieving feature flag values.
• Gracefully handle missing, malformed, or unavailable feature flag configuration.
• Share the implementation across both Owner Community portals where appropriate.

Application code should consume feature flags through the provided abstraction rather than directly loading or parsing the JSON configuration.

Backend

Implement the necessary backend infrastructure to:

• Load feature flags for the running application environment.
• Make feature flags available to backend runtime logic.
• Provide a strongly typed mechanism for retrieving feature flag values.
• Avoid repeated network requests or JSON parsing throughout the application.
• Gracefully handle missing, malformed, or unavailable configuration.

The implementation should integrate naturally with the existing Cellix application startup and dependency initialization patterns.

Shared Design

This implementation should establish the foundation for future feature flag usage throughout Cellix.

Where practical, reusable framework-level components should be introduced instead of duplicating application-specific logic.

Future work—including Tech Admin feature flag management, maintenance banners, impending maintenance messaging, and reusable maintenance providers—is explicitly outside the scope of this task.

Testing

Add automated test coverage for:

• Successful feature flag loading.
• Retrieval of configured feature flag values.
• Missing feature flag values.
• Missing feature flag configuration.
• Malformed feature flag configuration.
• Environment-specific configuration resolution.

Add any necessary Owner Community verification coverage to confirm feature flags are successfully initialized and available to both frontend and backend runtime code.

Acceptance Criteria

• A local feature flag JSON configuration exists within the repository.
• The configuration includes the expected maintenance-related feature flags for both the Staff Portal and Community Portal.
• Frontend runtime code can retrieve feature flag values through a typed abstraction.
• Backend runtime code can retrieve feature flag values through a typed abstraction.
• Feature flags can be loaded from a public Azure Blob Storage JSON file in deployed environments.
• Missing or invalid feature flag configuration results in predictable fallback behavior without causing uncontrolled application failure.
• No existing application functionality is required to be controlled by feature flags as part of this task.
• Automated tests cover the expected loading, retrieval, and failure scenarios.