ssrwire 0.1.0 → 0.3.0

package/CHANGELOG.md

@@ -5,6 +5,48 @@ All notable changes to SSRWire are documented here. The project follows
 
 ## [Unreleased]
 
+## [0.3.0] - 2026-08-28
+
+### Added
+
+- Streamed capture for core Open Graph and Twitter Card metadata with arrival
+  time, observed byte position, document location, bounded repeated values, and
+  report redaction.
+- Opt-in `require.openGraph` and `require.twitterCard` target contracts with
+  missing-field, invalid-URL, duplicate/conflict, and head/body delivery
+  findings.
+- A terminal social-preview readiness table and public social metadata signal
+  types in JSON and the programmatic API.
+
+### Changed
+
+- Enabled social contracts now participate in required-signal timing,
+  cross-agent comparison, and repeated-sample stability analysis.
+- Twitter Card readiness prefers native Twitter metadata and falls back to the
+  corresponding Open Graph title, description, and image.
+- Multiple `og:image` values are retained in document order without being
+  treated as conflicting scalar metadata.
+
+## [0.2.0] - 2026-08-24
+
+### Added
+
+- Bounded `repeat` configuration and `--repeat` CLI sampling for 1–10 requests
+  per target-agent pair.
+- Per-agent minimum, median, nearest-rank p95, maximum, and spread summaries for
+  response-header, first-byte, required-signal, and completion timings.
+- Response and streamed-HTML stability findings across repeated samples.
+- Sample attribution in terminal and JSON reports.
+
+### Changed
+
+- Added an npm package badge to the README.
+- Samples for one target-agent pair run sequentially while independent pairs
+  retain bounded concurrency.
+- Repeated policy findings are coalesced with occurrence and sample evidence.
+- Exact body-fingerprint variation alone is informational; timing variation
+  alone remains evidence rather than a policy failure.
+
 ## [0.1.0] - 2026-08-22
 
 ### Added
@@ -16,5 +58,7 @@ All notable changes to SSRWire are documented here. The project follows
 - Terminal, JSON, and SARIF reports with CI-safe exit codes.
 - YAML configuration, one-off URL checks, Docker support, and GitHub Actions examples.
 
-[Unreleased]: https://github.com/lame13/ssrwire/compare/v0.1.0...HEAD
+[Unreleased]: https://github.com/lame13/ssrwire/compare/v0.3.0...HEAD
+[0.3.0]: https://github.com/lame13/ssrwire/compare/v0.2.0...v0.3.0
+[0.2.0]: https://github.com/lame13/ssrwire/compare/v0.1.0...v0.2.0
 [0.1.0]: https://github.com/lame13/ssrwire/releases/tag/v0.1.0

package/CONTRIBUTING.md

@@ -28,7 +28,9 @@ Keep each change narrow. Include tests for behavior changes, especially for:
 - response chunk boundaries and elements split across chunks;
 - redirects, timeouts, aborted bodies, and size limits;
 - malformed, duplicated, late, or body-located metadata;
+- Open Graph and Twitter Card requirements, fallbacks, arrays, and URL values;
 - user-agent differences and comparison findings;
+- repeated-sample ordering, aggregation, and instability classification;
 - redaction of configured header values;
 - terminal, JSON, SARIF, and exit-code behavior.
 
@@ -39,11 +41,12 @@ positions instead.
 
 ## Scope
 
-SSRWire is an HTTP stream observer, not a browser, crawler, packet capture,
-performance benchmark, or framework plugin. New features should preserve that
-boundary. In particular, avoid conclusions that claim to reveal the server's
-original flush calls: proxies, compression, TLS, HTTP stacks, and client
-buffering can coalesce data before SSRWire sees it.
+SSRWire is an HTTP stream observer and bounded consistency sampler, not a
+browser, crawler, packet capture, load generator, performance benchmark, or
+framework plugin. New features should preserve that boundary. In particular,
+avoid conclusions that claim to reveal the server's original flush calls:
+proxies, compression, TLS, HTTP stacks, and client buffering can coalesce data
+before SSRWire sees it.
 
 By contributing, you agree that your contribution is licensed under the MIT
 License.

