@thejob/schema 2.1.9 → 2.3.0

package/src/index.ts

@@ -2,6 +2,7 @@
  * Common schemas and constants.
  */
 export * from "./common/common.schema.js";
+export * from "./common/facet.schema.js";
 export * from "./common/common.constant.js";
 
 /**
@@ -19,11 +20,13 @@ export * from "./extensions/date-string.extension.js";
  */
 export * from "./group/group.schema.js";
 export * from "./group/group.constant.js";
+export * from "./group/group-filter.schema.js";
 
 /**
  * Job schemas and constants.
  */
 export * from "./job/job.schema.js";
+export * from "./job/job-filter.schema.js";
 export * from "./job/job.constant.js";
 export * from "./job/job-taxonomy.constant.js";
 export * from "./job/job-taxonomy.util.js";
@@ -44,11 +47,30 @@ export * from "./question/index.js";
  */
 export * from "./location/location.schema.js";
 
+/**
+ * Geo reference schemas and constants (countries / states / cities).
+ *
+ * A MIRROR of the dr5hn countries-states-cities-database, owned and refreshed
+ * wholesale by common-service. Distinct from `LocationSchema` above, which is
+ * the per-document geo shape a job or user CARRIES; these are the reference
+ * tables its dropdowns are populated from.
+ */
+export * from "./geo/geo.constant.js";
+export * from "./geo/country.schema.js";
+export * from "./geo/state.schema.js";
+export * from "./geo/city.schema.js";
+export * from "./geo/country-filter.schema.js";
+export * from "./geo/state-filter.schema.js";
+export * from "./geo/city-filter.schema.js";
+export * from "./geo/geo-sync.schema.js";
+
 /**
  * Page schemas and constants.
  */
 export * from "./page/page.schema.js";
 export * from "./page/page.constant.js";
+export * from "./language/language-filter.schema.js";
+export * from "./page/page-filter.schema.js";
 
 /**
  * Marketing schemas and constants (mailing lists, campaigns).
@@ -77,14 +99,25 @@ export * from "./report/report.constant.js";
 /**
  * Feedback schemas and constants (feedback widget + reports inbox).
  */
+export * from "./feedback/feedback-filter.schema.js";
 export * from "./feedback/feedback.schema.js";
 export * from "./feedback/feedback.constant.js";
 
 /**
  * Skill schemas and constants.
  */
+export * from "./skill/skill-filter.schema.js";
 export * from "./skill/skill.schema.js";
 
+/**
+ * Billing schemas and constants (Paddle).
+ *
+ * Note that money here is in MINOR units, the opposite of the salary fields
+ * elsewhere in this package. See `MoneySchema`.
+ */
+export * from "./billing/billing.schema.js";
+export * from "./billing/billing.constant.js";
+
 /**
  * Social account schemas and constants.
  */
@@ -95,6 +128,8 @@ export * from "./social-account/social-account.constant.js";
  * User schemas and constants.
  */
 export * from "./user/user.schema.js";
+export * from "./user/user-filter.schema.js";
+export * from "./user/push-subscription.schema.js";
 
 export * from "./user/user-language.schema.js";
 export * from "./user/general-detail.schema.js";

package/src/job/job-filter.schema.ts

