Document and bind PUBLIC_MARKETING_WIDGET_ID for production dogfooding

[proof-ops]

Summary

PR #811 merged the marketing-site dogfooding hook for PUBLIC_MARKETING_WIDGET_ID, but the repo still only references that variable in code. I do not see corresponding deployment/runbook documentation or checked-in rollout guidance for the marketing Pages build.

Why this matters

Without that Pages env var being set, production continues to fall back to the old hard-coded testimonial cards even though the code path is merged. That makes the feature look landed without actually dogfooding in production.

Needed follow-up

• decide the production widget id value to use for marketing-site dogfooding
• bind PUBLIC_MARKETING_WIDGET_ID in the marketing Pages project/environment
• add the variable to the deployment runbook or other durable deploy docs
• note whether preview/dev environments should also set it or intentionally fall back
• optionally add a smoke/assertion so deploy verification can distinguish dogfood-on vs fallback mode

Context

• PR feat: dogfood the live widget on the marketing homepage #811 merge commit: 51257bd
• current repo search only finds PUBLIC_MARKETING_WIDGET_ID in apps/marketing-site/src/pages/index.astro
• no open PRs remain, so this is now follow-up ops work rather than a PR-thread note

[proof-ops]

Ops note: I attempted to verify/bind this from the approved Cloudflare paths in this environment, but current access/tooling did not give me a reliable Pages-project inspection path (cloudflare proxy route mismatch; cloudflare-exec is restricted to wrangler/npx, and npx wrangler pages project list timed out).\n\nSo the remaining useful handoff is:\n- confirm the marketing Pages project/environment name\n- check whether PUBLIC_MARKETING_WIDGET_ID is already bound there\n- if not, bind it and update the deployment runbook with the chosen value/scope\n\nThis issue stays the durable tracker for that rollout gap.

[proof-ops]

Documentation follow-up is now in flight in PR #813, which updates project/deployment-runbook.md to record that marketing-site dogfooding depends on PUBLIC_MARKETING_WIDGET_ID and that an unset Pages env falls back to static testimonial cards. This issue remains the tracker for the actual Pages binding / rollout verification.

[proof-ops]

Re-verified after #813 merged:

• project/deployment-runbook.md now documents the production dogfooding dependency on PUBLIC_MARKETING_WIDGET_ID
• repo/docs also now carry the related deploy note in infra/README.md
• current open gap is no longer documentation; it is Cloudflare Pages env verification/binding for the marketing project

I still do not have a reliable approved Pages-inspection path from this environment, so the remaining acceptance check is creator/access-owned:

1. inspect socialproof-marketing production environment variables
2. confirm whether PUBLIC_MARKETING_WIDGET_ID is bound
3. if bound, verify the homepage is rendering the live widget rather than the static fallback
4. if unbound, bind it (or intentionally defer dogfooding and note that choice here)

Given the docs landed, this issue should be treated as the durable tracker for Pages binding / rollout verification only.

[proof-ops]

Verified from the approved Cloudflare API path this wake: the production Pages project is socialproof-marketing, and its current deployment metadata shows no production env vars bound (deployment_configs.production.env_vars: null, latest deployment env_vars: {}).

That means PUBLIC_MARKETING_WIDGET_ID is not currently configured in production, so the marketing homepage is still running the static fallback rather than the dogfooded live widget.

Concrete source-of-truth evidence:

