Flags

Donde viven las feature flags de un proyecto: el estado, la cuota de servicio y la etapa del ciclo de vida de cada flag, editados en el sitio y aplicados sin release. La pantalla sirve por separado los entornos Live y Test.

The grid

Each row is one flag: its key, its state toggle, how much traffic it serves and when it was last evaluated. Rows carry a lifecycle stage, and the ordering surfaces the stages that want attention first: stale (nothing has evaluated it lately) and cleanup (past the lifespan its intent declares) sort ahead of live, develop and define. The toolbar narrows by search, the Active and Archived tabs split the population, and the grid's layout is a stored preference.

Flipping a toggle asks for confirmation before it changes what traffic sees, and the write is permission-gated: a reader without the flags write grant sees the state without the lever.

Opening a flag

Selecting a row opens the flag: its description, intent, rollout and variations. Variation weights rebalance as you drag, so the set always sums to one hundred rather than failing on save. Archiving asks first and archived flags keep their history: the Archived tab restores them. A flag deep-links as ?flag=<key>, so a row in a code review can point at the exact switch it discusses.

Where this meets the API

The concept behind the screen is the Flags pillar. On the wire: reads are GET /v1/flags and GET /v1/flags/snapshot (API reference), writes are the upsertFlag and archiveFlag mutations (GraphQL reference), every change fans out as flagChange on the project room (Realtime events), and agents reach the same operations through prodantix.flags.list, .upsert and .archive (MCP tools).