From c338297ac81c9a417cb11074aa95ef720416e36e Mon Sep 17 00:00:00 2001
From: Mario Tarosso <mariojgt2@gmail.com>
Date: Fri, 25 Sep 2026 10:56:10 +0100
Subject: [PATCH] Call the JS/Node widget the Patchstack Connector

The JavaScript/Node install, troubleshooting and Pulse overview pages called
the widget the "disclosure widget" or "Patchstack widget", and used "the
connector" for the @patchstack/connect package. The widget is now the
Patchstack Connector and the package is Connect.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
---
 .../installing-on-javascript-node-projects.md | 16 ++++++-------
 ...oubleshooting-javascript-node-projects.mdx | 24 +++++++++----------
 .../Patchstack App/Pulse/pulse-overview.md    | 22 ++++++++---------
 3 files changed, 31 insertions(+), 31 deletions(-)

diff --git a/src/content/docs/Getting Started/Installing Patchstack/installing-on-javascript-node-projects.md b/src/content/docs/Getting Started/Installing Patchstack/installing-on-javascript-node-projects.md
index ec7d21d..fa8725a 100644
--- a/src/content/docs/Getting Started/Installing Patchstack/installing-on-javascript-node-projects.md	
+++ b/src/content/docs/Getting Started/Installing Patchstack/installing-on-javascript-node-projects.md	
@@ -9,7 +9,7 @@ sidebar:
   label: "JavaScript / Node.js projects"
 ---
 
