Cor 3895 docs for beta release

docs/platform/feature-flags/features.md

@@ -28,6 +28,22 @@ The Feature List Page is where all of your Features can be viewed, edited, and f
 
 Use the search input to search by Name, Key, Tag, or Description. The filters can be used to filter by Creator, Status, Type, or [Staleness](/platform/feature-flags/stale-feature-notifications). Each column header can be clicked to sort the column.
 
+### Kanban View
+
+On the Feature list page, users can switch between a List view and a **Kanban-style view** that displays Features grouped by their current [Status](/platform/feature-flags/status-and-lifecycle), allowing teams to quickly visualize progress across the Feature lifecycle.
+
+![image of kanban view](/dec-2025-kanban-view.png)
+
+In this view:
+
+- Each column represents a Feature Status
+- Each column header includes a total count of Features in each Status
+- Features appear as cards within the column matching their current Status, and can be sorted within each column according to the selected sort option (for example, by name or last updated date)
+- Columns are ordered based on the Status order defined in Project Settings
+- Status colors are reflected in the column headers for quick visual scanning
+
+This view is intended for high-level lifecycle tracking and workflow management. Selecting a Feature card opens the Feature detail view for configuration, targeting, and Variable management.
+
 :::info
 To view another Project's Features, use the Project dropdown on the top of the Dashboard.
 :::

docs/platform/feature-flags/status-and-lifecycle.md

@@ -3,67 +3,204 @@ title: Status and Lifecycle
 sidebar_position: 4
 ---
 
-# Status and Lifecycle Management in DevCycle
+# Feature Status and Lifecycle Management
 
-In DevCycle, Features have **Statuses** which indicate their current position in the Development LifeCycle. The statuses are a succinct way to understand a Feature's state, and each status has its own unique properties.
+In DevCycle, Features have **Statuses** that indicate their current position in the feature lifecycle. Statuses provide a clear, at-a-glance understanding of where a Feature is in its development, release, and cleanup process.
+
+Each Status belongs to a **Status Category**, which defines how the Feature behaves, what actions are allowed, and how it is displayed across the dashboard.
 
 ## Statuses
 
-Features in DevCycle can exist in one of three Statuses to indicate their current LifeCycle stage:
+Every Feature in DevCycle always has **one Status**, which determines its lifecycle stage.  
+By default, DevCycle provides a set of predefined Statuses aligned to core lifecycle categories.
+
+The default Statuses are:
 
-- **In Progress**
+- **Development**
+- **Live**
 - **Completed**
 - **Archived**
 
-Each status comes with its unique properties, affecting how a Feature behaves, can be interacted with, or is displayed in the dashboard.
+In addition to the default Statuses, teams can define **custom Statuses** within their Project settings. This allows teams to better align Feature lifecycle tracking with their internal development and release processes while preserving DevCycle's lifecycle guarantees. Each custom Status inherits the behavior of their Category.
+
+Status changes are **not automatic** and are always managed explicitly by the user.
+
+---
+
+## Status Categories
+
+Statuses are grouped into **Categories**, which define shared lifecycle behavior.
+
+### Development
+
+This Category represents Features that are actively being built, tested, or prepared for release.
+
+By default, new Features are created with the **Development** Status.
+
+While a Feature is in Development, all Targeting rules and Variations remain editable.
+
+This stage is typically used while work is ongoing and before a Feature is considered ready for a broader release.
+
+Below are some examples of different Statuses that would make sense in the Development Category:
+
+- _In Development_
+- _Pending Design_
+- _QA_
+- _Internal Testing_
+
+---
+
+### Live
 
-Status changes are not automatic and are maintained by the User.
+The Live Category represents Features that are actively running in production or being exposed to users.
 
-The following is a description of each status:
+While a Feature is Live, all Targeting rules and Variations remain editable.
 
-### In Progress
+Below are some examples of different Statuses that would make sense in the Live Category:
 
