Imported from MarineTeam/fable-video (.claude/skills/domain-reference/SKILL.md). Install upstream with npx skills add MarineTeam/fable-video --skill domain-reference. Copyright stays with the author.

name: domain-reference description: Third-party domain knowledge for the Marine Video Portal — how Auth0 v4, bunny.net Stream, Upstash Redis, Resend, TUS uploads, and player.js actually behave IN THIS REPO (not generic docs). Load when reading or writing code that touches login/session, video upload/playback/tokens, collections, Redis keys, share-link email, or resume progress, and you need to know what a service call does, what a status code means, what a key holds, or why a signature formula is shaped the way it is. Trigger phrases: "what is X", "how does Y work here", embed token, TUS, pull zone, CDN hostname, collection, GUID, rolling session, sliding window, TTL, Resend, player.js.

Domain reference — Marine Video Portal

This file is the third-party knowledge a mid-level engineer would have to relearn from scratch: what Auth0 v4, bunny.net Stream, Upstash Redis, Resend, TUS, and player.js actually do in this codebase, not in general. It is not a tutorial on any of these products — it only documents the slice this app uses and exactly where.

Verified against the repository at v1.6.0 (2026-07-07), re-verified 2026-07-10; §8 (Web Push + PWA) added and re-verified 2026-07-15 against v1.8.0. Everything below was read directly from the cited files, not inferred. Line numbers are not cited because they drift; function/file names are cited instead — grep for them if you need the exact line.

When NOT to use this skill

Use this skill only for "how does the third-party service actually behave here" questions — signature formulas, status codes, key shapes, route maps, payload shapes.

1. Glossary

Definitions as they apply in this app. If a term has a generic meaning elsewhere, this is the meaning that matters here.

2. Auth0 v4 as used here

The client object

lib/auth0.js is the entire Auth0 wiring:

import { Auth0Client } from "@auth0/nextjs-auth0/server";
export const auth0 = new Auth0Client();

Zero-config constructor — it reads AUTH0_DOMAIN, AUTH0_CLIENT_ID, AUTH0_CLIENT_SECRET, AUTH0_SECRET, and APP_BASE_URL from process.env implicitly. There is no options object anywhere in this repo; if you need to pass an explicit option (e.g. a custom session duration), you're changing this constructor call, which makes the change security-touching per change-control.

Route map

Auth routes are mounted, not defined as page files — they don't exist under pages/api/auth/* or pages/auth/*. proxy.js calls auth0.middleware(request), and the SDK internally handles these paths:

v3 → v4 migration trap table

From README's "Upgrading from an older deployment?" note — relevant any time you see old-SDK code or a stale dashboard config:

Session reads

Every server-side session check in this app goes through auth0.getSession(req), never through a client-side hook. Two call sites:

• lib/guard.js (sessionEmail()) — used by every /api/** route via requireUser / requireApproved / requireAdmin.
• getServerSideProps directly, in pages/index.js, pages/admin.js, pages/watch/video/[id].js, pages/watch/[shareId].js — each one calls auth0.getSession(req), extracts session?.user?.email, and redirects to /auth/login?returnTo=... if absent.

The session object's only identity input the app trusts is session.user.email. session.user.name is read too (for display, e.g. session.user.name || email fallback), but every access-control decision — isAdmin(), isApprovedViewer(), share-link recipient matching — is keyed purely on the normalized email from lib/auth.js's normalizeEmail() (trim + lowercase). There is no role claim, no Auth0 "app_metadata" lookup, nothing else consulted.

Rolling sessions and why proxy.js's matcher must stay broad

proxy.js (Next.js 16's replacement for middleware.js) is three lines of substance:

export async function proxy(request) {
  return auth0.middleware(request);
}
export const config = {
  matcher: [
    "/((?!_next/static|_next/image|favicon.ico|sitemap.xml|robots.txt).*)",
  ],
};

The file's own comment: "Everything except static assets — the broad matcher is required for rolling sessions to refresh on ordinary page/API traffic." Concretely: the Auth0 SDK extends session expiry on every request that passes through its middleware. If the matcher were narrowed (e.g. to exclude /api/** or watch pages), sessions would stop refreshing on those routes and users could be logged out mid-session even while actively using the app. Narrowing this matcher is a security-touching change per change-control's classification table.

3. bunny.net Stream as used here

All calls go through lib/bunny.js. Base URL:

https://video.bunnycdn.com

Every call to /library/{libraryId}/... is authenticated with an AccessKey header set to BUNNY_API_KEY (see the api() helper). There is no OAuth, no signed request for the management API itself — only for the three playback/upload artifacts described below. Env values are read via a local env() helper that trims the value defensively (comment: "a stray newline in a pasted key corrupts TUS signatures and API calls").

Every endpoint the app calls

Video status codes

videoState() in lib/bunny.js maps bunny.net's numeric status field to one of three UI states:

Exact logic: status === 5 || status === 6 → "failed"; status === 4 || status > 6 → "ready"; everything else (0–3) → "processing". Only "ready" videos are ever shown to viewers (lib/videoList.js filters on this before building the homepage list).

The three keys, disambiguated

This is the single most common source of confusion in this codebase — three different bunny.net keys, each used for a different signature, with one silent fallback.

If you rotate BUNNY_TOKEN_AUTH_KEY in the bunny.net dashboard without also checking whether BUNNY_CDN_TOKEN_KEY was relying on the fallback, thumbnails silently start 401'ing while playback keeps working (or vice versa) — the two are independent unless the fallback is in effect.

The three signature formulas (verbatim)

All three are SHA-256 over a concatenated string (no delimiter, no HMAC — plain digest). bunny.net independently recomputes and verifies each one server-side; changing the concatenation order, the hash algorithm, or the encoding here breaks playback/upload/thumbnails without any local error — the failure only shows up as a bunny.net-side rejection. CodeQL flags these as "weak password hashing" — that is a false positive (these are per-request authorization tokens, not credential storage); see security-response for the accepted-risk record.

expires / expire in all three is a Unix timestamp in seconds (Math.floor(Date.now() / 1000) + ttlSeconds), not milliseconds.

The TUS upload flow, end to end

1. Admin drops a file in pages/admin.js's upload UI. startUpload(file) runs client-side.
2. It first calls POST /api/admin/upload with { title } (pages/api/admin/upload.js), which:
   • checks requireAdmin,
   • rate-limits via allowRequest("upload", admin, 30, "1 h"),
   • calls createVideo(title, collectionId) — this is the only step that touches bunny.net's management API; it creates an empty video record and returns its guid,
   • calls logAction(admin, "video.upload", title),
   • responds 201 with { video: { id, title }, tus: signTusUpload(video.guid) } — i.e. { endpoint, signature, expire, videoId, libraryId }.
3. Back in the browser, pages/admin.js dynamically imports tus-js-client and constructs new Upload(file, { endpoint: created.tus.endpoint, ... }) with headers AuthorizationSignature, AuthorizationExpire, VideoId, LibraryId taken verbatim from that response, then calls upload.start().
4. From this point, the file bytes go straight from the browser to https://video.bunnycdn.com/tusupload — this app's server is not in the data path at all, only the auth handshake in step 2.
5. onProgress drives the progress bar; onSuccess marks the row "done" and calls load() to refresh the video list; onError surfaces the error and offers retry (retryUpload), which re-POSTs step 2 for a new signature (the old one may have expired) and restarts the same tus-js-client Upload.
6. Cancelling before completion calls upload.abort(true) client-side, then DELETE /api/admin/upload?id=... server-side, which calls deleteVideo(id) to remove the half-created bunny.net record and pruneFromOrder(id) to drop it from any saved homepage order.

Embed iframe URL shape

https://iframe.mediadelivery.net/embed/{libraryId}/{videoId}?token={sha256hex}&expires={unixSeconds}&autoplay=false

Built by signEmbedUrl(). Note the host is iframe.mediadelivery.net, a different domain from the Stream management API (video.bunnycdn.com) and from the CDN pull zone (BUNNY_CDN_HOSTNAME) — three different bunny.net hostnames serve three different purposes in this app. This URL is generated fresh in getServerSideProps on every watch-page load (pages/watch/video/[id].js, pages/watch/[shareId].js) and passed as the iframe src to ResumablePlayer / the raw <iframe>. It is never persisted to Redis or anywhere else.

Direct media (MP4) URLs — and the audio-only question

Verified against bunny.net's documentation on 2026-09-13, not assumed. Stream has no audio-only or MP3 rendition. A video's stored files are:

• playlist.m3u8 (HLS),
• optional play_{height}p.mp4 fallbacks (1080/720/360/240),
• original (only with "keep original files" on),
• thumbnail.jpg + numbered variants, seek/_N.jpg sprites, preview.webp|gif| webm|mp4,
• captions/{lang}.vtt.

Two conditions on the MP4 fallbacks, both set on the bunny.net LIBRARY and not settable from this repo:

1. MP4 Fallback must be enabled under the library's Encoding settings.
2. bunny.net generates an MP4 only for videos uploaded after that was turned on — pre-existing videos have none and their URLs 404 until re-uploaded.

Pull-zone token authentication and "Block Direct URL File Access" apply to these URLs exactly as they do to thumbnails, using the same base64url(SHA256(cdnTokenKey + path + expires)) formula. That is why the podcast feed is possible at all: lib/bunnyMedia.js signs /{guid}/play_{height}p.mp4 with the same scheme thumbnailUrl() uses. Consequence for the feed: episodes are video, not audio — playable in podcast apps, but a far larger download. See architecture-contract (s) for why this is a narrowed exception to invariant (d) and why the formula is duplicated rather than shared with lib/bunny.js.

Thumbnails

• Default filename: thumbnail.jpg — used when video.thumbnailFileName is absent (file = video.thumbnailFileName || "thumbnail.jpg").
• Requires BUNNY_CDN_HOSTNAME set; thumbnailsEnabled() gates the homepage's grid-vs-list rendering mode entirely on this one var.
• Signed with the thumbnail formula above when cdnTokenKey() resolves to something; if no key is available at all, thumbnailUrl() returns the bare unsigned https://{host}{path} (only correct if the pull zone's "Block Direct URL File Access" is off).
• README notes the pull zone also does referer-based hotlink protection as an additional layer, independent of the token.

4. Upstash Redis as used here

Client shape

lib/redis.js wraps @upstash/redis's Redis class — a REST-based client, meaning every command (hget, set, sadd, ...) is one HTTPS request, not a persistent TCP connection. Practical implications:

• Objects auto-serialize to JSON on write and deserialize on read — a share record stored as { videoId, email, ... } via r.set(key, share) comes back as a real JS object from r.get(key), no manual JSON.parse/JSON.stringify needed (contrast with lib/audit.js, which stores audit entries as explicit JSON strings via JSON.stringify before lpush, and so must JSON.parse them back in recentActions()).
• hgetall returns {} for a missing/empty hash, not null — but the app doesn't rely on that alone; every call site still does (await redis().hgetall(...)) || {} defensively (see getSettings, listViewers, getProgress).

Key resolution

lib/redis.js's envBySuffix() matches KV_REST_API_URL / KV_REST_API_TOKEN (or the UPSTASH_REDIS_REST_URL / UPSTASH_REDIS_REST_TOKEN fallback names) either as an exact env var name or as a suffix of any env var name (comment: Vercel prefixes storage vars with the store's name when a project has more than one connected, e.g. fablevideo_KV_REST_API_URL). If you add a second Redis-backed integration to this Vercel project, this suffix-matching logic is what keeps the app finding the right credentials — or silently picking the wrong store's if names collide.

Complete key inventory

All keys are namespaced through k(...parts) in lib/redis.js, which joins "fablevideo" with the given parts using :. (Historical note: the prefix was pvp: before 2026-07-09, commit c37919e; anything under the old prefix is orphaned data, not read by current code — see failure-archaeology for the incident.)

Historical note (pre-v1.13): shares used to live as one STRING key per share (fablevideo:share:<id>) plus a SET index (fablevideo:shares:index) for listing. That shape was replaced by the single-hash design above because Upstash bills a multi-key command (the old MGET over every share key) per key touched, while a single-hash command (HGETALL/HMGET/HSETEX/HDEL) bills once regardless of field count — loading the admin Shares tab with 1000 shares dropped from ~1001 commands to 1. scripts/migrate-shares-to-hash.mjs carries pre-existing data from the old shape into the new one; the old keys are never read by current code and are left in place afterward, inert — same resolution as the pvp:* orphans from the 2026-07-09 rename (see failure-archaeology FA-5). If you're reading a real Redis census and see both fablevideo:share:* keys and a populated fablevideo:shares hash, that's expected during/after this transition, not a bug.

Share TTL lifecycle

1. Create (createShare/createShares in lib/shares.js): ttlHours = clampShareHours(hours) (clamped to 1–720 hours, i.e. up to 30 days; default 72 hours if unspecified/invalid). writeShares() issues one HSETEX fablevideo:shares EX <ttlHours*3600 + GRACE_SECONDS> FIELDS ... covering every share in the call (1 command for a whole bulk-create batch, since every pair in one call shares the same hours) — Redis drops each field at its own expiry with no app-level cron needed.
2. Update (updateShare/stampShares, used to stamp view/playback patches and emailedAt): merges the patch onto the current record (read via getShare/already in hand from an earlier batch read) and writes back with HSETEX ... KEEPTTL — each field's own existing remaining TTL is preserved exactly by Redis itself, with no separate TTL read-back needed (the old per-key design had to TTL the key first to avoid resetting it; hash-field KEEPTTL makes that read unnecessary).
3. List (listShares): one HGETALL returns every non-expired share in the hash — Redis's native per-field TTL means an already-expired share's field is simply absent from the result; no app-level dead-id pruning pass is needed (the old index-set design needed an opportunistic SREM for this).
4. Revoke (revokeShares, soft — the current, in-place-flag behavior; permanentlyDeleteShares is the old ungraced-delete behavior, used to finish off an already-revoked link): one HMGET (batch read) + one HSETEX ... KEEPTTL (batch write of {revoked: true, revokedAt}) for however many ids are selected — flat 2 commands regardless of selection size, instead of a get+ttl+set per id.

5. Resend as used here

lib/email.js talks to Resend's REST API directly — no resend npm SDK dependency.

Inert-until-configured contract: emailEnabled() is Boolean(env("RESEND_API_KEY") && env("EMAIL_FROM")) — both must be set. Every code path that might send email checks this first (e.g. pages/api/admin/share.js: if (shouldEmail && emailEnabled())), so with either var unset, share creation still succeeds and simply returns emailed: false — there is no error, no attempted call, no partial state. This is deliberate per README: "Without these, everything still works — admins copy share links and send them manually."

Domain verification requirement (from README, not in code — nothing in this repo checks it): the domain in EMAIL_FROM must be verified in Resend's dashboard, or every send fails at Resend's end with a delivery error that surfaces through the failure path above into the admin UI. This is an operational prerequisite, not something lib/email.js can detect or work around.

The site name in an email is the admin-set one: sendShareEmail() and sendBulkShareEmail() resolve it from Redis and inject it into the template as site, falling back to SITE_NAME/NEXT_PUBLIC_SITE_NAME and then "Marine Video Portal" (lib/siteName.js resolveSiteName()). siteName() in lib/email.js is now only that env-level fallback, kept synchronous for callers that can't await. It is used in the email subject line and body via shareEmailTemplate(), which also HTML-escapes every interpolated value (escapeHtml()) before building the HTML body, since videoTitle and the recipient email are admin/user -influenced strings.

6. player.js / resume

components/ResumablePlayer.js wraps the tokenized bunny.net <iframe> with the player.js npm package (bunny.net's embed implements the player.js postMessage protocol on the iframe side; this component is the protocol client on the host page).

Flow, in order:

1. The iframe renders immediately with the signed embed src — playback works even if the rest of this logic never runs.
2. On mount, player.js is dynamically imported (await import("player.js")) and a new playerjs.Player(iframeRef.current) instance is created, bound to the iframe via postMessage.
3. On the player's "ready" event: GET /api/progress?videoId=... fetches any previously saved position; if saved.t > 5 && saved.d && saved.t < saved.d * 0.95 (i.e. more than 5 seconds in, and not already essentially finished), it calls player.setCurrentTime(saved.t) to seek there.
4. Still inside "ready", it wires "timeupdate" (updates an in-memory lastKnown = {t, d} on every tick — no network call per tick), "pause" (saves immediately), and "ended" (sets t = d and saves — marks the video as finished for continue-watching filtering).
5. A setInterval(save, 10000) also persists every 10 seconds while playing, so a browser crash or tab close doesn't lose more than ~10s of progress.
6. save() itself is a guarded POST /api/progress with {videoId, t: lastKnown.t, d: lastKnown.d} — it no-ops if d is falsy or t < 5 (nothing meaningful to persist yet), and uses keepalive: true so the request can complete even during page unload.
7. Cleanup (component unmount / videoId change): clears the interval and fires one last save().

Graceful degradation: the whole player.js setup is wrapped in a try/catch with the comment "player.js failed to load — plain embed playback still works." If the dynamic import fails, or the protocol handshake never completes, the raw <iframe> still plays the video; only resume/progress tracking is lost, silently, with no user-visible error.

Where progress lands: POST /api/progress (pages/api/progress.js) validates the payload (videoId string ≤100 chars, t/d finite numbers, t >= 0, d > 0) then calls saveProgress(email, videoId, {t, d, at}) in lib/store.js, which hsets into fablevideo:progress:<email> — see the key inventory in section 4. The same endpoint's plain GET (no videoId) powers the homepage's "Continue watching" strip: it reads all progress entries, filters to t > 10 && d > 0 && t < d * 0.95 (started, has a real duration, not basically finished), sorts by most recent, caps at 8 (MAX_CONTINUE_ITEMS), and enriches each with title/thumbnail via listAllVideos().

7. Rate limits as configured

Every limiter goes through allowRequest(name, id, tokens, window) in lib/ratelimit.js, which lazily builds (and caches by `${name}:${tokens}:${window}`) an @upstash/ratelimit instance using Ratelimit.slidingWindow(tokens, window), prefixed under fablevideo:rl:{name}. Fails open on any Redis error — the whole function is wrapped in try/catch returning true on failure, with the comment "an infrastructure hiccup must never lock real users out." This means rate limiting is best-effort, not a hard security boundary — do not rely on it alone to bound abuse of an endpoint whose real risk is data exposure (auth/authorization guards are the hard boundary there).

All three key on email, not IP — meaning the limit is per-account, and an admin/viewer with multiple tabs/devices shares one bucket. There is no global/unauthenticated-endpoint limiter in this table because every rate- limited route sits behind requireAdmin/requireApproved first, so the identity used as the limiter key is always established before the limit check runs.

8. Web Push and the PWA as used here

Added in v1.7.0 (installable PWA) and v1.8.0 (Web Push notifications). All of it is inert until VAPID keys are configured — pushEnabled() in lib/push.js is Boolean(NEXT_PUBLIC_VAPID_PUBLIC_KEY && VAPID_PRIVATE_KEY), and every server entry point checks it first. See environment-and-config for the three env vars; this section is how the pieces actually behave.

The PWA shell (v1.7.0)

• Manifest: public/manifest.webmanifest — name "Marine Video Portal", short_name "Marine", display: standalone, start_url/scope /, theme/background #0f172a, and three icons (192, 512, and a 512 maskable). Linked from pages/_document.js via <link rel="manifest" href="/manifest.webmanifest" />.
• Service worker: public/sw.js, registered client-side in pages/_app.js (navigator.serviceWorker.register("/sw.js"), wrapped so a failure is silently ignored). On install it precaches the manifest + icons (CACHE = "mvp-static-v1") and calls skipWaiting(); on activate it deletes stale caches and calls clients.claim().
• What makes it installable: a linked manifest with the required icons + a registered service worker, served over HTTPS. Chrome then offers "Install app"; iOS/iPadOS offers "Add to Home Screen". Whether the browser shows a direct install entry vs. a generic "add to home screen / create shortcut" picker is a per-origin, per-device browser decision (Chrome's AppBannerManager engagement heuristic) — not controllable from the manifest, and not a bug in this app.

Subscribe / unsubscribe flow (client)

components/PushToggle.js renders the "🔔 Notify me" button (becomes "🔔 Notifications on" once subscribed). It:

1. No-ops entirely if NEXT_PUBLIC_VAPID_PUBLIC_KEY is absent, the browser lacks serviceWorker/PushManager/Notification, or notifications are already denied (then it shows a "blocked in browser settings" chip).
2. On enable: Notification.requestPermission(), then registration.pushManager.subscribe({ userVisibleOnly: true, applicationServerKey: urlBase64ToUint8Array(VAPID_PUBLIC_KEY) }), then POST /api/push/subscribe with { subscription }.
3. On disable: getSubscription(), DELETE /api/push/subscribe with { endpoint }, then subscription.unsubscribe() locally.

Server: lib/push.js (the whole feature)

The send-payload shape is a small JSON blob { title, body, url }; public/sw.js's push handler reads it (event.data.json()), shows registration.showNotification(title, { body, icon: "/icon-192.png", badge: "/icon-192.png", data: { url } }), and notificationclick focuses an existing tab (navigating it to url) or opens a new window.

The two send triggers

1. Automatic, on a new video becoming ready. pages/api/admin/videos.js (the admin video-list route) calls maybeAnnounceReadyVideos(videos) best-effort — wrapped in try/catch so a push failure never breaks the admin video list. Logic: filter to status === "ready" videos with an id; on the first ever run, SADD them all to fablevideo:push:notified and set the fablevideo:push:seeded sentinel without sending (so the pre-existing library isn't blasted); on later runs, for each ready video not already in notified, SADD it and send only if SADD returned 1 (atomic — exactly one concurrent instance wins per video). Message: { title: "New video", body: video.title, url: "/watch/video/<id>" }.
2. Manual admin broadcast. POST /api/admin/notify (requireAdmin, rate-limited 10/hour per admin via allowRequest("notify", ...), audit-logged as "push.broadcast"). Validates title (1–100 chars) and body (≤300 chars), clamps the click url to a same-origin path (startsWith("/") else /), calls sendPushToApproved, returns { ok, sent, pruned }. Triggered from the admin Settings tab's broadcast card (pages/admin.js), which shows a setup hint naming NEXT_PUBLIC_VAPID_PUBLIC_KEY/VAPID_PRIVATE_KEY when push is unconfigured.

The two subscribe/notify routes, status codes

iOS caveat (operational, from README, not enforceable in code)

iOS/iPadOS deliver Web Push only to a PWA that's been installed to the Home Screen (Safari 16.4+), never to an ordinary Safari tab. So on iOS the "Notify me" button only does anything after the user installs the app — this is an Apple platform constraint, not a bug in PushToggle.js. Android Chrome and desktop Chrome/Edge/Firefox subscribe from a normal tab without installing.

Provenance and maintenance

• Verified by reading, on 2026-07-13: lib/auth0.js, lib/auth.js, lib/guard.js, lib/redis.js, lib/store.js, lib/shares.js, lib/email.js, lib/ratelimit.js, lib/audit.js, lib/order.js, lib/theme.js, lib/theme-client.js, lib/bunny.js, lib/videoList.js, proxy.js, README.md, pages/api/admin/upload.js, pages/api/progress.js, pages/api/videos.js, pages/api/admin/share.js, pages/index.js, pages/admin.js (upload section), pages/watch/video/[id].js, pages/watch/[shareId].js, components/ResumablePlayer.js, package.json.
• Repo state at time of writing: v1.6.0 (released 2026-07-07), Redis key prefix fablevideo: (since commit c37919e, 2026-07-09).
• Updated 2026-07-15 (v1.8.0): added section 8 (Web Push + PWA), four glossary rows (Web Push, VAPID, service worker, PWA), and the three the public/feed-token rows and the "Direct media (MP4) URLs" section on 2026-09-13 (the bunny.net audio-only question answered against their live docs), and the roles/groups/requests/schedule/chapters/notes rows to the section-4 inventory the same day (the table had drifted — several of those keys shipped in earlier changes without being recorded here), alongside the earlier fablevideo:push:* keys — verified by reading lib/push.js, public/sw.js, public/manifest.webmanifest, components/PushToggle.js, pages/_app.js, pages/_document.js, pages/api/push/subscribe.js, and pages/api/admin/notify.js on that date. The iOS-install-required-for-push caveat is from README, not exercised here.
• Volatile facts to re-check if this file feels stale: the three signature TTLs (3h/6h/6h) and formulas in lib/bunny.js; the rate-limit table in section 7 (tokens/window are trivial to change and easy to drift from this doc); the Redis key inventory in section 4 (new features add keys); the video status code table in section 3 (bunny.net could add states). Re-grep the cited functions rather than trusting numbers here if more than a few weeks have passed.
• Not independently verified (asserted by README, not exercised against live services): Resend's actual error-message JSON shape on failure; the exact wording bunny.net returns on a rejected signature; whether Auth0's /auth/profile route response shape matches any assumption (no code in this repo actually calls it, so there is nothing to cross-check against).
• If any of lib/auth0.js, lib/bunny.js's signature functions, lib/redis.js's key prefix, or lib/email.js's endpoint change, update this file in the same PR — it will otherwise actively mislead the next reader.