@12-apps/prisma 6.5.0 → 6.6.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@12-apps/prisma",
-  "version": "6.5.0",
+  "version": "6.6.0",
   "sideEffects": false,
   "description": "Prisma host: the multi-file schema folder, the plugin migration seam, and the shared PrismaClient singleton with its audit / append-only extensions",
   "main": "dist/index.js",
@@ -69,7 +69,7 @@
   "devDependencies": {
     "@12-apps/audit": "^5.7.1",
     "@12-apps/auth": "^2.19.0",
-    "@12-apps/discounts": "^1.12.0",
+    "@12-apps/discounts": "^1.13.0",
     "@12-apps/entitlements": "^3.10.0",
     "@12-apps/entity-lifecycle": "^4.13.0",
     "@12-apps/eslint-config": "^1.22.0",
@@ -77,11 +77,11 @@
     "@12-apps/i18n": "^1.3.0",
     "@12-apps/jobs": "^4.5.0",
     "@12-apps/mcp": "^3.16.0",
-    "@12-apps/notifications": "^4.8.0",
+    "@12-apps/notifications": "^4.9.0",
     "@12-apps/onboarding": "^2.7.0",
-    "@12-apps/payments-backend": "^4.24.0",
+    "@12-apps/payments-backend": "^4.26.0",
     "@12-apps/product-research": "^2.10.0",
-    "@12-apps/rbac": "^4.13.0",
+    "@12-apps/rbac": "^4.14.0",
     "@12-apps/realtime": "^2.6.0",
     "@12-apps/report-builder": "^5.14.0",
     "@12-apps/shift": "^3.4.0",

package/prisma/migrations/20260830120000_discount_weekly_schedule/migration.sql

@@ -0,0 +1,40 @@
+-- @12-apps/discounts: the WEEKLY schedule (FUT-996).
+--
+-- "Toda sexta, das 16:00 às 20:00" — a recurring window INSIDE the campaign
+-- `[starts_at, ends_at)`, which until now was the only scheduling a rule had.
+--
+-- ── PURELY ADDITIVE, AND THAT IS THE POINT ────────────────────────────────
+-- One nullable column, no backfill, no CHECK to widen, nothing dropped. NULL
+-- means "always, within the campaign window", which is exactly what every
+-- existing row already means — so this migration cannot change the price of
+-- anything, and the release carrying it needs none of the expand/contract
+-- ceremony a destructive DDL would (see the host's CLAUDE.md on why a
+-- `DROP COLUMN` takes production down for the length of a healthcheck).
+--
+-- Replay-safe like its predecessor: `IF NOT EXISTS` throughout.
+--
+-- ── WHY JSON RATHER THAN A FOURTH TABLE ───────────────────────────────────
+-- The recurrence is not SQL-queryable in any useful way. The admin grid's
+-- vigência filter already punts on comparing two nullable timestamps against
+-- `now()` and rides as a separate parameter the store resolves, so a schedule
+-- table would buy queryability that nothing asks for — while adding a third
+-- `include` to `loadDiscountRules`, which is on the storefront's hottest read
+-- (a whole menu page's badge preview walks it once per request).
+--
+-- The trade is stated plainly: the database cannot check this column's SHAPE.
+-- `assertSchedule` in `src/server/validate.ts` is the only gate in front of it,
+-- and the evaluator is deliberately tolerant of a row that got past it — a
+-- malformed window covers NOTHING rather than everything, so the failure mode
+-- of a bad blob is a promotion that does not fire, never a cart priced at zero.
+--
+-- Shape, for a reader with only the database in front of them:
+--
+--   {"windows":[{"days":[4],"from":"16:00","to":"20:00"}]}
+--
+--   * `days`  — Monday-first, 0..6. NOT `Date#getDay()`'s Sunday-first axis.
+--   * `from`/`to` — "HH:MM", 24-hour, in the STORE's timezone, half-open
+--     [from, to) exactly as [starts_at, ends_at) is.
+--   * `to` < `from` means the window runs past midnight (a bar shutting at
+--     02:00), which is the most common happy hour there is.
+
+ALTER TABLE "discounts" ADD COLUMN IF NOT EXISTS "schedule" JSONB;

package/prisma/plugin-migrations.json

@@ -37,6 +37,7 @@
     "20260821120000_shift_kind_host_vocabulary",
     "20260821140000_discounts_package_owned",
     "20260824120000_payments_pending_verification",
-    "20260826170000_locale_preferences"
+    "20260826170000_locale_preferences",
+    "20260830120000_discount_weekly_schedule"
   ]
 }

package/prisma/schema/discounts.prisma

@@ -79,6 +79,29 @@ model Discount {
   // either side = open-ended.
   startsAt             DateTime? @map("starts_at")
   endsAt               DateTime? @map("ends_at")
+  // The WEEKLY schedule INSIDE that window (FUT-996) — "toda sexta, das 16:00
+  // às 20:00", "segunda e terça à tarde". NULL = always, within
+  // [starts_at, ends_at), which is what every row predating the feature means.
+  //
+  //   {"windows":[{"days":[4],"from":"16:00","to":"20:00"}]}
+  //
+  // `days` is Monday-first 0..6 — the axis every hours surface uses, and NOT
+  // `Date#getDay()`'s Sunday-first one. `from`/`to` are "HH:MM" in the STORE's
+  // timezone, half-open [from, to) exactly as the campaign window is, and a
+  // `to` earlier than `from` runs past midnight rather than being invalid.
+  //
+  // JSON rather than a fourth table because the recurrence is not usefully
+  // SQL-queryable (the grid's vigência filter already cannot express the
+  // campaign window either), and a fourth table would put a third `include` on
+  // the storefront's hottest read. The cost is that the DATABASE cannot check
+  // this shape: `assertSchedule` is the only gate, and the evaluator treats a
+  // malformed window as covering NOTHING, so a bad blob is a promotion that
+  // does not fire rather than a cart priced wrong.
+  //
+  // A recurring window is a WALL-CLOCK fact, so it is only meaningful against
+  // the store's own timezone. The engine never reads one: a host resolves the
+  // instant into a weekday and a minute-of-day and passes those in.
+  schedule             Json?     @map("schedule")
   // Minimum PRE-DISCOUNT cart subtotal, in cents. Always compared against the
   // untouched subtotal, never a running total — which is what makes the result
   // independent of the order the discounts are applied in.