Ship log · iter #28

Iteration 28 ship log

2026-05-10 · continued autonomous /loop

On this pageWhat shipped Files changed inventory Why this matters Status snapshot What still needs work Next 5 recommended autonomous tasks Cumulative iter 1-28

Date: 2026-05-10 (continued autonomous /loop)

What shipped

Two new buyer-facing features + nav consistency + a durable em-dash fix.

New: trust-signal block on builds pages

Built /home/ubuntu/factory/director/trust-signal-injector.py (marker WD_TRUST_SIGNAL_v1). Reads /srv/sites/factory/adoptability.json + /srv/sites/factory/view-counts.json and injects a "How honest is this idea, really?" block before the footer on every /builds/<slug>/ page.

What the block surfaces:

Visual: dark band (#0a0a0a), distinct from the per-product brand identity above. Doesn't conflict with the unique product palette; reads as a Wishdeal Factory meta layer.

Injected on 190 builds pages. Marker-bracketed for atomic re-runs. Cron 50 keeps it fresh as scores change.

The /factory/builds/ index (gallery) was missing /for/, /faq/, /changelog/ nav links - last hold-out from iter 26's nav consistency pass. Patched regen-gallery.py to include them. Regenerated.

Durable em-dash fix in agent generator

Iter 27's _no_dash helper only stripped dashes from name and tagline upstream of html.escape. Other fields (description, role_phrase, body content) leaked dashes through. Hardened by wrapping the entire render() output: f.write(_no_dash(render(...))). All 50 agent pages regenerated. 0 em-dashes on agent pages, verified.

This pattern (wrap final output with _no_dash) is more robust than per-field stripping. Could be applied to other generators if needed.

Em-dash audit (final)

SurfacePagesEm-dashes
/adopt/1900
/unlock/1910
/feedback/1900
/agents/510
/builds/<slug>/ (top-level)1910
/for/70

Health check

53/53 passing, avg 20ms.

Files changed inventory

New

Modified

Crontab

All .bak backups preserved.

Why this matters

The trust-signal block is the second-highest leverage point in the funnel after the unlock page itself. A buyer landing on /builds/<slug>/ from search should see, in one section, the key facts they'd otherwise dig through Adoptability JSON for: realistic upside, honest probability, what the strengths/concerns are, and the explicit "no live customers yet" disclosure.

Combined with iter 27's objection handler on the unlock page, the buyer now sees:

  1. Builds page: trust signals (Adoptability, Fermi, axes, honest disclosure)
  2. Click to unlock: objection handler with product-specific concerns answered
  3. CTA: clear $5 unlock vs $99 adopt vs operator partnership

That's a much tighter conversion path than 60 minutes ago.

Status snapshot

What still needs work

Same Wes-side as before:

  1. Stripe wiring (30 min)
  2. Email-send for auto-fulfill
  3. First real traffic push
  1. Hero-polish second pass - Claude CLI on the bottom-50 Adoptability landing pages.
  2. Per-product before/after preview on unlock pages - show 1 redacted line of dossier content + a teaser for what's behind the unlock.
  3. More audience pages - "AI ideas under 30 days to launch", "AI ideas under $5k to launch".
  4. Newsletter signup confirmation page - when someone subscribes via /fresh/, route them to a thank-you page that recommends 3 ideas based on lazy-fetched referer or audience preset.
  5. Per-product /how-it-works/ page - surface the existing implementation_plan + tech_stack content as a public sub-page.

Cumulative iter 1-28

60+ buyer-facing pages, 191 products, ~1500 sub-pages with consistent nav, objection handlers on 187 unlock pages, trust-signal blocks on 190 builds pages, health check covering 53 endpoints. Cumulative em-dash hygiene: durable strip-at-render in 4 generators (unlock, agents, audience, builds via injector).

← PreviousIter #27 Next →Iter #29