fix(smugmug): match event names whose only token is a number

[alchemydc]

Problem

The September event produced no Photos ↗ link, while every other 2026 event linked correctly.

This is not a regression — src/lib/smugmug.ts last changed in #99 (2026-07-28), well before the event. It is a latent bug that "The 912" is the first event name to trip.

matchEventFolder built the folder's content tokens as:

const contentTokens = tokenize(folder.urlName).filter((t) => !/^\d+$/.test(t));

That filter exists only to drop the conventional YYYY-MM-DD- prefix, but it is indiscriminate — it strips every pure-digit token, including digits that are part of the event name. The event-name side is not filtered at all.

For "The 912" (2026-09-12, league pca-rmr):

• tokenize("The 912") → ["912"] — the is a STOPWORD, leaving one digit token
• tokenize("2026-09-12-The-912-Autocross") → ["2026","09","12","912"] → digit filter → []

contentTokens.length === 0 hit the continue, the folder was skipped, and the function returned null. The link silently never rendered.

Confirmed against the live SmugMug API: the gallery 2026-09-12-The-912-Autocross exists, so matching was the only thing missing.

Ruled out: the league-config path. "The 912" is a pca-rmr event whose League row has smugmugUser=rmrpca / smugmugDisciplinePath=Autocross, so resolveSmugmugTarget returns a valid target. The multi-league split is not involved; no SCCA event is affected.

Fix

Strip only the leading date prefix, then tokenize the remainder — and reuse that same match for the date-proximity term instead of running a second regex over the same string.

This cannot loosen matching. Extra content tokens only ever lower reverse (matchCount / contentTokens.length) and never affect forward, so retaining in-name digits can only make a match stricter — except where the digit is the token we actually want. For date-prefixed folders the resulting token set is byte-identical to before.

matchCount, forward/reverse, tScore, dateScore, the 0.6/0.4 weighting and the strict > 0.6 threshold are all untouched.

Tests

Five new cases alongside the existing ones:

• matches an event whose only token is a number
• matches when the folder omits the leading article (2026-09-12-912-Autocross)
• does not match a same-day folder sharing no token — a lone numeric token must not match on date alone
• does not match a same-named folder ~60 days out — confirms date still gates a perfect token score (0.6 * 1.0 + 0.4 * 0 is not > 0.6)
• picks the date-nearest folder when several share the numeric token

Verification

• lint — clean
• typecheck — clean
• test — 736 passed / 62 files
• next build — compiled successfully

matchEventFolder runs outside the unstable_cache layer, so no cache bust is needed — the 1h folder-list and 1w year-node caches are unaffected and the fix takes effect on next render.

Notes for deploy

No schema, migration, admin UI, or Turso work. Code-only.

Separately surfaced while testing locally (not addressed here): dev.db had never had 20260730010000_scoring_policy_v4 applied, so every event page threw scoringPolicy.v must be 4 — got 3 before reaching any photo-link code. Worth confirming that migration is applied wherever this deploys.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
launchcontrol	Ready	Preview	Sep 19, 2026 2:36pm UTC

[Copilot]

Copilot review overview

🟢 Approval recommended

The fix is covered by regression tests and no unresolved issues remain.

Review effort: Lite
Findings: None

What changed in this PR

Fixes SmugMug matching for events whose meaningful name token is numeric, such as “The 912.”

Changes:

• Strip only the leading date prefix before tokenization.
• Reuse the parsed date for proximity scoring.
• Add regression tests for numeric names and date-selection boundaries.

File	Description
apps/​web/​tests/​smugmug.test.ts	Adds regression coverage for numeric event matching and date boundaries.
apps/​web/​src/​lib/​smugmug.ts	Corrects folder tokenization and date parsing.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.