@@ -0,0 +1,266 @@
+/**
+ * The job filter: the closed vocabulary of facets a job query can filter on.
+ *
+ * The counterpart of `UserFilterSchema`, and the single declaration that
+ * `thejob-jobs-service` and `@thejob/jobs-client` both derive from — the client
+ * types its `JobListQuery` facets with `InferType`, and the service checks
+ * incoming keys against `Object.keys` of it. Two hand-maintained lists had
+ * already drifted: six facets the service accepted (`tags`, `subCategories`,
+ * `companyNames`, `isPromoted`, `featuredMarkets`, `createdAt`) could not be
+ * expressed through the client at all.
+ *
+ * WHAT A FACET MEANS stays in the service (`JOB_FACETS` maps each name to a
+ * document path and a match operator, which is not a consumer's business). This
+ * declares only the NAMES and the SHAPES a caller may send.
+ *
+ * `search`, `page`, `limit`, `sortBy`, `sortDirection` and `fields` are
+ * deliberately absent: they are reserved query params, not facets. `search` in
+ * particular is hybrid search over meaning — it names no field on a job
+ * document and cannot sit inside a filter clause.
+ */
+import { array, boolean, number, object, string } from "yup";
+import {
+  SupportedEducationLevels,
+  SupportedExperienceLevels,
+} from "../common/common.constant.js";
+import { SupportedSalaryCurrencies } from "../user/user.constant.js";
+import {
+  SupportedEmploymentTypes,
+  SupportedJobStatuses,
+  SupportedWorkModes,
+} from "./job.constant.js";
+import {
+  SupportedJobCategories,
+  SupportedJobIndustries,
+  SupportedJobSubCategories,
+} from "./job-taxonomy.constant.js";
+import {
+  codeTokens,
+  days,
+  enumFacet,
+  epoch,
+  rejectUnknownKeys,
+  tokens,
+} from "../common/facet.schema.js";
+
+/**
+ * Every clause AND-s together; every LIST means OR ("remote or hybrid"). An
+ * empty list is "no constraint" and contributes no clause at all — never a term
+ * that matches nothing.
+ */
+/**
+ * The form section the geo facets share.
+ *
+ * Named once because it must be IDENTICAL across the four: `describeParams`
+ * buckets by this exact string, so one typo silently opens a second section
+ * with one control in it.
+ */
+const GEO_GROUP = "Geo";
+
+const JobFilterShape = object({
+  // ── Classification ──────────────────────────────────────────────────────────
+  // Closed vocabularies, sent verbatim and matched exactly: a partial match
+  // would make "remote" also match a hypothetical "remote_first".
+  employmentType: enumFacet(SupportedEmploymentTypes, "Employment Type"),
+  workMode: enumFacet(SupportedWorkModes, "Work Mode"),
+  experienceLevel: enumFacet(SupportedExperienceLevels, "Experience Level"),
+  educationLevel: enumFacet(SupportedEducationLevels, "Education Level"),
+  status: enumFacet(SupportedJobStatuses, "Status"),
+
+  // ── Taxonomy ────────────────────────────────────────────────────────────────
+  // NOT `enumFacet`, deliberately. Taxonomy is stored as the ENGLISH LABEL
+  // ("Technology, Data & Digital"), not the enum constant, so a caller sends the
+  // label and constraining these to `SupportedJobCategories` would reject every
+  // value that actually matches.
+  //
+  // `meta.options` publishes the vocabulary anyway, for forms only. The schema
+  // still accepts any string — it must, per the note above — but an admin
+  // picking one of eight categories should not be typing it: the stored label
+  // is "Technology, Data & Digital", and a hand-typed "Technology" matches
+  // nothing while looking correctly configured.
+  category: tokens("Category").meta({ options: SupportedJobCategories }),
+  industry: tokens("Industry").meta({ options: SupportedJobIndustries }),
+  subCategories: tokens("Sub-category").meta({
+    options: SupportedJobSubCategories,
+  }),
+  tags: tokens("Tags"),
+
+  // ── Identity ────────────────────────────────────────────────────────────────
+  /**
+   * Specific jobs, by `shortId`. The one facet that names jobs outright rather
+   * than narrowing by an attribute of them.
+   *
+   * It exists for a HAND-PICKED set: a group whose jobs an admin chose
+   * individually stores exactly this list as `group.jobIds`, so the field and
+   * the facet share a name and the stored data needs no translation.
+   *
+   * Case is LOAD-BEARING and must not be normalised: a shortId is mixed case
+   * (`tI8wnSIgRG5O`), so the uppercase treatment country and state codes get
+   * would turn every lookup into a match on nothing.
+   */
+  jobIds: tokens("Jobs"),
+
+  // ── Skills and company ──────────────────────────────────────────────────────
+  //
+  // `widget` is a RENDERING hint for whoever builds a form from this schema: it
+  // names the picker that produces values this facet can actually match, and
+  // nothing validates differently because of it. A form generated without one
+  // falls back to a free text box, which is what every admin filter was doing —
+  // so "Angular" was typed where the stored skill is "angular" and the filter
+  // narrowed to nothing while looking correctly configured.
+  skills: tokens("Skills").meta({ widget: "skill" }),
+  /** Company page SLUGS: a display name breaks the day a company renames itself. */
+  companies: tokens("Companies").meta({ widget: "company" }),
+  /**
+   * Company display names, for callers that only have one. Prefer `companies`.
+   *
+   * `hidden`: not a second control in a generated form. An admin picking a
+   * company gets the page, and `companies` (its slug) is the stable way to name
+   * it — a display name stops matching the day a company renames itself. This
+   * stays in the vocabulary for API callers who genuinely only hold a name.
+   */
+  companyNames: tokens("Company Names").meta({ widget: "hidden" }),
+
+  // ── Location ────────────────────────────────────────────────────────────────
+  //
+  // Four facets, THREE controls. They are independent OR-lists: jobs-service
+  // matches each path separately, so `countryCodes` alone asks "anywhere in
+  // India" and `cities` alone asks "in Pune, wherever that is". Collapsing them
+  // into one object facet would lose exactly that, and lose the cross-entry
+  // reading ("has an India office OR a London office") with it.
+  //
+  // What they must NOT be is free text. A country here is `IN`, not "India",
+  // and a state code is a BARE `KA`, not `IN-KA` — type either long form and
+  // the filter matches nothing while looking correctly configured.
+  //
+  // So each names the GEO reference autocomplete (common-service `/geo/*`, a
+  // closed vocabulary) and the field of the picked row it stores. `geoLevel`
+  // says which endpoint to search and `geoField` which key lands in the facet.
+  //
+  // THREE controls, not four: a picked state carries its name and its code, so
+  // the old separate "State Codes" box asked twice for one fact. See `states`.
+  //
+  // Geoapify's `/locations` is NOT the vocabulary here. It geocodes free-text
+  // addresses — the right tool for "where is this job", the wrong one for a
+  // filter, since it is a paid call per keystroke and its results are open.
+  /** ISO 3166-1 alpha-2, uppercase. */
+  countryCodes: codeTokens("Countries").meta({
+    group: GEO_GROUP,
+    widget: "geo",
+    geoLevel: "country",
+    geoField: "countryCode",
+  }),
+  /** Stored BARE (`KA`, not `IN-KA`) — see @todo STATE-CODE-ISO-PREFIX. */
+  stateCodes: codeTokens("States").meta({
+    group: GEO_GROUP,
+    widget: "geo",
+    geoLevel: "state",
+    geoField: "stateCode",
+  }),
+  /**
+   * State NAMES, kept as a facet but WITHOUT a control of its own.
+   *
+   * There is no second box to fill: a picked state carries its name and its
+   * code together, so asking an admin for both was asking twice for one fact.
+   * The picker writes `stateCodes`, which is where the data is going.
+   *
+   * The facet stays because jobs still hold state names — 15,483 carry a name
+   * with NO code — and a saved campaign may already constrain on it. Removing
+   * it would silently drop that constraint from those campaigns. It becomes
+   * unreachable from the UI and is settled by the data migration.
+   *
+   * @todo STATE-CODE-ISO-PREFIX — retire once every job carries a stateCode.
+   */
+  states: tokens("States").meta({ group: GEO_GROUP, widget: "hidden" }),
+  /**
+   * City NAMES, and the one facet here that does not match on a code.
+   *
+   * A name is a display label, not a matching key: it is not unique (99 Indian
+   * city names repeat in the reference data) and not stable (Bengaluru was
+   * Bangalore). Every other facet here matches a code for exactly that reason.
+   *
+   * Cities cannot yet. There is no city code to match ON either side: the
+   * reference dataset carries none, and no job stores one — `LocationSchema`
+   * has country/state codes and a city NAME. A `cityCodes` facet would match
+   * zero of 82,875 jobs on day one.
+   *
+   * So this stays on the name, and the picker does the work a code would: the
+   * admin selects a real city from the reference data, so the stored string is
+   * guaranteed to be a spelling that exists rather than a typo that silently
+   * matches nothing.
+   *
+   * @todo CITY-CODE-UNLOCODE — the fix is UN/LOCODE (or IATA) as the city key,
+   * and it is a data programme, not a facet change: ingest and reconcile the
+   * codes against the 152,970 reference rows, add `cityCode` to
+   * `LocationSchema`, backfill the ~81,000 jobs that carry only a name, and fix
+   * the write paths that emit it. Only then can this match on a code.
+   */
+  cities: tokens("Cities").meta({
+    group: GEO_GROUP,
+    widget: "geo",
+    geoLevel: "city",
+    geoField: "name",
+  }),
+
+  // ── Flags ───────────────────────────────────────────────────────────────────
+  // No `.default(false)`: an unchecked box must mean "no constraint", not "only
+  // the non-featured ones", so absent simply omits the clause.
+  isFeatured: boolean().optional().label("Featured Only"),
+  isPromoted: boolean().optional().label("Promoted Only"),
+  featuredMarkets: tokens("Featured Markets"),
+
+  // ── Ranges ──────────────────────────────────────────────────────────────────
+  /**
+   * Matched as an OVERLAP against the job's advertised band, not as a bound on
+   * one end: `{min}` keeps jobs whose `salaryRange.max` reaches it.
+   */
+  // NOT `currencyBound`: that guards the USER filter, where several currencies
+  // can be selected and a bound is meaningless across them. Here the currency is
+  // a single sibling field, so the bound is plain and the currency simply
+  // narrows which jobs are compared.
+  salary: object({
+    min: number().integer().min(0).optional().default(undefined).label("Salary ≥"),
+    max: number().integer().min(0).optional().default(undefined).label("Salary ≤"),
+    currency: string().oneOf(SupportedSalaryCurrencies).optional().label("Currency"),
+  })
+    .optional()
+    .default(undefined)
+    .label("Salary"),
+
+  /** Posted within this many days. Relative, so a saved filter does not rot. */
+  postedWithinDays: days("Posted Within (days)"),
+
+  /**
+   * Absolute posting window, for callers that want bounds rather than the
+   * relative `postedWithinDays`. EPOCH MS, matching how the field is stored — a
+   * coerced date string would not compare.
+   */
+  createdAt: object({
+    min: epoch("Posted After"),
+    max: epoch("Posted Before"),
+  })
+    .optional()
+    .default(undefined)
+    .label("Posted Between"),
+}).label("Job Filter");
+
+/**
+ * THE job filter, with unknown keys REJECTED.
+ *
+ * The guard its three sibling filter schemas (user, group, page) already carry,
+ * and this one was written without. Yup's own `.noUnknown()` is not an
+ * alternative: it only errors under `.strict()`, and strict mode also disables
+ * coercion — which would reject the `"7"` and `"true"` strings every query
+ * string is made of. `rejectUnknownKeys` is a `.test()` so both hold at once.
+ *
+ * Why it matters more here than anywhere else: a job filter arrives from a
+ * caller-controlled URL. Without this, a typo'd facet (`workplaceType`) and the
+ * retired `filter[workMode]=remote` form both VALIDATE, then reach the service
+ * as a facet no job document has — a 200 with a plausible full page, which is
+ * indistinguishable from a working search. Three consumers each hand-rolled an
+ * `assertKnownFacets` over `Object.keys` of this schema to compensate; this is
+ * the declaration those existed to substitute for.
+ */
+export const JobFilterSchema = rejectUnknownKeys(JobFilterShape, () =>
+  Object.keys(JobFilterShape.fields),
+);

