Content safety hardening: pre-generation topic moderation for abusive and zero-gibberish entries

[LynnColeArt]

Why this is necessary

Automated abuse attempts are creating synthetic/offensive topic slugs and getting them near-visible in production. This causes junk in public index surfaces, degrades trust, and can burn LLM tokens before post-write moderation can clean up.

Screenshot evidence

/home/lynn/Downloads/screenship-All-entries-Halupedia-2026-05-14T07-55-13.png

What we changed

1) Pre-generation content-policy gate

• Added isTitleModerationApproved(...) in /api/page/:slug before any article generation call.
• If a topic is not approved, the request is blocked up front with a refusal response.
• User-facing refusal message: I'm sorry Dave, I can't do that.

2) Deterministic gibberish / spam detection

• Added isObviousGibberishTitle(...) with guards for:
  • very long zero strings,
  • long mostly-numeric titles,
  • repetitive scripted token patterns.

3) Permanent blocklist hardening

• Expanded src/worker/blocklist.ts to catch zero-heavy and numeric-pattern abuse before generation and before moderation logging.

4) Index hardening

• Updated /api/index filtering so permanently blocked slugs are excluded from live listings too.

5) Friendly UI signal

• Updated banned-topic presentation in src/client/App.tsx so blocked requests show the actual refusal message.

Why this is the right approach

This moves safety from "clean up after write" to "reject before write" for clearly abusive/nonsensical topics, reducing abuse surface, improving UX clarity, and saving API budget.

Related PR

• Filter moderation-blocked slugs from /api/index #15

[GeoMaciolek]

Some simple regex to match e.g. /(.)\1{5,}/ (anything with five or more repeated characters in the name) would be a helpful, but I think that's only sustainable if that can be:

1. Edited in the admin UI (meaning a Config table or similar, and the associated DB lookups on every new article creation)
2. Applied to existing articles, also via the UI ideally

I haven't run a local instance (with or without the changes by @LynnColeArt ) so I'm not sure what the moderation workflow looks like yet, but this would obviously be a good thing to have placed within that.

One quick thought - as more and more database-related features get added, this is potentially getting more and more tied to Cloudflare D1, vs. a database abstraction layer. Given the active griefing & racist garbage the site's getting flooded with, I think content cleanup, moderation, etc is probably higher priority than architecture changes, but I think it's worth considering trying to make this somewhat more platform-agnostic.