Validate TinaCMS content slugs to reject invalid URL characters

[jakebromberg]

Problem

The blog post at content/blog/boy-harsher-at-cat's-cradle.md had an apostrophe in its filename. When @tinacms/cli was bumped past 2.x (see #177), the new validator rejected the path with:

Error: Unable to fetch
Invalid path: relativePath contains invalid characters

This broke prerender of /blog/boy-harsher-at-cat's-cradle and the entire production build.

The file was renamed to boy-harsher-at-cats-cradle.md as part of #177 to unblock the dependency bump, matching the convention used by every other Cat's Cradle post in the collection.

Why this happened

Nothing in the TinaCMS schema or our editorial workflow prevented an editor from typing a slug (or a title that gets slugified) containing an apostrophe, em-dash, parentheses, or other characters that are invalid in URL paths or that downstream tooling rejects. The editor saved the file; it built fine under the old cli; it silently became a landmine when the cli's validation tightened.

Proposal

Add a guardrail somewhere upstream of the build. Options, in rough order of preference:

1. TinaCMS schema-level filename/slug validation on the blog and archive collections — restrict slugs to [a-z0-9-]+ (lowercase kebab-case). This catches the problem at edit time, in the CMS UI, before the file is even committed.
2. Pre-commit / CI check that scans content/**/*.md filenames and fails on any character outside the allowed set. Cheaper to implement but only catches after-the-fact.
3. Both — schema validation prevents new bad slugs; CI check is the safety net.

Acceptance

• Editors can no longer save a TinaCMS post with an invalid slug character.
• CI fails fast (with a clear message) if such a file ever lands in content/.
• Existing content audited and renamed if any other files have this latent issue.

[jakebromberg]

Triage finding (2026-06-15): still valid. Current state of tina/collections/blog.js uses filename.readonly: true with a custom slugify that strips [^\w\s] from the title, which would catch apostrophes when filename derives from title. But the schema does not validate or constrain editor-supplied filenames (e.g. via TinaCMS ui.filename.slugify for the archive collection has the same shape), and there is no CI check on content/**/*.md filenames. Recommend approach 3 from the issue body — schema validation in both blog and archive collections AND a one-shot CI check. The CI check is the cheaper guardrail (one workflow step, a regex scan), and is independently useful for catching content directly pushed via git that bypassed Tina.

Cross-ref: predecessor was #177 (cli@2.x bump, merged in PR #181 on 2026-06-03 after renaming the bad file in commit 1649ad2). PR #190 (dependabot cli 2.4.3 -> 2.5.0) is open right now — worth landing #185's CI check before merging that PR.