# Strict-CSP vendored browser assets

Use this reference when a release vendors a JavaScript/CSS library locally under a strict Content Security Policy.

## Why ordinary asset checks are insufficient

A local file and zero cross-origin requests do not prove CSP cleanliness. Bundlers may convert imported CSS into JavaScript that injects an `@font-face`, inline style, source map, worker, or `data:` URI at runtime. The UI can look correct while the browser logs a CSP violation; an unused icon font is a common example.

## Pre-commit acceptance sequence

1. Build the pinned asset reproducibly and retain version, components/plugins, license, and source-package metadata.
2. Inspect the final browser-delivered artifact—not only its npm sources—for `http:`, `https:`, source maps, `data:`, `blob:`, `@font-face`, workers, and dynamically injected styles.
3. Generate the actual release HTML and load it through the real server/CSP. Exercise the feature that causes the vendor asset to initialize.
4. Fail the browser test on both `console.error` and `pageerror`; separately count external requests. Screenshots and visual success do not waive a console/CSP failure.
5. Verify the asset against the policy already approved for the application. Do not broaden `font-src`, `style-src`, `script-src`, or `connect-src` merely to accommodate an unused bundled feature.
6. If a safe post-processing step is required, make it deterministic and documented (for example, strip an unused embedded icon-font declaration). Run the transformation before computing metadata.
7. Recompute byte size, deterministic gzip size, SHA-256, and license SHA after every transformation. Add a test that hashes the checked-in artifact and license against metadata.
8. Rerun syntax, integrity, focused browser console/CSP, and the affected full acceptance gate before release. Treat any artifact or metadata change as a release-candidate change.

## Post-push discovery

If a CSP issue is discovered only after push or deployment:

- Do not amend or force-push a published release commit.
- Do not patch the runtime without matching repository state.
- Create a transparent follow-up fix commit, rerun the affected gates, push normally, update the rollback bundle if needed, and redeploy the corrected artifact atomically.
- Report the original release SHA and follow-up SHA separately.

## Test pattern

The browser smoke should initialize the feature and report only safe aggregates:

```text
console_errors: {csp: 0, resource: 0, pageerror: 0}
external_requests: 0
runtime_version: <pinned version>
```

Classify console text locally; do not persist full messages when they may contain private routes or source details.