package/src/language/language-filter.schema.ts

@@ -0,0 +1,40 @@
+/**
+ * The language filter: the closed vocabulary of facets a language query can
+ * filter on, for common-service's `GET /languages`.
+ *
+ * The counterpart of `SkillFilterSchema`, and it exists for the same reason:
+ * `parseFilter` there accepted ANY key and passed it to Mongo, so an invented
+ * facet returned 200 OK with zero rows and no error anywhere.
+ *
+ * ONE facet, because one is all this resource has. There is no `LanguageSchema`
+ * in this package: the `languages` collection is a flat reference list, and the
+ * only field common-service commits to is `name`, which is what its free-text
+ * search matches on. `UserLanguageSchema` is a different thing entirely — a
+ * USER's claim about a language, carrying `proficiencyLevel` — and its fields
+ * are not facets of the reference list.
+ *
+ * The collection is EMPTY in both `thejob` and `thejob-dev` today, and the one
+ * live caller (`language-field.svelte`) sends only `search`, `fields` and
+ * `sortBy`. So this is not modelling observed queries: it exists so the service
+ * has a closed vocabulary like every other one, and so the first real facet is
+ * an addition to a declaration rather than a new mechanism. Add facets here
+ * when a caller needs one, against real data.
+ *
+ * `search`, `page`, `limit`, `sortBy`, `sortDirection` and `fields` are reserved
+ * query params, not facets, and are absent for that reason instead.
+ */
+import { object } from "yup";
+import { rejectUnknownKeys, tokens } from "../common/facet.schema.js";
+
+const LanguageFilterShape = object({
+  /** Language names, matched exactly. Free-text matching is `?search=`. */
+  names: tokens("Names"),
+}).label("Language Filter");
+
+/**
+ * Wrapped so an unknown key is REJECTED rather than silently ignored. See
+ * `SkillFilterSchema` for why this is a `.test()` and not `.noUnknown()`.
+ */
+export const LanguageFilterSchema = rejectUnknownKeys(LanguageFilterShape, () =>
+  Object.keys(LanguageFilterShape.fields),
+);