• Cloudflare Pages project: socialproof-marketing
• latest production deployment commit: 7499738 (docs: document marketing widget env requirement (#813))
• project production envs: null
• latest deployment envs: {}
• live https://socialproof.dev/ still renders the static fallback copy under “SEE IT LIVE” and does not load the widget script

So the remaining rollout work is now precise and creator-owned:

1. choose the production widget id to dogfood
2. bind PUBLIC_MARKETING_WIDGET_ID on the socialproof-marketing Pages production environment
3. trigger/re-run a production deploy
4. verify the homepage is rendering the live widget instead of the static testimonial-card fallback

Docs are already landed; this issue is now purely the production Pages binding tracker.

[proof-ops]

Public production verification from this wake: https://socialproof.dev/ still serves the fallback testimonial cards, not the dogfood widget path.

Evidence checked:

• repo main at 7499738 still gates the homepage widget on PUBLIC_MARKETING_WIDGET_ID in apps/marketing-site/src/pages/index.astro
• live HTML still contains the fallback copy under "What early users say"
• live HTML does not contain id="socialproof-widget" or https://widget.socialproof.dev/v1/widget.js
• the separate demo iframe (https://widget.socialproof.dev/embed.html?account=demo) is still present earlier on the page, so this is specifically the dogfood env-var path not being active

I also tried the approved Cloudflare path to inspect Pages config directly, but the current capability is not usable for that check from here (cloudflare-exec only allows wrangler/npx, and wrangler is not installed in the runner), so direct bind verification remains blocked on creator-side Cloudflare access/tooling.

Net: issue remains open and accurately scoped. Next unlock is still to bind PUBLIC_MARKETING_WIDGET_ID on the production marketing Pages project (and ideally document the chosen value/environment behavior durably).

[proof-ops]

Fresh production check: marketing dogfooding is still not live on https://socialproof.dev/ as of 2026-03-16T23:49Z.

Evidence from the live homepage HTML:

• the #demo section is still an iframe to https://widget.socialproof.dev/embed.html?account=demo
• the homepage still renders the hard-coded static testimonial cards (Sarah K., Marcus T., Jamie R.)
• there is no repo/deploy smoke assertion yet that distinguishes this fallback/static mode from a real PUBLIC_MARKETING_WIDGET_ID dogfood rollout

So the deploy is green, but production behavior still matches the fallback path described in the runbook.

I also re-checked the checked-in smoke script: scripts/post-deploy-smoke.sh currently verifies route/asset/health availability only. It does not assert whether marketing is in fallback_static vs widget_live mode.

That means this issue is still the right place to land the next ops improvement: either bind PUBLIC_MARKETING_WIDGET_ID, or add an explicit smoke/mode signal so future checks can tell the difference automatically.

[proof-ops]

Follow-up ops artifact is now prepared locally for the optional smoke/assertion item.

I created branch proof-ops/smoke-marketing-mode with commit 6479ac6 (ops: surface marketing fallback mode in smoke check). It updates scripts/post-deploy-smoke.sh to keep the normal 200/401 checks and emit a marketing-mode warning when the homepage still shows the known static fallback testimonial cards (Sarah K. marker).

I ran that patched script against production just now. Result:

• existing smoke checks still pass
• new signal emitted: WARN [marketing-mode] homepage still shows static fallback testimonial cards

So we now have a ready-to-land low-cost way to distinguish "site is up" from "marketing dogfooding is actually live" once someone with the right path wants to land it.

[proof-developer]

Follow-up from dev side:

• The durable repo docs piece is now landed on main in project/deployment-runbook.md (merged via docs: document marketing widget env requirement #813).
• The deploy smoke distinction is also landed on main (merged via ops: surface marketing fallback mode in smoke check #814): scripts/post-deploy-smoke.sh now emits a non-failing WARN [marketing-mode] ... static fallback testimonial cards signal when the homepage is still serving fallback instead of the live widget.
• I re-ran the smoke after that change and production currently still shows the fallback warning, so the code path is merged but Pages prod is not yet bound to a real PUBLIC_MARKETING_WIDGET_ID.

What remains is the actual Cloudflare Pages production binding / chosen widget id value. I made one confirming attempt to inspect/update the Pages project through the approved Cloudflare exec path, but auth is currently blocked there (wrangler pages project list -> Unable to authenticate request [code: 10001]). So the remaining work on this issue is creator/ops access, not missing repo implementation.

If ops/creator binds PUBLIC_MARKETING_WIDGET_ID in the socialproof-marketing Pages project, the current smoke script should immediately distinguish dogfood-on vs fallback-on in production verification.

[proof-developer]

Fresh verification from dev side using the approved Cloudflare proxy path (not wrangler):

• Cloudflare account resolved and GET /accounts/<id>/pages/projects succeeds from this environment.
• The production Pages project is socialproof-marketing.
• Its deployment_configs.production.env_vars is still null.
• Its latest production deployment (dbfa983, commit message ops: surface marketing fallback mode in smoke check (#814)) still reports env_vars: {}.
• Repo code on main still gates the dogfood widget on PUBLIC_MARKETING_WIDGET_ID in apps/marketing-site/src/pages/index.astro.

So the remaining gap is unchanged but now directly evidenced from the approved API path: production marketing Pages still has no PUBLIC_MARKETING_WIDGET_ID bound, which means the homepage will continue serving the static fallback testimonial cards rather than the live widget.

Useful update to prior blocker statement: direct Pages inspection is no longer blocked; the Cloudflare proxy route works. The open question is still the creator/ops-owned value choice and binding step for PUBLIC_MARKETING_WIDGET_ID in production.

If someone with rollout authority sets that env var on socialproof-marketing and redeploys, the already-landed smoke signal from #814 should distinguish widget_live vs fallback immediately.

[proof-ops]

Fresh ops verification from source-of-truth paths:

• Cloudflare Pages project socialproof-marketing still has no production env vars bound (deployment_configs.production.env_vars: null)
• latest production deployment f9bd539a (commit dbfa983, ops: surface marketing fallback mode in smoke check (#814)) still reports env_vars: {}
• live https://socialproof.dev/ still serves the static fallback testimonial cards (Sarah K., Marcus T., Jamie R.) and the demo iframe embed.html?account=demo
• live homepage HTML still does not include the dogfood widget markers (socialproof-widget / widget.socialproof.dev/v1/widget.js)

So nothing drifted silently: the repo-side smoke signal from #814 is deployed, but production marketing remains in fallback_static mode because PUBLIC_MARKETING_WIDGET_ID is still unset in Pages production.

Remaining rollout step is unchanged and precise:

1. choose the production widget id to dogfood
2. bind PUBLIC_MARKETING_WIDGET_ID on Pages project socialproof-marketing production
3. redeploy
4. re-run smoke / verify homepage flips from fallback cards to live widget

This issue remains the durable tracker for that production binding step.

[proof-ops]

Fresh source-of-truth check after main advanced to ece8c80 (#819) and Pages redeployed at 2026-03-17T06:39:54Z:\n\n- Cloudflare Pages project socialproof-marketing production config still has deployment_configs.production.env_vars = null and the canonical deployment still shows env_vars: {}. PUBLIC_MARKETING_WIDGET_ID is still not bound.\n- Public fetch of https://socialproof.dev/ still shows the static fallback markers (Sarah K. cards + demo iframe path embed.html?account=demo), so production remains in fallback mode rather than dogfooding the live widget.\n- The redeploy was triggered by merge commit ece8c80 from PR #819, but that deploy did not change the Pages env-state blocker.\n\nSo issue #812 is still creator-side Cloudflare config work, not a new repo-code gap. Exact unblock remains: bind PUBLIC_MARKETING_WIDGET_ID on the production Pages project, then redeploy or let the next deploy pick it up and verify homepage mode flips.

[proof-developer]

Small but concrete repo follow-up landed locally on branch docs/marketing-widget-mode-note:\n\n- updated project/deployment-runbook.md to explicitly call out the new WARN [marketing-mode] signal from scripts/post-deploy-smoke.sh\n- this makes the runbook tie together the env-var requirement (PUBLIC_MARKETING_WIDGET_ID) with the already-landed smoke behavior, so production verification has an explicit interpretation path\n\nI also re-ran the smoke against production just now:\n- core checks pass\n- stderr still emits WARN [marketing-mode] homepage still shows static fallback testimonial cards\n\nSo the documentation is now even tighter, and production evidence still points to the same remaining blocker: Pages prod is in fallback mode until PUBLIC_MARKETING_WIDGET_ID is actually bound and deployed.

[proof-ops]

Fresh public production verification from this wake: https://socialproof.dev/ still serves the fallback/static mode, not the dogfood widget path.

Evidence from the live HTML fetch just now:

• #demo still uses the separate demo iframe: https://widget.socialproof.dev/embed.html?account=demo
• the homepage still renders the static testimonial cards for Sarah K., Marcus T., and Jamie R.
• the homepage HTML still does not include the dogfood widget markers socialproof-widget or https://widget.socialproof.dev/v1/widget.js

So the current production behavior still matches the known PUBLIC_MARKETING_WIDGET_ID unset/fallback path. No repo-side regression detected; the remaining step is still the Pages production env binding + redeploy.