-When a Feature is created, it starts in this status. While a Feature is "In Progress," you can modify everything, have as many Variations as you'd like, and have complex targeting rules.
+- _Beta_
+- _Ramping_
+- _In Production_
+- _Live Experiment_
+
+---
 
 ### Completed
 
-One could consider a Feature "Complete" once it has been tested, approved, and is ready for release or has been fully released. When the User changes the status to "Complete", the Feature enters a semi-readonly state the Feature enters a semi-readonly state, limiting some editability such as restricting the addition of new Targeting Rules and Variations. Additionally, all Users will be served a single Variation. 
+The Completed Category represents Features that have reached the end of active development and rollout.
+
+A Feature may be considered Completed once it has been tested, approved, and is fully released, or when no further targeting changes are expected.
+
+When a Feature is moved into a Status within the **Completed** Category, it enters a **semi-read-only state**:
+
+- A single **final (release) Variation** must be selected
+- All Environments will serve this Variation to all users
+- Targeting rules are replaced with an "All users" rule
+- New targeting rules and Variations cannot be added
+- Variable values may still be edited
+- Environments can still be toggled on or off
+
+When using the CLI to generate TypeScript types, Variables belonging to a Feature in the Completed Category will be marked as **deprecated**.
+
+Below are some examples of different Statuses that would make sense in the Completed Category:
+
+- _Ready for Cleanup_
+- _All Users Enabled_
+- _Stable Release_
+
+#### Cleanup Checklist
+
+Upon entering a Completed Status, a cleanup checklist is shown for each Variable associated with the Feature.
+
+This checklist helps teams determine when it is safe to remove Variables from their codebase or archive them.  
+If a Variable is still referenced in code or evaluated in production, removing it may result in default values being served.
+
+If Code References are enabled, additional context will be provided to assist with cleanup.
+
+---
 
 ### Archived
 
-The "Archived" status is designed to be the terminal state for Features that have reached the end of their lifecycle, were never implemented in code, or have become entirely obsolete. 
+The Archived Category represents the **terminal lifecycle state** for Features. This Category and Status cannot be edited or changed.
+
+A Feature should be archived once it has been fully cleaned up and its Variables have been removed from the codebase.
+
+When a Feature is Archived:
+
+- It becomes fully read-only
+- It is hidden from standard dashboard views
+- Audit Logs remain accessible for historical reference
+- Metrics & Reach data will not be visible on the dashboard for Archived features
+
+Archiving Features helps keep both your dashboard and codebase clean while preserving valuable lifecycle history.
+
+> **Note:** Feature deletion still exists, but should only be used for mistakes. Deleting a Feature permanently removes it and its Audit Log. Archived Features retain historical data that may be used for future reporting and analysis.
+
+---
+
+## Changing Status
+
+### Moving a Feature to Completed
+
+When a Feature is moved into the Completed Category:
+
+- A final Variation must be selected
+- All Environments serve that Variation to all users
+- Existing Environment statuses are preserved
+- Targeting rules are replaced with a single "All users" rule
+- Additional Variations and targeting rules are locked
+
+### Reverting to Development or Live
+
+Features in the Completed Category can be reverted back to an earlier Status.
+
+When reverting:
+
+- Previous Variations become available again
+- Changes made to Variable values while Completed are retained
+- Prior targeting rules are **not restored** and must be reconfigured
+
+---
+
+## Viewing Features by Status (Kanban View)
+
+On the Feature list page, users can switch between a List view and a **Kanban-style view** that displays Features grouped by their current Status, allowing teams to quickly visualize progress across the Feature lifecycle.
+
+![image of kanban view](/dec-2025-kanban-view.png)
+
+In this view:
+
+- Each column represents a Feature Status
+- Each column header includes a total count of Features in each Status
+- Features appear as cards within the column matching their current Status, and can be sorted differently by selected criteria
+- Columns are ordered based on the Status order defined in Project Settings
+- Status colors are reflected in the column headers for quick visual scanning
+
+This view is intended for high-level lifecycle tracking and workflow management. Selecting a Feature card opens the Feature detail view for configuration, targeting, and Variable management.
+
+---
+
+## Managing Statuses
+
+Statuses are managed at the **Project level** and apply to all Features within that Project.
+
+Each Project starts with a default set of Statuses aligned to DevCycle's lifecycle categories. Teams may customize these Statuses to better reflect their internal workflows.
 
