@impeccable/reviews 0.1.3 → 0.1.5

package/README.md

@@ -2,7 +2,7 @@
 
 Sets a repository up for Impeccable for PRs from your terminal. Run it in a checkout of the repository: it signs you in through the browser, then a setup agent reads the checkout, runs what it needs, saves the settings through Impeccable's setup API, asks you only what it cannot find out, opens a test drive pull request for Impeccable to review (and a setup pull request to merge, when the repository needs one) and writes a setup report. A web page mirrors the run as it goes and follows the review.
 
-You need Node 22.19 or newer, git, and the `gh` command signed in to GitHub as someone who can push branches to the repository (the agent opens the pull request as you). On Linux, `bubblewrap`, `socat` and `ripgrep` let the agent's commands run in a sandbox.
+You need Node 22.19 or newer, git, and the `gh` command signed in to GitHub as someone who can push branches to the repository (the agent opens the pull request as you). Right after sign-in the command asks GitHub with a dry run of a push, which creates nothing, and when git cannot push it says which account git signs in as and stops before anything is made, unless you fix it and try again. On Linux, `bubblewrap`, `socat` and `ripgrep` let the agent's commands run in a sandbox.
 
 ## Run it
 
@@ -28,7 +28,7 @@ Keys: Enter goes on, Esc cancels the intro or the sign-in and skips a question (
 | `--model <id>` | the model the service hands out (Sonnet 5.5 today) | The model the setup agent runs on, through Impeccable's gateway. |
 | `--effort <level>` | `high` | `off`, `minimal`, `low`, `medium`, `high`, `xhigh` or `max`. |
 | `--yes` | off | Runs the allowlisted commands without asking, which they already do; anything off the list is still refused. |
-| `--debug` | off | Writes a debug log and a transcript of the run (`transcript-<run>.md`, with its raw events in `transcript-<run>.jsonl`) to the temp folder, tokens removed, and prints where they are. |
+| `--debug` | off | Writes a debug log and a transcript of the run (`transcript-<run>.md`, with its raw events in `transcript-<run>.jsonl`) to the temp folder, with tokens and whatever is shaped like a secret removed, and prints where they are. |
 | `--transcript <path>` | the temp folder | Writes the transcript there instead: a folder, or a `.md` file with the `.jsonl` beside it. |
 | `--scan-report` | off | Writes what the fence's content checks found (`scan-report-<run>.json`: each match's check, where it was, the tool and what it did, never the text, with counts per check) beside the transcript, and prints where it is. |
 | `--frames <dir>` | off | Writes each screen into the folder as it changes (`NNN-<state>.ansi` with its styling, `NNN-<state>.txt`, and `index.json`), for the eval. |