package/src/marketing/marketing.constant.ts

@@ -1,24 +1,102 @@
+/**
+ * Where a campaign is in its life, as an OPERATOR would describe it.
+ *
+ * The states answer "what is this campaign doing?", not "what is the engine
+ * doing this second". That distinction is the whole design: a repeating
+ * campaign spends almost all its time between occurrences, and a status that
+ * tracked the send itself left it reading `sent` while it had years of mail
+ * still to go, indistinguishable from a one-shot that was finished forever.
+ *
+ * Per-occurrence detail (which run sent, how many, what failed) lives on the
+ * occurrence rows. This field is about the CAMPAIGN.
+ *
+ *   draft ──activate──> running ──pause──> paused ──resume──> running
+ *                          │                  │
+ *                          ├──────stop────────┤
+ *                          │                  │
+ *                          v                  v
+ *                       stopped            stopped        (terminal)
+ *                          │
+ *                   end condition met
+ *                          v
+ *                      completed                          (terminal)
+ *
+ * `failed` is reachable from `running` when a send throws, and is terminal.
+ */
 export enum CampaignStatus {
+  /** Being written. Has never sent and is not considered by the scheduler. */
   Draft = "draft",
-  Sending = "sending",
-  Sent = "sent",
+  /**
+   * Live: the scheduler will fire it whenever its schedule says so.
+   *
+   * A campaign is `running` from activation until something ends it, INCLUDING
+   * the gaps between occurrences. An "every day, forever" campaign is therefore
+   * `running` permanently, which is the honest answer — it is never finished.
+   */
+  Running = "running",
+  /**
+   * Halted by a person, and resumable.
+   *
+   * Moments that pass while paused are MISSED, and missed moments are skipped
+   * rather than replayed, so resuming does not produce a burst of backdated
+   * mail. An `afterOccurrences` campaign keeps its remaining budget, because
+   * that budget counts sends that happened.
+   */
+  Paused = "paused",
+  /** Halted by a person, permanently. Cannot be resumed; clone it instead. */
+  Stopped = "stopped",
+  /** Its end condition is satisfied: afterOccurrences spent, or onDate passed. */
+  Completed = "completed",
+  /** A send threw and the run could not be completed. */
   Failed = "failed",
 }
 
 export const SupportedCampaignStatuses = Object.values(CampaignStatus);
 