package/PUBLISHING.md

@@ -1,109 +1,124 @@
-# Publish SSRWire from a local machine
+# Publish SSRWire 0.3.0 from a local machine
 
-This repository intentionally includes no npm publishing workflow. Every npm
-release is published from a local interactive terminal after GitHub CI passes.
-Do not configure an `NPM_TOKEN`, trusted publisher, OIDC identity, or automated
-release workflow for npm publication.
+This repository intentionally includes no npm publishing workflow. Publish from
+a foreground local terminal only after the GitHub `CI` workflow passes. Do not
+configure an `NPM_TOKEN`, trusted publisher, OIDC identity, or automated npm
+release job.
 
-## 1. Prepare and verify
+The `main` branch is protected. Land every release change through a pull
+request, and do not use an administrator bypass or a direct push to `main`.
 
-From the extracted archive:
+## 1. Update the existing repository
+
+Work from a clean clone of the existing public repository. Copy the 0.3.0
+source files into that clone while preserving its `.git` directory.
 
 ```bash
-unzip ssrwire.zip # skip when already inside a source checkout
 cd ssrwire
+git switch main
+git pull --ff-only origin main
+git status --short
+git switch -c release/0.3.0
+```
+
+`git status --short` must be empty before creating the release branch and
+applying the release files.
+
+## 2. Verify the release locally
+
+```bash
 nvm use 24
 node --version
 npm --version
 npm ci
 npm run check
 npm pack --dry-run
+node dist/bin.js --version
 ```
 
-Install and authenticate GitHub CLI if needed:
-
-```bash
-brew install gh
-gh auth login -h github.com --web
-gh auth status -h github.com
-```
+The final command must print `0.3.0`. Inspect the dry-run file list. It must not
+contain `.env`, `.github`, `node_modules`, `test`, ZIP files, or tarballs.
 
-## 2. Create the Git history
+Review the release diff and version references:
 
 ```bash
-git init -b main
-git add -- \
-  .dockerignore .editorconfig .env.example .github .gitignore \
-  CHANGELOG.md CONTRIBUTING.md Dockerfile LICENSE PUBLISHING.md README.md SECURITY.md \
-  biome.json examples package.json package-lock.json scripts src test \
-  tsconfig.build.json tsconfig.json vitest.config.ts
-git commit -m "Initial SSRWire release"
+git diff --check
+git diff --stat
+git diff -- package.json package-lock.json CHANGELOG.md README.md PUBLISHING.md
+rg '0\.2\.0' README.md examples package.json package-lock.json scripts src test
 ```
 
-## 3. Create and push the public repository
+The final search should return nothing. Historical entries in `CHANGELOG.md`
+are excluded intentionally.
+
+## 3. Commit, push the release branch, and open a pull request
 
 ```bash
-gh repo create lame13/ssrwire \
-  --public \
-  --source=. \
-  --remote=origin \
-  --push \
-  --description "Inspect streamed SSR HTML, metadata timing, and crawler-specific delivery from the command line." \
-  --homepage "https://nikom.work"
+gh auth status -h github.com || gh auth login -h github.com --web
+git add --all
+git diff --cached --check
+git diff --cached --stat
+git commit -m "feat: release SSRWire 0.3.0"
+git push --set-upstream origin release/0.3.0
+gh pr create --base main --head release/0.3.0 --fill
+PR_NUMBER="$(gh pr view release/0.3.0 --json number --jq .number)"
+test -n "$PR_NUMBER"
+gh pr checks "$PR_NUMBER" --watch --fail-fast
 ```
 
