Collections, campaigns, categories, and progress

Scout's content is organized in three flat, non-nested layers, all rows in Postgres tables, no recursion or tree structure: - Category — a top-level browsing bucket (e.g.…

Summary

Scout's content is organized in three flat, non-nested layers, all rows in Postgres tables, no recursion or tree structure:

Category — a top-level browsing bucket (e.g. "nature", "history"). Every Collection belongs to exactly one.
Collection — a themed set of patches (e.g. "Illinois" inside Route 66, or "St. Louis" inside City Challenges). Every Patch can belong to any number of collections via a join table.
Campaign — an optional grouping of collections into one multi-part "journey" (e.g. Route 66's eight state collections, or National Parks' eleven regions). A collection has at most one campaign (Collection.campaignId is a single nullable FK), or none.

Progress ("2 of 8 collected") is never stored — it is recomputed on every render on-device by joining user_patches against patch_collections/collections/campaigns. There is no UserCollectionProgress or UserCampaignProgress table. Completing a collection or campaign awards nothing server-side: no achievement, no badge, no "Master Patch," no XP. It only flips a derived boolean (isComplete/progress === 1) used purely for UI (checkmarks, a "Complete" tag, a profile stat count). This confirms the long-standing internal claim that no Master Patch exists.

Campaigns render themselves with per-campaign "skins" declared in a static theme config: a road with mile markers (Route 66, Road Trips), or a dotted footpath with nature glyphs (National Parks, and most others). A third renderer exists — an era-flag timeline — but no campaign in the theme table currently selects kind: 'timeline', so it ships as unreachable code; the only place it can be seen is the DEV screen-mock gallery (scout://dev-screen-mock/campaign?state=timeline). The campaign gallery (app/(drawer)/campaigns.tsx) is a snap-scrolling stack of full-bleed cover photos, two per screen height.

City Challenges is not a distinct data type — it is one specific campaign (id: 'great-american-cities') whose member collections happen to be curated per-city. Nothing in the schema marks a collection as "a city collection"; it's convention plus curation (patch_collections membership) plus a client-side name/state fallback for patches not explicitly curated.

Surprising/notable findings, all verified in code:

The campaign detail screen's own progress bar/percentage does not apply the "never print 0%" rule — only the gallery cover (CampaignShowcasePanel) does, via campaignCounts.ts. See "Edge cases" below.
buildCampaignRail / RailStop (a "journey rail" concept referenced in comments as belonging to a CampaignShowcaseCard) is dead code today — no live screen imports it. The comment describing "the index journey rail" describes a UI variant that no longer exists; the shipped gallery uses a different, simpler mechanism.
Owning a collection via a store purchase (UserPurchase) makes it render as 100% complete client-side, with no patches actually collected — this is a display convenience, not data mutation (purchasedCollectionIds short-circuit in deriveCollectionsWithProgress).
Completing a City Challenge surfaces a promotional "20% off, earned not bought" banner on the Home screen that links to the in-app store — but the button passes no proof of completion to the store (it just opens /app signed in), so whether/how that discount is actually enforced is outside what this document can verify (store domain, out of scope here).

Status (shipped / beta-badged / flagged off)

Fully shipped, not gated behind any feature flag. rg -n "campaign|collection" backend/src/admin/feature-flag-definitions.ts returns nothing — no FeatureFlag/StoreFeatureFlag row governs Category/Collection/Campaign visibility. The only conditional visibility is Collection.adminOnly (see Configuration below), which is a per-row content flag, not a feature flag.

User-facing surfaces (screens, routes, deep links)

scout://campaigns → mobile/app/(drawer)/campaigns.tsx → CampaignsListScreen (mobile/src/screens/CampaignsListScreen.tsx) — the campaign gallery. Drawer entry point.
scout://campaign/<campaignId> → mobile/app/campaign/[id].tsx (a one-line re-export) → CampaignScreen (mobile/src/screens/CampaignScreen.tsx) — one campaign's detail/spine screen (Ken-Burns hero + themed spine).
scout://campaign-collection/<collectionId> → mobile/app/campaign-collection/[id].tsx → CampaignCollectionScreen (mobile/src/components/campaign/CampaignCollectionScreen.tsx) — one collection's member-patch grid, reached by tapping a campaign stop (or directly for a solo-kind campaign, see below).
Both routes are registered in the deep-link registry: mobile/src/dev/deepLinkRoutes.ts:42,106,107.
Both screens now carry a bookmark in their hero chrome, mirroring the back button on the opposite edge — campaign-favorite on campaign detail and campaign-collection-favorite on a collection. Bookmarking is member-only and the saved items appear at scout://favorites; see favorites. Note that a favorited collection resolves to /campaign-collection/<id> even when it has no campaign — CampaignCollectionScreen falls back to a plain 'COLLECTION' kicker with no theme when campaign is null.
There is no standalone /collections route or deep link. A non-campaign collection (campaignId: null) has no dedicated campaign-family screen in this scope; it is reached through category/patch-browser surfaces owned by other parts of the app (out of scope for this doc).
Profile screen: renders collectionsCompleted / totalCollections counts from useProfileStats() (mobile/src/hooks/useProfileData.ts) — out of scope in detail (owned by another surface) but it is the one place completion is aggregated into a headline number.

How it works (end-to-end mechanism)

Authoring (local DB only). Categories, Collections, Campaigns, and the patch_collections join rows are edited in the local admin (backend/src/admin/api/collections-api.controller.ts, campaigns-api.controller.ts) or by one-off scripts (backend/src/scripts/create-road-trips-campaign.ts, restructure-*-campaign.ts, etc.) run against the local dev DB. There is no admin endpoint to create a brand-new Campaign row — campaigns-api.controller.ts exposes GET, PATCH :id, POST :id/reorder, POST/DELETE :id/collections[...], but no POST to insert a campaign. New campaigns are created by hand-written scripts that upsert directly via Prisma (e.g. create-road-trips-campaign.ts:1-40), then the admin UI is used to attach/reorder/edit them afterward.
Publish. Per backend/src/content-publish/content-entities.ts, category, campaign, and collection are all classified as published content entities (lines ~78-233), same mechanism as patches — Alan runs the local→prod content-publish flow (owned by another doc/skill; not re-described here).
Sync to device. SyncService.getContent() (backend/src/sync/sync.service.ts:194-327) is the one place the mobile app fetches this data (GET is proxied through the sync controller). It runs one $transaction pulling category, collection, patch, patchType, patchCollection, and campaign rows and returns them as a flat SyncContentResponseDto. The mobile app caches this response under one TanStack Query key (contentQuery, keys.content()).
Client-side join + progress. Every screen that needs "how much of X is done" re-derives it from the cached content payload plus the user's collected-patch list (user_patches, itself synced separately) via pure functions in mobile/src/hooks/contentDerivations.ts. Nothing is precomputed or cached across renders except by React memoization (useMemo).
No server round-trip for progress. Collecting a patch (a GPS check-in) writes one UserPatch row via the sync/collect endpoints (owned by another feature doc — location unlock). That write is the only state change; every collection/campaign percentage anywhere in the app is recomputed from it locally, on the next render, with no dedicated "recompute progress" server call.

Data model (Prisma models and key fields)

All in backend/prisma/schema.prisma:

Category (schema.prisma:18-34): id, name, displayName, displayOrder, iconName, imageUrl, color. Has many Collection.
Collection (schema.prisma:36-68):
- id, name, description, categoryId (FK → Category, required), campaignId (FK → Campaign, nullable), campaignOrder (Int, position within its campaign)
- iconUrl/iconBlurhash, patchCount (denormalized count, recomputed server-side after publish — see comment at schema.prisma:44 and content-entities.ts:227-229, never trusted as a live source client-side beyond driving the progress denominator)
- productId/productHandle/priceUsd — Shopify linkage (store domain, out of scope)
- storeVisible (Boolean, default true) — store catalog visibility (out of scope here)
- adminOnly (Boolean, default false) — see Configuration below
- publicPurchase (Boolean, default false) — see Configuration below
- hatStyle, sortOrder
- Relations: category, campaign?, patches: PatchCollection[], purchases: UserPurchase[], submissions: PatchSubmission[]
Campaign (schema.prisma:70-86): id, name, tagline, description, heroImageUrl/heroBlurhash, color, sortOrder. Has many Collection. Carries no adminOnly/visibility column of its own — its visibility is entirely derived from whether it has ≥1 visible member collection (see Configuration).
PatchCollection (schema.prisma:247-258): pure join table, patchId + collectionId, @@unique([patchId, collectionId]). This is what lets one patch belong to multiple collections at once (e.g. a patch curated into both a region collection and, separately, a themed collection) — nothing in the schema prevents or limits multi-membership.
UserPatch (schema.prisma:785-808): the collected-patch record progress is computed from — userId, patchId, collectedAt, source ('gps' | 'import' | 'unknown').
No UserCollectionProgress, UserCampaignProgress, CollectionCompletion, or MasterPatch-shaped table exists anywhere in the schema. Grepping all 60+ models for anything progress/completion-shaped for collections/campaigns turns up nothing; Achievement/UserAchievement (schema.prisma:1766-1822) is the only reward table in the schema, and its metric/family/placeType fields key off Patch.collectionType (a patch's type slug, e.g. "national_park") — never off a specific Collection.id or Campaign.id (backend/src/achievements/achievement-evaluator.service.ts:8,86). Completing a named collection or campaign has no achievement counterpart.

API surface (endpoints, auth requirements)

Mobile-facing (read):

GET /api/sync/content (via SyncService.getContent, backend/src/sync/sync.service.ts:194) — returns categories, collections, patches, patchTypes, patchCollections, campaigns in one payload, filtered per isAdmin (see Configuration). Standard app auth (not admin-only), optional since param for delta sync.

Admin-facing (all behind @UseGuards(AdminGuard), mutations additionally behind ContentWriteGuard — local-only per CONTENT_EDITING_ENABLED):

backend/src/admin/api/collections-api.controller.ts: GET /api/admin/collections, GET /:id, GET /:id/enrich-status, POST / (create), PATCH /:id, DELETE /:id, POST /:id/patches (add member patch), DELETE /:id/patches/:patchId, plus enrichment/image endpoints (:id/enrich-all, generate-missing-images, :id/generate-image) — out of scope for this doc.
backend/src/admin/api/campaigns-api.controller.ts: GET /api/admin/campaigns (list, with _count.collections), GET /:id (detail incl. members + an "available to add" pool of campaign-less collections), PATCH /:id (edit name/tagline/hero/etc.), POST /:id/reorder (swap sortOrder with neighbor), POST /:id/collections (attach a collection, appends at maxCampaignOrder + 1), DELETE /:id/collections/:collectionId (detach, sets campaignId: null), POST /:id/collections/:collectionId/reorder (swap campaignOrder with neighbor). No POST /api/admin/campaigns to create one — see "How it works" step 1.

Key files (annotated)

Backend:

backend/prisma/schema.prisma:18-86,247-258 — Category/Collection/Campaign/PatchCollection models.
backend/src/sync/sync.service.ts:194-327 — the one query/serialization path that ships this content to mobile, including the adminOnly filter and the "campaign must have ≥1 visible member" rule (sync.service.ts:215-226).
backend/src/content-publish/content-entities.ts:78-233 — classifies which columns of Category/Campaign/Collection are published content vs. excluded (e.g. patch_count is excluded, always server-recomputed).
backend/src/admin/api/campaigns-api.controller.ts — campaign CRUD (minus create) + member reordering.
backend/src/admin/api/collections-api.controller.ts — collection CRUD + member patch attach/detach.
backend/src/scripts/create-road-trips-campaign.ts, restructure-*-campaign.ts — how new campaigns are actually minted (direct Prisma script, not the admin API).

Mobile — data/derivation:

mobile/src/hooks/contentDerivations.ts:67-133 — deriveCollectionsWithProgress, deriveCollectionsForCampaign, deriveCampaignsWithProgress: the one shared implementation of "how much of this collection/campaign is done," including the purchased-collection 100% short-circuit (lines 76-84).
mobile/src/hooks/useCollections.ts, useCampaigns.ts, useCampaignStops.ts — thin hooks wrapping the above derivations with live query data (content + purchases + collected patches).
mobile/src/hooks/useProfileData.ts:60-101 — where isComplete/completionDate per collection are computed for the profile screen; isComplete = collectedCount > 0 && collectedCount >= totalCount, completionDate = the collectedAt of the most recently collected member patch. Purely a display derivation.
mobile/src/domain/cityChallenges.ts — City Challenges resolution: supportedCities() derives one SupportedCity per collection under the great-american-cities campaign, pinning each to a state from its curated members; buildCityIndex()/cityForPlace() resolve an arbitrary photographed place to its city collection, curated membership taking priority over a name+state fallback match.

Mobile — honest-progress rules:

mobile/src/components/campaign/campaignCounts.ts — the single shared "how do we state a percentage honestly" module: started = collectedCount > 0; pctLabel is null (nothing rendered) until started, then '<1%' if Math.round(pct) === 0 else `${pct}%`; barWidthPct is 0 when unstarted, else Math.max(pct, 2) so one collected item always draws a visible sliver.
mobile/src/components/campaign/CampaignShowcasePanel.tsx:122-129 — where the rule actually lands on screen: the progress hairline is only rendered {counts.started ? <track/> : null} — an unstarted campaign's gallery cover draws no progress track element at all (comment: "Never a full-width empty track, which is what made sixteen unstarted campaigns read as sixteen failures").

Mobile — screens/spines:

mobile/src/screens/CampaignsListScreen.tsx — the campaign gallery: ScrollView with snapToInterval={viewportHeight / 2}, so a flick always lands on exactly two full covers, never a clipped one (lines 62-73).
mobile/src/components/campaign/CampaignShowcasePanel.tsx — one full-bleed cover (photo + scrim + name/tagline/counts + optional progress hairline).
mobile/src/screens/CampaignScreen.tsx — campaign detail, split into CampaignScreenViewModelImpl (every hook, CampaignScreen.tsx:147) and the pure CampaignScreenLayout (CampaignScreen.tsx:214), the house view-model pattern. buildCampaignScreenData (CampaignScreen.tsx:116) is the one pure derivation of status (loading / not-found / solo / ready), the spine variant and the hero source; the Ken-Burns hero lives in HeroBackdrop (scale 1.16→1, opacity 0→1, CampaignScreen.tsx:182-207); the layout switches on variant to one of three spine renderers (CampaignRoad / CampaignTimeline / CampaignTrail, CampaignScreen.tsx:319-325); a solo-kind campaign skips the spine entirely and hands off straight to CampaignCollectionScreen (CampaignScreen.tsx:258-260). mobile/app/campaign/[id].tsx is only the route file that re-exports it.
mobile/src/components/campaign/CampaignCollectionScreen.tsx — the stop-level screen: one collection's member-patch grid under the parent journey's identity. Split into CampaignCollectionScreenViewModelImpl (every hook, CampaignCollectionScreen.tsx:264) and the pure CampaignCollectionScreenLayout (CampaignCollectionScreen.tsx:378), the same house pattern as CampaignScreen. buildCampaignCollectionScreenData (CampaignCollectionScreen.tsx:198) is the one pure derivation of status (not-found / ready), the distance sort, the all/collected/uncollected filter, the hero source and the percentage; campaignCollectionMotif (:152) picks the hero badge as a discriminator (flag / glyph / marker / none) and campaignCollectionKicker (:174) the identity line — a solo campaign borrows the campaign's own kicker rather than repeating the title. It stays under components/campaign/ rather than moving to screens/ because it has TWO consumers: mobile/app/campaign-collection/[id].tsx (the route) and CampaignScreen's solo branch, which embeds it. The hero image is a member patch's own location photo (lowest patch id, so it is stable against the user's location), falling back to the campaign hero and then to nothing.
mobile/src/components/campaign/CampaignRoad.tsx — "road" spine: an asphalt rail with a gold centerline, mile-marker nodes, per-stop fanned patch thumbnails (LayeredThumbnailStack) and a per-state progress bar (comment lines 1-4).
mobile/src/components/campaign/CampaignTrail.tsx — "trail"/"list"/default spine: a dashed SVG footpath (strokeDasharray="3 8", chosen over RN's unreliable borderStyle: 'dashed', lines 24-28) with nature-glyph nodes instead of mile markers.
mobile/src/components/campaign/CampaignTimeline.tsx — "timeline" spine (era U.S.-flag glyphs via eraFlags.tsx). Currently selected by no campaign at all — Civil War and Founding & Revolution are both kind: 'trail' in the theme table — so this renderer is live code on an unreachable branch.
mobile/src/config/campaignThemes.ts — the per-campaign theme table: kind: 'road' | 'list' | 'trail' | 'timeline' | 'solo', kicker/route copy, start/end labels, per-collection marker/icon maps. list and the unthemed default both render via CampaignTrail (only road and timeline get their own branch — CampaignScreen.tsx:319-325; campaignSpineVariant at CampaignScreen.tsx:103 is the mapping).
mobile/src/hooks/useCampaignStops.ts:30-53 — buildCampaignStops: for each ordered member collection, up to 3 member patches as thumbnail specs, collected ones sorted first so "the front badge is one you have."
mobile/src/components/campaign/campaignRail.ts — stopState() (completed/in_progress/untouched from collected vs. total), resolvePipGlyph(); also contains buildCampaignRail/sampleEvenly, which per grep is currently unused by any shipped screen (dead code from a prior gallery variant, see Summary).

Configuration and flags

Collection.adminOnly (default false): when true, the collection is excluded from the mobile content sync entirely for non-admin sessions. SyncService.getContent applies { adminOnly: false } to the collection filter and { collection: { adminOnly: false } } to the patch-collection join filter whenever isAdmin is false (sync.service.ts:194-213) — this is deliberately not gated on NODE_ENV (prod runs with NODE_ENV unset; an env-based gate previously leaked store-only packs into the app, per the comment at sync.service.ts:196-200). Admins see everything (for QA). This means "hidden from the earn-in-app catalog" — but calling it "store-only" was inaccurate before 2026-09 and this doc is correcting itself: adminOnly was never actually a "still sold in the store" flag by design, it just happened to have no effect there. StoreCollectionsService.getCollections (backend/src/store-collections/store-collections.service.ts:195-238, filters only storeVisible: true at :203) returns adminOnly as a plain field and always did — it never filtered on it, and for a long time neither did any of its four consumers (the in-app "Your sets" shelf filter, its collection-id fallback, getCollectionDetail's handle/id lookup, or getProductContext). The result, confirmed live before the fix: 15 legacy adminOnly collections the mobile app had stopped syncing (major-cities, us-states, national-parks, civil-war-battlefields, founding-revolution, and ten more) were still reachable and buyable as $8 "sets" through the in-app store — offering scouts sets they could never actually complete, since the app never gave them any members to collect. All five doors are now closed (docs/features/commerce-and-store.md's "Edge cases" has the detail — the fifth was the backend filter's own side effect, a kind ternary on the storefront product pages that defaulted the set gate's publicPurchase to true for exactly the contexts the filter had started refusing); adminOnly now means "hidden from the earn-in-app catalog and the store" everywhere except the genuinely-intentional exception, Collection.publicPurchase packs, which are adminOnly: true by design and stay store-visible on purpose (see below).
Campaign visibility is derived, not stored. A Campaign row has no visibility column; SyncService.getContent requires collections: { some: { adminOnly: false } } for non-admins (sync.service.ts:215-226), so a campaign whose every member collection is adminOnly never syncs to a regular device at all — the whole campaign, not just its collections, disappears.
Collection.publicPurchase (default false): "store-exclusive" / open-purchase flag — a collection's patches can be bought directly as a set without being earned via GPS check-in first (StoreCollectionsService, backend/src/store-collections/store-collections.service.ts:22-23,87-88,110-114). This is orthogonal to adminOnly: publicPurchase governs how a patch can be obtained (store purchase vs. earned unlock), adminOnly governs whether the collection appears in the in-app earn-it catalog at all. Full store mechanics are out of scope for this doc.
No feature flag gates categories/collections/campaigns as a feature — see Status above.

Edge cases and known limits

Detail-screen progress does not apply the honest-progress rules. campaignProgressPct (mobile/src/screens/CampaignScreen.tsx:106-107) computes pct = Math.round(progress * 100) directly and renders `${pct}%` and a width: ${pct}% fill with no floor and no <1%/null suppression — unlike the gallery cover, a campaign one stop into 258 (0.4%) would show a literal "0%" and a zero-width bar on its own detail screen's hero, even though the gallery card for the same campaign correctly shows "<1%" and a 2%-wide sliver. This is a real inconsistency between the two screens, not a guess — both code paths were read directly.
patchCount is a denormalized column, recomputed server-side after every content publish (content-entities.ts:227-229), not derived live from patch_collections on the client. If it ever drifts from the real join-table count between publishes, every progress percentage for that collection is wrong until the next publish/recompute.
A patch can be a member of multiple collections simultaneously (PatchCollection has no uniqueness constraint beyond [patchId, collectionId] itself), so collecting one patch can move the needle on several collections' — and thus several campaigns' — progress at once. No code path treats this as unusual; it is the normal case for, e.g., a patch curated into both a themed collection and a City Challenge collection.
City Challenge state assignment can fall back to a majority vote. supportedCities() (cityChallenges.ts:78-97) prefers the state of a member patch whose city string name-matches the collection, but falls back to "whichever state has the most members" when no member's city field matches the collection name exactly — a city collection with no exactly-named member could theoretically be assigned the wrong state.
CampaignCollectionScreen has no loading and no error branch. It reads useContent() and usePatches() for their DATA only and ignores both hooks' isLoading/error, so collection is null until the first content sync lands — and the screen renders "Collection not found." for the whole of that window, and again if the sync fails outright. On a warm start the catalog is already cached and nothing is visible; on a cold start from a scout://campaign-collection/<id> deep link it is a real flash of a false error. Its sibling CampaignScreen does distinguish the two (status: 'loading' | 'not-found'). Not fixed as of 2026-09-04; the screen-mock gallery deliberately registers no loading or error state because either would be a pixel-identical copy of not-found.
The hero has a third fallback with no art in it. heroUri is a member patch's location photo, else the campaign's heroImageUrl, else null — and with both gone the 322dp hero is just the scrim over bare canvas, with the kicker and title floating in it. No shippable collection reaches this today (every one has at least one member patch with a location photo), but a hero-less campaign plus unenriched patches would; see scout://dev-screen-mock/campaign-collection?state=no-hero-art.
A solo-kind campaign (Zoos, Aquariums, Major Airports) has no spine at all — tapping it on the gallery routes straight to CampaignCollectionScreen for its one collection; there is no intermediate "campaign detail" moment for these.
Large trail campaigns (e.g. 54-city Great American Cities) are handled by the dead sampleEvenly/buildCampaignRail downsampling logic in campaignRail.ts, but since nothing currently renders that rail, there is no live UI path that actually downsamples a long list of stops — CampaignRoad/CampaignTrail render every stop in the campaign, unsampled, in the detail screen's spine.

What this feature does NOT do

It does not award anything for completing a collection or campaign. No achievement, no XP, no badge, no "Master Patch." This was explicitly checked against Achievement/UserAchievement/achievement-rules.ts/achievement-evaluator.service.ts — the achievement system keys entirely off Patch.collectionType (a type slug) and place counts, never off Collection.id or Campaign.id. Completion only flips a client-computed isComplete/progress === 1 boolean used for display (a checkmark node, a "Complete" label, a profile-screen tally).
It does not persist progress anywhere. There is no server-side progress table for collections or campaigns; every screen recomputes it from user_patches on every render.
It does not gate content behind campaigns. A patch's location-unlock (geofence) is completely independent of collection/campaign membership — a patch can be physically unlockable regardless of whether its parent campaign or collection has been "started."
It does not let admins create a new Campaign row through the admin UI/API. New campaigns require a hand-written script run against the database directly (see "How it works," step 1) — the admin API only edits, reorders, and (dis)connects existing campaigns/collections.
"City Challenges" is not a distinct data type. There is no Collection.type or kind: 'city' column. It is one campaign (great-american-cities) with curated per-city member collections; the "which city does this photo belong to" logic (cityForPlace) is entirely client-side, computed from patch_collections membership plus a name/state string-match fallback, not a queryable server property.
It does not verify or transmit collection-completion proof to the store. The Home screen's "20% off, earned not bought" completion banner (mobile/src/components/home-v3/PlaceBody.tsx:225-259) routes to a generic signed-in store WebView (mobile/app/store-webview.tsx) with no completion token, discount code, or collection id passed — whatever enforces that discount, if anything does, lives entirely in the store domain (out of scope here; not verified by this document).

Tests that cover it

Mobile (unit, pure-function level, jest):

mobile/src/components/campaign/__tests__/campaignCounts.test.ts — the honest-progress rules directly: unstarted campaigns get pctLabel: null/barWidthPct: 0; 1-of-258 renders '<1%' with a floored barWidthPct: 2; started campaigns state a real percentage; solo/single-collection campaigns hide the group count; divide-by-zero safety for an empty campaign.
mobile/src/hooks/__tests__/store.campaign-progress.test.ts — deriveCollectionsWithProgress/deriveCollectionsForCampaign/deriveCampaignsWithProgress against a small Route 66 fixture (Illinois/Missouri member collections + a non-member Chicago collection), asserting correct membership filtering and ordering.
mobile/src/hooks/__tests__/useCampaignStops.test.ts — the thumbnail-fanning derivation (buildCampaignStops), including the "collected members sort first" rule.
mobile/src/hooks/__tests__/store.campaigns.test.ts, campaignsPersisted.test.ts — campaign hook/query behavior.
mobile/src/config/__tests__/campaignThemes.test.ts — theme table sanity (every campaign resolves to a valid kind, etc.).
mobile/src/components/campaign/__tests__/campaignRail.test.ts — stopState/resolvePipGlyph/buildCampaignRail (the last of which, per the Summary above, is otherwise dead code — tested but unused).
mobile/src/hooks/__tests__/useCollections.test.tsx — useCollections/useCollection progress derivation.

Mobile (screen tier, jest.screens.config.js):

mobile/screen-tests/campaign-id.test.tsx — the detail screen end to end through its route: title/tagline and hero progress derived from seeded member collections; the "Campaign not found." branch for an id with no matching campaign; the trail stop cards' fanned patch art (present, contentFit: 'contain', vertically centred) and its falsification with no patch_collections join rows.
mobile/screen-tests/campaigns.test.tsx — the gallery.
mobile/screen-tests/screen-mocks.test.tsx — renders every state of the DEV screen-mock gallery, including the ten campaign states (mobile/src/dev/mocks/campaign.tsx): the road / trail / timeline skins, the no-hero + unthemed fallback, zero / partial / complete progress, a campaign with no member collections, loading and not-found. It also renders the eleven campaign-collection states (mobile/src/dev/mocks/campaign-collection.tsx, scout://dev-screen-mock/campaign-collection): the Zoos solo hand-off (interactive — its view toggle and filters really work), photo-card view, part-way and fully-collected progress, both empty filters, an empty grid, the trail glyph + singularised "· REGION" kicker on the longest collection name in the catalog, the Route 66 mile marker, the bare hero with no art at all, and not-found. Fixtures are four real shippable collections (Zoos, Route 66's Illinois, National Parks' Appalachia & the Mid-Atlantic, O'Fallon Illinois) with all 57 of their real member patches; the only synthetic fields are isCollected (progress is user state; the catalog's best real campaign progress is 2%) and the nulled location photos on the no-hero state. Each state asserts content only it produces, so a mock that has silently stopped tracking the screen fails the build.