Restore tracker and shared capture scripts blocked by root CSP

[sarthakagrawal927]

Verified defect

Chrome Network records CSP blocks for the existing App Health tracker, newsletter capture and shared AI/feedback footer scripts. The document response policy matches next.config.ts securityHeaders. Local project-strip loads successfully. Newsletter has no shadow root and feedback/extension are absent.

Proposed bounded repair

Add exactly https://sassmaker.com and https://health.sassmaker.com to the existing script-src allowlist in next.config.ts. Preserve all other directives and headers. No credentials, dependencies, provider bindings, or wildcard hosts. These are the first-party producers already referenced by the product HTML.

Release gate

Owner approval required by Fleet production-config boundary. After approval use a clean managed writer; validate policy regression and normal build/CI; release exact main through existing guarded workflow; verify browser document CSP and loaded tracker/capture/feedback, including responsive dialog. Do not submit synthetic feedback or joins. Rollback is removal of the two explicit hosts.

Caveat

Source/header verification alone is insufficient: the first observation used HTTP headers lacking this CSP, whereas fresh Chrome Network exposes the effective response policy and blocked script IDs. Browser runtime is the acceptance source.

---

Recreated from original issue #83 (repo recreated 2026-10-04 to purge leaked personal data and a secret from git history).

[sarthakagrawal927]

Current read-only production verification (2026-10-05): the homepage CSP has both exact script origins. Tracker loaded (304); newsletter capture, project strip, AI chat footer and capture configuration loaded (200); an ordinary browser pageview beacon was accepted (202). No form was filled or submitted. The original host-block symptom is not reproduced on the ordinary homepage.

The responsive acceptance is still failing. At a 390×844 CSS-pixel viewport, Send feedback opens the dialog without horizontal viewport growth, but its 44×44 close control at x330/y20 is covered by the sticky header. Hit-testing its center resolves to the header's Open RolePatch link, so clicking would navigate rather than close. Escape dismisses the modal. The viewport was restored after testing.

Five enforced script-src eval audit records lack a blocked URL, source location or request ID; they cannot yet be attributed to a particular production script. No CSP/security weakening or production/source changes were made.

Current main is 2a6b0be with successful CI37248388498. Provider deployment metadata shows 100% Worker version0420fc39… from the earlier eaa3a35… source; the associated Actions deploy attempt failed, so that Actions deployment is not reported as successful. Keep #3 open until the responsive close path and eval records are resolved. Footer implementation remains with its separately assigned owner.

[sarthakagrawal927]

Verification update — 2026-10-06 UTC

The bounded root CSP repair is merged in PR #8, source 1110236f1814720b7d103898000e4691bf460430. Exact-main CI, Docs and the canonical deploy guard passed. The source restores the existing intended policy on the Astro root and served Worker asset responses; it does not add wildcard origins or broaden the existing policy.

Production Actions failed at the Cloudflare routes API permission check after upload/activation; that workflow's smoke was skipped. Read-only provider metadata independently confirms deployment 83f97812-e71a-425e-857e-87f6e6584046, version b1116d1c-bc49-48b4-8dbe-4ffb193a47f9, tagged with the merged source above and serving 100% traffic. The independent anonymous production smoke passed 6/6; authenticated apply-agent checks were not run. The failed workflow remains failed evidence.

The isolated live Chromium verification passed at desktop 1440×900 and mobile 390×844. Both document responses enforce the exact intended CSP, with no report-only or meta policy. Tracker, newsletter, project-strip, AI footer and feedback launcher each returned 200 with completed response bodies. The feedback script loads after the normal launcher click. Both dialogs opened and Escape dismissed them; no CSP violations were observed. The provider artifact digest was verified before reviewing its JSON and screenshots.

The first browser attempt failed because the harness incorrectly expected the lazy feedback script before the launcher click. That result is retained separately; correcting the ordering preserved all five completed-download assertions.

This issue stays open: screenshot review shows the sticky header overlaps the dialog/Close area at both widths, with stronger layering problems on mobile. Footer implementation remains with its separate owner. No feedback/newsletter was submitted, no consent selected and no account session used. Script downloads and ordinary pageviews do not establish accepted capture or telemetry privacy. Historical eval records are not attributed by this clean current run. No cloud worker, connector setup or new account is needed. The temporary verification workflow was restored to its exact original helper-branch tree; normal main workflows were unchanged.

[sarthakagrawal927]

Verified on production, 9 October 2026: closing

Both remaining acceptance items now pass on the live https://rolepatch.com/ homepage. I checked them with read-only headless Chromium. Nothing was submitted, no consent box was ticked and no account session was used.

• CSP: the document response (curl -sI) enforces script-src … https://sassmaker.com https://health.sassmaker.com with no report-only or meta policy. This matches next.config.ts on origin/main (1110236, PR fix: restore homepage CSP and patch CI security advisories #8).
• Scripts load: tracker.js, newsletter-capture.js, project-strip.js, ai-chat-footer.js, projects.json and feedback-launcher.js (fetched after the launcher click) all returned 200.
• CSP violations: a securitypolicyviolation listener installed before navigation recorded 0 events across page load and opening the dialog, at both widths. The policy includes 'unsafe-eval', so the current policy cannot produce enforced eval blocks. The historical unattributed eval records do not reproduce.
• Responsive close path (the remaining defect): at 390×844 the Close control sits at (330, 18, 44×44); at 1440×900 it sits at (1360, 44, 44×44). At both widths, hit-testing its center resolves to the button itself, not the header. A real click dismissed the dialog at both widths. The deployed Precision landing renders .precision-surface .site-header { position: static }, so the sticky header that covered Close no longer exists.

Caveat: the static-header landing and the font-src https://sassmaker.com change are in the deployed uncommitted snapshot based on d22cd94, not on origin/main. Redeploying main as it stands would bring back the sticky header and drop font-src. That parity gap belongs with the release snapshot, not with this issue.