Summary
PR #113 merged; admin controls available for targeted rollouts
4Questions
0Links
0Comments
1PRs
Open questions
- 1 Which roles can access the flag management surface?
- 2 What is the minimum audit trail required before pilots?
- 3 Does this manage only global flags for now, or also org/class/user targeting in v1?
- 4 How should new flag definitions be declared so code, seed data, and admin UI stay in sync?
Spec body
# 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
{
"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"
}