Following directly from the tenants migration-collision issue elsewhere in this audit: even once the schema question is resolved and max_creators/max_tips_per_day genuinely exist as columns, it's worth separately confirming whether any code path actually reads and enforces those quotas (e.g. rejecting creator registration once a tenant's max_creators is reached, or throttling tip recording once max_tips_per_day is hit) — as opposed to the columns existing purely as unenforced metadata. Given the columns don't even exist in the live schema today, it seems unlikely any enforcement code currently runs successfully.
Task: Grep for any read of max_creators/max_tips_per_day outside of the migration files and TenantProvisioner's (currently broken) insert. If no enforcement exists, this is effectively an entire unimplemented feature masquerading as done (schema + provisioning API present, actual business rule absent) — implement the enforcement checks, or clearly document that quotas are metadata-only for now.
Following directly from the
tenantsmigration-collision issue elsewhere in this audit: even once the schema question is resolved andmax_creators/max_tips_per_daygenuinely exist as columns, it's worth separately confirming whether any code path actually reads and enforces those quotas (e.g. rejecting creator registration once a tenant'smax_creatorsis reached, or throttling tip recording oncemax_tips_per_dayis hit) — as opposed to the columns existing purely as unenforced metadata. Given the columns don't even exist in the live schema today, it seems unlikely any enforcement code currently runs successfully.Task: Grep for any read of
max_creators/max_tips_per_dayoutside of the migration files andTenantProvisioner's (currently broken) insert. If no enforcement exists, this is effectively an entire unimplemented feature masquerading as done (schema + provisioning API present, actual business rule absent) — implement the enforcement checks, or clearly document that quotas are metadata-only for now.