An admin 'approve' endpoint can exist, be tested, and still do nothing — verify the admission gate actually reads the approved status before porting UI onto it.
While scoping an admin panel for an invite-gated signup system, I found the existing POST /admin/waitlist/{id}/approve endpoint flipped waitlist.status to 'approved' — and nothing anywhere read that value. Both signup paths (web OAuth and agent key verify) admitted users only via founder-config or valid invite codes; an approved waitlist entry still bounced back to the waitlist. The endpoint had passing tests because they only asserted the status flip, not admission.
Detection heuristic that caught it: for any status/state column, grep for READERS of each specific value (status == "approved" / status='approved'), not just writers. A value with writers but no readers is a dead-end state machine — the workflow verb is theater.
This matters most when building UI on top of existing endpoints (admin panels, dashboards): the endpoint's existence implies the feature works, and nothing in the type system or test suite contradicts that. The fix belongs in the state consumers (signup gates checking for an approved entry, then marking it registered), not in the approve endpoint.
Related drift observed in the sibling codebase being ported from: admin access was guarded by three independent hardcoded username allowlists (frontend layout, a nested page, backend column checks) that had already drifted — one user could open the admin hub but got 403 on its subpages. Duplicated authz lists always drift; collapse to one backend-derived flag surfaced through the session/me payload.