@12-apps/prisma 6.5.0 → 6.7.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@12-apps/prisma",
-  "version": "6.5.0",
+  "version": "6.7.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",
@@ -68,22 +68,22 @@
   },
   "devDependencies": {
     "@12-apps/audit": "^5.7.1",
-    "@12-apps/auth": "^2.19.0",
-    "@12-apps/discounts": "^1.12.0",
+    "@12-apps/auth": "^2.21.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",
     "@12-apps/feature-flags": "^2.4.1",
     "@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/mcp": "^3.17.0",
+    "@12-apps/notifications": "^4.11.0",
     "@12-apps/onboarding": "^2.7.0",
-    "@12-apps/payments-backend": "^4.24.0",
+    "@12-apps/payments-backend": "^4.27.1",
     "@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/report-builder": "^5.14.1",
     "@12-apps/shift": "^3.4.0",
     "@12-apps/typescript-config": "^1.21.0",
     "@types/node": "^22.10.6",

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/migrations/20260910120000_add_refresh_grace_seal/migration.sql

@@ -0,0 +1,37 @@
+-- @12-apps/mcp: the sealed successor that makes refresh rotation RETRYABLE.
+--
+-- `oauth_refresh_tokens.grace_seal` holds a token's own plaintext, encrypted
+-- (AES-256-GCM) under a key derived by HKDF from the plaintext of the token it
+-- was rotated FROM, with its grace deadline sealed inside the same blob.
+--
+-- WHY THE COLUMN EXISTS. Rotation-on-use with replay revocation cannot tell a
+-- thief from a client that used one token twice for an innocent reason, and
+-- there are two routine innocent reasons: a response lost to a proxy timeout,
+-- and two of the client's own sessions refreshing at the same moment. Both were
+-- punished as theft — the whole lineage revoked, including the successor just
+-- handed to whoever won — which killed a live connection and sent a human back
+-- through the full authorization flow. With this column, re-presenting a
+-- just-consumed token inside the window returns THAT SAME successor instead, so
+-- one successor is still all that ever exists and no second family is created.
+--
+-- WHY IT IS NOT A PLAINTEXT COLUMN. The key is never stored: it is derived from
+-- the parent, which is itself only ever stored hashed. A dump of this table
+-- therefore yields ciphertext and nothing that opens it, so the package's
+-- "hashed, never plaintext" invariant is unchanged. The only party that can open
+-- a seal is one presenting the parent — which is the party being served, and
+-- which already held the token that mints the successor.
+--
+-- The seal is CLEARED whenever a token is consumed or revoked, and that is the
+-- bound on what it costs: a seal opens only under the plaintext it was rotated
+-- from, so spent seals left in place would chain — one historical plaintext plus
+-- a copy of this table would walk forward to the live token offline, with no
+-- server call and therefore no replay detection.
+--
+-- Nullable, but NOT optional: the package writes this field on every rotation,
+-- so a deployment that raises the package version without applying this
+-- migration gets a runtime failure on every refresh, not a quietly disabled
+-- window. Apply it in the same change as the version raise. Guarded with
+-- IF NOT EXISTS like every other statement this package ships, so a host that
+-- already added the column adopts the migration as a no-op.
+ALTER TABLE "oauth_refresh_tokens"
+  ADD COLUMN IF NOT EXISTS "grace_seal" TEXT;

package/prisma/plugin-migrations.json

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

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.

package/prisma/schema/mcp.prisma

@@ -71,6 +71,16 @@ model OAuthRefreshToken {
   revokedAt   DateTime? @map("revoked_at")
   createdAt   DateTime  @default(now()) @map("created_at")
 
+  // This token's own plaintext, SEALED under a key derived from the plaintext of
+  // the token it was rotated from, with its grace deadline inside the sealed
+  // blob. It is what lets a rotation be RETRIED: re-presenting the consumed
+  // parent within the window returns this same successor instead of revoking the
+  // lineage, so a lost response or two concurrent refreshes no longer end the
+  // connection. Only a caller holding the parent can open it, so the "never store
+  // a token in the clear" rule is intact — a dump of this table yields ciphertext
+  // and no key. Null on a root token, and whenever the window is turned off.
+  graceSeal   String?   @map("grace_seal")
+
   // `tokenHash` is already indexed by its `@unique` constraint — the
   // lookup-on-presentation path — so no separate `@@index([tokenHash])` is added
   // (it would be redundant). The composite index serves per-user/per-client