@impeccable/reviews 0.1.1 → 0.1.3

package/dist/log.js

@@ -1,8 +1,13 @@
 import { appendFileSync } from 'node:fs';
 import { tmpdir } from 'node:os';
 import { join } from 'node:path';
-/** An error whose message is written for the person at the terminal. */
+/** 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;
+    constructor(message, step) {
+        super(message);
+        this.step = step;
+    }
 }
 const TOKEN = /\b(pst|phr)_[A-Za-z0-9._~+/=-]+/g;
 const NAMES = 'access_token|run_token|code_verifier|code|authorization|x-api-key';

package/dist/login.js

@@ -130,7 +130,7 @@ export async function startCallbackServer(state, ports = CALLBACK_PORTS) {
             },
         };
     }
-    throw new UserError(`Ports ${ports.join(', ')} are all taken on this machine, and sign-in needs one. Close what uses one of them and run it again.`);
+    throw new UserError(`Ports ${ports.join(', ')} are all taken on this machine, and sign-in needs one. Close what uses one of them and run it again.`, { event: 'setup_command_sign_in_ended', outcome: 'ports_busy' });
 }
 /** The code from what the person pasted: the whole callback address, or the code alone. Null when it is neither, or from another sign-in. */
 export function parsePasted(text, state) {
@@ -215,18 +215,20 @@ export async function exchangeCode(host, input, log) {
 }
 /**
  * The browser sign-in: callback server, PKCE and state, the paste fallback,
- * then the token exchange, once per code. `check` stops a token the command
+ * then the token exchange, once per code. `repo` is the checkout's owner/name:
+ * the consent page names it, so the person approves and picks nothing (an
+ * older Impeccable ignores it and asks). `check` stops a token the command
  * cannot use; otherwise the tab that brought the code goes on to the page
  * `landing` resolves to (the web page that mirrors the run, once the command
  * has what it needs to show a run there), or says why it will not.
  */
-export async function signIn(host, log, prompt, check = (t) => t, landing = async (t) => progressPage(host, t)) {
+export async function signIn(host, repo, log, prompt, check = (t) => t, landing = async (t) => progressPage(host, t)) {
     const state = randomBytes(24).toString('base64url');
     const { verifier, challenge } = pkcePair();
     log.secret(verifier);
     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' }).toString();
+    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}`);
     prompt.show(authorize.href);
     openBrowser(authorize.href);
@@ -235,8 +237,8 @@ export async function signIn(host, log, prompt, check = (t) => t, landing = asyn
     try {
         const code = await new Promise((resolve, reject) => {
             server.code.then(resolve, reject);
-            stopPaste = prompt.listen(state, resolve, () => reject(new UserError('Sign-in cancelled.')));
-            timer = setTimeout(() => reject(new UserError('Sign-in timed out after 30 minutes. Run impeccable-reviews again.')), LOGIN_TIMEOUT_MS);
+            stopPaste = prompt.listen(state, resolve, () => reject(new UserError('Sign-in cancelled.', { event: 'setup_command_sign_in_ended', outcome: 'cancelled' })));
+            timer = setTimeout(() => reject(new UserError('Sign-in timed out after 30 minutes. Run impeccable-reviews again.', { event: 'setup_command_sign_in_ended', outcome: 'timed_out' })), LOGIN_TIMEOUT_MS);
         });
         log.secret(code);
         const token = check(await exchangeCode(host, { code, verifier, redirectUri: server.redirectUri }, log));

package/dist/main.js

@@ -4,18 +4,20 @@ import { tmpdir } from 'node:os';
 import { dirname, join } from 'node:path';
 import { promisify } from 'node:util';
 import { runAgent } from './agent.js';
-import { fenceExtension } from './fence.js';
+import { fenceExtension, hostsAgreed, placeOf } from './fence.js';
 import { focusInstructions, focusState, severalApps } from './focus.js';
 import { requestJson } from './http.js';
 import { copyText, letTabsHear, openBrowser, progressPage, screenPrompt, setupAuth, signIn } from './login.js';
 import { createLog, UserError } from './log.js';
 import { firstMessage, playbook, setupContext } from './playbook.js';
 import { checkoutFrontEnd, parseFlags, readCheckout, stateSaysNoFrontEnd, USAGE } from './preflight.js';
+import { startSandbox } from './sandbox.js';
 import { scanRecorder } from './scan.js';
+import { createReporter, reportingOff } from './report.js';
 import { createSessionSync, syncExtension } from './sync.js';
 import { createTools, resultLine } from './tools.js';
 import { transcriptPaths } from './transcript.js';
-import { atExit, closeScreens, helpMark, recordFrames, showIntro, showOutro, showPullRequest, showRun, showSignIn } from './ui/screens.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);
 /** How a run on a repository with no web front end ends, here and on the web page. */
@@ -41,9 +43,11 @@ function previewWait() {
     return Number.isFinite(totalMs) && totalMs > 0 ? { totalMs, everyMs: Math.min(15_000, Math.max(50, Math.floor(totalMs / 5))) } : undefined;
 }
 /** The end of a run with nothing to set up, before the agent: the web page says why too, and the command exits 2. */
-async function nothingToSetUp(sync, title, result, links) {
-    sync.update({ phase: 'error', status: result, question: null });
+async function nothingToSetUp(sync, reporter, why, title, result, links) {
+    sync.update({ phase: 'error', status: result, question: null, stop_reason: why });
     const saved = await settle(sync.flush(), 5000);
+    if (!saved?.ok)
+        reporter.step({ event: 'setup_command_stopped', outcome: 'update_lost' });
     await showOutro({
         outcome: 'stopped',
         title,
@@ -52,12 +56,14 @@ async function nothingToSetUp(sync, title, result, links) {
         todo: [],
         warnings: saved?.ok ? [] : [`The web page missed this (${saved?.error ?? 'no answer'}), so it may still show the run as going.`],
     });
-    await letTabsHear();
+    await Promise.all([letTabsHear(), reporter.done()]);
     process.exit(2);
 }
 export async function main(argv) {
     let log = createLog(false);
     let sync;
+    // Nothing is reported until the flags say where to and whether to.
+    let reporter = createReporter({ host: '', off: true });
     // The tab the person approved in goes on to the web page once the run is minted, so the page has a run to show; a stop before then is what it says instead.
     let land = () => { };
     const landing = new Promise((resolve, reject) => (land = (outcome) => (typeof outcome === 'string' ? resolve(outcome) : reject(outcome))));
@@ -67,33 +73,64 @@ export async function main(argv) {
         if (flags.help)
             return say(`${helpMark().join('\n').trimEnd()}\n\n${USAGE}`);
         log = createLog(flags.debug);
+        reporter = createReporter({ host: flags.host, off: reportingOff(process.env, flags.noTelemetry) });
+        reporter.step({ event: 'setup_command_launched', outcome: 'launched' });
+        // A screen that ends the command at once (Ctrl+C before a run, a signal), and anything nobody caught, still say so first.
+        onScreenExit(async (why) => {
+            reporter.step({ event: 'setup_command_stopped', outcome: why });
+            await reporter.done();
+        });
+        const crashed = (err) => {
+            console.error(err);
+            reporter.step({ event: 'setup_command_stopped', outcome: 'crashed' });
+            void reporter.done().finally(() => process.exit(1));
+        };
+        process.once('uncaughtException', crashed);
+        process.once('unhandledRejection', crashed);
         // Printed as the command exits, after the screen has gone, so it stays in the scrollback.
         if (log.path)
             atExit(() => [`Debug log: ${log.path}`]);
         log.write('start', { host: flags.host, model: flags.model, effort: flags.effort, yes: flags.yes, node: process.versions.node });
         if (flags.frames)
             recordFrames(flags.frames);
-        const checkout = readCheckout(process.cwd());
+        const checkout = readCheckout(flags.installDir?.path ?? process.cwd(), flags.installDir?.from);
         const interactive = Boolean(process.stdin.isTTY && process.stdout.isTTY);
         const slug = `${checkout.owner}/${checkout.repo}`;
-        if (!(await showIntro()))
-            return;
+        // From the checkout's top, where the sandbox lays its own protections of a checkout.
+        process.chdir(checkout.root);
+        // Scratch output (a server's log, a build's output) goes here and never into the checkout.
+        const scratch = mkdtempSync(join(tmpdir(), 'impeccable-reviews-scratch-'));
+        process.on('exit', () => rmSync(scratch, { recursive: true, force: true }));
+        const sandbox = await startSandbox({
+            root: checkout.root,
+            scratch,
+            host: flags.host,
+            log,
+            place: placeOf,
+            hosts: () => hostsAgreed(log),
+        });
+        if (!(await showIntro(slug, sandbox.warning))) {
+            reporter.step({ event: 'setup_command_sign_in_ended', outcome: 'cancelled' });
+            return void (await reporter.done());
+        }
         const onHost = (url) => URL.canParse(url) && new URL(url).origin === flags.host;
         /** The sign-in's answer, when it is for this checkout and points at --host only. */
         const accept = (t) => {
             log.secret(t.access_token);
             const approved = `${t.repository.owner}/${t.repository.name}`;
             if (approved.toLowerCase() !== slug.toLowerCase()) {
-                throw new UserError(`You approved ${approved}, but this checkout is ${slug}. Run it again and pick ${slug} on the consent page.`);
+                throw new UserError(`You approved ${approved}, but this checkout is ${slug}. Run it again and approve ${slug} on the consent page.`, { event: 'setup_command_sign_in_ended', outcome: 'repo_mismatch' });
             }
             if (!onHost(t.setup_api) || !onHost(t.cli_api)) {
                 throw new UserError(`Impeccable answered with addresses off ${flags.host}, so the command stopped before sending anything there.`);
             }
             return t;
         };
-        const token = await signIn(flags.host, log, screenPrompt(showSignIn), accept, () => landing);
+        const token = await signIn(flags.host, slug, log, screenPrompt(showSignIn), 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.
+        reporter.signedIn(token.access_token, cliApi);
         const page = progressPage(flags.host, token);
         // The run screen opens at once, with its placeholder, while the run starts. Stopping before the agent takes over
         // stops the command, and a run already started shows as stopped on the web page.
@@ -104,13 +141,14 @@ export async function main(argv) {
             stopping = true;
             const why = 'Impeccable stopped before the setup started.';
             if (sync) {
-                sync.update({ phase: 'error', status: why, question: null });
+                sync.update({ phase: 'error', status: why, question: null, stop_reason: 'stopped' });
                 await settle(sync.flush(), 5000);
             }
             land(new UserError(why));
             await closeScreens();
             console.error(why);
-            await letTabsHear();
+            reporter.step({ event: 'setup_command_stopped', outcome: 'ctrl_c' });
+            await Promise.all([letTabsHear(), reporter.done()]);
             process.exit(130);
         };
         showRun({ onCancel: () => void stopEarly() });
@@ -126,6 +164,8 @@ export async function main(argv) {
             throw new UserError(`Impeccable answered with a model gateway off ${flags.host}, so the command stopped before sending anything there.`);
         land(page);
         const runToken = run.run_token;
+        // From here the run's own token, so each step names the run too.
+        reporter.signedIn(runToken, cliApi);
         const sessionUrl = `${cliApi}/sessions/${encodeURIComponent(run.run_id)}`;
         const liveSync = createSessionSync((payload) => requestJson(sessionUrl, { method: 'PUT', token: runToken, body: payload }, log));
         sync = liveSync;
@@ -135,7 +175,7 @@ export async function main(argv) {
         log.write('front end', frontEnd);
         const webPage = { label: 'Web page', url: page };
         if (frontEnd === 'none')
-            await nothingToSetUp(liveSync, 'No web front end', NO_FRONT_END, [webPage]);
+            await nothingToSetUp(liveSync, reporter, 'nothing_to_set_up', 'No web front end', NO_FRONT_END, [webPage]);
         const [instructions, state] = await Promise.all([
             requestJson(`${setupApi}/instructions`, { token: token.access_token }, log),
             requestJson(`${setupApi}/state`, { token: token.access_token }, log),
@@ -145,15 +185,12 @@ export async function main(argv) {
         // When the checkout cannot tell, the setup state's own verdict decides. When it has a web front end Impeccable skipped, the person adds it first.
         if (stateSaysNoFrontEnd(state.data, token.repository.name)) {
             if (frontEnd === 'unknown')
-                await nothingToSetUp(liveSync, 'No web front end', NO_FRONT_END, [webPage]);
+                await nothingToSetUp(liveSync, reporter, 'nothing_to_set_up', 'No web front end', NO_FRONT_END, [webPage]);
             const setupPage = state.data.account?.setupPage;
-            await nothingToSetUp(liveSync, 'Repository skipped', SKIPPED, [...(typeof setupPage === 'string' && onHost(setupPage) ? [{ label: 'Setup page', url: setupPage }] : []), webPage]);
+            await nothingToSetUp(liveSync, reporter, 'skipped_repo', 'Repository skipped', SKIPPED, [...(typeof setupPage === 'string' && onHost(setupPage) ? [{ label: 'Setup page', url: setupPage }] : []), webPage]);
         }
         if (!interactive)
             say('Signed in.\n');
-        // Scratch output (a server's log, a build's output) goes here and never into the checkout.
-        const scratch = mkdtempSync(join(tmpdir(), 'impeccable-reviews-scratch-'));
-        process.on('exit', () => rmSync(scratch, { recursive: true, force: true }));
         // Beside the transcript, named after the run as it is, so a run never writes over another's in the temp folder.
         const scans = scanRecorder(log, flags.scanReport ? join(dirname(transcriptPaths(run.run_id, flags.transcript).markdown), `scan-report-${run.run_id.replace(/[^\w.-]/g, '_')}.json`) : undefined);
         atExit(() => scans.report());
@@ -187,12 +224,18 @@ export async function main(argv) {
                 // The web page has the report; when it missed it, the report stays here instead.
                 if (!saved?.ok)
                     say(`\n${report.markdown.trim()}`);
+                if (!saved?.ok)
+                    reporter.step({ event: 'setup_command_stopped', outcome: 'update_lost' });
+                await reporter.done();
                 process.exit(0);
             }
             const waiting = liveSync.payload.phase === 'waiting' ? liveSync.payload.question?.prompt : undefined;
             const why = fatal ? `Impeccable stopped: ${fatal}` : waiting ? `Impeccable stopped while waiting for an answer: ${waiting}` : 'Impeccable stopped before the setup finished.';
-            liveSync.update({ phase: 'error', status: why, question: null });
+            const stopped = fatal ? 'model_error' : waiting ? 'unanswered' : cancelled ? 'stopped' : 'failed';
+            liveSync.update({ phase: 'error', status: why, question: null, stop_reason: stopped });
             const saved = await settle(liveSync.flush(), 5000);
+            if (!saved?.ok)
+                reporter.step({ event: 'setup_command_stopped', outcome: 'update_lost' });
             const missed = saved?.ok ? [] : [`The web page missed this (${saved?.error ?? 'no answer'}), so it may still show the run as going.`];
             const { test_pr: drive, setup_pr: setup } = liveSync.payload;
             await showOutro({
@@ -203,6 +246,7 @@ export async function main(argv) {
                 todo: ['Run impeccable-reviews again to carry on. What was saved stays saved; the web page has the details.'],
                 warnings: missed,
             });
+            await reporter.done();
             process.exit(1);
         };
         await runAgent({
@@ -212,12 +256,12 @@ export async function main(argv) {
             effort: flags.effort,
             gatewayUrl: run.gateway_url,
             runToken,
-            systemPrompt: playbook({ owner: checkout.owner, name: token.repository.name, scratch }),
+            systemPrompt: playbook({ owner: checkout.owner, name: token.repository.name, scratch, sandboxed: !sandbox.warning }),
             firstMessage: firstMessage({ owner: checkout.owner, name: token.repository.name }),
             firstContext: setupContext(focused, focusState(state.data)),
             tools: createTools({
                 setupApi,
-                auth: setupAuth(token, (_pi, why) => signIn(flags.host, log, screenPrompt((link, on) => showSignIn(link, { ...on, why })), accept)),
+                auth: setupAuth(token, (_pi, why) => signIn(flags.host, slug, log, screenPrompt((link, on) => showSignIn(link, { ...on, why })), accept)),
                 owner: token.repository.owner,
                 repo: token.repository.name,
                 instructions: focused,
@@ -227,11 +271,13 @@ export async function main(argv) {
                 onReport: (r) => void (report = r),
                 log,
                 previewWait: previewWait(),
+                sandbox,
             }),
             extensions: [
                 fenceExtension(checkout.root, log, checkout.protectedBranches, scratch, scans),
                 syncExtension(liveSync, { onFatal: (message) => void (fatal = message), onQuit: finish }),
             ],
+            bash: sandbox.shell,
             interactive,
             runId: run.run_id,
             transcript: flags.transcript,
@@ -247,12 +293,19 @@ export async function main(argv) {
         land(new UserError(message));
         log.write('fatal', err instanceof Error ? (err.stack ?? err.message) : String(err));
         if (sync) {
-            sync.update({ phase: 'error', status: message, question: null });
+            // A sign-in the person cancelled mid-run (a renewed one) is a stop they chose, not a failure.
+            const chose = err instanceof UserError && err.step?.event === 'setup_command_sign_in_ended' && err.step.outcome === 'cancelled';
+            sync.update({ phase: 'error', status: message, question: null, stop_reason: chose ? 'stopped' : 'failed' });
             await settle(sync.flush(), 5000);
         }
+        // A stop that ends a step reports it, and anything the command did not expect is a crash; the rest the Worker saw itself.
+        if (!(err instanceof UserError))
+            reporter.step({ event: 'setup_command_stopped', outcome: 'crashed' });
+        else if (err.step)
+            reporter.step(err.step);
         await closeScreens();
         console.error(message);
-        await letTabsHear();
+        await Promise.all([letTabsHear(), reporter.done()]);
         process.exit(1);
     }
 }

package/dist/netlify-password.js

@@ -47,7 +47,8 @@ export async function passNetlifyLock(deps) {
     const finish = async (password, how) => {
         deps.remember(password);
         deps.remember(basicCredentials(password));
-        const proof = await deps.prove(password);
+        // Netlify's form, which an app's own password form looks like, gets the password only on a site whose settings show one.
+        const proof = await deps.prove(password, site !== null);
         // locked: Netlify's lock stood all the same, and its form did not take the password either. Any other failure is the proof's to say: the form took it and the header did not, or the page past the lock is another, or did not answer.
         if (!proof.proven)
             return { reason: proof.reason ?? 'The address did not open with the password.', locked: proof.gate !== undefined && !proof.formOpened };

package/dist/netlify.js

@@ -3,6 +3,7 @@ import { readFile } from 'node:fs/promises';
 import { join } from 'node:path';
 import { setTimeout as sleep } from 'node:timers/promises';
 import { promisify } from 'node:util';
+import { gitEnvironment } from './sandbox.js';
 /**
  * Netlify: the deploy previews this repository's pull requests get (from
  * GitHub's record and from the Netlify CLI on this machine when it is signed
@@ -28,11 +29,13 @@ const previewAddress = (pullRequest, site) => (`deploy-preview-${pullRequest}--$
 /**
  * A runner for gh or netlify here: its input ends at once, so nothing waits on it, and no browser opens (a sign-in is the
  * person's) unless `browser` says so, for `netlify login`, which opens one and waits for the person's approval there.
+ * `env` adds settings the command reads, such as the account cf acts in.
  */
 export function commandRunner(name, cwd, opts = {}) {
     return async (args) => {
         try {
-            const env = { ...process.env, ...(opts.browser ? {} : { BROWSER: 'none', CI: 'true' }), GH_PROMPT_DISABLED: '1' };
+            // The CLIs run git in the checkout, outside the sandbox.
+            const env = gitEnvironment({ ...process.env, ...(opts.browser ? {} : { BROWSER: 'none', CI: 'true' }), GH_PROMPT_DISABLED: '1', ...opts.env });
             const run = execFileAsync(name, args, { cwd, encoding: 'utf8', timeout: opts.timeoutMs ?? 30_000, maxBuffer: 16 * 1024 * 1024, signal: opts.signal, env });
             run.child.stdin?.end();
             return (await run).stdout;

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

@@ -1,6 +1,6 @@
 ### When this applies
 
-Cloudflare Pages deploys previews of the pull requests: impeccable_cloudflare_previews lists a built preview of a pull request (`state` success), with its address and the branch's alias. Ask it only where the repository is set up for Cloudflare (`wrangler.toml`, `wrangler.json` or `wrangler.jsonc`, a `wrangler` or `@cloudflare/*` package, a `.pages.dev` address in the README or the workflows), but its record decides, not the checkout: Cloudflare's GitHub app posts a check run on each commit it built and a comment on the pull request, and wrangler on this machine lists the project's deployments when it is signed in. Cloudflare builds and serves every preview, so these steps replace the playbook's step 3, and the repository needs no workflow and no setup pull request.
+Cloudflare Pages deploys previews of the pull requests: impeccable_cloudflare_previews lists a built preview of a pull request (`state` success), with its address and the branch's alias. Ask it only where the repository is set up for Cloudflare (`wrangler.toml`, `wrangler.json` or `wrangler.jsonc`, a `wrangler` or `@cloudflare/*` package, a `.pages.dev` address in the README or the workflows), but its record decides, not the checkout: Cloudflare's GitHub app posts a check run on each commit it built and a comment on the pull request, and cf, Cloudflare's CLI, lists the project's deployments when it is signed in here. Cloudflare builds and serves every preview, so these steps replace the playbook's step 3, and the repository needs no workflow and no setup pull request.
 
 ### Steps
 
@@ -10,8 +10,8 @@ Cloudflare Pages deploys previews of the pull requests: impeccable_cloudflare_pr
 ### Reference
 
 - **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 ci-tunnel or static-site says instead, and say under "What is not verified" what the Cloudflare address answered.
-- **Nothing listed**: Cloudflare's previews are not on record, so set the preview up as ci-tunnel 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**: 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.
+- **Nothing listed**: 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".
 - **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, and never sign wrangler in. 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 evidence is read only: link, deploy and change nothing on Cloudflare. The one Cloudflare sign-in is impeccable_cloudflare_access's, behind Access, 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 pattern saved under "What was configured, and by whom". 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

@@ -25,4 +25,4 @@ A rerun: the setup pull request an earlier run opened has a preview job that fai
 | 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 | The app refusing the forwarded Host (see ci-tunnel), not Impeccable's own access gate: a 403 on the bare link alone is not a broken preview. |
+| 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/monorepo.md

@@ -8,9 +8,10 @@ The state's repository has an `apps` item: the scan proposed several apps, folde
    - **An item that is `done` or `skipped`** was answered before, on the setup page or by an earlier run (a run that stopped at the question left the scan's default, as a skip does): write nothing and ask nothing; the state's apps that are `enabled` are the chosen ones. Step 4.
 2. **Ask which apps get previews**, once, with impeccable_ask: `id: "apps"`, `kind: "multi"`, `title` *"This repository has several apps"*, `prompt` *"Which apps should get Impeccable previews?"*, `hint` *"Each draws pages of its own; untick any that should not get previews."*, and `options` one per app the answer listed: `value` its `key`, `label` its `name` and folder (*"Storefront · apps/storefront"*), `selected: true` on every one. The repository's own app (`main`) is among them only where the Worker kept it as a product of its own, with pages outside every app's folder: its label is its name and `/`. Done when it answered `values`, or a skip.
 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 Skip**, write nothing more: the app the scan switched on stays the one that is on. Done when the last answer's `apps` show `enabled` true for every chosen app and false for the rest, or, after Skip, the confirm's answer stands.
-4. **Read the state again** with impeccable_state. Done when the preview item's `apps` names each chosen app's `directory`, `build` and `method`, 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 (ci-tunnel 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), 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"*). Done when every chosen app's method is saved 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 app whose preview Impeccable builds) once every chosen app's method and build settings are saved; the test drive adds its page to every chosen app, 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 6 checks once, with the first chosen app's `appKey`, and the other apps' previews go under "What is not verified". Done when pull-requests' steps are done.
+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), 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"*). 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 6 checks once, with the `appKey` of the first chosen app with a preview, and the other apps' previews go under "What is not verified". 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, the scan's default 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. Done when every app is on one line.
 

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

@@ -10,8 +10,8 @@ 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.
-- **Another app, or no answer from any of the three**: Netlify's previews do not show this app. Set the preview up as ci-tunnel 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 ci-tunnel 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 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 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

@@ -1,13 +1,13 @@
 ### When this applies
 
-The checkout is set up for Netlify: a `netlify.toml`, a `.netlify/` folder, or a package script that runs the `netlify` command (a Netlify package alone, `@netlify/*` or `netlify-cli`, says nothing of where the repository deploys). And no pull request has a Netlify deploy preview: impeccable_netlify_previews lists none, and no `error` (an error says nothing either way). These steps replace the playbook's step 3. As in netlify-previews, the repository needs no workflow and no setup pull request.
+The checkout is set up for Netlify: a `netlify.toml`, a `.netlify/` folder, or a package script that runs the `netlify` command (a Netlify package alone, `@netlify/*` or `netlify-cli`, says nothing of where the repository deploys); or the person picked Netlify in server-previews. And no pull request has a Netlify deploy preview: impeccable_netlify_previews lists none, and no `error` (an error says nothing either way). These steps replace the playbook's step 3. As in netlify-previews, the repository needs no workflow and no setup pull request.
 
 ### Steps
 
 1. **Sign in**, before any other preview work, with impeccable_ask: `kind: "confirm"`, `id: "netlify-setup"`. The tool does the rest: it shows the sign-in screen only when the Netlify CLI is signed out (a person signed in already is asked nothing), runs the login in the browser and offers a retry. Done when it answered `confirmed`.
    - **`cli: "missing"`**: install the CLI with the person's package manager (`npm install -g netlify-cli`, `pnpm add -g netlify-cli`, `yarn global add netlify-cli` or `bun add -g netlify-cli`), 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 ci-tunnel 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 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.
 2. **Link or create the site**: `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.
 3. **Connect the repository** with impeccable_netlify_connect: it connects the linked site to this repository through Netlify's GitHub app, so pull requests build deploy previews, 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.
 4. **Build and push the test drive** (the Test drive task) as pull-requests' steps 2 to 4 say, with the changes netlify-previews' reference gives: from the default branch, no setup pull request, built once with the build Netlify runs. Stage its files by name: `netlify sites:create` writes `.netlify/` and may add it to `.gitignore`, and that change stays out of the pull request. Done when `git push -u origin impeccable/test-drive` succeeded.
@@ -15,9 +15,9 @@ The checkout is set up for Netlify: a `netlify.toml`, a `.netlify/` folder, or a
 
 ### Reference
 
-- **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 ci-tunnel 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 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`): `netlify deploy --build --context deploy-preview` builds this linked checkout as Netlify does, uploads a draft, and prints why it failed, so the report can name the cause.
+  - **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`.
 - **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".

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

@@ -4,8 +4,8 @@ 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 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 one taking the Cloudflare API token that creating it takes, and it allows the token in the Access application's policy), 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`:
-   - `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. Step 2.
+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`:
+   - `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.
    - `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.
@@ -15,7 +15,7 @@ impeccable_prove_preview answered a `gate`: the host's own lock stands in front
 
 ### 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 the Cloudflare API token the person made for the run 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 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 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.

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

@@ -6,11 +6,11 @@ Every run, once the settings are saved. The person merges the setup pull request
 
 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 (ci-tunnel, static-site): the input that proved the preview, with both pages in `paths` for a server (a redirect to the sign-in fails there) or in `entries` for a static site. 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.
+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.
 4. **Push the test drive and prove its preview**: commit, `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** (ci-tunnel, 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.
+   - **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.
 
    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 two pages 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. Done when impeccable_test_pr answered "Recorded".

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

@@ -0,0 +1,17 @@
+### 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.
+
+### 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.
+   - **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, say under "What was skipped, and why" that the pages need a server and no host deploys previews of them, and put "Turn on your host's pull request previews, then run the setup again" in `left`, naming Vercel, Netlify and Cloudflare in the report. 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.
+
+### Reference
+
+- **Already on Impeccable's tunnel**: a repository whose state shows `ci-tunnel` as the preview's method, with its workflow committed, keeps working as it is. Change nothing about that preview: a host the person picks here replaces it once its preview is saved, and after a skip the tunnel stays, which the report says in place of the step for `left`.
+- **Never save `ci-tunnel`**: impeccable_write refuses it.
+- The sign-in case applies all the same: the accounts serve the host's previews once they come.

package/dist/playbook/cases/sign-in.md

@@ -18,4 +18,3 @@ The app has its own sign-in: a form that takes a username or an email and a pass
 - impeccable_ask and impeccable_write are the terminal prompt the instructions' `signIn` describes: the person types each password hidden, and it goes straight to `test-accounts`.
 - **A password is only the reference impeccable_ask returned**; impeccable_write refuses any other, so a password in the seed, a README or an env file stays where it is. When the seed sets one, name its file in the account question's hint and let the person type it.
 - `loginPage` is the login form's path when the code names one, such as `/login`.
-- A `ci-tunnel` preview runs the seed, so the seed's accounts exist there.

package/dist/playbook/cases/static-site.md

@@ -1,6 +1,6 @@
 ### When this applies
 
-The pages need no server from this repository: plain HTML, or a build that writes a complete static site. Pages that need SSR, API routes or a backend here follow ci-tunnel; an external API they call does not change that. A build that writes only JavaScript, CSS or types is a library, not a site.
+The pages need no server from this repository: plain HTML, or a build that writes a complete static site. Pages that need SSR, API routes or a backend here follow server-previews; an external API they call does not change that. A build that writes only JavaScript, CSS or types is a library, not a site.
 
 ### Steps
 

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

@@ -10,7 +10,7 @@ Vercel deploys previews of the pull requests: impeccable_hosted_previews lists a
 ### Reference
 
 - **Behind Vercel's login** (`gate: "vercel-protection"`): Deployment Protection 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**: Vercel's previews do not show this app. Set the preview up as ci-tunnel or static-site says instead, and say under "What is not verified" what the Vercel address answered.
+- **Another app, or no answer from any of the three**: Vercel'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 Vercel address answered.
 - **The pull requests**: no setup pull request; the test drive branches from the default branch, and Vercel builds its preview from the push, which pull-requests' step 4 waits for and proves the test drive's page on before the pull request opens. In place of pull-requests' step 3, build the test drive branch once with the install and build Vercel runs (`vercel.json`'s `installCommand` and `buildCommand`, else the package's), as plain commands (`pnpm install`, then `pnpm run build`) and not with impeccable_verify_preview, which is for a preview Impeccable starts itself, so a page that does not build is never pushed.
 - The evidence is GitHub's: link, deploy and change nothing on Vercel, and save no address pattern, since Vercel reports each preview's address to GitHub itself.
 - The report names the address that answered with this app under "What we found", and puts the test drive's own preview under "What is not verified".

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

@@ -1,6 +1,6 @@
 ### When this applies
 
-The checkout is set up for Vercel (`vercel.json`, `.vercel/project.json`, a `vercel` dependency or script) and Vercel has never deployed it: impeccable_hosted_previews lists no deployment that Vercel made (`vercel: true`), and no `error` (an error says nothing either way). These steps replace the playbook's step 3. As in vercel-previews, the repository needs no workflow and no setup pull request.
+The checkout is set up for Vercel (`vercel.json`, `.vercel/project.json`, a `vercel` dependency or script), or the person picked Vercel in server-previews, and Vercel has never deployed it: impeccable_hosted_previews lists no deployment that Vercel made (`vercel: true`), and no `error` (an error says nothing either way). These steps replace the playbook's step 3. As in vercel-previews, the repository needs no workflow and no setup pull request.
 
 ### Steps
 
@@ -8,7 +8,7 @@ The checkout is set up for Vercel (`vercel.json`, `.vercel/project.json`, a `ver
    - **`cli: "missing"`**: install the CLI with the person's package manager (`npm install -g vercel`, `pnpm add -g vercel`, `yarn global add vercel` or `bun add -g vercel`), then ask again: the screen shows no second time.
    - **`teams` in the answer instead of `team`** (several teams, none current): ask once which owns the project, `kind: "single"`, `id: "vercel-team"`, `options` the teams as given (the tool words the rest). The pick is the team.
    - **Neither `team` nor `teams`**: the account has no team, and `vercel link --yes` without `--team` links in the person's own scope.
-   - **Skip**: set the preview up as ci-tunnel or static-site says, and say under "What was skipped, and why" that Vercel was found and the sign-in was skipped. The steps below do not apply.
+   - **Skip**: set the preview up as server-previews or static-site says, and say under "What was skipped, and why" that Vercel was found and the sign-in was skipped. The steps below do not apply.
 2. **Create the project** (run each Vercel command plain: its answer is short, and a pipe to `tail` is refused): `vercel link --yes --team <the team>` creates the project in that team, named after the folder (or links the one that has that name), and connects the GitHub `origin`; the CLI names no team on its own without a terminal, so the option is given whenever there is a team. Done when it prints the linked project.
 3. **Connect the repository, and lock the project before its first deployment**, with impeccable_vercel_connect: it runs the connection on the linked project, asks the person for Vercel's GitHub app's access when the app cannot reach the repository, and then, on a project with no production deployment, puts Vercel's login in front of every address of the project, its own included. Vercel makes a new project's first deployment Production whatever branch it builds and serves it at the project's own address, and the test drive's push is that first deployment. Done when it answered `connected: true` with `production: "exists"` or `locked: true`; a project connected by the link already is, and it says so.
 4. **Build and push the test drive** (the Test drive task) as pull-requests' steps 2 to 4 say, with the changes vercel-previews' reference gives: from the default branch, no setup pull request, built once with plain commands. Stage its files by name: `vercel link` writes `.vercel/` and a `.env.local` that holds a Vercel token, and may add `.vercel` to `.gitignore`, and none of that goes into the pull request. Its push starts the project's first deployment. Done when `git push -u origin impeccable/test-drive` succeeded.
@@ -16,7 +16,7 @@ The checkout is set up for Vercel (`vercel.json`, `.vercel/project.json`, a `ver
 
 ### Reference
 
-- **A step fails before the test drive is pushed** (the sign-in skipped or not completed, the team skipped, the project not created, the repository not connected): the Vercel setup ends there. Set the preview up as ci-tunnel 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 Vercel'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 team skipped, the project not created, the repository not connected): the Vercel 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 Vercel's GitHub app access to the repository", with the `access` page in the report.
 - **A push before step 3** is refused, since a connected project builds every push: run impeccable_vercel_connect first.
 - **`locked: false`** from step 3, with `production` not "exists": push nothing, and set up no other preview either, since the connected project would build that push as its first deployment, public at its own address. Mark the Test drive task failed, say under "What was skipped, and why" what stopped the lock (the answer's `reason`) and how the person locks the project (Vercel Authentication for All Deployments, under the project's Settings → Deployment Protection), and put "Lock the Vercel project, then run the setup again" in `left`.
 - **No preview for the pushed test drive**: save no method, set up no other preview and open no pull request, as pull-requests' "No preview, no test drive" says; the project and the connection stay, and the report names them.