@impeccable/reviews 0.1.17 → 0.1.18

package/README.md

@@ -15,7 +15,7 @@ npx @impeccable/reviews
 
 `npm install -g @impeccable/reviews` puts the `impeccable-reviews` command on your PATH instead.
 
-Your browser opens Impeccable's consent page; after Approve it goes on to the run's web page. Keep that tab open: it shows the task list, a question waiting for you, the pull requests and, at the end, the report and the review. The terminal takes over its window while it works, one screen at a time in the same frame (the start; the sign-in, its link copied to the clipboard when you press C; understanding your app; a question when it needs you; the tasks; the test drive, then the setup pull request, each opened in your browser and copied to the clipboard as its screen appears), and gives it back with a short summary: the outcome, the test drive, the setup pull request, the web page and what is left for you. What the agent writes there (its status lines, the tasks, its questions, what is left and the report) shows as plain text: an escape sequence that would have the terminal write the clipboard, retitle the window, link words to another address or clear the screen is taken out, and the agent's status line or line of what is left that holds one is refused.
+Your browser opens Impeccable's consent page; after Approve it goes on to the run's web page. Keep that tab open: it shows the task list, a question waiting for you, the pull requests and, at the end, the report and the review. The terminal takes over its window while it works, one screen at a time in the same frame (the start; the sign-in, its link copied to the clipboard when you press C; understanding your app; a question when it needs you; the tasks; the test drive, then the setup pull request, each opened in your browser and copied to the clipboard as its screen appears), and gives it back with a short summary: the outcome, the account or team and the project or site it used on each host whose preview it opened, the test drive, the setup pull request, the web page and what is left for you. What the agent writes there (its status lines, the tasks, its questions, what is left and the report) shows as plain text: an escape sequence that would have the terminal write the clipboard, retitle the window, link words to another address or clear the screen is taken out, and the agent's status line or line of what is left that holds one is refused.
 
 Keys: Enter goes on, Esc cancels the intro or the sign-in and skips a question (every question can be skipped); on the run screen, Esc twice (or Ctrl+C) stops the run. A screen taller than the terminal scrolls with ↑↓ and PgUp PgDn (↑↓ still move among a question's choices). The screens are black and white, with emphasis by intensity: greys on a terminal that takes true colour and reports its background, bold and dim elsewhere, and under `NO_COLOR`. The mark at the top is the logo's own image in a terminal that shows images (iTerm2, kitty, Ghostty, WezTerm; never under tmux), a square with its slash beside the letter-spaced wordmark elsewhere, and plain text on a dumb terminal.
 

package/dist/cloudflare-access.js

@@ -104,9 +104,9 @@ const granted = (s) => s.cli === 'signed-in' && (!s.scopes || ACCESS_SCOPES.ever
  * a retry, and two failed retries end it. The new sign-in asks for the scopes it held as well, so whatever else the
  * person uses cf for goes on working.
  */
-async function reach(deps) {
+async function reach(deps, read) {
     const through = (s) => ({ way: throughCf(deps.cf, s.accounts, deps.signal) });
-    let status = await cfStatus(deps.cf, deps.signal);
+    let status = read;
     if (granted(status))
         return through(status);
     if (status.cli === 'missing' || status.cli === 'unknown')
@@ -196,6 +196,8 @@ async function covering(way, url) {
         return unread ? stop(way, unread, '') : { reason: `No Access application ${way.who} reaches covers ${url.host}.` };
     return { apps };
 }
+/** Why no token is made where several applications cover the address. */
+const unclear = (count, host) => `${count} Access applications cover ${host}, so which one's policy should allow the token is not clear.`;
 /**
  * As the person, the way they reach Cloudflare's API: on the one application in front of the address, the service
  * token, then a Service Auth policy that allows it. An application on reusable policies (every one the dashboard makes
@@ -208,7 +210,7 @@ async function create(way, deps, found) {
     const api = way.call;
     const url = new URL(deps.url);
     if (found.length > 1)
-        return { reason: `${found.length} Access applications cover ${url.host}, so which one's policy should allow the token is not clear.` };
+        return { reason: unclear(found.length, url.host) };
     const { account, app } = found[0];
     const base = `/accounts/${account}/access`;
     let links = list(app.policies).flatMap((p, i) => (uid(p.id) ? [{ id: p.id, precedence: typeof p.precedence === 'number' ? p.precedence : i + 1 }] : []));
@@ -313,10 +315,6 @@ export async function passCloudflareAccess(deps) {
         covered ||= 'apps' in found;
         return found;
     };
-    const build = async (way) => {
-        const found = await find(way);
-        return 'apps' in found ? create(way, deps, found.apps) : found;
-    };
     /** A token that opened the address, saved for reviews. */
     const keep = async (token, how, made = {}) => {
         const failed = await deps.save(token);
@@ -325,16 +323,37 @@ export async function passCloudflareAccess(deps) {
     /** Why the run's own way ended without a token that opens the address, for the paste screen's skip, and how to make one by hand there. */
     let stopped;
     let manual;
-    if (!(await deps.consent())) {
-        stopped = 'The person skipped creating a service token.';
-        // cf signed in here, with whatever scopes, says whether an application of the person's covers the address, since reading takes no write; a skip opens no sign-in for it.
-        const status = await cfStatus(deps.cf, deps.signal);
-        if (status.cli === 'signed-in')
-            await find(throughCf(deps.cf, status.accounts, deps.signal));
-    }
+    // cf signed in here, with whatever scopes, reads the Access application in front of the address before anything is asked, since reading takes no write
+    // (#357): none covering it asks nothing, and the consent names the one that does. Signed out, or refused the read, the consent comes first, as its yes opens
+    // the sign-in or the API token screen that finding it takes.
+    const status = await cfStatus(deps.cf, deps.signal);
+    const reads = status.cli === 'signed-in' && (!status.scopes || status.scopes.some((scope) => /^access\.(read|write)$/.test(scope)));
+    const early = reads ? await find(throughCf(deps.cf, status.accounts, deps.signal)) : undefined;
+    const apps = early && 'apps' in early ? early.apps : undefined;
+    const named = apps?.length === 1 ? apps[0] : undefined;
+    /** An application as the consent names it. */
+    const described = ({ account, app }) => ({ id: String(app.id), application: typeof app.name === 'string' && app.name ? app.name : url.host, account });
+    const SKIPPED = 'The person skipped creating a service token.';
+    if (early && 'reason' in early)
+        stopped = early.reason;
+    else if (apps && apps.length > 1)
+        stopped = unclear(apps.length, url.host);
+    else if (!(await deps.consent(named && described(named))))
+        stopped = SKIPPED;
     else {
-        const reached = await reach(deps);
-        let made = 'way' in reached ? await build(reached.way) : 'stopped' in reached ? { reason: reached.stopped } : reached;
+        /** Read anew, by a new sign-in or the API token: an application other than the one the yes named is asked about before anything is made on it. */
+        const rebuild = async (way) => {
+            const found = await find(way);
+            if (!('apps' in found))
+                return found;
+            const target = found.apps.length === 1 ? found.apps[0] : undefined;
+            if (named && target && (String(target.app.id) !== String(named.app.id) || target.account !== named.account) && !(await deps.consent(described(target))))
+                return { reason: SKIPPED };
+            return create(way, deps, found.apps);
+        };
+        const reached = await reach(deps, status);
+        // The sign-in that read the applications makes the token on the one it found, or answers the same refusal, without reading them again; a new sign-in reads its accounts.
+        let made = 'way' in reached ? (early && granted(status) ? ('apps' in early ? await create(reached.way, deps, early.apps) : early) : await rebuild(reached.way)) : 'stopped' in reached ? { reason: reached.stopped } : reached;
         let apiToken = false;
         if ('fallback' in made) {
             // Where cf's sign-in cannot make the token, an API token the person makes for the run can.
@@ -344,7 +363,7 @@ export async function passCloudflareAccess(deps) {
             else {
                 deps.remember(key);
                 apiToken = true;
-                made = await build(withApiToken(key, deps));
+                made = await rebuild(withApiToken(key, deps));
             }
         }
         if (!('token' in made)) {

package/dist/cloudflare.js

@@ -306,8 +306,9 @@ export async function cfStatus(cf, signal) {
     if (status?.authenticated !== true)
         return { cli: 'unknown', accounts: [] };
     const scopes = Array.isArray(status.scopes) ? status.scopes.filter((s) => typeof s === 'string') : undefined;
-    const accounts = list(status.accounts).map((a) => a.id).filter((id) => typeof id === 'string' && /^[0-9a-f]{32}$/.test(id));
-    return { cli: 'signed-in', ...(scopes ? { scopes } : {}), accounts };
+    const listed = list(status.accounts).filter((a) => typeof a.id === 'string' && /^[0-9a-f]{32}$/.test(a.id));
+    const names = Object.fromEntries(listed.flatMap((a) => (typeof a.name === 'string' && a.name && a.name.length <= 100 ? [[a.id, a.name]] : [])));
+    return { cli: 'signed-in', ...(scopes ? { scopes } : {}), accounts: listed.map((a) => a.id), ...(Object.keys(names).length ? { names } : {}) };
 }
 /** What a Pages deployment's latest stage says of its build: success once it deployed, and building until a stage failed or it was cancelled or skipped. */
 const stageState = (stage) => stage?.status === 'failure' ? 'failure' : stage?.status === 'canceled' || stage?.status === 'skipped' ? 'canceled' : stage?.status === 'success' && stage.name === 'deploy' ? 'success' : 'building';
@@ -322,7 +323,7 @@ const PAGES = 4;
  * built from another repository is not this one's.
  */
 async function fromCf(named, cf, repository, settings, signal) {
-    const { cli, scopes, accounts } = await cfStatus(cf, signal);
+    const { cli, scopes, accounts, names } = await cfStatus(cf, signal);
     const pages = !scopes || scopes.includes('pages:read') || scopes.includes('pages:write');
     if (cli !== 'signed-in' || !pages)
         return { cli, rows: [], failed: cli === 'unknown' };
@@ -361,7 +362,8 @@ async function fromCf(named, cf, repository, settings, signal) {
             subdomain = typeof ours.project.subdomain === 'string' && new RegExp(`^${LABEL}\\.pages\\.dev$`).test(ours.project.subdomain) ? ours.project.subdomain : undefined;
         }
     }
-    const settled = { ...(pullRequestPreviews ? { pullRequestPreviews } : {}), ...(account ? { account } : {}), ...(subdomain ? { subdomain } : {}) };
+    const accountName = account ? names?.[account] : undefined;
+    const settled = { ...(pullRequestPreviews ? { pullRequestPreviews } : {}), ...(account ? { account } : {}), ...(accountName ? { accountName } : {}), ...(subdomain ? { subdomain } : {}) };
     if (!project)
         return { cli, rows: [], failed: false, ...settled };
     const ours = (d) => {
@@ -450,6 +452,9 @@ export async function readCloudflarePreviews(owner, repo, cwd, deps = {}) {
         : cf.cli !== 'signed-in' ? `Which Cloudflare Pages project builds ${where} cannot be told: cf here is not signed in with Pages access, and only a project's settings name the folder it builds (its root directory).`
             : (cf.matching?.length ?? 0) > 1 ? `Several Cloudflare Pages projects build ${where} (${cf.matching.join(', ')}), so which one is this app's cannot be told.`
                 : !cf.project ? `No Cloudflare Pages project of this repository builds ${where} (its root directory), as far as cf here can see.` : undefined;
+    // The name of the account the project was found in goes to the last screen alone, never into the evidence (#360).
+    if (cf.accountName && !unmatched)
+        deps.onAccountName?.(cf.accountName);
     if (unmatched)
         github.previews = [];
     // A preview's address names the project's own host, which a taken name suffixes (crewline-x1y.pages.dev), not always its name.

package/dist/host-questions.js

@@ -81,6 +81,10 @@ const previewsOff = (id, name, where) => ({
         skipLabel: 'Skip',
     },
 });
+/** The consent to a Vercel bypass secret, saying whose previews Vercel's login keeps and where the secret is revoked. */
+const bypassHint = (whose, where) => `Impeccable reviews each pull request on its preview,\nand Vercel keeps ${whose} behind a login.\n\nVercel's way in for a tool like Impeccable is via a bypass secret. It is stored encrypted, used only to open previews and you can revoke it any time in ${where} Settings → Deployment Protection.`;
+/** The consent to a Cloudflare service token, saying which Access application keeps whose previews, and whose policy allows the token. */
+const accessHint = (keeps, policy) => `Impeccable reviews each pull request on its preview, and ${keeps} behind a login.\n\nCloudflare's way in for tools is a service token made for one tool: with your Cloudflare sign-in, the run creates one named "Impeccable reviews" and allows it in ${policy} policy. It is stored encrypted, used only to open previews, and you can revoke it any time in Zero Trust → Access controls → Service credentials.`;
 /** The screens a tool shows on its own: a sign-in's retry, the one-time access the host's GitHub app needs, the consent to turning a host's pull-request previews on, 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' },
@@ -138,7 +142,7 @@ export const HOST_SCREENS = {
         id: 'vercel-bypass',
         kind: 'confirm',
         title: 'Your Vercel previews are protected',
-        hint: 'Impeccable reviews each pull request on its preview,\nand Vercel keeps yours behind a login.\n\nVercel\'s way in for a tool like Impeccable is via a bypass secret. It is stored encrypted, used only to open previews and you can revoke it any time in the project\'s Settings → Deployment Protection.',
+        hint: bypassHint('yours', "the project's"),
         prompt: 'Create the secret for Impeccable?',
         confirmLabel: 'Create',
         skipLabel: 'Skip',
@@ -193,7 +197,7 @@ export const HOST_SCREENS = {
         id: 'cloudflare-access',
         kind: 'confirm',
         title: 'Your Cloudflare previews are protected',
-        hint: 'Impeccable reviews each pull request on its preview, and Cloudflare Access keeps yours behind a login.\n\nCloudflare\'s way in for tools is a service token made for one tool: with your Cloudflare sign-in, the run creates one named "Impeccable reviews" and allows it in your Access application\'s policy. It is stored encrypted, used only to open previews, and you can revoke it any time in Zero Trust → Access controls → Service credentials.',
+        hint: accessHint('Cloudflare Access keeps yours', "your Access application's"),
         prompt: 'Create the token for Impeccable?',
         confirmLabel: 'Create',
         skipLabel: 'Skip',
@@ -224,6 +228,17 @@ export function sentTo(screen, url) {
     const line = `This run sends it first to ${url}, to prove it opens before anything saves it.`;
     return screen.kind === 'confirm' ? screen : { ...screen, prompt: `${screen.prompt} ${line}` };
 }
+/** The consent to a Vercel bypass secret, naming the project that holds it and, on a repository with several apps, the app whose previews it opens (#358). */
+export function vercelBypassConsent(project, app) {
+    const screen = HOST_SCREENS['vercel-bypass'];
+    if (!project)
+        return screen;
+    return { ...screen, hint: bypassHint(app ? `${app}'s previews, built by the Vercel project ${project},` : `the previews of the Vercel project ${project}`, `${project}'s`) };
+}
+/** The consent to a service token, asked once the Access application in front of the preview was found (#357): that application, its Cloudflare account, and whose previews at which host it keeps. */
+export function cloudflareAccessConsent(found, host, app) {
+    return { ...HOST_SCREENS['cloudflare-access'], hint: accessHint(`the Access application "${found.application}", in the Cloudflare account ${found.account}, keeps ${app ? `${app}'s previews` : 'yours'} (${host})`, `"${found.application}"'s`) };
+}
 /** The one consent to making the Access application's own policies reusable, which the run's way through cf needs to add the token's policy (#327): the application named. */
 export function cloudflareAccessReusable(application) {
     return {

package/dist/hosted.js

@@ -138,6 +138,24 @@ export function netlifySiteOf(url) {
     const { hostname } = new URL(url);
     return NETLIFY.exec(hostname)?.[1] ?? LIVE.netlify.exec(hostname)?.[1] ?? null;
 }
+/**
+ * The project and team a Vercel deployment's own address names, `<project>-<hash>-<team>.vercel.app` (Vercel's generated
+ * address, its hash nine letters and digits), for the last screen (#360): only where one split fits, and that split's
+ * project is `project` where a host tool named it; null otherwise, a project's own address included, and any address
+ * with `-git-` in it, which a branch's alias `<project>-git-<branch>-<team>` has, so a branch's word is never a hash.
+ */
+export function vercelDeploymentOf(url, project) {
+    if (!URL.canParse(url))
+        return null;
+    const parsed = new URL(url);
+    if (!plainHttps(parsed) || !LIVE.vercel.test(parsed.hostname) || parsed.hostname.includes('-git-'))
+        return null;
+    const parts = parsed.hostname.slice(0, -'.vercel.app'.length).split('-');
+    const splits = parts
+        .flatMap((part, i) => (i > 0 && i < parts.length - 1 && /^[a-z0-9]{9}$/.test(part) ? [{ project: parts.slice(0, i).join('-'), team: parts.slice(i + 1).join('-') }] : []))
+        .filter((split) => project === undefined || split.project === project.toLowerCase());
+    return splits.length === 1 ? splits[0] : null;
+}
 /** The address pattern a proven preview stands for, where the host reports none to GitHub: Netlify's by pull request, Cloudflare's by the branch's alias. A live address stands for none. */
 function patternOf(hostname) {
     const site = NETLIFY.exec(hostname)?.[1];
@@ -169,17 +187,56 @@ async function checkoutHolds(root, words) {
         return false;
     }
 }
-/** Whether a file the checkout tracks (in `folder`, one app's, when given) names the address's origin as such, whole (a full stop after it is the sentence's): not as the tail of a longer host name, such as a deploy preview's of the same site. */
+const escapeRegExp = (text) => text.replace(/[.*+?^${}()|[\]\\/]/g, '\\$&');
+/** The address's origin as such, whole (a full stop after it is the sentence's): not as the tail of a longer host name, such as a deploy preview's of the same site. */
+const wholeOrigin = (origin) => `(^|[^A-Za-z0-9.-])${escapeRegExp(origin)}([^A-Za-z0-9.-]|\\.([^A-Za-z0-9]|$)|$)`;
+/** Whether a file the checkout tracks (in `folder`, one app's, when given) names the address's origin, whole. */
 export async function checkoutNames(root, origin, folder = '') {
-    const escaped = origin.replace(/[.*+?^${}()|[\]\\/]/g, '\\$&');
     try {
-        await execFileAsync('git', ['grep', '--quiet', '--ignore-case', '--extended-regexp', '-e', `(^|[^A-Za-z0-9.-])${escaped}([^A-Za-z0-9.-]|\\.([^A-Za-z0-9]|$)|$)`, '--', `:(literal)${folder || '.'}`, ':(exclude,glob)**/.env*'], { cwd: root, timeout: 30_000, env: gitEnvironment() });
+        await execFileAsync('git', ['grep', '--quiet', '--ignore-case', '--extended-regexp', '-e', wholeOrigin(origin), '--', `:(literal)${folder || '.'}`, ':(exclude,glob)**/.env*'], { cwd: root, timeout: 30_000, env: gitEnvironment() });
         return true;
     }
     catch {
         return false;
     }
 }
+/** Whether a line names an app's name or folder whole, not inside a longer name, a host name or a path, such as `apps/web` in `archived/apps/web`. */
+const namesWhole = (line, words) => new RegExp(`(^|[^\\p{L}\\p{N}_./-])${escapeRegExp(words)}(?![\\p{L}\\p{N}_-]|[./][\\p{L}\\p{N}])`, 'iu').test(line);
+/**
+ * Whether a line of the checkout's root README names the address's origin, whole, beside one app, by its name or its
+ * folder, and no other app: a row of a table of the apps' live addresses, or an item of such a list (#367). The
+ * addresses on the line are left out of the match, so a host name made of an app's name names no app.
+ */
+export async function readmeNamesApp(root, origin, app, others) {
+    let lines;
+    try {
+        lines = (await execFileAsync('git', ['grep', '-h', '--ignore-case', '--extended-regexp', '-e', wholeOrigin(origin), '--', ':(glob,icase)README*'], { cwd: root, timeout: 30_000, env: gitEnvironment() })).stdout;
+    }
+    catch {
+        return false;
+    }
+    // Each name or folder with every app it belongs to, so a name two apps share names both; the longest first, each taken
+    // out once found, so "Web" inside "Web admin" is not that app named.
+    const names = new Map();
+    for (const each of [app, ...others])
+        for (const words of [each.name, each.folder])
+            if (words)
+                names.set(words.toLowerCase(), [...(names.get(words.toLowerCase()) ?? []), each]);
+    const longestFirst = [...names].sort(([x], [y]) => y.length - x.length);
+    return lines.split('\n').some((line) => {
+        // The addresses end where a table cell or a tag does; a path's parentheses, and a link's closing one, go with them.
+        let text = line.replace(/https?:\/\/[^\s|<>[\]"'`]+/gi, ' ');
+        const named = new Set();
+        for (const [words, apps] of longestFirst) {
+            if (!namesWhole(text, words))
+                continue;
+            for (const each of apps)
+                named.add(each);
+            text = text.replace(new RegExp(escapeRegExp(words), 'giu'), ' ');
+        }
+        return named.size === 1 && named.has(app);
+    });
+}
 /** What a visitor never sees of a page: comments, scripts, styles and templates. */
 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. */

package/dist/main.js

@@ -290,6 +290,7 @@ export async function main(argv) {
                         { label: 'Web page', url: page },
                     ],
                     todo: end.todo,
+                    ...(report.hosts?.length ? { used: report.hosts } : {}),
                     warnings: [...removed, ...left, ...(await unopened(Boolean(testPr))), ...(saved && !saved.ok ? [`The web page missed the last update (${saved.error}), so it may lag behind this.`] : [])],
                 }, hand);
                 // The web page has the report; when it missed it, or the run fell short of all set up, whose why it holds, the report stays here as well.

package/dist/netlify.js

@@ -145,6 +145,7 @@ async function netlifySites(netlify) {
 async function fromCli(owner, repo, netlify, only, directory) {
     const { cli } = await netlifyStatus(netlify);
     const addresses = new Map();
+    const teams = {};
     if (cli !== 'signed-in')
         return { cli, sites: [], addresses, previews: [], failed: cli === 'unknown' };
     const slug = `${owner}/${repo}`.toLowerCase();
@@ -162,6 +163,8 @@ async function fromCli(owner, repo, netlify, only, directory) {
             if (directory !== undefined && folderOf(record(site.build_settings)?.base) !== directory)
                 continue;
             sites.push(site.name);
+            if (typeof site.account_name === 'string' && site.account_name && site.account_name.length <= 100)
+                teams[site.name] = site.account_name;
             const fact = netlifyPreviewsFact(site);
             if (fact)
                 facts.push(fact);
@@ -186,7 +189,7 @@ async function fromCli(owner, repo, netlify, only, directory) {
         failed = true;
     }
     const pullRequestPreviews = pickPreviewsFact(facts);
-    return { cli: 'signed-in', sites, addresses, previews, failed, ...(pullRequestPreviews ? { pullRequestPreviews } : {}) };
+    return { cli: 'signed-in', sites, addresses, ...(Object.keys(teams).length ? { teams } : {}), previews, failed, ...(pullRequestPreviews ? { pullRequestPreviews } : {}) };
 }
 /** The site whose address `production` is: the newest preview's, else the first the evidence names. */
 export const liveSite = (evidence) => evidence.previews[0]?.site ?? evidence.sites[0];
@@ -204,7 +207,10 @@ export async function readNetlifyPreviews(owner, repo, cwd, deps = {}) {
                 : !cli.sites.length && !cli.failed ? `No Netlify site of this repository builds ${where} (its base directory), as far as the Netlify CLI here can see.` : undefined;
     const github = deps.directory === undefined ? read : { ...read, previews: unmatched ? [] : read.previews.filter((p) => cli.sites.includes(p.site)) };
     if (unmatched)
-        Object.assign(cli, { sites: [], previews: [], addresses: new Map(), pullRequestPreviews: undefined });
+        Object.assign(cli, { sites: [], previews: [], addresses: new Map(), teams: undefined, pullRequestPreviews: undefined });
+    // Each site's team goes to the last screen alone, never into the evidence (#360).
+    if (cli.teams)
+        deps.onTeams?.(cli.teams);
     // A deploy of an older commit than its pull request's head says nothing of the head's own preview: a commit status, which names the head, outranks it, and a wait for that pull request's preview ignores it.
     const older = (p) => p.from === 'netlify cli' && Boolean(p.sha) && github.heads.has(p.pullRequest) && github.heads.get(p.pullRequest) !== p.sha;
     // Of a pull request's status and the CLI's deploy of the same commit the later change is the truer, a status winning a tie; an older commit's deploy comes next, a bot's comment, which names no commit and changes no state, last.

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

@@ -11,15 +11,15 @@ Cloudflare Pages deploys previews of the pull requests: impeccable_cloudflare_pr
 
 - **The live app**: `production` in the evidence is the project's own address, `https://<project>.pages.dev`; live-app-address says how it becomes the before, in step 2's write.
 - **Behind Cloudflare Access** (`gate: "cloudflare-access"`): Cloudflare's login stands in front of the previews. Get past it as preview-protection says, which proves the preview, and go on with step 2; when nothing got past it, that case says how the run ends.
-- **Another app, or no answer from any of the three**: Cloudflare'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 Cloudflare address answered.
+- **Another app, or no answer from any of the three**: Cloudflare's previews do not show this app. Set the preview up as server-previews says instead, and say under "What is not verified" what the Cloudflare address answered.
 - **No pull-request previews**: the checkout is set up for Cloudflare and nothing is listed, or a project's settings build none. The aim holds: find out why from the answer, in this order, and for each cause ask once with the tool that fixes it, before anything is pushed and never a second time; with a preview listed, after step 1's proof and preview-protection's steps, so the person sees the lock's question and this one back to back, at most one each. Each tool shows its one screen and does the change as the person, or opens the page where it cannot. After `enabled` or `connected`, nothing is listed yet, so the test drive's build is the first preview: take pull-requests' step 4 the Cloudflare way and save the method on its alias as step 2 says, no setup pull request.
   1. **Previews off** (`pullRequestPreviews` with `enabled: false` and `cause` `previews` or `deployments`, with its `reason`): cf, signed in, found the Pages project built from this repository, and its settings build no previews of pull requests. impeccable_enable_previews (`host: "cloudflare"`) turns the preview branch control on; deployments off altogether is the person's change, on the page it opens.
   2. **Not connected** (`cause: "source"`): the Pages project the checkout names (its wrangler config, or the README's pages.dev address) exists with no Git repository connected, so no push builds. impeccable_cloudflare_connect connects it to this repository.
   3. **A Worker, not a Pages project** (`worker` in the answer, and no `pullRequestPreviews`): Cloudflare builds the repository as a Worker (Workers Builds: its check runs name the script, or the wrangler config or the README's workers.dev address does), which gives pull requests no preview, and a Worker with static assets no branch build at all. impeccable_cloudflare_connect, with the build command and output folder the checkout runs, creates a Pages project for the repository and connects it; the Worker stays as it is. The same tool creates the project where the config names a Pages project cf finds nowhere.
   4. **Cloudflare's GitHub app cannot see the repository** (`githubApp` in the answer: the app's installation covers selected repositories, or `installed: false`): a project connected with previews on still gets no build, since the app builds only the repositories its installation names. Nothing in the account shows it, so the wait for the test drive's build tells: when none comes, the wait's own screen opens the installation page (`githubApp.page`) and waits again on the person's yes. Its `reason` says when they skipped it or no build came after the retries.
-- **`skipped` or `refused` from any of these**: push no test drive on Cloudflare (pull-requests' "No preview, no test drive" where a preview was proven; else set the preview up as server-previews or static-site says, never without saying so) and say under "What was skipped, and why" which cause stopped it, with the `reason`, and name the `page` where there is one; the person was asked in this run, so `left` stays empty.
+- **`skipped` or `refused` from any of these**: push no test drive on Cloudflare (pull-requests' "No preview, no test drive" where a preview was proven; else set the preview up as server-previews says, never without saying so) and say under "What was skipped, and why" which cause stopped it, with the `reason`, and name the `page` where there is one; the person was asked in this run, so `left` stays empty.
 - **No `pullRequestPreviews`, no `worker`** (`cli` signed out or unknown, or no Pages project built from this repository among the accounts cf reaches): the check could not be made. Say so in one line under "What is not verified", naming why, and go on as the aim says: nothing listed, as "Nothing listed" says; a preview listed, as the steps say, where the wait for the test drive's build then tells.
-- **Nothing listed**, and neither `pullRequestPreviews` nor `worker` nor a project the checkout names: Cloudflare's previews are not on record, so 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".
+- **Nothing listed**, and neither `pullRequestPreviews` nor `worker` nor a project the checkout names: Cloudflare's previews are not on record, so set the preview up as server-previews 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, and Cloudflare builds every pushed branch, so pull-requests' step 4 goes the Vercel way with impeccable_cloudflare_previews in place of impeccable_hosted_previews: with `branch: "impeccable/test-drive"` it waits up to five minutes for the check run on the pushed head, under a status line with its timer, and the test drive's page is proven on the alias it lists before the pull request opens. In place of pull-requests' step 3, build the test drive branch once with the build Cloudflare runs (the Pages project's build command, which the checkout's `package.json` `build` script usually is), so a page that does not build is never pushed.
 - The evidence is read only: link, deploy and change nothing on Cloudflare beyond what impeccable_enable_previews and impeccable_cloudflare_connect do on the person's yes. The Cloudflare sign-ins are those tools' own, on the person's yes. Cloudflare does not report its previews as GitHub deployments, so Impeccable finds them by their address pattern, the branch's alias: 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 Worker, where Cloudflare builds one), and the pattern saved under "What was configured, and by whom", with the pull-request previews turned on when they were (`by` says whether the run or the person did), the Pages project created or connected (`created` says which; name its `subdomain` address) and the access given to Cloudflare's GitHub app, since the account changed. The test drive's own preview, which Cloudflare builds after the run, goes under "What is not verified".

package/dist/playbook/cases/first-preview-failure.md

@@ -22,7 +22,6 @@ A rerun: the setup pull request an earlier run opened has a preview job that fai
 | setup | `runtime` in the state; correct `runtimeVersion`. Nothing was installed yet. |
 | install | The lockfile and the package manager's pinned version. |
 | prepare, build | The script's name, the package runner and the app's folder. |
-| upload | The real build output and its entry page; correct `outputDir`. |
 | seed | The migration or seed command and the throwaway database. |
 | start | `startCommand`, `port`, `env` and readiness. |
 | tunnel | A repository already on Impeccable's tunnel: the app refusing the forwarded Host, allowed in the framework's host check for previews only (Rails `config.hosts`, Django `ALLOWED_HOSTS`, Vite `preview.allowedHosts`), not Impeccable's own access gate: a 403 on the bare link alone is not a broken preview. |

package/dist/playbook/cases/live-app-address.md

@@ -1,6 +1,6 @@
 ### When this applies
 
-Every run that saves a preview method, for the state's `before` item: the address of the live app, which every review then shows beside the change. The item reads `optional` until an address is saved, so the checkup never waits on it; the run sets it all the same, from what the host or the repository already says, and asks nobody: the host's own address of the connected project changes nothing of the person's. Where Impeccable builds the previews itself (static-site), its build of the default branch is the before and the item reads done on its own: set nothing.
+Every run that saves a preview method, for the state's `before` item: the address of the live app, which every review then shows beside the change. The item reads `optional` until an address is saved, so the checkup never waits on it; the run sets it all the same, from what the host or the repository already says, and asks nobody: the host's own address of the connected project changes nothing of the person's.
 
 ### Steps
 

package/dist/playbook/cases/monorepo.md

@@ -1,22 +1,21 @@
 ### When this applies
 
-The state's repository has an `apps` item: the scan proposed several apps, folders that each draw pages of their own, and the rest of the setup is asked only once the apps are answered. The scan proposes them, so while the scan item's `scan` is `running` the item may not be there yet: read the state again before taking the repository for one app. The person is asked once a run, this question, and nothing else about apps: **every run asks it**, however the setup page or an earlier run answered, since a run sets up the apps picked in it; as "The aim" says, it is the one question about apps. These steps come before the playbook's step 3, under the Apps task; steps 3 to 6 then go app by app.
+The state's repository has an `apps` item: the scan proposed several apps, folders that each draw pages of their own, and the rest of the setup is asked only once the apps are answered. The scan proposes them, so while the scan item's `scan` is `running` the item may not be there yet: read the state again before taking the repository for one app. The person is asked once a run, this question, and nothing else about apps: **every run asks it**, however the setup page or an earlier run answered, since a run sets up the apps picked in it; as "The aim" says, it is the one question about apps. These steps come before the playbook's step 3, under the Set up monorepo apps task; steps 3 to 6 then go app by app.
 
 ### Steps
 
 1. **Confirm the proposal** as it stands, while the item's status is `needs-you`: impeccable_write to `apps` with the `confirm` action the item's instructions give. Its answer lists every app of the repository, on and off, with its `key`, `name`, `pathPrefixes` and `enabled`; the one the scan switched on is the repository's default. An item that is `done` or `skipped` was answered before (on the setup page, or by an earlier run): no confirm, and step 2 all the same. Done when it answered `apps`, or the item was answered before.
-2. **Ask which apps this run sets up**, on every run, with impeccable_ask: `id: "apps"`, `kind: "multi"`, and the `prompt` *"Which apps should get Impeccable previews?"*. The tool words the question and lists the state's apps (the repository's own, `main`, only where the Worker kept it as a product of its own), each picked as it is on, or every one after this run's confirm. Mark the Apps task in progress first. Every write and host tool for an app is refused until it is answered. Done when it answered `values`, `named` (the command was started for that one app with `--app`, from its card on the dashboard: the tool showed one confirm screen naming that app instead of the list, and the list all the same when the person asked for other apps there), or a skip, whose `on` lists the apps that are on: the ones this run sets up. After `named`, that app is the one this run sets up: every host read, key, proof, method and check is its own, and no other app is mentioned past that screen.
+2. **Ask which apps this run sets up**, on every run, with impeccable_ask: `id: "apps"`, `kind: "multi"`, and the `prompt` *"Which apps should get Impeccable previews?"*. The tool words the question and lists the state's apps (the repository's own, `main`, only where the Worker kept it as a product of its own), each picked as it is on, or every one after this run's confirm. Mark the Set up monorepo apps task in progress first. Every write and host tool for an app is refused until it is answered. Done when it answered `values`, `named` (the command was started for that one app with `--app`, from its card on the dashboard: the tool showed one confirm screen naming that app instead of the list, and the list all the same when the person asked for other apps there), or a skip, whose `on` lists the apps that are on: the ones this run sets up. After `named`, that app is the one this run sets up: every host read, key, proof, method and check is its own, and no other app is mentioned past that screen.
 3. **Write the picks**, one action a call as the item's instructions give them: `enable` each chosen app that is off, then `disable` each app that is on and was not chosen. The last app that is on cannot be switched off (409), which is why the enables come first. **After `named`**, `enable` that app when it is off, and switch no other off. **After Skip**, write nothing more: the apps that are on stay on. Done when the last answer's `apps` show `enabled` true for every chosen app and false for the rest (after `named`, true for that app), or, after Skip, nothing was written.
 4. **Read the state again** with impeccable_state. Done when the preview item's `apps` names each chosen app's `directory`, `build` and `method` (none yet for an app not set up), and `perApp` its status.
-5. **Set each chosen app up**, one after the other, as the playbook's steps 3 and 4 say for that app alone, `appKey` on every write and check (`preview`, `test-accounts`, `latest-pull-check`, `connection-check`): its method by the case that applies to it (server-previews when its pages need a server, static-site when they do not, a host's case when the host deploys that app as a project of its own, proven on that app's own address: impeccable_hosted_previews, impeccable_netlify_previews and impeccable_cloudflare_previews take its `appKey` and list only the previews of the project or site that builds its folder (impeccable_netlify_connect takes it too, and connects that site), so another app's address, project or key never stands in for it; their `unmatched` says why none can be told, and that app goes as server-previews or static-site says, with the reason under "What is not verified"), and its own sign-in when the scan item's `accessByApp` says it has one, each account question's title naming the app (*"Order desk admin account"*). **The lock in front of each app's previews is that app's own**: when its proof answers a `gate`, preview-protection's steps run for that app, with its `appKey`, before any other app's step (the tools refuse the next app's reads and writes until its key tool was called), and the key goes to that app's own project or site; a key saved for one app says nothing about another's, and the state's `keySaved` speaks for one app at most. Done when every chosen app's method is saved, or its preview skipped as server-previews says, and its sign-in saved or skipped, and no other app got a write, a build or a question.
-6. **The pull requests** as pull-requests says, once for the repository: the setup commit takes the state's one workflow `file` (a job for each chosen static site whose preview Impeccable builds) once every chosen app's method and build settings are saved, or its preview skipped as server-previews says; the test drive adds its page to every chosen app with a preview (an app whose preview was skipped gets none, and goes under "What was skipped, and why"), in that app's own framework and linked from that app's own public page, so one review renders each of them on its own preview; that case's step 3 proves each chosen app with the input that proved it; its step 4 proves the test drive's page on each chosen app's own preview, with that app's key where its lock stands in front; its step 6 checks each chosen app with a preview, with its `appKey`, one call each. Done when pull-requests' steps are done.
+5. **Set each chosen app up**, one after the other, as the playbook's steps 3 and 4 say for that app alone, `appKey` on every write and check (`preview`, `test-accounts`, `latest-pull-check`, `connection-check`): its method by the case that applies to it (server-previews when no host deploys it, a host's case when the host deploys that app as a project of its own, proven on that app's own address: impeccable_hosted_previews, impeccable_netlify_previews and impeccable_cloudflare_previews take its `appKey` and list only the previews of the project or site that builds its folder (impeccable_netlify_connect takes it too, and connects that site), so another app's address, project or key never stands in for it; their `unmatched` says why none can be told, and that app goes as server-previews says, with the reason under "What is not verified"), and its own sign-in when the scan item's `accessByApp` says it has one, each account question's title naming the app (*"Order desk admin account"*). **The lock in front of each app's previews is that app's own**: when its proof answers a `gate`, preview-protection's steps run for that app, with its `appKey`, before any other app's step (the tools refuse the next app's reads and writes until its key tool was called), and the key goes to that app's own project or site; a key saved for one app says nothing about another's, and the state's `keySaved` speaks for one app at most. Done when every chosen app's method is saved, or its preview skipped as server-previews says, and its sign-in saved or skipped, and no other app got a write, a build or a question.
+6. **The pull requests** as pull-requests says, once for the repository: the setup commit takes the state's one workflow `file` once every chosen app's method and build settings are saved, or its preview skipped as server-previews says; the test drive adds its page to every chosen app with a preview (an app whose preview was skipped gets none, and goes under "What was skipped, and why"), in that app's own framework and linked from that app's own public page, so one review renders each of them on its own preview; that case's step 3 builds each chosen app as its host's case says; its step 4 proves the test drive's page on each chosen app's own preview, with that app's key where its lock stands in front; its step 6 checks each chosen app with a preview, with its `appKey`, one call each. Done when pull-requests' steps are done.
    - **A chosen app whose preview was skipped** (server-previews): it stays on, with no method, no job in the workflow and no test drive page. It holds nothing back: the other apps' setup commit, test drive and checks go on as above, and its checkup entry left in `next` counts as done for the playbook's step 5. The report says, on its line and under "What was skipped, and why", that it gets no preview until its host deploys them.
-   - **A host previews some chosen apps and Impeccable builds the others**: a host's case speaks for its own app. The setup commit carries the workflow for the others and the test drive branches from it, and pull-requests' step 4 goes each app's way: the host's app proven on the host's build, the others by the workflow. The repository goes without a workflow and a setup pull request only where a host previews every chosen app.
 7. **Report per app**: under "What was configured, and by whom", one line per app the question offered: on or off and why (picked, unticked, named with `--app`, on already after a skip), its method, its sign-in, what was verified; an app left out is under "What was skipped, and why" as well, with the setup page as where it is turned on. impeccable_report adds a section of its own, "Each app, as this run left it", from what the run saved and proved, and the last screen says "You're all set up" only when every chosen app is: an app whose preview met a lock with no key saved, or got no method, is named there with its one step, so the report's lines say the same. Done when every app is on one line.
 
 ### Reference
 
-- **The folders**: the install runs where the manifest the lockfile belongs to is (`build.installDirectory` in the state: the root of a workspace with one lockfile), the build and the start in the app's own folder (`build.workingDirectory`, the `directory` the preview item's `apps` names). impeccable_verify_preview takes no `appKey`: give each step its `directory` accordingly, and `output.directory` from the checkout's root; the saved `outputDir` is relative to the app's folder (`.` when its files are the pages), since the job uploads from there. Where the check is skipped on this machine (static-site says when), each app's job proves its build on the pull request.
+- **The folders**: the install runs where the manifest the lockfile belongs to is (`build.installDirectory` in the state: the root of a workspace with one lockfile), the build and the start in the app's own folder (`build.workingDirectory`, the `directory` the preview item's `apps` names).
 - **Ask nothing else about apps**: names, a split or a merge are the person's on the setup page. A proposal that looks wrong (a shared package, a missing folder) goes into the report, never into a `split`.
 - **Status lines** name the app (*"Proving the storefront's preview"*), under the playbook's tasks.
 - The checkup's entries for an app read "<repository> (<app>): …", and its `apps` check is answered by step 1.

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

@@ -15,8 +15,8 @@ It applies as well **before the first pull request**: a site built from this rep
 - **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.
 - **Deploy Previews off now** (`pullRequestPreviews` in the answer, `enabled: false`, with its `reason`): the site built previews before, and its settings build none now. The aim holds: ask once with impeccable_enable_previews (`host: "netlify"`), after step 1's proof and preview-protection's steps and before the test drive is pushed, so the person sees the lock's question and this one back to back, at most one each. `enabled`: go on. `skipped` or `refused`: push no test drive (pull-requests' "No preview, no test drive"), and say under "What was skipped, and why" that Deploy Previews are off for the site, with the `reason`, and name the `page`; `left` stays empty, since the person was asked in this run. `enabled: 'unknown'`: say so in one line under "What is not verified" and go on.
-- **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. With a site of this repository whose Deploy Previews are on, that is the first pull request still to come, above. Else, 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".
+- **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 says instead, and say under "What is not verified" what the Netlify address answered.
+- **Nothing listed**: Netlify's previews are not on record. With a site of this repository whose Deploy Previews are on, that is the first pull request still to come, above. Else, where the checkout is set up for Netlify, that is the netlify-setup case's; else set the preview up as server-previews 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, beyond what impeccable_netlify_password and impeccable_enable_previews do 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

@@ -7,7 +7,7 @@ The checkout is set up for Netlify: a `netlify.toml`, a `.netlify/` folder, or a
 1. **Sign in**, before any other preview work, with impeccable_ask: `kind: "confirm"`, `id: "netlify-setup"`. The tool does the rest: it shows the setup screen once (a person signed in already confirms the setup with that sign-in on it, with no login to run), runs the login in the browser when the Netlify CLI is signed out and offers a retry. Done when it answered `confirmed`.
    - **`cli: "missing"`**: install the CLI with `npm install -g netlify-cli@27.11.2`, exactly so: the run installs it with npm alone, pinned to that version, and refuses another package manager, version or tag; then ask again: the screen shows no second time.
    - **`teams` in the answer** (the person has several Netlify teams): ask once which owns the site, `kind: "single"`, `id: "netlify-team"`, `options` the teams as given (the tool words the rest), and pass the pick to `sites:create` as `--account-slug`.
-   - **Skip**: set the preview up as server-previews or static-site says, and say under "What was skipped, and why" that Netlify was found and the sign-in was skipped. The steps below do not apply.
+   - **Skip**: set the preview up as server-previews says, and say under "What was skipped, and why" that Netlify was found and the sign-in was skipped. The steps below do not apply.
 2. **Link or create the site** (run each Netlify command plain, on its own: a command chained after `sites:create` leaves the site unrecorded): `netlify link --git-remote-url <the GitHub origin>` links a site Netlify already builds from this repository; when it finds none, `netlify sites:create --name <name>` creates one in the person's team and links this folder. Name it after the repository: lowercase letters, digits and hyphens, at most 40 characters; a name Netlify says is taken gets `-2`. Done when `netlify status` names the linked project.
    - **A site already built from this repository** (impeccable_netlify_previews named it in `sites`; on a repository with several apps, read with the app's `appKey`): link nothing, since `netlify link` asks in a terminal this run does not have when several sites are built from the repository. Step 3 finds that site by itself.
 3. **Connect the repository** with impeccable_netlify_connect (with the app's `appKey` on a repository with several apps): it connects the linked site to this repository through Netlify's GitHub app, so pull requests build deploy previews, when that site is the one this run created or one built from this repository already (a site built from another repository, or one the run did not create, is left as it is, with the reason), and asks the person for the app's access when Netlify cannot read the repository. Give `command` and `publish` only where no `netlify.toml` sets the build. Done when it answered `connected: true`; a site `netlify link` found is connected already, and it says so. **Deploy Previews off** on that site (`pullRequestPreviews` in its answer, or in impeccable_netlify_previews', `enabled: false`): the aim holds, so ask once with impeccable_enable_previews (`host: "netlify"`) before step 4, and never a second time. `enabled`: step 4. `skipped` or `refused`: the setup ends here, as "A step fails before the test drive is pushed" says, with the `reason` and the `page` in the report, and `left` empty, since the person was asked in this run.
@@ -18,7 +18,7 @@ The checkout is set up for Netlify: a `netlify.toml`, a `.netlify/` folder, or a
 
 - **The live app**: a site created here has none yet, so the before stays unset, which the report says (live-app-address).
 - **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.
+- **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 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 wait's own screen opens the site's deploy settings, where Deploy Previews are turned on, and waits again on the person's yes (a site whose settings said they were off was asked about in step 3, so this wait is for a build, not a setting). 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.

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

@@ -4,12 +4,12 @@ impeccable_prove_preview answered a `gate`: the host's own lock stands in front
 
 ### 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 Vercel's project with or without a `.vercel/` link (no `vercel link` is needed, and the tool signs the Vercel CLI in where it is signed out), then 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`:
+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 Vercel's project with or without a `.vercel/` link (no `vercel link` is needed, and the tool signs the Vercel CLI in where it is signed out), then 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 (naming the Access application in front of the preview, its Cloudflare account and the app, once cf signed in here found it; none found, nothing is asked; 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.
    - `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` with `protection: "none"` (Netlify: the site's settings show neither a password nor the team login, or the site is public now, `madePublic` saying who made it so, and the page past the login is not the app's), or on Vercel whose `reason` says the settings show no Deployment Protection: the page you proved is the app's own sign-in or another page, however it is worded, and the previews are open. Prove a page a visitor opens without signing in, as vercel-previews' or netlify-previews' step 1 says, and on `proven: true` go on with that case's step 2, the save, calling this tool no more: there is no lock to get past. No such page proven: the host's previews do not show this app to a visitor, so go on as that case's "Another app, or no answer" says (set the preview up as server-previews or static-site says, and say under "What is not verified" what the address answered), never step 3, whose lock the settings show is not there.
+   - `refused` with `protection: "none"` (Netlify: the site's settings show neither a password nor the team login, or the site is public now, `madePublic` saying who made it so, and the page past the login is not the app's), or on Vercel whose `reason` says the settings show no Deployment Protection: the page you proved is the app's own sign-in or another page, however it is worded, and the previews are open. Prove a page a visitor opens without signing in, as vercel-previews' or netlify-previews' step 1 says, and on `proven: true` go on with that case's step 2, the save, calling this tool no more: there is no lock to get past. No such page proven: the host's previews do not show this app to a visitor, so go on as that case's "Another app, or no answer" says (set the preview up as server-previews says, and say under "What is not verified" what the address answered), never step 3, whose lock the settings show is not there.
    - Any other `refused` on Netlify whose `reason` says to prove or try a page a visitor opens, or that the page asks for the app's own sign-in past the lock: the site password (Netlify's own, or the one typed) got past the lock to the app's own sign-in on the page you proved, or opened neither the header nor Netlify's form, 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`.
@@ -18,6 +18,7 @@ impeccable_prove_preview answered a `gate`: the host's own lock stands in front
 
 ### Reference
 
+- **Before the test drive's push, on Vercel** (pull-requests' step 4): impeccable_vercel_bypass with `beforePush: true`, and the app's `appKey` on a repository with several apps, reads the project's settings and, where Vercel's login will stand in front of the test drive's preview, asks the person now, on a screen naming the project and the app. `protected: false`, or `protected: true` with `consent` `given` or `not-needed`, or `protected: "unknown"`: push. Once the proof meets the gate, step 1 runs as written, and the yes is not asked again. `skipped`: push and open no test drive, and end as step 3 says, with the tool's `reason`.
 - **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. On a repository with several apps, the item's `keySaved` speaks for one app at most: an app whose own proof answered a `gate` gets step 1 with its `appKey`, whatever another app's key did, and its step 2 check is its own.

package/dist/playbook/cases/pull-requests.md

@@ -5,12 +5,11 @@ Every run, once the settings are saved. The person merges the setup pull request
 ### Steps
 
 1. **The setup commit**, when the repository needs a change to keep previews working: the workflow and any fix the build needed, nothing else. With the workflow current on the default branch and no fix, there is none. Check access as workflow-as-person says, branch `impeccable/setup` from `origin/<defaultBranch>`, and bring in the workflow and commit as that case says. Push it in step 7, after the test drive. Done when that case's steps are done.
-2. **The test drive page**, always. The test drive shows the person a whole review: pages to capture, a finding for each measure, and a new page, which is what starts the review's visitor sessions. Branch `impeccable/test-drive` from the setup commit, so it carries the same workflow and its preview runs from its own head (from the default branch when there is no setup commit). Add one small, self-contained page in the repository's own framework, such as `/impeccable-test-drive`: a file where the routing finds pages, plus its styles, with a heading, a paragraph and a few elements in the app's own words (so the review judges it as one of the app's pages), and the flaws below. Link it from a page **a visitor opens without signing in**, the landing page when it is one, and keep the new page open without signing in too: no guard, on the server or in the browser, sends it to the sign-in. Done when the new page carries every flaw below with its comment, and the page you picked links to it.
-3. **Prove both pages** with impeccable_verify_preview, for a preview Impeccable builds itself (static-site): the input that proved the preview, with both pages in `entries`. A host's preview (vercel-previews, vercel-setup, netlify-previews, netlify-setup) is proven on the host's own build in step 4 instead; its case says how the branch is built here first. Done when it answers `verified: true`, or the preview is a host's, or the check is skipped on this machine (its answer says it has no sandbox for it): then the workflow's job proves both pages on the pull request, under "What is not verified".
-4. **Push the test drive and prove its preview**: a host whose evidence said `pullRequestPreviews.enabled: false` is asked first, once, as its case says (impeccable_enable_previews; skipped or refused, push nothing: "No preview, no test drive" below); then commit the new page **and** the page that links to it, each staged by name, `git push -u origin impeccable/test-drive`, then the way its preview comes:
+2. **The test drive page**, always. The test drive shows the person a whole review: pages to capture, a finding for each measure, and a new page, which is what starts the review's visitor sessions. Branch `impeccable/test-drive` from the setup commit, so it carries the same workflow and its preview runs from its own head (from the default branch when there is no setup commit). Add one small, self-contained page in the repository's own framework, such as `/impeccable-test-drive`: a file where the routing finds pages, plus its styles, with a heading, a paragraph and a few elements in the app's own words (so the review judges it as one of the app's pages), and the flaws below. Every word a visitor sees, the page's title, heading and copy and the link to it, reads as a plausible real page of the site, such as a short feature or about page in the product's voice: none says it is a test, a demo or a test drive, names Impeccable or a review, or calls its content placeholder or not real, since a visitor who reads that marks the page down. The flaws' comments stay in the code, never on the page. Link it from a page **a visitor opens without signing in**, the landing page when it is one, and keep the new page open without signing in too: no guard, on the server or in the browser, sends it to the sign-in. Done when the new page carries every flaw below with its comment, and the page you picked links to it.
+3. **Build the test drive branch here**, as the host's case says in place of this step (vercel-previews, netlify-previews, cloudflare-previews), so a page that does not build is never pushed; its preview is proven on the host's own build in step 4. Done when the build passed.
+4. **Push the test drive and prove its preview**: a host whose evidence said `pullRequestPreviews.enabled: false` is asked first, once, as its case says (impeccable_enable_previews; skipped or refused, push nothing: "No preview, no test drive" below); on Vercel, impeccable_vercel_bypass with `beforePush: true` (and each app's `appKey`, one call per app) asks for the bypass secret first where Vercel's login will stand in front of the preview, as preview-protection's "Before the test drive's push" says (`skipped`, push nothing); then commit the new page **and** the page that links to it, each staged by name, `git push -u origin impeccable/test-drive`, then the way its preview comes:
    - **Vercel** (vercel-previews, vercel-setup) builds every push: impeccable_hosted_previews with `branch: "impeccable/test-drive"` waits up to five minutes for its deployment of the pushed head, under a status line with its timer. Prove the test drive's page on that address with impeccable_prove_preview (past Vercel's login as preview-protection says), and save the method as the case says. Then step 5.
    - **Netlify** (netlify-previews, netlify-setup) builds a deploy preview only for a pull request: open the test drive now as a **draft**, step 5's `gh pr create` with `--draft`, which Impeccable leaves unreviewed. impeccable_netlify_previews with `pull` the number it printed waits up to five minutes for the deploy preview, under a status line with its timer. Prove the test drive's page on it, save the method as the case says, then `gh pr ready impeccable/test-drive --repo <owner>/<repo>` marks it ready, which starts the review. Then step 5's recording.
-   - **Impeccable's own preview** (static-site): the workflow in the branch builds it on the pull request, and Impeccable's review holds up to eight minutes for that job before it renders, so step 3's proof and the workflow in the branch (from the setup commit) are all this step takes. Then step 5.
 
    A host's wait that ran out shows its own screen, which opens the host's page where its builds are turned on and waits again on the person's yes. Done when the test drive's page is proven on its preview, and a host's method saved; when nothing proved it, the reference below says how the run goes on.
 5. **Open the test drive and record it**: `gh pr create --repo <owner>/<repo> --head impeccable/test-drive --base <defaultBranch>` with the title "Impeccable test drive (safe to close)" and a body that starts "This pull request only shows Impeccable reviewing a change. Close it when you are done; nothing here needs to be merged." and then names the pages its diff holds, no more, and lists the flaws planted for the review to find, one line each (a Netlify draft opened this way in step 4, and was marked ready there). Record it right away with impeccable_test_pr, so the web page follows its review; it refuses a draft, and a branch that changes no existing page. Done when impeccable_test_pr answered "Recorded".
@@ -27,5 +26,5 @@ Every run, once the settings are saved. The person merges the setup pull request
   - **A layout transition**: `transition: width 0.3s`, naming the layout property.
   - **Body text at the viewport edge**: a paragraph of more than 40 characters in the main content, without a background, flush with the sides of the viewport.
 - **No preview, no test drive**: when step 4 ends with the preview unproven (the host's build failed or none came within the five minutes, the host's login stayed in front, step 3 failed), open no test drive: mark the Test drive task failed, say under "What is not verified" what was missing and what the person can do, and put their step in `left` (on Cloudflare, cloudflare-previews' "No pull-request previews" names the cause and the page; a step the person was asked about in this run goes in the report, not in `left`). The setup pull request still opens in step 7 when there is a setup commit. A Netlify draft stays open, unrecorded: name it in the report. Put "Mark the test drive #N ready once Netlify builds its preview" in `left` only where Netlify built no preview; where it built one and the lock stayed in front, preview-protection's step 3 says what the report says instead.
-- **A single-page app**, whose routes live in the browser: the new page is a self-contained HTML file in the folder the build copies as it is (`public/` in Vite), so the output holds it for `entries` and the review counts it as a page added.
+- **A single-page app**, whose routes live in the browser: the new page is a self-contained HTML file in the folder the build copies as it is (`public/` in Vite), so the build's output holds it and the review counts it as a page added.
 - **A branch name an earlier run took** (checkout or push says so): use `-2`, then `-3`, and name the earlier pull request in the report so the person can close it.

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

@@ -1,14 +1,14 @@
 ### When this applies
 
-The pages need a server from this repository (SSR, API routes, or a backend the front end calls; a front end whose bundle builds on its own still needs its backend here), and no host's previews show them: no host case applied, or one ended without a preview. Impeccable no longer runs a server in CI for a new setup, so such pages are previewed only by their host's pull request previews. These steps replace the playbook's step 3.
+No host's previews show the pages: no host case applied, or one ended without a preview. Impeccable no longer runs a server or builds a static site in CI for a new setup, so the pages are previewed only by their host's pull request previews. These steps replace the playbook's step 3. Pages that need no server from this repository (plain HTML, or a build that writes a complete static site; an external API they call does not change that) take no question: step 3 applies to them straight away.
 
 ### Steps
 
-1. **Ask where the previews come from**, once, with impeccable_ask: `id: "preview-host"`, `kind: "single"`, `title` *"Pull request previews"*, `prompt` *"Which host should deploy a preview of each pull request?"*, `hint` *"Impeccable reviews this app on its host's previews, and no longer runs its server itself."*, and `options` Vercel (`vercel`) and Netlify (`netlify`). Done when it answered a value, or a skip.
+1. **Ask where the previews come from**, when the pages need a server from this repository (SSR, API routes, or a backend the front end calls; a front end whose bundle builds on its own still needs its backend here), once, with impeccable_ask: `id: "preview-host"`, `kind: "single"`, `title` *"Pull request previews"*, `prompt` *"Which host should deploy a preview of each pull request?"*, `hint` *"Impeccable reviews this app on its host's previews, and no longer runs its server itself."*, and `options` Vercel (`vercel`) and Netlify (`netlify`). Done when it answered a value, or a skip.
    - **Several apps**: ask once for each app this case applies to, the title naming the app (*"Order desk previews"*).
    - **Asked already for this app in this run**, or a host's setup for it ended without a preview (the sign-in skipped, a step failed): ask nothing, and go on as after a skip.
 2. **Set the host up**: on `vercel`, as the vercel-setup case says, and on `netlify`, as the netlify-setup case says. The pick stands in for that case's "When this applies": its steps run whatever the checkout holds for the host, and even where the host already deploys previews that showed another app or did not answer, since the test drive's own preview, proven on that host, decides. Done when that case's steps are done.
-3. **After a skip**: no preview, no test drive. Save no method and write no workflow for these pages, and open no test drive, as pull-requests' "No preview, no test drive" says. Mark the Preview method and Test drive tasks failed, and say under "What was skipped, and why" that the pages need a server and no host deploys previews of them, naming Vercel, Netlify and Cloudflare as the hosts whose pull request previews Impeccable reviews. The checkup's entry for this preview then stays in `next`, which counts as done for the playbook's step 5. With several apps this holds for the skipped app alone: the other chosen apps' previews and the test drive go on as monorepo says, and the tasks fail only where no app has a preview. Done when the report says so.
+3. **After a skip, or for pages that need no server**: no preview, no test drive. Save no method and write no workflow for these pages, and open no test drive, as pull-requests' "No preview, no test drive" says. Mark the Preview method and Test drive tasks failed, and say under "What was skipped, and why" that no host deploys previews of the pages (and that they need a server, where they do), naming Vercel, Netlify and Cloudflare as the hosts whose pull request previews Impeccable reviews. The checkup's entry for this preview then stays in `next`, which counts as done for the playbook's step 5. With several apps this holds for that app alone: the other chosen apps' previews and the test drive go on as monorepo says, and the tasks fail only where no app has a preview. Done when the report says so.
 
 ### Reference