-## 4. Add repository topics
+Do not merge while any Node, package-smoke, or Docker job is failing. Satisfy
+all review and branch-protection requirements, then merge with GitHub's allowed
+strategy. Running `gh pr merge "$PR_NUMBER"` without a strategy flag lets the
+CLI prompt for one of the repository's permitted methods. Do not select an
+administrator bypass.
 
 ```bash
-gh repo edit lame13/ssrwire \
-  --add-topic technical-seo \
-  --add-topic seo \
-  --add-topic ssr \
-  --add-topic streaming-html \
-  --add-topic nextjs \
-  --add-topic nuxt \
-  --add-topic astro \
-  --add-topic crawler \
-  --add-topic typescript \
-  --add-topic cli \
-  --add-topic seo-tools \
-  --add-topic github-actions \
-  --add-topic sarif
+gh pr merge "$PR_NUMBER"
 ```
 
-Enable the private vulnerability-reporting channel referenced by
-`SECURITY.md` (this requires repository admin permission):
+After GitHub reports the pull request as merged, update local `main` and wait
+for the CI run on the exact merged commit:
 
 ```bash
-gh api --method PUT repos/lame13/ssrwire/private-vulnerability-reporting
+git switch main
+git pull --ff-only origin main
+git status --short
+gh pr view "$PR_NUMBER" --json state,mergedAt,mergeCommit
+COMMIT_SHA="$(git rev-parse HEAD)"
+RUN_ID="$(gh run list --workflow CI --branch main --commit "$COMMIT_SHA" \
+  --limit 1 --json databaseId --jq '.[0].databaseId')"
+test -n "$RUN_ID"
+gh run watch "$RUN_ID" --exit-status
 ```
 
-Alternatively, enable **Private vulnerability reporting** in the repository's
-Settings → Security settings before publishing the first release.
+`git status --short` must be empty. Do not publish until the merged-commit CI
+run succeeds.
 
-Recommended repository description:
+## 4. Verify npm state
 
-> Inspect streamed SSR HTML, metadata timing, and crawler-specific delivery from the command line.
+```bash
+npm view ssrwire version dist-tags homepage keywords repository.url --json
+npm config get registry
+npm config get provenance
+```
 
-Wait for the repository's `CI` workflow to pass before publishing.
+The published version and `latest` tag must still be `0.2.0`. If npm already
+reports `0.3.0`, stop: never reuse a version that npm accepted.
 
-## 5. Publish version 0.1.0 to npm locally
+In the npm package settings, select **Require two-factor authentication and
+disallow tokens**. npm documents this as the strongest package publishing
+setting:
 
-Verify the release from a clean checkout before starting npm's short-lived
-authenticated session:
+- <https://docs.npmjs.com/requiring-2fa-for-package-publishing-and-settings-modification/>
+- <https://docs.npmjs.com/about-two-factor-authentication/>
 
-```bash
-npm ci
-npm run check
-npm pack --dry-run
-npm view ssrwire
-```
+## 5. Publish interactively
 
-For the first release, `npm view` returning a 404 means the name is not
-currently published. Start authentication only after verification so the
-session remains fresh for publication:
+Remove inherited automation credentials before starting the interactive
+session:
 
 ```bash
+unset NODE_AUTH_TOKEN NPM_TOKEN NPM_CONFIG_OTP npm_config_otp
 npm login --auth-type=web --registry=https://registry.npmjs.org
 npm whoami --registry=https://registry.npmjs.org
 npm publish --access public --registry=https://registry.npmjs.org
@@ -111,24 +126,23 @@ npm view ssrwire version dist-tags homepage keywords repository.url --json
 npm logout --registry=https://registry.npmjs.org
 ```
 
-Run login and publish in a foreground interactive terminal. Complete npm's
-browser, passkey, or two-factor-authentication challenge when prompted. Never
-put an OTP in a command argument, and do not add an `NPM_TOKEN` to this
-repository.
+Complete npm's browser, passkey, or two-factor-authentication challenge when
+prompted. Do not use a token with bypass 2FA, put an OTP in a command argument,
+or add an npm credential to the repository or GitHub Actions. The package-level
+"disallow tokens" setting ensures that publication remains interactive.
 