-A Feature should be archived after it has been cleaned up and its Variables removed from the codebase. Ideally, users should have also marked the Feature as **[Completed](/platform/feature-flags/status-and-lifecycle#completed)**  in DevCycle.
+### Project Settings
 
-Archiving Features helps clean up your dashboard and codebase by essentially putting the Feature into a read-only mode and hiding it from the standard dashboard views. Archived Features' Audit Logs are accessible and available for teams to review.
+Statuses can be viewed and managed from the **Project Settings** page under the **Feature Statuses** section.
 
-Feature deletion still exists; however, it is recommended that Delete only be used for mistakes. Deletion permanently removes the Feature and its Audit Log from DevCycle. Keeping archived Features will allow a team to retain valuable information about its history and hopefully in the future, will allow DevCycle to make reports on the Feature lifecycle using that information.
+![image of feature status section in project settings](/dec-2025-statuses-project-settings.png)
 
+From this page, users can:
 
-## LifeCycle and Changing Status
+- View all Statuses grouped by Category
+- Create new custom Statuses within supported Categories
+- Edit existing Status names (Note: each Status must have a unique key)
+- Reorder Statuses within a Category
+- Assign colors to Statuses for quick visual identification
+- Add a description to provide context behind what a Status represents
+- Select the default Status applied when a new Feature is created
 
-### Completing a Feature
+Changes made in Project Settings take effect immediately and apply across the Project.
 
-When a Feature is marked as "Completed," the following changes are implemented:
+#### Status Categories and Rules
 
-- Status changes to "Complete."
-- A "Release Variation" must be chosen which will be served to all Users for every Environment.
-- Targeting rules for all Environments will be replaced with an "All users" rule serving the selected "Release Variation"
-- Previously set Environment statuses are preserved.
-- Additional targeting rules cannot be added when a Feature is "Complete" and must be reverted to In Progress to do so.
-- The Variables section will display only one single Variation; you may not add more Variations.
-- Variable values can still be modified, and Environments can be toggled on and off.
-- When using the CLI code generator to [generate typescript types](https://docs.devcycle.com/sdk/client-side-sdks/javascript/javascript-typescript#cli), any Variables that are a part of a completed Feature will be marked as deprecated.
+Statuses must belong to one of DevCycle's predefined Categories.
 
-### Cleanup Checklist for Variables
+The following rules apply:
 
-Upon completing a Feature, you will see a cleanup checklist for each Variable associated with the Feature. You’ll have the option of [Cleaning up Variables](/platform/feature-flags/variables-and-variations/variables#cleaning-up-variables) which allows you archive or keep them permanently.
+- New Categories cannot be created
+- Each Category must contain at least one Status
+- The last remaining Status in a Category cannot be deleted
+- Status labels and ordering within a Category can be modified
 
-The details in the checklist will help you know when it's safe to remove the Variable from the Feature, or archive the Variable. If the Variable is still seen in code, or if evaluations are still seen in production, removing this Variable from the Feature could result in the Variable serving default values to Users. If Code References are enabled, additional details will be shown to inform you of where to remove the Variable from code, and variables will be marked as deprecated in code.
+### Permissions for Status Changes
 
-#### Reverting to In Progress
+#### Permission Rules
 
-The "Completed" status is reversible by clicking "Revert to In Progress."
+When permissions are enabled:
 
-- Previous Feature variations will be available again, but any new changes to Variables made while in the "Complete" status remain.
-- Past targeting rules will not be restored.
+- Statuses in the **Development** and **Live** Categories can be applied by any user with access to the Project
+- Statuses in the **Completed** and **Archived** Categories can only be applied by users with the **Publisher** permission
+- Only **Publishers** can create, and modify Feature Statuses in the Project Settings