Central Station / YPM-ARCHIVE-ADMIN-FEATURE-FLAG-MANAGEMENT

Admin feature flag management

archive/admin-feature-flag-management.md · Updated 2026-05-13
GET /api/tickets/YPM-ARCHIVE-ADMIN-FEATURE-FLAG-MANAGEMENT

Summary

PR #113 merged; admin controls available for targeted rollouts

4Questions 0Links 0Comments 1PRs
Open questions 4 items
  1. 1 Which roles can access the flag management surface?
  2. 2 What is the minimum audit trail required before pilots?
  3. 3 Does this manage only global flags for now, or also org/class/user targeting in v1?
  4. 4 How should new flag definitions be declared so code, seed data, and admin UI stay in sync?
Spec body Markdown
# Admin feature flag management

Give operators/admins a safer way to view and manage DB-backed feature flags without manual SQL for every preview, pilot, and production rollout.

## Problem

Several active Yawp specs now depend on feature flags:

- Revision flow should seed disabled-by-default and be enabled intentionally for pilots.
- Released grades organization is shipped behind `feature_released_grades_organization`.
- AssignmentType visibility and Course view both need staged rollout.
- Teacher dashboard cleanup depends on these flags being understandable during preview/prototype review.

Manual SQL is workable for a one-off, but it makes pilot state easy to lose track of and slows down Brian/Kevin review cycles.

## Current status

`yawp-2.0` PR #113 merged on 2026-05-09 with passing TypeScript, Terraform, Playwright E2E, and preview deploy checks.

## Goals

- Admin/operator can see current feature flags and targeted rollout state.
- Admin/operator can enable or disable a flag for the intended target scope without hand-editing SQL.
- New flags can be seeded disabled-by-default so preview/prod environments do not need emergency manual setup.
- Changes are auditable enough for pilots: who changed what, when, and for what target.

## Non-goals

- Building a full experimentation platform.
- Letting teachers or students self-enable unreleased features.
- Replacing the product decision process. Brian still approves student-facing pilot exposure before rollout.

## Open questions

- [ ] Which roles can access the flag management surface?
- [ ] What is the minimum audit trail required before pilots?
- [ ] Does this manage only global flags for now, or also org/class/user targeting in v1?
- [ ] How should new flag definitions be declared so code, seed data, and admin UI stay in sync?

## Rollout

Keep behind admin-only access. Use it first for internal preview flags, then for the next Brian-approved pilot rollout. Do not use it to widen student-facing features until the underlying feature spec says rollout is approved.
Repo sync Metadata
{
  "url": "https://github.com/The-Connell-School/yawp-2.0/pull/113",
  "repo": "The-Connell-School/yawp-2.0",
  "draft": false,
  "state": "MERGED",
  "title": "[codex] Add admin feature flag management",
  "branch": "codex/admin-feature-flags",
  "checks": {
    "total": 7,
    "failing": 2,
    "pending": 0,
    "successful": 5
  },
  "number": 113,
  "syncedAt": "2026-05-26T21:38:23.522Z",
  "mergeable": "UNKNOWN"
}