@@ -36,7 +36,7 @@ Keys: Enter goes on, Esc cancels the intro or the sign-in and skips a question (
 
 ## What happens
 
-1. **Sign in.** The consent page names this repository, read from the checkout's `origin` remote; you approve, and it answers a small server on the first free port of 8239, 8238, 8240, 8237, 8236 and 8235, with PKCE and a state check, then sends the browser on to the run's web page. On a remote shell, press P and paste the address the browser ends on.
+1. **Sign in.** The consent page names this repository, read from the checkout's `origin` remote; you approve, and it answers a small server on the first free port of 8239, 8238, 8240, 8237, 8236 and 8235, with PKCE and a state check, then sends the browser on to the run's web page. The server holds its port on both loopback addresses (`127.0.0.1` and `::1`), since a browser takes `localhost` for either: a port another program holds on one of them counts as taken. On a remote shell, press P and paste the address the browser ends on.
 2. **A web front end?** Impeccable reviews web front ends, mobile web included. A checkout with none (a React Native, Expo or Flutter app without a web target, or a service with no page, template, stylesheet or web framework) ends here: the terminal and the web page say "Impeccable reviews web front ends, and this repository does not have one. Nothing was set up.", and it exits 2. When the checkout cannot tell, Impeccable's own scan decides. A checkout with a web front end that the scan skipped stops the same way, with the setup page, where the person chooses Add anyway before running it again.
 3. **Set up.** On a run with its own capped model token (model calls go through Impeccable's gateway, so this machine holds no model key), the agent reads the checkout, runs the build, saves settings through the setup API, and asks you in a dialog only what it cannot find out. It never asks you to run a command: what it cannot run goes into the report, with the command. When Vercel, Netlify or Cloudflare Pages already deploys previews of your pull requests, it opens the newest one (Netlify's it finds on GitHub, and through the Netlify CLI when you are signed in to it on this machine, read only; Cloudflare's in the check run and the comment Cloudflare's GitHub app posts, and through Cloudflare's CLI, cf, when you are signed in to it here, read only), and once that page is your app it takes the host's previews as they are, with no question and no setup pull request. When the repository is set up for Vercel or Netlify but that host has never previewed it, it asks you for one thing, to sign in to the host, and only when its CLI on this machine is signed out: one screen, Sign in or Skip, the login in your browser on Enter, and a retry when it did not complete (two failed retries count as a skip). Then it does the rest itself. On Vercel it creates the project with `vercel link` in the team the CLI's current scope names (asking which, only when you have several and none is current), connects the repository, puts Vercel's login in front of every address of the new project before pushing anything (Vercel makes a new project's first deployment production, whatever branch it builds, and would serve the test drive at the project's own address otherwise; the report says how to open production once your default branch is live), pushes the test drive and waits up to five minutes for Vercel's build of it (the task in progress reads "waiting for Vercel's preview · 1:05", counting up), proves that preview, takes Vercel's previews as they are and only then opens the test drive's pull request, so its review renders; a new project starts with Vercel Authentication on, which the run gets past with a bypass secret on your yes. On Netlify it creates the site in your Netlify team (asking which, only when you have several), connects the repository through Netlify's site settings and Netlify's GitHub app, so pull requests get deploy previews, pushes the test drive and opens it as a draft, which Impeccable leaves unreviewed, waits for its deploy preview, proves it, takes Netlify's previews as they are and marks the draft ready. When the host's GitHub app cannot reach the repository, one more screen opens the app's page on GitHub for you to give it access, and the run waits. On skip it builds Impeccable's own previews as usual.
 4. **Two pull requests,** opened as you with `gh`, even when something is left for a person, which goes into the report, both into the default branch and in this order:
@@ -80,10 +80,14 @@ Each report carries the step, how it ended, when, the command's version, Node's
 
 The setup token and the run token stay in memory. The agent never sees them: the tools add them to their own requests. The debug log and the transcript remove them.
 
+The debug log and the transcript also remove whatever is shaped like a secret, wherever the agent wrote or read it: a cloud or GitHub key, a token, a private key through its end, and a random value under a secret-like name (`API_TOKEN=…`), whose name stays. So a call the fence refused for holding a secret leaves no copy of it there.
+
 A test account's password, typed hidden on the account's screen (after a screen that says why the run asks), goes from there to Impeccable's test-accounts setting: the agent only holds a reference to it, and the debug log and the transcript remove it.
 
+What you type into any other question the agent asks, it reads. So a question whose title, prompt or hint names a token, a password, a secret, a key or a credential is typed hidden however the agent asked it, and the agent gets a reference, as for a test account's password. Every other question with a field says under it "Never enter a password, a token or a key here."
+
 Vercel's bypass secret, which lets reviews open previews behind Vercel's login, is handled the same way. When Vercel's login stands in front of a preview, the command asks you once, on one screen, whether to create a bypass secret for Impeccable, and on your yes creates it as you through the Vercel CLI, labelled "Impeccable reviews" (`vercel api` for Vercel's protection-bypass route; an older CLI's `vercel project protection enable --protection-bypass`), then reads it back from the project's settings. A project that already holds a secret with that label gives it without a question. When the CLI is signed out, this folder is not linked, or your role cannot make one, a screen names the settings page and takes the secret you type, hidden. It opens the preview with the secret first and saves it, with the setting that sends it in the `x-vercel-protection-bypass` header, only once the page shows your app. The agent never holds it: the secret goes from the command's own process to Vercel and to Impeccable's setting, and the debug log and the transcript remove it. Vercel documents this as Protection Bypass for Automation, which every plan includes; you revoke it in the project's Settings, Deployment Protection.
 
-Netlify's site password (Password Protection on Pro and Enterprise plans; "Project visibility: Password" on a credit-based Pro plan) is handled the same way. When a Netlify deploy preview asks for it, the command reads the site's settings through the Netlify CLI, signed in as you. For a password Netlify gives back, it asks you once, on one screen, whether to store the site password for Impeccable, and on your yes reads it from the site as you. When Netlify does not give the password back, the CLI is signed out or the site is in none of your teams, a screen takes the password you type, hidden (the run never sets one itself: the Netlify CLI takes a new password only on its command line, where any process could read it). It opens the preview with the password first, as basic credentials in the `Authorization` header (Netlify's password page asks for a password alone, so the credentials carry no username), and saves it, with the setting that sends that header, only once the page shows your app; a password that opens the preview on Netlify's own form but not in the header is reported, not saved, since reviews can send only a header. A site behind Netlify's team login (a private site, or team login protection) has no way in for tools: the run reports it and takes no method. The agent never holds the password: it goes from the command's own process to Netlify and to Impeccable's setting, and the debug log and the transcript remove it.
+Netlify's site password (Password Protection on Pro and Enterprise plans; "Project visibility: Password" on a credit-based Pro plan) is handled the same way. When a Netlify deploy preview asks for it, the command reads the site's settings through the Netlify CLI, signed in as you. For a password Netlify gives back, it asks you once, on one screen, whether to store the site password for Impeccable, and on your yes reads it from the site as you. When Netlify does not give the password back, the CLI is signed out or the site is in none of your teams, a screen takes the password you type, hidden (the run never sets one itself: the Netlify CLI takes a new password only on its command line, where any process could read it). It opens the preview with the password first, as basic credentials in the `Authorization` header (Netlify's password page asks for a password alone, so the credentials carry no username), and saves it, with the setting that sends that header, only once the page shows your app; a password that opens the preview on Netlify's own form but not in the header is reported, not saved, since reviews can send only a header. A site behind Netlify's team login (a private site) has no way in for tools, so the command asks you once, on one screen, whether to make the site public, and on your yes makes it public as you through the Netlify CLI (`netlify api updateSite` with `sso_login` off); anyone with its address can then open it, the live site included, until you make it private again in Project configuration, General, Visitor access. Where Netlify refuses (your team's default keeps every project private, or your role cannot change it), the command opens that page in your browser and asks you to try again once you changed it there; a password you set there instead is stored as above. The agent never holds the password: it goes from the command's own process to Netlify and to Impeccable's setting, and the debug log and the transcript remove it.
 
 A Cloudflare Access service token, which lets reviews open Pages previews behind Access, is handled the same way. When Access stands in front of a preview, the command asks you once, on one screen, whether to create a service token for Impeccable. On your yes it creates the token as you through Cloudflare's CLI, cf (run through npx), named "Impeccable reviews", and allows it in a Service Auth policy of the Access application in front of the preview (a reusable policy added to the application's list). When cf here is not signed in with Access, your browser opens Cloudflare's sign-in first, for five scopes (`account:read`, `user:read`, `pages:read`, `access.write`, `access-service-token.write`), with a retry when it did not complete. Only where that sign-in cannot create the token (it grants no Access, cf does not run here, or the application runs on policies of its own, which cf has no command for) does the command ask for a Cloudflare API token with two permissions (Access: Apps and Policies, Edit; Access: Service Tokens, Edit), used for that run only and stored nowhere. On a skip, or where that cannot be done, a screen takes a client id and secret you paste, the secret hidden. It opens the preview with the token in the `CF-Access-Client-Id` and `CF-Access-Client-Secret` headers first and saves it, with the setting that sends them, only once the page shows your app; a token it made that opens nothing is deleted, with its policy. The agent never holds either, and the debug log and the transcript remove both. You revoke it in Zero Trust, Access controls, Service credentials, Service Tokens.

package/dist/agent.js

@@ -36,8 +36,8 @@ function gatewayModel(modelRuntime, id) {
  * to the command's finish.
  */
 export async function runAgent(opts) {
-    // Inside our command pi makes no calls of its own: no version check, no catalog refresh, no install telemetry.
-    process.env.PI_OFFLINE ??= '1';
+    // Inside our command pi makes no calls of its own: no version check, no catalog refresh, no install telemetry, whatever the person's shell exports.
+    process.env.PI_OFFLINE = '1';
     // pi's own configuration stays out of this: no settings, credentials, extensions or sessions from ~/.pi.
     const agentDir = mkdtempSync(join(tmpdir(), 'impeccable-reviews-pi-'));
     process.on('exit', () => rmSync(agentDir, { recursive: true, force: true }));

package/dist/fence.js

@@ -1183,6 +1183,10 @@ export function chooseHostTeam(log, questionId, team) {
     if (host && Object.hasOwn(HOST_CLIS, host) && hostsAgreed(log).has(host) && /^[A-Za-z0-9][A-Za-z0-9_.-]{0,99}$/.test(team))
         teamsChosen(log).set(host, team);
 }
+/** The team picked or found for a host's CLI in this run, which its dashboard's addresses name. */
+export function chosenHostTeam(log, host) {
+    return teamsChosen(log).get(host);
+}
 /** What impeccable_vercel_connect settled of the linked Vercel project's first deployment in this run, by the run's log. */
 const settledVercel = new WeakMap();
 export function settleVercelFirstDeployment(log, settlement) {

package/dist/host-questions.js

@@ -21,7 +21,20 @@ export const HOST_QUESTIONS = {
 };
 /** Where a person reads or changes a site's password in Netlify, as Netlify's docs name the page on every plan. */
 export const NETLIFY_PASSWORD_WHERE = 'Project configuration → General → Visitor access';
-/** The screens a tool shows on its own: a sign-in's retry, the one-time access the host's GitHub app needs, and the consent to a key for a host's lock (a bypass secret for Vercel's login, the site password for Netlify's, a service token for Cloudflare Access), with the paste where the run does not get one. */
+/** The wait for a host's build that ran out: the page where the host's builds of pull requests are turned on, and the wait again. */
+const buildWait = (id, name, where) => ({
+    [`${id}-build`]: {
+        id: `${id}-build`,
+        kind: 'confirm',
+        title: `Waiting for ${name}`,
+        hint: `Five minutes and no preview yet. If ${name} hasn't started a build, ${where} on the page that opens. The run carries on by itself once the preview is built.`,
+        prompt: `Open ${name} and keep waiting?`,
+        confirmLabel: 'Keep waiting',
+        skipLabel: 'Skip',
+    },
+    [`${id}-build-retry`]: { id: `${id}-build-retry`, kind: 'confirm', title: `Waiting for ${name}`, prompt: `Still no preview from ${name}.`, confirmLabel: 'Keep waiting', skipLabel: 'Skip' },
+});
+/** The screens a tool shows on its own: a sign-in's retry, the one-time access the host's GitHub app needs, and the consent to a key for a host's lock (a bypass secret for Vercel's login, the site password for Netlify's, a service token for Cloudflare Access), with the paste where the run does not get one, and to making a site behind Netlify's team login public. */
 export const HOST_SCREENS = {
     'netlify-signin-retry': { id: 'netlify-signin-retry', kind: 'confirm', title: 'Sign in to Netlify', prompt: 'The sign-in did not complete.', confirmLabel: 'Try again', skipLabel: 'Skip' },
     'netlify-access': {
@@ -45,6 +58,20 @@ export const HOST_SCREENS = {
         skipLabel: 'Skip',
     },
     'vercel-access-retry': { id: 'vercel-access-retry', kind: 'confirm', title: 'Vercel needs access on GitHub', prompt: "Vercel still can't see the repository.", confirmLabel: 'Try again', skipLabel: 'Skip' },
+    // Vercel refused the run's lock on a new project: the person turns it on, since the test drive's push is the project's first deployment.
+    'vercel-lock': {
+        id: 'vercel-lock',
+        kind: 'confirm',
+        title: 'Lock the new Vercel project',
+        hint: "The test drive's push is the project's first deployment, which Vercel shows to anyone at the project's own address. Vercel didn't let the run put its login in front. Turn on Vercel Authentication for All Deployments on the page that opens. The run carries on by itself once it's on.",
+        prompt: 'Open Vercel to lock the project?',
+        confirmLabel: 'Open Vercel',
+        skipLabel: 'Skip',
+    },
+    'vercel-lock-retry': { id: 'vercel-lock-retry', kind: 'confirm', title: 'Lock the new Vercel project', prompt: "The project isn't locked yet.", confirmLabel: 'Try again', skipLabel: 'Skip' },
+    ...buildWait('vercel', 'Vercel', 'connect the repository in Settings → Git'),
+    ...buildWait('netlify', 'Netlify', 'turn Deploy Previews on'),
+    ...buildWait('cloudflare', 'Cloudflare', 'connect the repository to the Pages project'),
     // Vercel's login in front of the previews: the one consent to a bypass secret the run creates as the person, and the paste when the CLI cannot.
     'vercel-bypass': {
         id: 'vercel-bypass',
@@ -81,6 +108,25 @@ export const HOST_SCREENS = {
         prompt: `Netlify keeps your previews behind the site password, and the run could not read it: the Netlify CLI here is signed out, the site is in none of your teams, or Netlify does not give the password back. Find it, or set a new one, in ${NETLIFY_PASSWORD_WHERE}. It is stored encrypted and used only to open previews.`,
         hint: 'Paste the password',
     },
+    // Netlify's team login in front of the previews: the one consent to making the site public as the person, and the retry once they changed it on Netlify's page where Netlify refused.
+    'netlify-visibility': {
+        id: 'netlify-visibility',
+        kind: 'confirm',
+        title: 'Your Netlify previews are private',
+        hint: `Impeccable reviews each pull request on its preview, and Netlify keeps this site behind your team's login, which tools can't get past. The run makes the site public as you, so anyone with an address of it can open it, the live site too. Change it back any time in ${NETLIFY_PASSWORD_WHERE}.`,
+        prompt: 'Make the site public?',
+        confirmLabel: 'Make public',
+        skipLabel: 'Skip',
+    },
+    'netlify-visibility-retry': {
+        id: 'netlify-visibility-retry',
+        kind: 'confirm',
+        title: 'Your Netlify previews are private',
+        hint: "Netlify still shows its login in front of the previews. On the Netlify page that opened, set Visitor access to Public (or Password protected, on Pro). Public is greyed out until the site has a live deploy, or while your team's default keeps it private (Team settings → General → Visitor access).",
+        prompt: 'Changed it?',
+        confirmLabel: 'Try again',
+        skipLabel: 'Skip',
+    },
     // Cloudflare Access in front of the previews: the one consent to a service token the run creates as the person through cf, the retry of cf's sign-in, the API token where that sign-in cannot create it, and the paste where the run does not create one.
     'cloudflare-access': {
         id: 'cloudflare-access',

package/dist/hosted.js

@@ -136,6 +136,8 @@ async function inCheckout(root, words) {
 const UNSEEN = /<!--[\s\S]*?-->|<(script|style|noscript|template)\b[^>]*>[\s\S]*?<\/\1\s*>/gi;
 /** The words a visitor sees: the title and the text, without comments, scripts, styles, tags or attributes. */
 const visible = (html) => plain(html.replace(UNSEEN, ' ').replace(/<[^>]*>/g, ' '));
+/** The team login's page, in its script: Netlify's edge-access login, the slashes escaped or not. */
+const NETLIFY_TEAM_LOGIN = /https:\\?\/\\?\/app\.netlify\.com\\?\/edge-access\b/;
 /**
  * Netlify's own lock, never the status alone, as Netlify documents it: the basic challenge (`WWW-Authenticate: Basic`)
  * its Basic-Auth rules send, which "trigger the built-in basic browser authentication"
@@ -144,13 +146,14 @@ const visible = (html) => plain(html.replace(UNSEEN, ' ').replace(/<[^>]*>/g, '
  * (https://docs.netlify.com/manage/security/secure-access-to-sites/password-protection/); or the "Netlify-branded page"
  * its team login shows a visitor (https://docs.netlify.com/manage/security/secure-access-to-sites/project-visibility/),
  * whose title names Netlify other than in the site's own address: a mention in an app's own page, such as a footer, is
- * not one.
+ * not one. Today that page is a "Login Redirect" whose script sends the browser to Netlify's edge-access login, its
+ * address written with escaped slashes; that address is the team login's marker (#233).
  */
 function netlifyLock(challenge, html) {
     const seen = html.replace(UNSEEN, ' ');
     const fields = [...seen.matchAll(/<input\b[^>]*>/gi)].map(([tag]) => /\stype\s*=\s*["']?([\w-]+)/i.exec(tag)?.[1]?.toLowerCase() ?? 'text').filter((type) => !['hidden', 'submit', 'button', 'reset', 'image'].includes(type));
     const title = plain(/<title\b[^>]*>([\s\S]*?)<\/title\s*>/i.exec(seen)?.[1] ?? '');
-    return /^basic\b/i.test(challenge ?? '') || (/<form\b/i.test(seen) && fields.join() === 'password') || /\bnetlify\b/.test(title.replace(/\S*\.netlify\.app\S*/g, ' '));
+    return /^basic\b/i.test(challenge ?? '') || (/<form\b/i.test(seen) && fields.join() === 'password') || /\bnetlify\b/.test(title.replace(/\S*\.netlify\.app\S*/g, ' ')) || NETLIFY_TEAM_LOGIN.test(html);
 }
 /** The first `max` bytes of a page, as text. */
 async function pageText(res, max = 1_000_000) {
@@ -256,7 +259,7 @@ export async function provePreview(url, words, root, deps = {}) {
                 if (withPassword && deps.form && (await formOpens(target, deps.password, phrase, open, signal))) {
                     return { ...unproven("The password opens the address on Netlify's own form, but not in the Authorization header, the one way reviews can send it.", res.status), gate, formOpened: true };
                 }
-                return { ...unproven(`The address asked for ${name}'s login or password${still}.`, res.status), gate };
+                return { ...unproven(`The address asked for ${name}'s login or password${still}.`, res.status), gate, ...(host === 'netlify' && NETLIFY_TEAM_LOGIN.test(page) ? { teamLogin: true } : {}) };
             }
             if (res.status < 200 || res.status >= 300) {
                 await res.body?.cancel().catch(() => { });

package/dist/log.js

@@ -1,6 +1,7 @@
 import { appendFileSync } from 'node:fs';
 import { tmpdir } from 'node:os';
 import { join } from 'node:path';
+import { redactShapes } from './scan.js';
 /** An error whose message is written for the person at the terminal; `step` is the onboarding step it ends, which the command reports (report.ts). */
 export class UserError extends Error {
     step;
@@ -21,6 +22,10 @@ export function redact(text, secrets = []) {
             out = out.split(secret).join('[redacted]');
     return out.replace(TOKEN, '$1_[redacted]').replace(FIELD, '$1[redacted]');
 }
+/** What a file about the run may hold: `redact`, and nothing shaped like a secret, which the text of a call the fence refused would otherwise leave there. `field` names the field the text is the value of, when it has one. */
+export function scrub(text, secrets = [], field) {
+    return redactShapes(redact(text, secrets), field);
+}
 export function createLog(debug, dir = tmpdir()) {
     const secrets = new Set();
     const secret = (value) => void secrets.add(value);
@@ -33,7 +38,7 @@ export function createLog(debug, dir = tmpdir()) {
         write(message, data) {
             const detail = data === undefined ? '' : ` ${typeof data === 'string' ? data : JSON.stringify(data)}`;
             try {
-                appendFileSync(path, `${redact(`${new Date().toISOString()} ${message}${detail}`, secrets)}\n`, { mode: 0o600 });
+                appendFileSync(path, `${scrub(`${new Date().toISOString()} ${message}${detail}`, secrets)}\n`, { mode: 0o600 });
             }
             catch {
                 // A debug log that cannot be written is not worth stopping the run for.

package/dist/login.js

@@ -47,12 +47,14 @@ function waitingPage(res, state) {
     page(res, 200, 'Signed in. One moment…', `<noscript><p><a href="/go?state=${escapeHtml(encodeURIComponent(state))}">Go on to the progress page</a></p></noscript>${script}`);
 }
 /**
- * Listens on the first free port of `ports` for `/callback?code=&state=`. A
- * wrong state gets a 400 and the wait goes on; the right one hands over the
- * code and answers at once with a page that asks `/next` where to go, which
- * says "not yet" until `land` knows (a JSON `wait`), then the page or what
- * went wrong. `/go` is the same for a tab without scripts: a redirect, or
- * the waiting page again.
+ * Listens on the first free port of `ports` for `/callback?code=&state=`, on
+ * both loopback addresses: a browser takes `localhost` for either, so a port
+ * another process holds on one of them is taken, and no other process hears
+ * the callback. A wrong state gets a 400 and the wait goes on; the right one
+ * hands over the code and answers at once with a page that asks `/next` where
+ * to go, which says "not yet" until `land` knows (a JSON `wait`), then the
+ * page or what went wrong. `/go` is the same for a tab without scripts: a
+ * redirect, or the waiting page again.
  */
 export async function startCallbackServer(state, ports = CALLBACK_PORTS) {
     let resolve;
@@ -66,7 +68,7 @@ export async function startCallbackServer(state, ports = CALLBACK_PORTS) {
     let landing;
     let heard = () => { };
     const told = new Promise((r) => (heard = r)).finally(() => untold.delete(told));
-    const server = createServer((req, res) => {
+    const answer = (req, res) => {
         const url = new URL(req.url ?? '/', 'http://localhost');
         const route = req.method === 'GET' ? url.pathname : '';
         if (!['/callback', '/next', '/go'].includes(route))
@@ -94,33 +96,59 @@ export async function startCallbackServer(state, ports = CALLBACK_PORTS) {
         visited = true;
         resolve(got);
         waitingPage(res, state);
-    });
+    };
+    /** One server for each loopback address, on the port in use. */
+    let servers = [];
     const shut = () => {
         heard();
-        server.close();
-        server.closeIdleConnections();
+        for (const server of servers) {
+            server.close();
+            server.closeIdleConnections();
+        }
     };
     let closing = false;
     const shutLater = () => void setTimeout(shut, LANDED_MS).unref();
+    /** A server on one loopback address: false when the port is taken there, null when this machine has no IPv6 loopback, where no other process listens either. */
+    const listen = (address, port) => new Promise((done, fail) => {
+        const server = createServer(answer);
+        const onError = (err) => {
+            if (err.code === 'EADDRINUSE' || err.code === 'EACCES')
+                done(false);
+            else if (address === '::1' && (err.code === 'EADDRNOTAVAIL' || err.code === 'EAFNOSUPPORT'))
+                done(null);
+            else
+                fail(err);
+        };
+        server.once('error', onError);
+        server.listen(port, address, () => {
+            server.off('error', onError);
+            done(server);
+        });
+    });
     for (const port of ports) {
-        const listening = await new Promise((done, fail) => {
-            const onError = (err) => (err.code === 'EADDRINUSE' || err.code === 'EACCES' ? done(false) : fail(err));
-            server.once('error', onError);
-            server.listen(port, '127.0.0.1', () => {
-                server.off('error', onError);
-                done(true);
-            });
+        const v4 = await listen('127.0.0.1', port);
+        if (!v4)
+            continue;
+        const actual = v4.address().port;
+        // The port is let go on IPv4 whenever IPv6 does not follow: taken there, or failing for a reason of its own, which stops the sign-in.
+        const v6 = await listen('::1', actual).catch((err) => {
+            v4.close();
+            throw err;
         });
-        if (!listening)
+        if (v6 === false) {
+            v4.close();
             continue;
-        const actual = server.address().port;
+        }
+        servers = v6 ? [v4, v6] : [v4];
         return {
             redirectUri: `http://localhost:${actual}/callback`,
+            addresses: v6 ? ['127.0.0.1', '::1'] : ['127.0.0.1'],
             code,
             land: (next) => void next.then((url) => void (landing ??= { page: url }), (err) => void (landing ??= { error: err instanceof UserError ? err.message : 'Sign-in did not finish. Back to your terminal.' })).then(() => closing && shutLater()),
             close: () => {
                 // The tab asks again every half second; it is never a reason for the command to stay.
-                server.unref();
+                for (const server of servers)
+                    server.unref();
                 if (!visited)
                     return shut();
                 // It stops a while after the tab has somewhere to go, however long that takes to know.
@@ -229,7 +257,7 @@ export async function signIn(host, repo, log, prompt, check = (t) => t, landing
     const server = await startCallbackServer(state);
     const authorize = new URL(`${host}/app/cli/authorize`);
     authorize.search = new URLSearchParams({ redirect_uri: server.redirectUri, state, code_challenge: challenge, code_challenge_method: 'S256', repo }).toString();
-    log.write(`callback server at ${server.redirectUri}`);
+    log.write(`callback server at ${server.redirectUri}`, `on ${server.addresses.join(' and ')}`);
     prompt.show(authorize.href);
     openBrowser(authorize.href);
     let stopPaste = () => { };

package/dist/main.js

@@ -15,8 +15,10 @@ import { startSandbox } from './sandbox.js';
 import { scanRecorder } from './scan.js';
 import { createReporter, reportingOff } from './report.js';
 import { createSessionSync, syncExtension } from './sync.js';
+import { checkPushAccess, readPushAccess } from './push-access.js';
 import { createTools, resultLine } from './tools.js';
 import { transcriptPaths } from './transcript.js';
+import { askPerson } from './ui/bridge.js';
 import { atExit, closeScreens, helpMark, onScreenExit, recordFrames, showIntro, showOutro, showPullRequest, showRun, showSignIn } from './ui/screens.js';
 const say = (line = '') => console.log(line);
 const execFileAsync = promisify(execFile);
@@ -126,7 +128,7 @@ export async function main(argv) {
             }
             return t;
         };
-        const token = await signIn(flags.host, slug, log, screenPrompt(showSignIn), accept, () => landing);
+        const token = await signIn(flags.host, slug, log, screenPrompt((link, on) => showSignIn(link, { ...on, checkout: { repository: slug, folder: checkout.root } })), accept, () => landing);
         const setupApi = token.setup_api.replace(/\/$/, '');
         const cliApi = token.cli_api.replace(/\/$/, '');
         // Signed in: what the command held goes now, on the person who approved.
@@ -189,6 +191,17 @@ export async function main(argv) {
             const setupPage = state.data.account?.setupPage;
             await nothingToSetUp(liveSync, reporter, 'skipped_repo', 'Repository skipped', SKIPPED, [...(typeof setupPage === 'string' && onHost(setupPage) ? [{ label: 'Setup page', url: setupPage }] : []), webPage]);
         }
+        // The setup pushes as the person, so whether git may push is asked of GitHub now, before anything is created.
+        const push = await checkPushAccess(slug, () => readPushAccess(checkout.root), async (screen) => {
+            liveSync.update({ phase: 'waiting', question: { id: screen.id, prompt: screen.prompt } });
+            const answer = await askPerson({ ...screen, skippable: true });
+            liveSync.update({ phase: 'running', question: null });
+            return answer;
+        });
+        log.write('push access', push.outcome);
+        if (push.outcome === 'refused' || push.outcome === 'signed-out') {
+            await nothingToSetUp(liveSync, reporter, 'stopped', "Git can't push", `Git can't push to ${slug}${push.account ? ` as ${push.account}` : ''}, so nothing was set up. Sign git in as an account that can, then run this again.`, [webPage]);
+        }
         if (!interactive)
             say('Signed in.\n');
         // Beside the transcript, named after the run as it is, so a run never writes over another's in the temp folder.
@@ -272,6 +285,7 @@ export async function main(argv) {
                 log,
                 previewWait: previewWait(),
                 sandbox,
+                pushAccess: push.outcome,
             }),
             extensions: [
                 fenceExtension(checkout.root, log, checkout.protectedBranches, scratch, scans),

package/dist/netlify-password.js

@@ -7,7 +7,8 @@
  * no password goes back to the model. The person consents once, on the tool's screen, before the password is stored;
  * a password opens the locked address before anything saves it. A password Netlify does not give back is the
  * person's to type: setting one through the CLI would put it on the command line, where any process could read it.
- * Netlify's team login (a private site, or team login protection) has no way in for tools, and is reported as such.
+ * Netlify's team login (a private site) has no way in for tools, so on the person's yes the run makes the site public
+ * through the CLI; where Netlify refuses, the person changes Visitor access on Netlify's page and the run tries again.
  */
 /** The header reviews send the password in. */
 export const PASSWORD_HEADER = 'Authorization';
@@ -15,6 +16,13 @@ export const PASSWORD_HEADER = 'Authorization';
 export const basicCredentials = (password) => `Basic ${Buffer.from(`:${password}`).toString('base64')}`;
 /** The CLI's read of a site by the address every deploy preview of it carries (`site_id` takes the site's default domain), an authenticated call of Netlify's API. */
 export const readSiteCall = (site) => ['api', 'getSite', '--data', JSON.stringify({ site_id: `${site}.netlify.app` })];
+/**
+ * The CLI's change of a site's visitor access to Public: the team login off. `updateSite` documents no such field, but
+ * `getSite` reads it back and Netlify's own tools send it; `sso_login_context` stays out, since Netlify answers 422 with it.
+ */
+export const publicSiteCall = (id) => ['api', 'updateSite', '--data', JSON.stringify({ site_id: id, body: { sso_login: false } })];
+/** Netlify's page where a site's Visitor access is changed. */
+export const visitorAccessPage = (site) => `https://app.netlify.com/projects/${site}/configuration/general#visitor-access`;
 const record = (value) => (value !== null && typeof value === 'object' && !Array.isArray(value) ? value : undefined);
 /** A site's name and id as Netlify makes them. */
 const NAME = /^[a-z0-9](?:[a-z0-9-]{0,61}[a-z0-9])?$/;
@@ -38,11 +46,19 @@ export async function readSite(run, site) {
 /**
  * Gets the site password in place for the address Netlify's lock stands in front of, and saves only one that opens it.
  * The site's settings say what the lock is: a password, which the person's yes has the run store when Netlify gives it
- * back; the team login, which no tool gets past; or neither. When the CLI cannot read the site, or Netlify gives no
- * password back, the person may paste the password.
+ * back; the team login, which the person's yes has the run lift by making the site public; or neither. When the CLI
+ * cannot read the site, or Netlify gives no password back, the person may paste the password.
  */
 export async function passNetlifyLock(deps) {
-    const site = await readSite(deps.run, deps.site);
+    let site = await readSite(deps.run, deps.site);
+    // The team login, as the site's settings or the address show it: the CLI may be signed out, or the site another team's, or the login the team's own. The person is asked the same one question.
+    if (!site?.hasPassword && (site?.teamLogin || deps.teamLogin)) {
+        const opened = await openToVisitors(deps, site);
+        if ('status' in opened)
+            return opened;
+        // The person picked Password protected on Netlify's page: the password is got in place as any site password is.
+        site = opened;
+    }
     const from = site ? { site: site.name } : {};
     const finish = async (password, how) => {
         deps.remember(password);
@@ -73,9 +89,6 @@ export async function passNetlifyLock(deps) {
             return { status: 'refused', reason: done.locked ? "Netlify's own site password opened the address neither in the header nor on Netlify's form: the page asks for the app's own sign-in past the lock, or Netlify did not answer. Prove a page a visitor opens without signing in, and call this tool again." : done.reason, protection: 'password', ...from };
         }
     }
-    else if (site.teamLogin) {
-        return { status: 'login', protection: 'team-login', reason: "Netlify's team login stands in front of the previews: they open for a member of the Netlify team signed in in their browser, and Netlify gives tools no way in.", ...from };
-    }
     else {
         return { status: 'refused', protection: 'none', reason: "Netlify's settings show neither a password nor the team login on the site: the sign-in is the app's own, so prove a page a visitor opens without signing in.", ...from };
     }
@@ -87,3 +100,48 @@ export async function passNetlifyLock(deps) {
     const done = await finish(typed, 'typed');
     return 'status' in done ? done : { status: 'refused', reason: done.locked ? `The password typed did not open the address: it is not the site's password, or the page asks for the app's own sign-in past the lock. ${done.reason}` : done.reason, ...from };
 }
+/**
+ * A site behind Netlify's team login made public on the person's yes: the CLI's change, read back, then the preview
+ * proven. Where Netlify refuses (the team's default keeps every project private, the field is not taken, the role
+ * cannot) or the preview still asks for the login, its Visitor access page opens and the person tries again, twice at
+ * most. A password the person set there instead comes back as the site, for the password's own steps.
+ */
+async function openToVisitors(deps, site) {
+    const from = { site: site?.name ?? deps.site, protection: 'team-login' };
+    if (!(await deps.makePublic()))
+        return { status: 'skipped', reason: 'The person skipped making the site public.', ...from };
+    // A site the CLI could not read: signed in on the yes, it is read again; still unreadable, it is another team's, and Netlify's page is the person's.
+    let read = site ?? ((await deps.signIn()) ? await readSite(deps.run, deps.site) : null);
+    /** The run's change went through: the site stays public whatever comes after, and every later answer says so. */
+    let ranPublic = false;
+    const kept = () => (ranPublic ? { madePublic: 'run' } : {});
+    for (let tries = 0;; tries++) {
+        if (read?.teamLogin && !read.hasPassword) {
+            try {
+                await deps.run(publicSiteCall(read.id));
+                read = await readSite(deps.run, deps.site);
+                if (read && !read.teamLogin)
+                    ranPublic = true;
+            }
+            catch {
+                // Refused: the site as read stays, and the person's page is next.
+            }
+        }
+        if (read?.hasPassword)
+            return read;
+        // A site read as public, or one the CLI cannot read once the person changed it on Netlify's page: the preview says.
+        if (read ? !read.teamLogin : tries > 0) {
+            const proof = await deps.prove(undefined, false);
+            if (proof.proven)
+                return { status: 'opened', madePublic: ranPublic ? 'run' : 'person', ...from };
+            // Past the login, a page that is not the app's: the proof says why.
+            if (proof.gate === undefined)
+                return { status: 'refused', reason: proof.reason ?? 'The address did not open.', site: from.site, protection: 'none', ...kept() };
+        }
+        if (tries === 2)
+            return { status: 'login', reason: "Netlify kept its team login in front of the previews.", ...from, ...kept() };
+        if (!(await deps.retry(visitorAccessPage(from.site), tries === 0)))
+            return { status: 'skipped', reason: "The person skipped changing Visitor access on Netlify's page.", ...from, ...kept() };
+        read = await readSite(deps.run, deps.site);
+    }
+}

package/dist/playbook/cases/netlify-previews.md

@@ -9,9 +9,10 @@ Netlify deploys previews of the pull requests: impeccable_netlify_previews lists
 
 ### Reference
 
-- **Behind a password or Netlify's login** (`gate: "netlify-protection"`): the site password, or Netlify's team login, stands in front of the previews. That is the preview-protection case's, whose steps come before step 2: the password is got past on the person's yes, the team login is not.
+- **The aim** holds here: the CLI does the work, and the person is asked only what the playbook's aim allows.
+- **Behind a password or Netlify's login** (`gate: "netlify-protection"`): the site password, or Netlify's team login, stands in front of the previews. That is the preview-protection case's, whose steps come before step 2: on the person's yes the password is stored, or the site behind the team login made public.
 - **Another app, or no answer from any of the three**: Netlify's previews do not show this app. Set the preview up as server-previews or static-site says instead, and say under "What is not verified" what the Netlify address answered.
 - **Nothing listed**: Netlify's previews are not on record. Where the checkout is set up for Netlify that is the netlify-setup case's; else set the preview up as server-previews or static-site says. An `error` means a read failed, so a preview may exist that is not listed: say so under "What is not verified".
 - **The pull requests**: no setup pull request; the test drive branches from the default branch. Netlify builds a deploy preview only for a pull request, so the test drive opens as a draft, its deploy preview is waited for and the test drive's page proven on it, and then the draft is marked ready: pull-requests' step 4. In place of pull-requests' step 3, build the test drive branch once with the build Netlify runs (`netlify.toml`'s `[build]` `command`, else the package's `build` script), so a page that does not build is never pushed.
-- The evidence is read only: link, deploy and change nothing on Netlify. Netlify does not report its previews as GitHub deployments, so Impeccable finds them by their address pattern: save the pattern the proof answered, and no other.
+- The evidence is read only: link, deploy and change nothing on Netlify, beyond what impeccable_netlify_password does on the person's yes. Netlify does not report its previews as GitHub deployments, so Impeccable finds them by their address pattern: save the pattern the proof answered, and no other.
 - The report names the address that answered with this app under "What we found", and the pattern saved under "What was configured, and by whom". The test drive's own preview, which Netlify builds after the run, goes under "What is not verified".

package/dist/playbook/cases/netlify-setup.md

@@ -15,10 +15,11 @@ The checkout is set up for Netlify: a `netlify.toml`, a `.netlify/` folder, or a
 
 ### Reference
 
+- **The aim** holds here: the CLI does the work, and the person is asked only what the playbook's aim allows.
 - **A step fails before the test drive is pushed** (the sign-in skipped or not completed, the site not created, the repository not connected): the Netlify setup ends there. Set the preview up as server-previews or static-site says, say under "What was skipped, and why" what stopped it, and put the person's step in `left` when there is one, such as "Give Netlify's GitHub app access to the repository", with the `access` page in the report.
 - **No preview for the draft**: save no method, set up no other preview, and leave the draft as it is, unrecorded, as pull-requests' "No preview, no test drive" says; the site and the connection stay, and the report names them.
   - **The build failed** (`state` is `error` or `failure`): say so under "What is not verified", with the command that builds this linked checkout as Netlify does and prints why, for the person to run: `netlify deploy --build --context deploy-preview`. It never runs here, since it builds with their Netlify sign-in.
-  - **No deploy preview within five minutes**: the build had not finished, or Netlify builds no deploy preview for pull requests here: Deploy Previews may be off in the site's settings, so put "Turn Deploy Previews on in the site's Netlify settings" in `left`.
-- **Behind a password or Netlify's login** (`gate: "netlify-protection"`): the preview-protection case's, whose steps come before the save in step 5. A team that keeps new sites private puts Netlify's team login in front of the new site's previews, which no tool gets past: put "Make the site public, or password-protected, in Project configuration → General → Visitor access" in `left`.
+  - **No deploy preview within five minutes**: the wait's own screen opens the site's deploy settings, where Deploy Previews are turned on, and waits again on the person's yes. When they skip it, or none came after its retries, say under "What is not verified" that Netlify built no deploy preview here, and that Deploy Previews may be off in the site's settings.
+- **Behind a password or Netlify's login** (`gate: "netlify-protection"`): the preview-protection case's, whose steps come before the save in step 5. A team that keeps new sites private puts Netlify's team login in front of the new site's previews: the tool makes the site public on the person's yes, and step 5 goes on once it answers `opened`.
 - **The report** names the Netlify site under "What was configured, and by whom", whichever way the run ended, since it stays in the person's Netlify account, with how the repository was connected and the CLI's install when there was one. The site's environment variables are the person's: when the app needs some (`.env.example`), list their names, never their values, under "Before you merge".
 - **Status lines**: the sign-in, the link and the connection belong to the Preview method task; from the page on, the Test drive task, so name the test drive in each line about its build, its push, the draft, the wait for its preview, the proof and the save (*"Saving the test drive's preview as the method"*). Word Netlify's login as a login, since a line about signing in belongs to the Sign-in task.

package/dist/playbook/cases/preview-protection.md

@@ -1,21 +1,23 @@
 ### When this applies
 
-impeccable_prove_preview answered a `gate`: the host's own lock stands in front of a preview the host made, and a visitor gets its login or its password page. Three locks have a way in for a tool, each with a tool of its own that works as the person in the command's own process, so no key ever reaches you: Vercel's Deployment Protection (`gate: "vercel-protection"`: Vercel Authentication, or Password Protection, which shows the same gate), whose way in is a bypass secret of the project, sent in a header, which every plan has; Netlify's site password (`gate: "netlify-protection"`), sent as basic credentials in the Authorization header; and Cloudflare Access in front of a Pages preview (`gate: "cloudflare-access"`), whose way in is a service token that a Service Auth policy of the Access application allows, sent in two headers. Netlify's team login, which the same gate answers for, has none. A project the Vercel CLI creates starts protected, so vercel-setup's new project ends here as well, and so does netlify-setup's new site on a team that keeps new sites private: these steps come between the proof and the save of the method, in vercel-previews', netlify-previews' or cloudflare-previews' step 2 or vercel-setup's or netlify-setup's step 5, before the test drive's pull request opens (on Netlify, before its draft is marked ready), and end with the preview opened.
+impeccable_prove_preview answered a `gate`: the host's own lock stands in front of a preview the host made, and a visitor gets its login or its password page. Three locks have a way in for a tool, each with a tool of its own that works as the person in the command's own process, so no key ever reaches you: Vercel's Deployment Protection (`gate: "vercel-protection"`: Vercel Authentication, or Password Protection, which shows the same gate), whose way in is a bypass secret of the project, sent in a header, which every plan has; Netlify's site password (`gate: "netlify-protection"`), sent as basic credentials in the Authorization header; and Cloudflare Access in front of a Pages preview (`gate: "cloudflare-access"`), whose way in is a service token that a Service Auth policy of the Access application allows, sent in two headers. Netlify's team login, which the same gate answers for, has none, so the tool makes the site public on the person's yes. A project the Vercel CLI creates starts protected, so vercel-setup's new project ends here as well, and so does netlify-setup's new site on a team that keeps new sites private: these steps come between the proof and the save of the method, in vercel-previews', netlify-previews' or cloudflare-previews' step 2 or vercel-setup's or netlify-setup's step 5, before the test drive's pull request opens (on Netlify, before its draft is marked ready), and end with the preview opened.
 
 ### Steps
 
-1. **Get the key in place** (the Preview method task): impeccable_vercel_bypass for Vercel's login, under the status line *"Getting past Vercel's login"*; impeccable_netlify_password for Netlify's lock, under *"Getting past Netlify's password"*; impeccable_cloudflare_access for Cloudflare Access, under *"Getting past Cloudflare Access"*. The tool does the rest: it finds the project's secret labelled "Impeccable reviews", or reads what Netlify's settings say stands in front of the site; shows one screen asking to create the secret, to store the site password Netlify gives back, or to create a service token (then Cloudflare's sign-in in the browser where cf here lacks it, and it creates the token as the person and allows it in the Access application's policy; a screen takes a Cloudflare API token only where that sign-in cannot), or, when it cannot make or read one, one screen taking a pasted one; opens the preview with it; and saves it for reviews. The key never comes back to you. Done when it answered `status`:
+1. **Get the key in place** (the Preview method task): impeccable_vercel_bypass for Vercel's login, under the status line *"Getting past Vercel's login"*; impeccable_netlify_password for Netlify's lock, under *"Getting past Netlify's password"*; impeccable_cloudflare_access for Cloudflare Access, under *"Getting past Cloudflare Access"*. The tool does the rest: it finds the project's secret labelled "Impeccable reviews", or reads what Netlify's settings say stands in front of the site; shows one screen asking to create the secret, to store the site password Netlify gives back, to make a site behind Netlify's team login public (signing the Netlify CLI in, in the browser, on that yes where it is signed out; where Netlify refuses, it opens Netlify's Visitor access page and asks the person to try again once they changed it there), or to create a service token (then Cloudflare's sign-in in the browser where cf here lacks it, and it creates the token as the person and allows it in the Access application's policy; a screen takes a Cloudflare API token only where that sign-in cannot), or, when it cannot make or read one, one screen taking a pasted one (Vercel's with the page where it is made opened); opens the preview with it; and saves it for reviews. The key never comes back to you. Done when it answered `status`:
    - `saved`: the preview is proven (`proven: true`); `secret`, `password` or `token` says whether it was created, existing or typed, and `project`, `site` or `application` which one holds or allows it; Cloudflare's `pattern` is the address pattern to save with the method, and `apiToken` says a Cloudflare API token the person made created the token. Step 2.
-   - `login` (Netlify): the site is behind Netlify's team login, which no tool gets past; `reason` says so. Step 3.
+   - `opened` (Netlify): the site is public now and the preview proven (`proven: true`); `madePublic` says whether the run or the person made it public, and `site` which site. Step 2.
+   - `login` (Netlify): Netlify kept its team login in front through the retries; `reason` says so. Step 3.
+   - Any answer with `madePublic` but `opened`: the run made the Netlify site public and it stays so, though the preview did not open; the report names that change as the bullet below says, whatever step comes next.
    - `refused` whose `reason` says to prove a page a visitor opens: Netlify's own site password opened neither the header nor Netlify's form, so the page you proved asks for the app's own sign-in past the lock, or Netlify did not answer. Prove a page a visitor opens without signing in, as netlify-previews' step 1 says, and call the tool again; the consent is not asked a second time. Refused again, step 3.
    - Any other `skipped` or `refused`: nothing was saved; `reason` says what stopped it. Step 3.
    - `save-failed`: the setup API did not take it all; `reason` says how far it got. Call the tool once more; when it fails again, step 3, with "Save the Vercel bypass secret on the setup page", "Save the Netlify site password on the setup page" or "Save the Cloudflare service token on the setup page" in `left`.
 2. **Check it from Impeccable's side**: impeccable_write to `connection-check` with `{"appKey": "main"}`, and report what it answered. Then go on with the case that sent you here: the proof stands, so save the method as vercel-previews', netlify-previews' or cloudflare-previews' step 2 says, Cloudflare's with the tool's `pattern`. Done when the method is saved.
-3. **When nothing was saved**, save no method and set up no other preview, whatever the checkup's `next` says, and open no test drive (pull-requests' "No preview, no test drive"). Say under "What is not verified" that the previews are behind the host's lock, with the tool's `reason`, and name the settings page where the person makes the key (the report's bullet below); end the report's "Not part of this setup" line with the lock the tool met: "Vercel's Deployment Protection in front of the previews", "Netlify's password in front of the previews", "Netlify's team login in front of the previews", or "Cloudflare Access in front of the previews". Done when the report says so.
+3. **When nothing was saved**, save no method and set up no other preview, whatever the checkup's `next` says, and open no test drive (pull-requests' "No preview, no test drive"). Say under "What is not verified" that the previews are behind the host's lock, with the tool's `reason`, and name the settings page where the person makes the key, or makes the Netlify site public (the report's bullet below); put the person's one step in `left`, the settings action alone and never running the setup again (for Netlify's team login, none: the person was asked in this run, so `left` stays empty and the report names the Visitor access page); end the report's "Not part of this setup" line with the lock the tool met: "Vercel's Deployment Protection in front of the previews", "Netlify's password in front of the previews", "Netlify's team login in front of the previews", or "Cloudflare Access in front of the previews". Done when the report says so.
 
 ### Reference
 
-- **The report** names, under "What was configured, and by whom", the Vercel project that holds the secret named "Impeccable reviews" (`project`), whether this run created it, found it there or the person typed it, and where it is revoked: the project's Settings → Deployment Protection → Protection Bypass for Automation; or the Netlify site (`site`) whose password is stored, whether this run read it from the site or the person typed it, and where it is changed: the site's Project configuration → General → Visitor access; or the service token named "Impeccable reviews", whether this run created it or the person typed it, the Access application whose policy allows it (`application`), when a created one runs out (`expires`), and where it is revoked: Zero Trust → Access controls → Service credentials → Service Tokens; with `apiToken`, the Cloudflare API token the person made for the run is theirs to delete (dash.cloudflare.com/profile/api-tokens). Revoking, regenerating or changing it stops reviews until this setup is run again.
+- **The report** names, under "What was configured, and by whom", the Vercel project that holds the secret named "Impeccable reviews" (`project`), whether this run created it, found it there or the person typed it, and where it is revoked: the project's Settings → Deployment Protection → Protection Bypass for Automation; or the Netlify site (`site`) whose password is stored, whether this run read it from the site or the person typed it, and where it is changed: the site's Project configuration → General → Visitor access; or, with `opened`, the Netlify site made public, by this run on the person's yes or by the person on Netlify's page (`madePublic`), so anyone with its address opens it, and where it is made private again: the same Visitor access; or the service token named "Impeccable reviews", whether this run created it or the person typed it, the Access application whose policy allows it (`application`), when a created one runs out (`expires`), and where it is revoked: Zero Trust → Access controls → Service credentials → Service Tokens; with `apiToken`, the Cloudflare API token the person made for the run is theirs to delete (dash.cloudflare.com/profile/api-tokens). Revoking, regenerating or changing it stops reviews until a new one is saved on the setup page.
 - **The tool does the writes**: the key as Impeccable's credential for the lock, and the setting that sends it in the host's header (`x-vercel-protection-bypass`, `Authorization`, or `CF-Access-Client-Id` and `CF-Access-Client-Secret`), both through the setup API, so impeccable_write refuses those two. The state's `preview-protection` item words the same calls, and shows `keySaved` once they are done.
 - **A key saved before** (the item shows `keySaved` and a `check` that `passed`): the lock was handled by an earlier run or the person. Run step 2's check and go on; call the tool only when that check fails.
 - **The key is never yours**: it goes from the command's own process to the host and to Impeccable, and into no message, status line, file, command or report. `vercel project protection`, `vercel api`, `vercel curl` and `netlify api` print it, and the fence refuses them.