Moderator role existed in the schema and was already respected by
comment deletion, but every admin page/route treated moderator
identically to a regular user (403/redirect). Wires it up narrowly:
admin/layout.tsx now lets admin+moderator through and filters the
nav by role, while every admin-only page (users, tiers, settings,
webhooks, insights, etc.) explicitly redirects moderators away via a
new requireFullAdminPage() helper -- the nav filter is UX, this is
the actual gate. Moderators land on Reports and Recipes: reports
GET/PATCH now accept requireAdmin({allowModerator: true}), and a new
PATCH /api/v1/admin/recipes/[id] lets admin+moderator unpublish a
public recipe (flip to private) as a takedown action, audit-logged.
Also found and fixed a real bug while auditing the PWA push pipeline
for a "push click-through" gap: public/sw.js had no `push` event
listener at all, so incoming push messages never displayed anything
-- push was silently non-functional end-to-end despite the
subscribe/send plumbing all working. Added the push listener
(showNotification) and a notificationclick listener that focuses an
existing tab or opens one at the payload's url.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Full read of routes/schema/components across recipes+AI, meal
planning/pantry/shopping/nutrition, social/messaging/notifications,
admin/billing/ops, and PWA/offline/mobile -- corrects several wrong
assumptions from earlier speculation (recipe-import-from-URL,
pantry barcode scan, and cooking-mode voice control all already
exist; they were guessed as missing before this audit).
Real confirmed gaps: no Stripe checkout/billing-portal (only the
webhook consumer exists), no recipe video, no nutrition trend view,
no OS share-target, no push click-through handling, no anonymous
meal-plan link, no offline coverage beyond recipes+mark-cooked.
Per user request, this file should be kept current going forward --
every shipped feature gets an entry here alongside the usual
version-bump/changelog/OpenAPI updates.
Arnaud