The "Forked from X" backlink only worked one direction. The original recipe now also shows "Forked by N others" with links to each fork — filtered to forks that are public/unlisted or belong to the viewer, so a private fork never leaks its existence or title to other viewers of the original.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
UpgradeDialog's CTA now sends users to Settings > Billing (with a feature-specific banner) instead of a generic support-ticket prefill, and fires a best-effort tracking beacon recording which feature triggered the click. New feature_upgrade_clicks table + Admin > Insights chart ("Most-requested locked features") gives admins visibility into which locked features actually drive upgrade interest.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Recipe version history is now gated like the other 9 per-tier features (enabled by default, locked-vs-hidden treatment via isFeatureAvailableAnyTier). UpgradeDialog now shows a tagline + concrete bullet list per feature instead of one generic sentence.
Also closes a real gap: the AI-generate dialog's Photo tab hit /api/v1/ai/import-photo directly with no tier check in the UI (server route was already correctly gated) — a locked-out user could fill it in and hit a dead-end error instead of an upgrade prompt. Now threaded through the same lock/hide props as the dedicated PhotoImportButton.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Rule, applied consistently everywhere via a new isFeatureAvailableAnyTier() helper: if a feature is enabled on at least one tier, it stays visible for locked-out viewers with a small "Pro" badge and opens an upgrade prompt on click; if a feature is disabled on every tier, it hides entirely, since there's no upgrade path to point at.
Covers: recipe variations, meal/drink pairings, nutrition estimation, Markdown export (5 call sites), weekly nutrition, import from URL, import from photo, and the Instacart grocery-delivery menu item. Previously inconsistent — some hid outright, one showed a lock icon overlapping its own icon.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
The lock icon overlapping the branch icon looked bad. Button is visible again when locked (not hidden) — click opens the upgrade dialog, tooltip shows a small "Pro" badge instead of an icon overlay.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Was the one gated feature still shown as a clickable disabled button with a small lock icon overlay, opening an upgrade dialog on click. Every other gated feature (pairings, nutrition estimate, markdown export) hides entirely instead — brought this one in line and removed the now-dead locked/UpgradeDialog code from VariationsButton.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
getMarketingLocale() only ever read the marketing_locale cookie, defaulting anonymous first-time visitors to English until they manually used the language switcher — even though the switcher and a full French translation already existed. Now falls back to parsing Accept-Language when no cookie is set; an explicit switcher choice still wins on every later visit.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
New accounts land on a 3-step wizard after signup — welcome, dietary preferences & allergens, notification opt-in — skippable at every step, shown once via a users.onboardingCompletedAt gate in the (app) layout. Existing accounts are backfilled as already-onboarded.
Also gives the allergen-preferences step a real write path: user_allergens previously only had a GDPR-export read.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Adds a new user_billing_details table (1:1 with users, separate from the display name) with a form and GET/PUT API route. Full name is required by the form/API; address and phone stay optional. Not wired into Stripe invoicing yet — just captured for future use.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Adds a general-purpose "mark cooked" dialog for any recipe (not just batch-cook dishes), with a date picker for backdating and a pantry-deduct checkbox defaulted on. Also flips the previously dead-in-the-UI deductFromPantry flag to true for the existing batch-cook and meal-planner cook actions.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Extends the existing feature-flags system (previously 3 keys, all
default-enabled) with 6 more: recipe_import_url, recipe_import_photo,
nutrition_estimation, markdown_export, weekly_nutrition,
grocery_delivery. Each FEATURE_DEFINITIONS entry now carries its own
defaultEnabled -- the new 6 default to false, the original 3 stay
true -- so no migration/seed was needed for the "off by default"
requirement, just a per-key fallback instead of a blanket true.
Gated server-side (requireFeatureEnabledResponse, a new shared
helper avoiding six copies of the same try/catch) on: import-url,
import-photo, nutrition POST estimate, bulk markdown export, weekly
meal-plan nutrition GET, Instacart export. Gated client-side by
hiding the trigger entirely (not just disabling) on every page that
renders one: recipe detail (meal/drink pairing buttons, nutrition
panel's estimate button, markdown export), recipes list (import-URL
button, including the OS Share Target auto-import path), new-recipe
page (photo import), meal-plan page (markdown export, weekly
nutrition bar), shopping-list/collection/pantry pages (markdown
export), shopping-list page (Instacart button, now gated by both the
existing env-var check AND the tier flag).
Also: BYOK section on Settings -> AI now hidden entirely for
non-BYOK users (previously showed a locked-and-teased notice, same
inconsistency the Model Prefs fix closed yesterday). Language
switcher shows a flag icon (FlagGB/FlagFR, moved from
components/marketing to components/shared so both the logged-in
settings switcher and the logged-out marketing one can use it)
instead of plain "English"/"Français" text-only options.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Settings -> AI's model-selection form (per-use-case provider + model
ID picker) had no access gate -- every user could see and use it,
regardless of whether they had a BYOK key to route calls to or any
reason to care which model served a request. Now gated behind
isByokEnabled, same reasoning as BYOK itself: picking a specific
provider/model only makes sense once you have your own key. Hidden
entirely for everyone else, not locked-and-teased -- there's nothing
for a non-BYOK user to unlock here.
GET/PUT /api/v1/users/me/model-prefs switched from requireSession to
requireByok to match.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
5 parallel domain re-sweeps against current code (last full audit was
2026-07-21/22, three days of heavy shipping since -- billing,
developer/BYOK permission split, moderator scoping). Corrections and
additions:
- Fixed stale admin nav count (13 -> 15 sections, was missing Billing
entirely).
- Closed the /r/[id] followers-visibility gap that was flagged open --
it's fixed in code, found a new inconsistency in its place: a
followers-only recipe never shows on the author's own profile grid.
- Corrected "auto-deduct pantry on cook" -- the API logic is real and
correct but both UI callers hardcode it off, so it never fires in
practice. Was overstated as "Exists, one nuance."
- Fixed "bulk-set-week" mislabel (it's bulk-clear only, no bulk-create).
- Added several undocumented features: recipe notes, manual nutrition
entry, AI conversation thread management + chat-history search,
two more draft-recipe AI endpoints, the authenticated meal-plan
collaboration UI (distinct from the public link), move-to-pantry
button, pantry bulk-merge, public shopping-list page + print/QR,
add-to-shopping-list AI tool, leftover-cron scope limitation.
- Noted shopping-list collaboration now supplements polling with real
push notifications on add/check events.
New "Consumer-friendliness assessment" section directly answers
whether Epicure has too many technical/developer-oriented features
for a home-cook audience: mostly no -- API keys, webhooks, BYOK,
OpenAPI docs, and self-serve developer access are all real surface
but properly gated and hidden from nav by default. One genuine
exception found and flagged: Settings -> AI's Model Prefs picker lets
every user pick raw model IDs with zero gating -- the one place a
developer-tool control was left unfenced on a consumer screen.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Implements plans/STRIPE_PLAN.md sections 1-9 for solo Pro/Family
billing (family multi-user sharing, section 1a, deliberately deferred
-- flagged in that plan as the most novel/error-prone piece).
Decisions locked in: cancel/downgrade at period end (Stripe Portal
default), no trial period.
- lib/stripe.ts: single client factory reading STRIPE_SECRET_KEY via
site-settings (DB overrides env, same pattern as every other
provider key in this codebase).
- Webhook route rewritten on the real `stripe` SDK
(stripe.webhooks.constructEvent replaces the hand-rolled HMAC
verifier) and now handles the full event set: checkout.session.completed,
customer.subscription.{updated,deleted}, invoice.{payment_failed,paid}.
past_due deliberately never downgrades tier on its own -- Stripe
retries the card first, recovering via invoice.paid or eventually
giving up via subscription.deleted. Every handler audit-logs under
billing.<event>. Dedup via the existing processed_stripe_events
table, unchanged.
- Schema: tierDefinitions gained stripe{ProductId,PriceIdMonthly,
PriceIdYearly} (the lookup table mapping a Price back to a tier on
checkout); users gained stripeSubscriptionId/subscriptionStatus/
currentPeriodEnd.
- New POST /api/v1/billing/checkout (creates a subscription Checkout
Session, allow_promotion_codes: true), POST /api/v1/billing/portal
(Stripe's hosted self-serve cancel/upgrade/card-update), GET
/api/v1/billing/status.
- /settings/billing: current plan + renewal date, past_due warning,
usage-vs-limits (reuses the existing UsageQuotaSection), plan
comparison cards with per-tier Checkout buttons, manage-billing
button once a Stripe customer exists.
- /admin/billing: connection status (test/live mode detection),
subscriber counts, past-due list, recent billing audit events, link
to Stripe Dashboard. Tier Limits page extended with the three Stripe
price fields per tier (own render branch, not the numeric+Unlimited-
switch machinery the existing fields use).
Before going live: an admin needs to create real Products/Prices in
Stripe, enter the IDs on Tier Limits, and configure the Stripe-side
webhook endpoint -- all operational steps the plan always called for,
none of it code.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Splits what was one isDeveloper flag (gating webhooks, API keys, AND
BYOK together) into two independent permissions:
- isDeveloper (webhooks + self-serve API keys): admin-toggled as
before, but now ALSO self-serve -- PATCH /api/v1/users/me/developer-access
lets any paid-tier (tier !== "free") user turn it on themselves, no
added fee. Free tier still needs an admin grant. Turning it off is
always self-serve regardless of tier, since revoking your own
access needs no gatekeeping. canSelfServeDeveloperAccess() in
lib/permissions.ts is the single check for "is this tier eligible."
- isByokEnabled (BYOK AI provider keys): new column, admin-only, no
self-serve path at all -- routing real AI provider spend through
Epicure on the user's own key warrants a manual admin check-in that
webhooks/API access don't need. requireByok() replaces
requireDeveloper() on the three ai-keys routes.
Migration adds is_byok_enabled and grandfathers in anyone who already
has a BYOK key configured (the earlier grandfather migration only
covered the combined isDeveloper flag, which BYOK no longer reads).
Settings UI: webhooks/API-keys pages show a self-serve "Enable"
toggle for paid-tier non-developers instead of the locked notice
(still shown to free-tier users), plus a "Disable developer access"
link once enabled. Settings -> AI's BYOK section now checks
isByokEnabled instead of isDeveloper -- unaffected by the self-serve
change, still fully admin-gated.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Webhooks, self-serve API keys, and BYOK AI provider keys had zero
access gating -- any logged-in user, any tier. Adds users.isDeveloper
(boolean, admin-toggled in admin/users/[id] alongside role/tier),
checked via a single hasDeveloperAccess() (lib/permissions.ts) so a
future subscription-tier auto-grant is a one-line change there, not
a redesign across call sites.
requireDeveloper() (lib/api-auth.ts) wraps requireSession() with a
fresh isDeveloper check (same reasoning as requireAdmin re-querying
role: session.user's cookieCache can be up to 5 minutes stale) and
replaces requireSession in all 8 gated routes: webhooks CRUD +
deliveries + redeliver, api-keys CRUD, ai-keys CRUD.
Settings UI: the sidebar hides API Keys/Webhooks nav entries for
non-developers; those pages and the BYOK section of Settings -> AI
show a locked notice instead of the manager component when accessed
directly.
Migration grandfathers in anyone who already has a webhook, API key,
or BYOK key row -- ships as a new gate on existing features, not a
silent lockout of active integrations.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
estimateNutrition() (lib/ai/features/estimate-nutrition.ts) is now a
hybrid: for each ingredient, estimateGrams() (lib/ingredient-grams.ts)
converts its quantity+unit to grams where possible (weight units
exactly; volume units -- cup/tbsp/tsp/ml/l/etc -- via a 1ml~=1g water-
density approximation, documented as a real simplification but far
better than skipping them). Convertible ingredients get looked up in
USDA FoodData Central (lib/usda.ts, SR Legacy + Survey (FNDDS)
datasets -- the two suited to generic/raw ingredients, not Branded
packaged products or narrower Foundation) and summed. Whatever's left
(count-based units like "2 cloves", no USDA match, or USDA_API_KEY
unset entirely) goes through one AI call asking for just that
subset's total contribution, which sums directly with the USDA
totals -- no whole-recipe AI estimate to reconcile against.
Same exported signature and return shape as before
(NutritionEstimate / {perServing: {...}}), so every existing caller
(the nutrition route, meal-plan generation) gets more accurate
results automatically once USDA_API_KEY is set in Admin -> Settings,
with zero behavior change when it isn't.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Extends GET /api/v1/users/me/nutrition-diary with a `range` query
param (7/30/90) that switches it into trend mode -- daily
calorie/macro totals bucketed from the same cooking-history rows the
single-day diary already reads, with zero-filled days so the chart
has a continuous x-axis. New NutritionTrend component reuses the
existing hand-rolled TimeSeriesChart (previously admin-only, now
imported from user-facing code too) for the calorie line, plus
simple average-macro stat tiles below it.
Nutrition page now has Diary/Trend tabs instead of just the diary.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Mirrors shopping lists' isPublic pattern but read-only only -- no
publicEditable equivalent, since anonymous editing of someone's
weekly meal schedule isn't a real use case the way collaborative
shopping-list editing is. New PATCH /api/v1/meal-plans/{weekStart}
toggles it (lazily creates the week's plan row if missing, same
pattern as the existing POST). Public page at /m/[id] renders the
week grouped by day, linking through to public/unlisted recipes and
just showing the title otherwise.
ShareMealPlanButton gained the same public-link toggle UI as its
shopping-list sibling, plus a QR code (generated client-side via the
already-installed `qrcode` package) for the link once enabled --
handing someone a printed or screenshotted plan doesn't require
typing a URL.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Declares share_target in manifest.ts (action /recipes, GET,
title/text/url params). recipes/page.tsx extracts the shared link --
preferring the url param, falling back to the first http(s) URL
found inside text since senders vary on where they put it -- and
passes it to RecipesHeader as sharedUrl. UrlImportDialog gained
initialUrl/autoImport props so the existing import-from-URL flow
opens pre-filled and fires immediately instead of requiring the user
to paste the link back in.
Chromium/Android only -- Safari has no Share Target API at all,
same restriction already documented for the install-prompt banner.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
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