-Patchstack monitors JavaScript and Node.js applications — not only WordPress sites — through [`@patchstack/connect`](https://www.npmjs.com/package/@patchstack/connect), the official Patchstack connector package, maintained and published by Patchstack on npm under the `@patchstack` organization.
+Patchstack monitors JavaScript and Node.js applications — not only WordPress sites — through [`@patchstack/connect`](https://www.npmjs.com/package/@patchstack/connect), the official Patchstack Connect package, maintained and published by Patchstack on npm under the `@patchstack` organization.
 
 - **npm:** https://www.npmjs.com/package/@patchstack/connect
 - **Source (MIT-licensed):** https://github.com/patchstack/connect
@@ -17,7 +17,7 @@ Patchstack monitors JavaScript and Node.js applications — not only WordPress s
 
 ## What it does
 
-The connector reads the project's dependency lockfile (`package-lock.json`, `pnpm-lock.yaml`, or `yarn.lock`; bun projects are detected via `node_modules/`) and reports package names and versions to Patchstack, which matches them against its vulnerability database and notifies you when a dependency needs patching. It works with any framework — Next.js, Vite, Nuxt, Remix, SvelteKit, TanStack Start, plain Node — and with npm, pnpm, yarn, and bun.
+Connect reads the project's dependency lockfile (`package-lock.json`, `pnpm-lock.yaml`, or `yarn.lock`; bun projects are detected via `node_modules/`) and reports package names and versions to Patchstack, which matches them against its vulnerability database and notifies you when a dependency needs patching. It works with any framework — Next.js, Vite, Nuxt, Remix, SvelteKit, TanStack Start, plain Node — and with npm, pnpm, yarn, and bun.
 
 It sends dependency names and versions only: no source code, no environment variable values, no file paths, no git history.
 
@@ -34,7 +34,7 @@ npx --no-install patchstack-connect setup
 
 1. **Scans the lockfile and sends the dependency manifest** (package names and versions) to Patchstack.
 2. **Provisions a Patchstack site** on the first run and writes its UUID to `.patchstackrc.json` (commit this file); later runs reuse the existing site instead of creating a duplicate.
-3. **Manages the disclosure-widget tag** in the project's root HTML shell (the first of `index.html`, `public/index.html`, or `src/app.html` that exists) — see the widget section below.
+3. **Manages the Patchstack Connector tag** in the project's root HTML shell (the first of `index.html`, `public/index.html`, or `src/app.html` that exists) — see the widget section below.
 4. **Adds production build integration to `package.json`:** `scan` runs before the build and `mark-build` after it, via `prebuild`/`postbuild` lifecycle hooks (or a direct build chain on bun, which skips npm-style hooks). Existing build commands are preserved, dev scripts are untouched, and `setup` never runs the build itself.
 5. **Prints a status checklist** of anything that still needs a manual step, such as framework-specific widget placement.
 
@@ -48,7 +48,7 @@ A site that is scanning but not connected is an anonymous record: it is monitore
 2. **From the dashboard link.** Open the link `setup`, `scan`, or `status` printed in your browser and sign in.
 3. **From the terminal.** `npx @patchstack/connect claim` prints a link to sign in with, then attaches the site to that account.
 
-On a **published** build the connect panel is hidden from ordinary visitors (see [the disclosure widget](#the-disclosure-widget) below). As the owner you can still reach the sign-in there by loading any page with `#patchstack` appended to the URL — `?patchstack` works too.
+On a **published** build the connect panel is hidden from ordinary visitors (see [the Patchstack Connector](#the-patchstack-connector) below). As the owner you can still reach the sign-in there by loading any page with `#patchstack` appended to the URL — `?patchstack` works too.
 
 Once the site is connected, the panel never appears again, and the widget shows the public report form instead.
 
@@ -80,9 +80,9 @@ The same pieces can be applied individually: `npx @patchstack/connect scan` perf
 
 Run `npx @patchstack/connect guide` at any time for a project-aware checklist of what is present and what is missing, with commands tailored to the project. `npx @patchstack/connect status` re-prints the site UUID and dashboard link.
 
-## The disclosure widget
+## The Patchstack Connector
 
-The connector installs Patchstack's **vulnerability disclosure widget** — a floating control that becomes a "Report a vulnerability" button once the site is connected to an account, so anyone who spots an issue can report it straight to you. The widget is a single script tag loading `https://cdn.patchstack.com/patchstack-widget.js`, configured with the site UUID (which is public by design — it ships in client-side HTML and is not a secret). A pre-existing manually placed widget tag is left untouched, and `mark-build` ensures the tag in build output (`dist/`, `build/`, `out/`, `.output/public`) without ever editing source.
+Connect installs the **Patchstack Connector**, Patchstack's vulnerability disclosure widget — a floating control that becomes a "Report a vulnerability" button once the site is connected to an account, so anyone who spots an issue can report it straight to you. The widget is a single script tag loading `https://cdn.patchstack.com/patchstack-widget.js`, configured with the site UUID (which is public by design — it ships in client-side HTML and is not a secret). A pre-existing manually placed widget tag is left untouched, and `mark-build` ensures the tag in build output (`dist/`, `build/`, `out/`, `.output/public`) without ever editing source.
 
 Frameworks without a static HTML shell need a one-line placement in the root layout; `guide` prints the exact snippet for the detected framework, and the [widget reference](https://cdn.patchstack.com/llm.html) covers additional patterns.
 
@@ -90,7 +90,7 @@ To run without the widget, set `"widget": false` in `.patchstackrc.json` — thi
 
 **What the widget shows depends on whether the site is connected to an account.** While it is unclaimed, the widget serves the one-time "Connect this website" panel *instead of* the report button — so on a fresh install the first thing you see is the sign-in, not the floating button. Connect the site and the panel is replaced by the public **Report a vulnerability** button for good. To skip the onboarding entirely and always show the report form, set `data-build-mode="false"` on the script tag.
 
-On a **published** build the connector's `mark-build` hook stamps `window.__PATCHSTACK_PROD__` into the built HTML, which hides the connect panel and the owner "Log in" link from visitors and leaves the report form only. Owners reach the sign-in there with `#patchstack` (or `?patchstack`) appended to any page URL.
+On a **published** build Connect's `mark-build` hook stamps `window.__PATCHSTACK_PROD__` into the built HTML, which hides the connect panel and the owner "Log in" link from visitors and leaves the report form only. Owners reach the sign-in there with `#patchstack` (or `?patchstack`) appended to any page URL.
 
 See [Troubleshooting JS / Node.js](/getting-started/installing-patchstack/troubleshooting-javascript-node-projects/) if the widget does not appear at all.
 
@@ -121,7 +121,7 @@ Reporting stops immediately. Local removal does not delete the site record on Pa
 
 ## Troubleshooting
 
-A widget that never appears, a published site serving an old build, a broken config file, or a connector stuck on an old version are all covered — with copy-paste prompts for AI site builders — in [Troubleshooting JavaScript / Node.js projects](/getting-started/installing-patchstack/troubleshooting-javascript-node-projects/).
+A widget that never appears, a published site serving an old build, a broken config file, or a Connect install stuck on an old version are all covered — with copy-paste prompts for AI site builders — in [Troubleshooting JavaScript / Node.js projects](/getting-started/installing-patchstack/troubleshooting-javascript-node-projects/).
 
 ## How this relates to host-level npm protection
 
diff --git a/src/content/docs/Getting Started/Installing Patchstack/troubleshooting-javascript-node-projects.mdx b/src/content/docs/Getting Started/Installing Patchstack/troubleshooting-javascript-node-projects.mdx
index b82a11c..90213d6 100644
--- a/src/content/docs/Getting Started/Installing Patchstack/troubleshooting-javascript-node-projects.mdx	
+++ b/src/content/docs/Getting Started/Installing Patchstack/troubleshooting-javascript-node-projects.mdx	
@@ -1,6 +1,6 @@
 ---
 title: "Troubleshooting JavaScript / Node.js projects"
-excerpt: "Fix a disclosure widget that never appears or appears twice, a published build that serves an old integration, a broken config file, or an outdated @patchstack/connect — including prompts to paste into an AI site builder."
+excerpt: "Fix a Patchstack Connector that never appears or appears twice, a published build that serves an old integration, a broken config file, or an outdated @patchstack/connect — including prompts to paste into an AI site builder."
 hidden: false
 createdAt: "Mon Sep 07 2026 00:00:00 GMT+0000 (Coordinated Universal Time)"
 updatedAt: "Wed Sep 09 2026 00:00:00 GMT+0000 (Coordinated Universal Time)"
@@ -11,7 +11,7 @@ sidebar:
 
 import { Steps, Aside } from '@astrojs/starlight/components';
 
-This page covers the problems that come up after connecting a JavaScript or Node.js project with [`@patchstack/connect`](/getting-started/installing-patchstack/installing-on-javascript-node-projects/): a disclosure widget that never appears, a widget that appears twice, a published site still serving an old integration, a build that broke after a config change, a connector stuck on an old version, and an update that will not take because the package manager is holding the release back.
+This page covers the problems that come up after connecting a JavaScript or Node.js project with [`@patchstack/connect`](/getting-started/installing-patchstack/installing-on-javascript-node-projects/): a Patchstack Connector that never appears, a widget that appears twice, a published site still serving an old integration, a build that broke after a config change, a Connect install stuck on an old version, and an update that will not take because the package manager is holding the release back.
 
 Every section ends with a **prompt you can paste into your site builder's AI chat**. The prompts are deliberately explicit about proving the result, because builder assistants otherwise tend to report the version they remember, or stop after editing one file.
 
@@ -57,7 +57,7 @@ same package manager for every command. Do not create a second lockfile.
 
 ## The widget is not visible on my site
 
-The visitor-facing **Report a vulnerability** button does not appear until the site is connected to a Patchstack account. If you installed the connector and never saw it, that is usually the reason rather than a broken install — work through these in order.
+The visitor-facing **Report a vulnerability** button does not appear until the site is connected to a Patchstack account. If you installed Connect and never saw it, that is usually the reason rather than a broken install — work through these in order.
 
 <Steps>
 
@@ -101,16 +101,16 @@ The visitor-facing **Report a vulnerability** button does not appear until the s
 Use this when the widget works in the builder preview but is absent from the published site.
 
 ```text
-Please diagnose why the Patchstack widget works in preview but is missing from
+Please diagnose why the Patchstack Connector works in preview but is missing from
 the published site.
 
 1. Use the latest @patchstack/connect release from npm.
-2. Confirm the root page contains exactly one connector-managed script from
+2. Confirm the root page contains exactly one Connect-managed script from
    https://cdn.patchstack.com/patchstack-widget.js with data-site-uuid set from
    the public .patchstackrc.json value.
 3. Do not read the site UUID from VITE_*, NEXT_PUBLIC_*, or another
    environment-only variable.
-4. Run the connector setup/scan flow and the complete production build,
+4. Run the Connect setup/scan flow and the complete production build,
    including mark-build where the project scripts require it.
 5. Inspect the generated production output — not only source files — and verify
    that the widget script and window.__PATCHSTACK_PROD__ marker are present.
@@ -147,7 +147,7 @@ Please do not stop at a source-code check; verify the live deployment.
 Thank you.
 ```
 
-## Is this the latest connector version?
+## Is this the latest Connect version?
 
 Site builders often resolve `@patchstack/connect` from cached package metadata and land on an older release. Check what npm actually has:
 
@@ -195,7 +195,7 @@ Patchstack allows for this. The update notice in your dashboard and in the widge
 
 ## The build broke after a config update
 
-The connector uses two config files with different jobs, and mixing them up breaks the build:
+Connect uses two config files with different jobs, and mixing them up breaks the build:
 
 | File | Commit it? | Holds |
 |------|-----------|-------|
@@ -225,14 +225,14 @@ Please diagnose and fix the Patchstack build after the config-file update.
 Please complete and verify the fix. Thank you.
 ```
 
-## I see two Patchstack widgets
+## I see two Patchstack Connectors
 
 Two shield buttons stacked in the corner, sometimes one opening the owner log-in and the other the report form, mean the widget script ran twice on that page. They often sit on exactly the same pixel, so the second one only shows when a panel opens or the layout shifts.
 
 The widget keeps **one floating launcher per page** on its own:
 
 - A second copy loaded by the **same document** is ignored, with a `[PatchstackWidget]` warning in the browser console.
-- A copy inside a page of **your own site that the shell shows in an `<iframe>`** stands down as well, with a console message. The connector's `mark-build` step stamps every built HTML file, so an embedded static page carries the tag too; that copy is harmless and you can leave it.
+- A copy inside a page of **your own site that the shell shows in an `<iframe>`** stands down as well, with a console message. Connect's `mark-build` step stamps every built HTML file, so an embedded static page carries the tag too; that copy is harmless and you can leave it.
 
 What still needs your attention is a second tag that you, or the builder's AI, added by hand. It usually lives in a component, a layout, or a runtime `useEffect` that appends the script. Keep exactly one tag, in the root shell.
 
@@ -252,12 +252,12 @@ If the page embeds another page of your site in an `<iframe>`, run the same two
 ### Prompt: two widgets on the page
 
 ```text
-Please make sure the Patchstack widget is loaded exactly once on this site.
+Please make sure the Patchstack Connector is loaded exactly once on this site.
 
 1. Search the entire project - source files, layouts, components, and static
    HTML under public/ - for "patchstack-widget.js" and list every place that
    loads it.
-2. Keep exactly one <script> tag: the connector-managed one in the root shell
+2. Keep exactly one <script> tag: the Connect-managed one in the root shell
    (index.html, or the root layout for Next.js / TanStack Start / Remix). It
    must carry data-site-uuid with the value from the committed
    .patchstackrc.json.
diff --git a/src/content/docs/Patchstack App/Pulse/pulse-overview.md b/src/content/docs/Patchstack App/Pulse/pulse-overview.md
index 26ef24e..c61c7bf 100644
--- a/src/content/docs/Patchstack App/Pulse/pulse-overview.md	
+++ b/src/content/docs/Patchstack App/Pulse/pulse-overview.md	
@@ -15,7 +15,7 @@ That difference in mechanism is why a Pulse site's dashboard does not look like
 
 ## Getting a site into the dashboard
 
-Install the connector in your project and run `setup`. The first scan creates the site for you — there is no "add site" step to do first, and no API key to paste.
+Install Connect in your project and run `setup`. The first scan creates the site for you — there is no "add site" step to do first, and no API key to paste.
 
 The site starts out **unclaimed**: it is being monitored, but it is not attached to anyone's account, so nobody can see its reports. `setup` prints a dashboard link. Open it, sign in, and the site attaches to your account. If you lose the link, `npx @patchstack/connect status` prints it again.
 
@@ -48,10 +48,10 @@ The headline is one of:
 - **Sandbox only** — builds have been reported from a hosted builder's sandbox, and nothing has gone to production.
 - **Not deployed yet** — the app was added but no build has reported at all.
 - **Needs deploying** — a newer build has been scanned than the one the live site is serving.
-- **Deployed** — the live site is running a build Patchstack scanned. The date is when the build was seen to change on the live site; where nothing has changed under observation, it is the build time, labelled as such. A production build that reports itself from a hosting platform's own production build (Netlify, Vercel, Cloudflare and the others the connector recognises) also reads as **Deployed**, dated by the build, until the live page confirms it.
+- **Deployed** — the live site is running a build Patchstack scanned. The date is when the build was seen to change on the live site; where nothing has changed under observation, it is the build time, labelled as such. A production build that reports itself from a hosting platform's own production build (Netlify, Vercel, Cloudflare and the others Connect recognises) also reads as **Deployed**, dated by the build, until the live page confirms it.
 - **Deploy reported** — a production build reported itself, but the live page has not been seen running it. This happens in two cases. Patchstack has read the page since the report and it is not running that build: either nothing has been published yet, or the build went out without its marker. Or the label was assumed from the project's builder rather than read from a platform: Lovable and Replit build the app for the preview and for publishing alike, so a build on its own is not proof of a publish. The first visit or scheduled check that finds the build live turns this into **Deployed**.
 - **Deployed without Patchstack** — the live site is running a build that was never scanned. Run the build again with `@patchstack/connect` installed.
-- **Live, build unverified** — the widget is checking in from the site's address, but the page carries no build marker, so nothing says which build is running. This is what a build made on your own machine looks like once it is uploaded by hand: the connector only stamps the marker on a build it can tell is a deployment. Build for publishing with `PATCHSTACK_ENVIRONMENT=production`, or run `npx @patchstack/connect mark-build --production` before uploading, and the next deploy reads as **Deployed**.
+- **Live, build unverified** — the widget is checking in from the site's address, but the page carries no build marker, so nothing says which build is running. This is what a build made on your own machine looks like once it is uploaded by hand: Connect only stamps the marker on a build it can tell is a deployment. Build for publishing with `PATCHSTACK_ENVIRONMENT=production`, or run `npx @patchstack/connect mark-build --production` before uploading, and the next deploy reads as **Deployed**.
 - **Deploy state unknown** — production builds exist, but nothing current says which one is live.
 
 Next to the headline, **Reporting from** names the environment Patchstack last heard from — *local machine*, *sandbox*, or *production*. **Built with** names the builder when one was recognised, and **Hosted on** names the platform serving the site (Netlify, Vercel, Cloudflare, DigitalOcean, AWS, GitHub Pages and others), as read from the build's own environment and confirmed from the live page's response headers. The four stages below them (**Configured**, **Deployed**, **Monitoring**, **Protection**) are each graded from what was actually observed, with its timestamp. A stage is not ticked because a later one is: an app can be live without a production scan, and the card says so. The **Protection** stage is ticked when protection is on for the site, whether through the per-site add-on or a plan that protects every site — the same rule the site header and the widget use.
@@ -62,7 +62,7 @@ Under the status card, **Live site activity** shows how often the site has been
 
 The headline above the grid says when the site was last heard from and by which witness, and reads **Checking in** while the last check-in is under an hour old. The grid is the difference between a site with visitors and one somebody opened once: the status card can say the site was seen five minutes ago, but only the grid can say whether that was the first time this week or the four-hundredth. Check-ins are kept for 30 days.
 
-Under the grid, **Recent builds** lists each build that reported its packages this week, newest first: the environment the connector said it ran in, what decided a production label (the platform's own variables, an assumption from the project's builder, or `PATCHSTACK_ENVIRONMENT`), the build id, and whether a visitor's widget or Patchstack's own page read has since seen that build on the live site. That last column is the difference between a build and a deploy. Nothing in the list names a machine, a person, a path or a branch: the connector reports only the label and how it decided it.
+Under the grid, **Recent builds** lists each build that reported its packages this week, newest first: the environment Connect said it ran in, what decided a production label (the platform's own variables, an assumption from the project's builder, or `PATCHSTACK_ENVIRONMENT`), the build id, and whether a visitor's widget or Patchstack's own page read has since seen that build on the live site. That last column is the difference between a build and a deploy. Nothing in the list names a machine, a person, a path or a branch: Connect reports only the label and how it decided it.
 
 Every status that is not the finished one names the next step. For a locally configured app that is: add `PATCHSTACK_API_KEY` to the hosting platform's environment, commit the generated changes, and deploy. Expand **What this is based on** to see every signal behind the verdict — a scan on a developer machine, a production build, the widget checking in from the live site, Patchstack's own fetch of the page — with where each came from and when.
 
@@ -72,13 +72,13 @@ A deploy that was scanned before it went out, but not by the build that shipped
 
 ## Connected, scanned, and synced
 
-The site header shows **Last scan** — when the connector last sent a dependency manifest. This moves when you build or install dependencies, and it is how old the package data on the page is.
+The site header shows **Last scan** — when Connect last sent a dependency manifest. This moves when you build or install dependencies, and it is how old the package data on the page is.
 
-Hover it and Patchstack also tells you when it last had any contact with the site, whenever that is much more recent than the scan. The two differ because Patchstack learns about a Pulse site from more than one signal. The connector reports at build time. The disclosure widget in your served pages checks in when a visitor loads the site, which is how Patchstack knows the app is actually live and running the build you last reported. Patchstack also re-fetches the published page on a schedule to confirm the widget is still there.
+Hover it and Patchstack also tells you when it last had any contact with the site, whenever that is much more recent than the scan. The two differ because Patchstack learns about a Pulse site from more than one signal. Connect reports at build time. The Patchstack Connector in your served pages checks in when a visitor loads the site, which is how Patchstack knows the app is actually live and running the build you last reported. Patchstack also re-fetches the published page on a schedule to confirm the widget is still there.
 
 An app that builds rarely but gets traffic will show an old scan time and recent contact. That is normal, not a fault.
 
-Because the widget check-in runs in a public page, Patchstack treats it as corroboration rather than proof — a site's connection status is derived from what can be verified, not from the check-in alone. What makes a check-in verifiable is the build fingerprint it carries: when that matches the build the connector last reported, it says a real browser loaded a page from that build, and Patchstack counts the app as connected even if its own re-fetch of the page came back with nothing recognisable.
+Because the widget check-in runs in a public page, Patchstack treats it as corroboration rather than proof — a site's connection status is derived from what can be verified, not from the check-in alone. What makes a check-in verifiable is the build fingerprint it carries: when that matches the build Connect last reported, it says a real browser loaded a page from that build, and Patchstack counts the app as connected even if its own re-fetch of the page came back with nothing recognisable.
 
 That happens more often than you might expect. Patchstack's re-fetch reads the HTML the server sends, so on an app that renders its markup in the browser — most React and Vue projects, and the default on the sandbox domains builders serve previews from — there is nothing in that HTML for it to find. The check-in from inside the page is the signal that settles it, and it arrives on its own whenever the site is loaded. You should not have to press anything to keep an app that is running and reporting from reading as out of sync.
 
@@ -86,7 +86,7 @@ That happens more often than you might expect. Patchstack's re-fetch reads the H
 
 Beside those timestamps, a Pulse site's header carries a **deploy status**. Building and deploying are separate events, and Patchstack tracks them separately.
 
-The connector's `mark-build` step stamps each build's fingerprint into the HTML it publishes. Patchstack reads that fingerprint back off the live site — from the widget when a visitor loads a page, and from its own scheduled fetch of the published page — and compares it against the builds you have reported. That comparison is what the status says out loud:
+Connect's `mark-build` step stamps each build's fingerprint into the HTML it publishes. Patchstack reads that fingerprint back off the live site — from the widget when a visitor loads a page, and from its own scheduled fetch of the published page — and compares it against the builds you have reported. That comparison is what the status says out loud:
 
 | Status | What it means |
 |--------|---------------|
@@ -94,7 +94,7 @@ The connector's `mark-build` step stamps each build's fingerprint into the HTML
 | **Last build \<when\>** | The same, except nobody has seen this app change build since Patchstack started watching. The time shown is when the build ran, not when it went live. |
 | **Deploy reported** | A production build reported itself, but the live page has not been seen running it — either the page was read since and is not running it, or the label was assumed from the project's builder. Publish if you have not, or open the published site once so the widget can confirm the build. |
 | **Needs deploying** | A newer build was scanned, but the live site is still serving an older one. Deploy to put it live. |
-| **Deployed without Patchstack** | The live site is running a build Patchstack never scanned — the build ran without the connector. Run the build again with `@patchstack/connect` so its packages get checked. |
+| **Deployed without Patchstack** | The live site is running a build Patchstack never scanned — the build ran without Connect. Run the build again with `@patchstack/connect` so its packages get checked. |
 | **Live, build unverified** | The widget is checking in from the site's address, but the page carries no build marker, so nothing can say which build is live. Typically a build made on a developer's machine and uploaded by hand. Build with `PATCHSTACK_ENVIRONMENT=production`, or run `mark-build --production` before uploading. |
 | **Sandbox only** | Builds have been reported, but only from a sandbox. Nothing has gone to production yet. |
 | **Build environment** | This site is a build environment rather than a live one. Deploys are tracked on the production site it belongs to. |
@@ -102,7 +102,7 @@ The connector's `mark-build` step stamps each build's fingerprint into the HTML
 
 **Needs deploying** is the one worth acting on. The vulnerabilities Patchstack lists are the ones in the build it scanned; if that build never shipped, neither did the fixes in it.
 
-The status also appears in the disclosure widget's owner panel, under the sync line — useful, because you are standing on the live site when you read it there.
+The status also appears in the Patchstack Connector's owner panel, under the sync line — useful, because you are standing on the live site when you read it there.
 
 While the newest build has not been seen on the live site — the app is configured locally, only sandbox builds exist, a production build reported itself without confirmation, or a newer build is waiting to go out — the owner panel carries a short reminder that Patchstack is not on the live site yet and the project needs republishing. It is a statement, not a publish button: nothing is published for you. It goes away on its own once a check-in or page read finds the new build live, and returns if a later build is scanned and not shipped.
 
@@ -124,7 +124,7 @@ Runtime protection on a production Pulse app is a paid feature. See [The runtime
 
 The guard screens requests, so it needs a request path to sit on. Some apps have none, and the Status tab and the Protection card say so instead of offering protection:
 
-- **Not available for this app** — the app builds a static site (Eleventy, Gatsby, Docusaurus, VitePress, a SvelteKit site with the static adapter, and similar) and nothing in it receives a request. Dependency monitoring and the disclosure widget still apply; runtime protection does not. `setup` installs nothing for it on such a project, and `protect --check` reports the capability as not applicable rather than as failing. Protection becomes available if the app later gains a server or edge request path.
+- **Not available for this app** — the app builds a static site (Eleventy, Gatsby, Docusaurus, VitePress, a SvelteKit site with the static adapter, and similar) and nothing in it receives a request. Dependency monitoring and the Patchstack Connector still apply; runtime protection does not. `setup` installs nothing for it on such a project, and `protect --check` reports the capability as not applicable rather than as failing. Protection becomes available if the app later gains a server or edge request path.
 - **Deploy first** — the app has not been deployed with Patchstack yet. Protection is verified against a live site, so deploy, then enable it.
 
 The card names what the verdict is based on: the attack-surface map's analysis of the source where the app has reported one, otherwise the packages in its newest build.