+/** No transition leaves these. */
+export const TerminalCampaignStatuses = [
+  CampaignStatus.Stopped,
+  CampaignStatus.Completed,
+  CampaignStatus.Failed,
+] as const;
+
+/**
+ * The only status changes allowed, keyed by where the campaign is now.
+ *
+ * Declared as data rather than written as `if` chains in each route, so an
+ * illegal move (resuming a stopped campaign, pausing a draft) is refused in one
+ * place and the diagram above cannot quietly drift from the code.
+ */
+export const CampaignStatusTransitions: Record<CampaignStatus, readonly CampaignStatus[]> = {
+  [CampaignStatus.Draft]: [CampaignStatus.Running],
+  [CampaignStatus.Running]: [
+    CampaignStatus.Paused,
+    CampaignStatus.Stopped,
+    CampaignStatus.Completed,
+    CampaignStatus.Failed,
+  ],
+  [CampaignStatus.Paused]: [CampaignStatus.Running, CampaignStatus.Stopped],
+  [CampaignStatus.Stopped]: [],
+  [CampaignStatus.Completed]: [],
+  [CampaignStatus.Failed]: [],
+};
+
+/** Whether a campaign may move from `from` to `to`. */
+export function canTransitionCampaign(from: CampaignStatus, to: CampaignStatus): boolean {
+  return CampaignStatusTransitions[from]?.includes(to) ?? false;
+}
+
 /**
  * How a campaign decides when to send.
  *
- * The two scheduled kinds dedupe differently, and that difference is the reason
- * they are separate kinds rather than one kind with a flag:
+ * Every kind here fires on a wall clock, so an occurrence is a shared moment:
+ * its identity is the occurrence itself, and a recipient may legitimately be
+ * mailed again on the next one.
  *
- *  • `Schedule` fires on a wall clock. Every occurrence is a shared moment, so
- *    its identity is the occurrence itself and a recipient may legitimately be
- *    mailed again next occurrence.
- *  • `Lifecycle` fires relative to each user's own anchor date (signup, …), so
- *    there is no shared moment. Identity is the user, permanently: a lifecycle
- *    campaign mails a given person at most once, ever.
+ * A `Lifecycle` kind (per-user, N days after that user's own anchor date) was
+ * removed; it was never used by any campaign. It did not belong beside these:
+ * having no shared moment, it deduped on the USER permanently rather than on
+ * the occurrence, which is a different engine wearing the same word.
  */
 export enum CampaignTriggerKind {
   /** Admin presses send. Also the dry-run test path. */
@@ -27,8 +105,6 @@ export enum CampaignTriggerKind {
   Once = "once",
   /** Repeats on a wall-clock schedule until its end condition. */
   Schedule = "schedule",
-  /** Fires per user, N days after that user's anchor date. Once per user ever. */
-  Lifecycle = "lifecycle",
 }
 
 export const SupportedCampaignTriggerKinds = Object.values(CampaignTriggerKind);
@@ -51,20 +127,6 @@ export enum CampaignEndKind {
 
 export const SupportedCampaignEndKinds = Object.values(CampaignEndKind);
 
-/**
- * The user-document date a `lifecycle` trigger counts its offset from. A closed
- * list because each value must be a real, indexed, immutable-enough date on the
- * user: an anchor that moves would re-fire the campaign for someone already
- * mailed, which the permanent idempotency key would then silently suppress.
- */
-export enum CampaignAnchorField {
-  CreatedAt = "createdAt",
-  OnboardingCompletedAt = "onboardingCompletedAt",
-  MarketingConsentUpdatedAt = "marketingConsent.updatedAt",
-}
-
-export const SupportedCampaignAnchorFields = Object.values(CampaignAnchorField);
-
 /**
  * Where a single template variable's value comes from. The admin picks one per
  * variable the chosen template declares.
@@ -73,7 +135,18 @@ export const SupportedCampaignAnchorFields = Object.values(CampaignAnchorField);
  * personalised iff any binding is `Recipient` or `Source`. A stored flag could
  * disagree with the bindings it describes.
  */
-export enum BindingKind {
+/**
+ * Where ONE template variable's value comes from.
+ *
+ * A campaign names a template, the template declares its variables, and each
+ * variable needs a source: a fixed string, something about the recipient, a
+ * link, or a field of whatever the campaign's data source returned. That
+ * mapping is a "binding".
+ *
+ * The string VALUES are stored in campaign documents — renaming one is a data
+ * migration, not a refactor.
+ */
+export enum TemplateVariableBindingKind {
   /** A literal typed by the admin. Same for everyone. */
   Static = "static",
   /** A field of the resolved recipient, e.g. `name`. */
@@ -84,7 +157,9 @@ export enum BindingKind {
   Source = "source",
 }
 
-export const SupportedBindingKinds = Object.values(BindingKind);
+export const SupportedTemplateVariableBindingKinds = Object.values(
+  TemplateVariableBindingKind,
+);
 
 /** Lifecycle of one materialised occurrence of a scheduled campaign. */
 export enum OccurrenceStatus {
@@ -98,8 +173,8 @@ export enum OccurrenceStatus {
 export const SupportedOccurrenceStatuses = Object.values(OccurrenceStatus);
 
 /**
- * Hard ceiling on recipients per scheduled/lifecycle send, enforced in code and
- * not overridable by config. Distinct from the one-shot audience cap: a campaign
+ * Hard ceiling on recipients per scheduled send, enforced in code and not
+ * overridable by config. Distinct from the one-shot audience cap: a campaign
  * that repeats forever gets the tighter bound, because a misconfigured filter
  * that mails too many people does it again every occurrence.
  */