Flags

Kung saan nakatira ang mga feature flag ng proyekto: ang estado, serve share at yugto ng lifecycle ng bawat flag, ineedit sa mismong lugar at nalalapat nang walang release. Hiwalay na inihahain ng screen ang Live at Test na kapaligiran.

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).