-If the package is not immediately visible after `npm publish` succeeds, wait
-for npm's publish-time scanning to finish instead of publishing the same
-version again.
+If npm's publish-time scanning delays package visibility, wait. Do not publish
+`0.3.0` again or change the tag to work around propagation.
 
-After npm confirms `0.1.0`, create the matching source release:
+## 6. Tag the exact published commit
 
 ```bash
 node scripts/clean.mjs
 rm -rf node_modules/.vite
 git status --short
-git tag -a v0.1.0 -m "SSRWire v0.1.0"
-git push origin v0.1.0
-gh release create v0.1.0 --generate-notes --title "SSRWire v0.1.0"
+git tag -a v0.3.0 -m "SSRWire v0.3.0"
+git push origin v0.3.0
+gh release create v0.3.0 --generate-notes --title "SSRWire v0.3.0"
 ```
 
-`git status --short` must print nothing before tagging the release.
+`git status --short` must print nothing before tagging.

package/README.md

@@ -1,16 +1,17 @@
 # SSRWire
 
 [![CI](https://github.com/lame13/ssrwire/actions/workflows/ci.yml/badge.svg)](https://github.com/lame13/ssrwire/actions/workflows/ci.yml)
+[![npm version](https://img.shields.io/npm/v/ssrwire.svg)](https://www.npmjs.com/package/ssrwire)
 [![MIT License](https://img.shields.io/badge/license-MIT-blue.svg)](LICENSE)
 
-Inspect streamed SSR HTML, metadata timing, and crawler-specific delivery from
-the command line.
+Inspect streamed SSR HTML, SEO and social metadata timing, and crawler-specific
+delivery from the command line.
 
 SSRWire makes a real HTTP request for each selected user-agent profile, reads
-the response incrementally, and records when important SEO signals become
-observable to its parser. It reports their elapsed time, observed byte
-position, and document location without launching a browser or executing
-JavaScript.
+the response incrementally, and records when important SEO and social-preview
+signals become observable to its parser. It reports their elapsed time,
+observed byte position, and document location without launching a browser or
+executing JavaScript.
 
 ```bash
 npx ssrwire https://example.com/product
@@ -24,7 +25,9 @@ Modern SSR output is not always one complete HTML document delivered at once:
 - a framework may intentionally stream metadata into `<body>` for a capable
   crawler while blocking for an HTML-limited bot;
 - browser, search-crawler, and social-crawler user agents may receive different
-  titles, canonicals, robots directives, redirects, or statuses;
+  titles, canonicals, social-preview metadata, robots directives, redirects, or
+  statuses;
+- the same URL and user agent may receive inconsistent SSR output between requests;
 - an interrupted or oversized stream may never deliver the expected elements;
 - a working hydrated page can hide thin or incomplete source HTML.
 
@@ -84,13 +87,13 @@ form of `npx ssrwire check URL`.
 
 ## What it observes
 
-For each target and agent, SSRWire captures:
+For each target, agent, and configured sample, SSRWire captures:
 
 - response status, final URL, redirect chain, and an allowlisted response-header snapshot;
 - time to response headers, first response-body bytes, and completed body;
 - total bytes delivered to the stream parser and a body fingerprint;
-- title, meta description, canonical, meta robots, H1, first main-content
-  text, and JSON-LD blocks;
+- title, meta description, canonical, meta robots, Open Graph, Twitter Card,
+  H1, first main-content text, and JSON-LD blocks;
 - elapsed arrival time, observed byte position, and `head`/`body` location for
   each signal;
 - clean completion, timeout, network failure, invalid response, or configured
@@ -105,10 +108,15 @@ It then checks:
 | Missing title | Error |
 | Missing description, canonical, H1, or main text | Warning |
 | Duplicate or conflicting title, description, canonical, or robots values | Warning |
+| Missing an enabled Open Graph or Twitter Card contract | Warning |
+| Invalid social metadata URL or conflicting scalar social metadata | Warning |
 | Invalid JSON-LD | Warning |
 | JSON-LD block/count exceeds the bounded analysis budget | Warning |
-| Critical metadata in `<body>` for a profile that requires head metadata | Error |
-| Status, final URL, title, canonical, or robots drift between profiles | Warning |
+| Critical or enabled social metadata in `<body>` for a profile that requires head metadata | Error |
+| Status, final URL, title, canonical, robots, or enabled social metadata drift between profiles | Warning |
+| Completion, status, final URL, or redirect-chain drift between samples | Warning |
+| Metadata value or document-location drift between complete samples | Warning |
+| Exact body fingerprint drift without metadata drift | Information |
 | First byte or required-signal arrival over a configured limit | Warning |
 | Timeout, truncation, network error, or another incomplete probe | Error / incomplete run |
 
@@ -157,6 +165,41 @@ agents:
     requiresHeadMetadata: true
 ```
 
+## Social preview metadata
+
+Every probe captures these bounded, ordered metadata signals when they arrive
+before completion or termination:
+
+- Open Graph: `og:title`, `og:type`, `og:url`, `og:image`, and
+  `og:description`;
+- Twitter Card: `twitter:card`, `twitter:title`, `twitter:description`, and
+  `twitter:image`.
+
+SSRWire accepts either the conventional `property` attribute or a `name`
+attribute for those keys. Each captured value carries the same arrival time,
+observed byte position, and document location as the existing metadata
+signals. The terminal report shows a compact readiness table whenever social
+metadata is observed or required, while JSON retains every captured value.
+
+Social policy is opt-in per target. `openGraph: true` requires the four basic
+[Open Graph protocol](https://ogp.me/) properties: title, type, URL, and image.
+The `twitterCard: true` option requires `twitter:card` plus a usable title,
+description, and image; SSRWire prefers the corresponding `twitter:*` value
+and falls back to `og:title`, `og:description`, or `og:image`. These are
+explicit SSRWire audit contracts, not a claim that a social platform will
+render a particular preview.
+
+Enabled contracts also participate in critical-signal timing, head/body
+policy, cross-agent drift, and repeated-sample stability checks. URL-valued
+fields must be absolute HTTP or HTTPS URLs. Open Graph permits multiple images,
+so SSRWire retains them in order without treating the array as a scalar
+conflict; the first non-empty image satisfies readiness.
+
+When both options are false, SSRWire still records and reports raw social
+signals but emits no social-policy or social-drift findings. It does not fetch
+images, verify dimensions or media types, execute JavaScript, or simulate a
+platform's rendered preview.
+
 ## Configuration
 
 SSRWire automatically looks for `ssrwire.config.yml`,
@@ -174,6 +217,8 @@ targets:
       canonical: true
       h1: true
       mainText: true
+      openGraph: true
+      twitterCard: true
     maxFirstByteMs: 1200
     maxCriticalMs: 2500
 
@@ -185,6 +230,8 @@ targets:
       canonical: false
       h1: true
       mainText: true
+      openGraph: false
+      twitterCard: false
 
 agents:
   - browser
@@ -198,6 +245,7 @@ headers:
 timeoutMs: 15000
 maxBytes: 10485760
 maxRedirects: 10
+repeat: 1
 ```
 
 A target can also be a plain URL string when defaults are sufficient:
@@ -212,10 +260,12 @@ Defaults:
 
 - expected status: `200`;
 - title, description, canonical, H1, and main text: required;
+- Open Graph and Twitter Card contracts: disabled;
 - agents: `browser`, `googlebot`, `bingbot`, and `twitterbot`;
 - timeout: 15 seconds per probe;
 - response limit: 10 MiB;
-- redirect limit: 10.
+- redirect limit: 10;
+- samples per target and agent: 1, with an allowed range of 1–10.
 
 Unknown configuration keys are rejected. URLs must be absolute HTTP or HTTPS
 URLs and cannot contain embedded credentials.
@@ -255,11 +305,11 @@ The final response must declare `text/html` or `application/xhtml+xml` as its
 sniff headerless, JSON, text, or binary responses for HTML-looking fragments.
 
 To keep hostile or accidentally huge pages bounded, SSRWire retains at most
-256 signals of each repeated metadata kind, analyzes at most 64 JSON-LD blocks,
-and captures at most 1,048,576 characters from one JSON-LD block. Exceeding a
-JSON-LD analysis budget produces a dedicated warning rather than being
-mislabeled as invalid JSON. The configured response-byte limit remains the
-outer bound.
+256 signals of each repeated metadata kind, including each supported social
+property, analyzes at most 64 JSON-LD blocks, and captures at most 1,048,576
+characters from one JSON-LD block. Exceeding a JSON-LD analysis budget produces
+a dedicated warning rather than being mislabeled as invalid JSON. The
+configured response-byte limit remains the outer bound.
 
 ## Timing interpretation
 
@@ -276,6 +326,40 @@ transfer-size or packet-boundary evidence. They count bytes delivered by the
 Fetch implementation to SSRWire; those bytes are post-content-decoding when a
 server ignores SSRWire's `Accept-Encoding: identity` request.
 
+## Repeated sampling
+
+Use repeated sampling when one successful request does not prove that SSR output
+is stable:
+
+```bash
+npx ssrwire check --repeat 3
+```
+
+`repeat` is the total number of samples, not a retry count. SSRWire retains
+failures instead of replacing them with a later success. Samples for one
+target-agent pair run sequentially; different target-agent pairs may still run
+concurrently. SSRWire does not add delays, cache-busting parameters, or special
+cache headers.
+
+The request count is `targets × agents × repeat`, plus redirect hops. Configured
+same-origin headers are sent for every sample and retain the existing
+cross-origin stripping and report-redaction behavior.
+
+For repeated runs, terminal reports include individual sample numbers and a
+per-agent timing table. JSON retains every probe and adds per-agent stability
+summaries. The summaries report sample count, minimum, median, nearest-rank p95,
+maximum, and spread for available header, first-byte, required-signal, and
+completion timings. With small sample counts, nearest-rank p95 will often equal
+the maximum.
+
+Timing spread alone is evidence, not a failure. Network and cache variation can
+change timings without changing the response contract. SSRWire warns when HTTP
+response evidence or streamed metadata changes across samples. Enabled social
+contracts are included in metadata stability; observed social tags remain
+evidence-only when their contracts are disabled. Exact body-hash variation by
+itself is informational because timestamps, nonces, and other legitimate
+dynamic values commonly change source HTML.
+
 ## CLI reference
 
 ```text
@@ -294,6 +378,7 @@ Check options:
 | `--timeout <ms>` | Override request timeout |
 | `--max-bytes <bytes>` | Override response-body limit |
 | `--max-redirects <count>` | Override redirect limit |
+| `--repeat <count>` | Run 1–10 sequential samples per URL and agent |
 | `-f, --format <format>` | `terminal`, `json`, or `sarif` |
 | `-o, --output <path>` | Write the report to a file |
 | `--fail-on <level>` | `error`, `warning`, or `never` |
@@ -304,9 +389,10 @@ removed.
 
 ## Reports and exit codes
 
-- `terminal`: compact tables and findings for local use.
+- `terminal`: compact sample, social-readiness, aggregate-timing, and finding
+  tables for local use.
 - `json`: structured machine-readable evidence, including every probe and timing
-  signal.
+  signal plus repeated-run stability summaries.
 - `sarif`: findings suitable for GitHub Code Scanning and other SARIF 2.1.0
   consumers.
 
@@ -369,7 +455,7 @@ by the CLI:
 ```ts
 import { loadConfig, renderJson, runAudit } from "ssrwire";
 
-const config = await loadConfig({ urls: ["https://example.com/"] });
+const config = await loadConfig({ urls: ["https://example.com/"], repeat: 3 });
 const audit = await runAudit(config);
 process.stdout.write(renderJson(audit));
 ```
@@ -380,15 +466,18 @@ versions.
 
 ## Scope
 
-SSRWire does not execute JavaScript, inspect a hydrated DOM, measure Core Web
-Vitals, discover URLs, validate indexing, bypass access controls, or emulate a
-crawler's rendering pipeline. Use [RoutePlay](https://github.com/lame13/routeplay)
-when the question is server HTML versus a cold browser versus real client-side
-navigation.
+SSRWire does not execute JavaScript, inspect a hydrated DOM, render social
+previews, fetch social images, measure Core Web Vitals, discover URLs, validate
+indexing, bypass access controls, perform load testing, or emulate a crawler's
+rendering pipeline. Use
+[RoutePlay](https://github.com/lame13/routeplay) for server HTML versus a cold
+browser versus real client-side navigation. Use
+[RouteLint](https://github.com/lame13/routelint) for route discovery,
+indexability, and technical SEO policy.
 
 Run SSRWire only against targets you are authorized to inspect. Keep target
-lists intentionally small; one run starts one probe per target/profile pair,
-with additional requests for redirect hops.
+lists and repeat counts intentionally small. It is a consistency sampler, not a
+load generator.
 
 ## Development
 

package/SECURITY.md

@@ -20,7 +20,11 @@ report. You should receive an initial response within seven days.
 ## Operational safety
 
 SSRWire sends real HTTP requests to every configured target for every selected
-agent profile. Run it only against systems you are authorized to test. Treat
-custom headers as secrets, prefer environment-variable interpolation, and do
-not commit populated `.env` files or generated reports containing private
-URLs.
+agent profile and sample. The base request count is
+`targets × agents × repeat`, plus redirect hops. Samples for one target-agent
+pair are sequential, but different pairs may run concurrently. Keep `repeat`
+bounded and use SSRWire only against systems you are authorized to test.
+
+Treat custom headers as secrets and remember that they are sent on every
+same-origin sample. Prefer environment-variable interpolation, and do not
+commit populated `.env` files or generated reports containing private URLs.

package/dist/analyze.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"analyze.d.ts","sourceRoot":"","sources":["../src/analyze.ts"],"names":[],"mappings":"AAAA,OAAO,KAAK,EACV,YAAY,EACZ,WAAW,EAEX,OAAO,EACP,WAAW,EAIX,iBAAiB,EAClB,MAAM,YAAY,CAAC;AAgepB,wBAAgB,aAAa,CAC3B,MAAM,EAAE,WAAW,EACnB,MAAM,EAAE,SAAS,WAAW,EAAE,GAC7B,SAAS,OAAO,EAAE,CAuGpB;AAED,wBAAgB,cAAc,CAAC,OAAO,EAAE,SAAS,iBAAiB,EAAE,GAAG,YAAY,CA6BlF"}
+{"version":3,"file":"analyze.d.ts","sourceRoot":"","sources":["../src/analyze.ts"],"names":[],"mappings":"AAWA,OAAO,KAAK,EACV,YAAY,EACZ,WAAW,EAEX,OAAO,EACP,WAAW,EAMX,iBAAiB,EAClB,MAAM,YAAY,CAAC;AA2pBpB,wBAAgB,aAAa,CAC3B,MAAM,EAAE,WAAW,EACnB,MAAM,EAAE,SAAS,WAAW,EAAE,GAC7B,SAAS,OAAO,EAAE,CAwGpB;AAED,wBAAgB,cAAc,CAAC,OAAO,EAAE,SAAS,iBAAiB,EAAE,GAAG,YAAY,CA6BlF"}