Area: Engagement (audit p9) · Surface: /admin/badges, Badge model, AdminBadgeController · Dimension: competitor-gap · Severity: minor
Circle, Discourse, and Skool all support rule-based badges that award automatically (e.g. '100 helpful reactions', 'answered 25 questions', 'top contributor this month'). Manual-only badges don't scale — an admin won't hand-assign a 'Helpful' badge to hundreds of members, so the badge wall stays sparse and meaningless. We already built criteria-driven badges for mobieusLearn; the community badge system should inherit the same engine so admins can define a condition once and let it award itself.
Evidence
The Badge model is pure manual CRUD with an is_assignable flag (src/Models/Badge.php:44-77) and AdminBadgeController exposes only manual create/edit/assign/remove (src/Controllers/AdminBadgeController.php: index/edit/update/create/delete/assign/remove). There is no criteria/condition column and no engine that auto-awards a badge. By contrast, the LMS side DOES have criteria-driven badges (database/migrations/2026-06-03-learn-badge-criteria-narrative.sql, 2026-06-03-learn-phase2-badges.sql) — proving the capability exists in code but was never extended to the community badge system.
Suggested fix. Add an optional criteria definition to community badges (reusing the Achievement checkAndGrant condition vocabulary + the Learn badge-criteria pattern) and an awarder that runs on the same hooks as Achievement::checkAndGrant. Keep manual assignment for one-off honors.
Filed by the automated tenant-app audit and adversarially evidence-verified. Status: verified. Open — not yet actioned.
Patrick Bass
@mobieus