bug(showcase): two live entries show literal unresolved '{slug}' template placeholder as title/company name

[developer-ainative]

Summary

Found live while human-testing #955/#958's fixes on production: two showcase entries show the literal, unresolved template placeholder text `{slug}`` as both their title and company name, instead of a real idea or company name.

Evidence

TITLE: '{slug}`'
PROMPT: 'Build a polished, production-quality single-page marketing LANDING PAGE for "{slug}`" -- a real company for this idea: {slug}`. Include: a hero with...'
SLUG: 'slug-x6wOHR'

TITLE: '{slug}`'
PROMPT: 'Build a real, working, functional application for "{slug}`" that actually implements this idea: {slug}`. This is the founder's REAL, WORKING TOOL...'
SLUG: 'slug-7W6siL'

Both the company-app (landing-page-only) AND company-product (real app) generation templates received the literal string {slug} + a trailing backtick as the name/idea value, rather than a real substituted value. This is not a server-side template-literal bug -- grepped the whole app/api/build tree and every real ${slug} usage correctly interpolates. This looks like either:

1. A test/seed script that sent literal placeholder text as real input (possibly markdown documentation text pasted/run verbatim, given the trailing backtick), or
2. A real caller somewhere that failed to substitute a template before sending it to the generation pipeline.

Impact

Two garbage entries are live on the public /showcase page right now, titled `{slug}`` -- visually broken, confusing to a real visitor, and inconsistent with #955's whole point (showing real founders' real businesses).

Suggested fix

1. Identify and remove/hide these two specific entries (slugs slug-x6wOHR, slug-7W6siL) from the public showcase -- likely via the existing is_showcase gate (generation-persist.ts) or a manual ZeroDB row update, whichever this codebase's established pattern is for excluding a bad entry.
2. Trace where the literal {slug} text actually originated (check recent test/seed scripts, or add validation that rejects a name/slug parameter containing unsubstituted {/} template syntax before it ever reaches the generation pipeline) so this can't happen again for a future entry.

Not fixing this myself in the same pass as #958 since the root cause (where the bad data came from) is still unknown and needs investigation before a confident fix, not just a guess.

[developer-ainative]

Root-caused and fixed in #963 (open, not merged — left for review).

Real root cause, reproduced exactly

Confirmed your read: this is not a server-side template-literal bug. Every ${slug} in app/api/build interpolates correctly, and both prompt templates are well-formed.

The origin is the deep-link entry point, contexts/build-context.tsx:

dispatch({ type: 'START_BUILD', idea: company, appSub: company, companyName: company })

It seeds idea, appSub and companyName from the raw ?company= query param. Live.tsx then posts state.companyName as name and state.idea as idea to both /api/build/company-app and /api/build/company-product — which is why both templates got hit with the same value, one entry each.

Someone opened /build?screen=live&company={slug} with the markdown code-span's closing backtick still attached. Your guess that it was documentation text pasted verbatim was right, and the source is in this repo: docs/growth/WINBACK_EMAIL_2026-08-27.md line 23 literally contained

`?screen=live&company={slug}` (durable)

components/build/StandalonePreviewRegenerate.tsx's own doc comment carries the same placeholder in backticks.

Reproduction — fed {slug} + backtick as the single input through the real, unmodified functions:

	Live row	Reproduced
company-app title / slug	{slug}` / slug-x6wOHR	{slug}` / slug-x6wOHR
company-product title / slug	{slug}` / slug-7W6siL	{slug}` / slug-7W6siL

Both prompts match character for character.

The slugs are derived, not stored — app/api/showcase/route.ts builds them as generateSlug(title) + '-' + chat_id.slice(0, 6), which is why x6wOHR/7W6siL looked like a random suffix no script generates. They're just the nanoid chatId prefixes: x6wOHR9rN8UDxcUyTXElZ and 7W6siLoHGM8O4rsusuIQt, both 2026-09-23. No builder_app_registry row exists for either, so registerApp never ran — a one-off URL open, not a repeating caller.

Ruled out: no committed script/seed/test/agent surface POSTs these routes; nothing in git history around 2026-09-23 touched them.

Fix (three layers, all existing mechanisms)

1. Prevention at the source — ?company= with {...}/${...}/a backtick no longer starts a build; routed to the companies picker via the existing deepLinkNotFound path.
2. API-boundary backstop — both routes 400 on a placeholder idea/name before touching the registry or starting generation. (The validation you suggested.)
3. The 2 live entries removed — read-time filter next to the existing is_showcase gate in app/api/showcase/route.ts.

On your is_showcase suggestion specifically: that gate couldn't work here. Both rows were persisted with is_showcase: true and pass isQualityApp — nothing was wrong with their code, only with the name they were generated for — and is_showcase is computed at persist time, so it can't retroactively fix a stored row. ZeroDB rows are append-only/latest-wins with no delete path, so read-time exclusion is the established pattern here, in the same place the is_showcase filter already lives. No new mechanism invented.

Verification

50 new tests across 4 files, built from the actual live rows (verbatim prompts/chat_ids fetched from production), weighted toward the false-positive direction — 20+ realistic founder names/ideas (O'Brien & Sons, Café Müller, C++ tutoring, cost: $19) must all still pass, since rejecting a real build would be worse than the bug.

npx vitest run → 6510 passed, 1 pre-existing unrelated failure (task-splitter.test.ts #904, confirmed failing identically on clean origin/main with my changes stashed — not touched). npx tsc --noEmit clean.

Honest limits

High confidence on the mechanism and on the string's source. Not determinable, and not claimed: who opened the URL and when exactly — there's no request log for an anonymous deep-link page load, and the registry rows that would have carried an owner were never written. That gap doesn't affect the fix, which keys on the shape of the input rather than its sender.

One follow-up worth its own issue: the 2 rows still physically exist in generations (now excluded at read time). There is no hard-delete/tombstone path for a ZeroDB generation row.