nerdsystem 0.0.9 → 0.0.11

package/dist/cli.d.ts

@@ -1,3 +1,5 @@
+/** The published version, read from package.json so a release bump is the only place it changes. */
+export declare function cliVersion(): string;
 export declare function main(argv: string[]): Promise<void>;
 /**
  * Runs one command and turns any failure into a non-zero exit code. `process.exitCode` is set

package/dist/cli.js

@@ -1,3 +1,4 @@
+import { createRequire } from "node:module";
 import { parseArgs } from "node:util";
 import { authConfig, authSecret } from "./commands/auth.js";
 import { check } from "./commands/check.js";
@@ -60,8 +61,12 @@ const HELP = `nerd: start, check, and deploy a web app on nerdsystem
   nerd logs [--since 30m] [--limit 100] [--q text] [--pr n]  Logs from the deployed app
   nerd audit [--out file.csv]         Export deployments and builds (Studio)
 
-Every command accepts --json for machine-readable output.
+Every command accepts --json for machine-readable output. nerd --version prints the version.
 Operator: nerd admin --help`;
+/** The published version, read from package.json so a release bump is the only place it changes. */
+export function cliVersion() {
+    return createRequire(import.meta.url)("../package.json").version;
+}
 const BOOL = { type: "boolean", default: false };
 const STR = { type: "string" };
 export async function main(argv) {
@@ -70,6 +75,18 @@ export async function main(argv) {
         console.log(HELP);
         return;
     }
+    if (cmd === "version" || cmd === "--version" || cmd === "-v") {
+        if (rest.includes("--json"))
+            console.log(JSON.stringify({ version: cliVersion() }));
+        else
+            console.log(cliVersion());
+        return;
+    }
+    // `nerd <command> --help` prints the help instead of "Unknown option"; admin keeps its own help text.
+    if (cmd !== "admin" && (rest.includes("--help") || rest.includes("-h"))) {
+        console.log(HELP);
+        return;
+    }
     const parse = (options, allowPositionals = true) => parseArgs({ args: rest, options: { json: BOOL, ...options }, allowPositionals, strict: cmd !== "dev" });
     switch (cmd) {
         case "login": {

package/dist/commands/check.js

@@ -121,7 +121,7 @@ export async function runChecks(root, opts) {
     }
     if (opts.typecheck && problems.every((p) => p.endsWith("(warning)") || p.startsWith("Agent instruction files"))) {
         log.step("Typechecking");
-        const code = await run("npx", ["tsc", "-b", "--pretty"], { cwd: root });
+        const code = await run("npx", ["tsc", "-b", "--pretty"], { cwd: root, stdoutToStderr: true });
         if (code !== 0)
             problems.push("Typecheck failed (see errors above).");
     }
@@ -144,7 +144,9 @@ export async function check(opts) {
         }
     }
     // Loaded here, not at the top: the gates import staticChecks from this file.
-    const { runVerify } = await import("./verify.js");
+    const { runVerify, assertRuleHasGate } = await import("./verify.js");
+    if (opts.rule)
+        assertRuleHasGate(opts.rule);
     const out = await runVerify(root, { withBuild: !opts["no-build"], stopOnFail: false, quiet: opts.json, onlyRules: opts.rule ? [opts.rule] : undefined });
     const failed = out.results.filter((r) => r.status === "fail").length;
     if (opts.json)

package/dist/commands/deploy.js

@@ -65,7 +65,10 @@ async function probeAfterDeploy(deployment, url, skip) {
         return skippedProbe("--skip-probe was given");
     if (deployment.status !== "live")
         return skippedProbe(`the deployment status is ${deployment.status}, not live`);
-    await waitForDeployment(url);
+    // Until the dispatcher knows the new script it answers its own 404 page, which has none of the app's
+    // headers or routes; probing that would report false auth failures. Wait, and say so when it never came.
+    if (!(await waitForDeployment(url)))
+        return skippedProbe("the app had not started answering within 30 seconds; open the URL to check, or run nerd deploy again to probe it");
     return probeDeployment(url);
 }
 function printProbe(url, probes) {
@@ -99,7 +102,7 @@ export async function deploy(opts) {
     if (!opts["skip-build"]) {
         log.step("Building with vite");
         ensureDeps(root);
-        await runOrThrow("npx", ["vite", "build"], { cwd: root });
+        await runOrThrow("npx", ["vite", "build"], { cwd: root, stdoutToStderr: true });
     }
     const build = readBuildOutput(root);
     const built = await runGates(BUILD_GATES, { root, build, knownSecrets, log: (l) => log.info(l) }, { stopOnFail: true });
@@ -127,10 +130,12 @@ export async function deploy(opts) {
     }
     const { deployment } = await api.post(projectPath(nerd, "/deployments"), form);
     const { project } = await api.get(projectPath(nerd));
+    log.ok(`Deployed ${deployment.id} (${deployment.status}) → ${project.url}`);
+    if (!opts["skip-probe"] && deployment.status === "live")
+        log.step(`Probing ${project.url}`);
     const probes = await probeAfterDeploy(deployment, project.url, Boolean(opts["skip-probe"]));
     if (opts.json)
         return printJson({ deployment, url: project.url, migrations: mig, probes });
-    log.ok(`Deployed ${deployment.id} (${deployment.status}) → ${project.url}`);
     printProbe(project.url, probes);
     log.info(`First time? Sign up on your app at ${project.url}, then make yourself admin in the dashboard's Auth tab: ${dashboardUrl(api.apiUrl)}/app/${nerd.org}/projects/${nerd.project}/auth`);
 }

package/dist/commands/doctor.d.ts

@@ -1,3 +1,7 @@
+/** The template's Vite needs Node 22.12 or newer (its engines field: ^20.19.0 || >=22.12.0); the CLI asks for 22, so 22.12 is the floor. */
+export declare const NODE_FLOOR = "22.12";
+/** Whether a Node version string ("22.11.0") meets the floor; a 22.0-22.11 machine only failed at `nerd deploy` before. */
+export declare function nodeMeetsFloor(version: string, floor?: string): boolean;
 /** Checks the machine, not the app: the things that stop a newcomer before the first deploy. */
 export declare function doctor(opts: {
     json: boolean;

package/dist/commands/doctor.js

@@ -3,11 +3,18 @@ import { exec, hasTool } from "../gates/code.js";
 import { loadConfig } from "../config.js";
 import { findProjectRoot } from "../project.js";
 import { log, printJson } from "../util.js";
+/** The template's Vite needs Node 22.12 or newer (its engines field: ^20.19.0 || >=22.12.0); the CLI asks for 22, so 22.12 is the floor. */
+export const NODE_FLOOR = "22.12";
+/** Whether a Node version string ("22.11.0") meets the floor; a 22.0-22.11 machine only failed at `nerd deploy` before. */
+export function nodeMeetsFloor(version, floor = NODE_FLOOR) {
+    const [major = 0, minor = 0] = version.split(".").map(Number);
+    const [fMajor = 0, fMinor = 0] = floor.split(".").map(Number);
+    return major > fMajor || (major === fMajor && minor >= fMinor);
+}
 /** Checks the machine, not the app: the things that stop a newcomer before the first deploy. */
 export async function doctor(opts) {
     const checks = [];
-    const nodeMajor = Number(process.versions.node.split(".")[0]);
-    checks.push({ name: "Node.js 22+", ok: nodeMajor >= 22, detail: `v${process.versions.node}`, fix: "Install Node 22 from https://nodejs.org or with your version manager." });
+    checks.push({ name: `Node.js ${NODE_FLOOR}+`, ok: nodeMeetsFloor(process.versions.node), detail: `v${process.versions.node}`, fix: `Install Node ${NODE_FLOOR} or newer from https://nodejs.org` });
     for (const [tool, fix] of [["pnpm", "npm install -g pnpm"], ["git", "Install git from https://git-scm.com"]]) {
         const r = await exec(tool, ["--version"], process.cwd());
         checks.push({ name: tool, ok: r.code === 0, detail: r.code === 0 ? r.stdout.trim().split("\n")[0] ?? "" : "not found", fix });

package/dist/commands/init.d.ts

@@ -12,4 +12,5 @@ export declare function init(dir: string | undefined, args: {
     slug?: string;
     describe?: string;
     "no-create": boolean;
+    json?: boolean;
 }): Promise<void>;

package/dist/commands/init.js

@@ -4,7 +4,7 @@ import path from "node:path";
 import { fileURLToPath } from "node:url";
 import { ApiClient } from "../api.js";
 import { projectPath, writeNerdJson } from "../project.js";
-import { CliError, log } from "../util.js";
+import { CliError, log, printJson } from "../util.js";
 const SLUG_RE = /^[a-z0-9](?:[a-z0-9-]{0,28}[a-z0-9])?$/;
 function templateDir() {
     const here = path.dirname(fileURLToPath(import.meta.url));
@@ -168,10 +168,18 @@ export async function init(dir, args) {
     }
     catch (err) {
         const reason = err instanceof Error ? err.message : String(err);
-        throw new CliError(`The folder is ready but the project was not created: ${reason}\nFix that, then run: cd ${dir} && nerd link --slug ${slug}${args.org ? ` --org ${args.org}` : ""}`);
+        const code = err instanceof CliError && err.code ? err.code : "error";
+        // A plan limit is not something to fix in the folder: the API's message says how to free a slot.
+        const link = `cd ${dir} && nerd link --slug ${slug}${args.org ? ` --org ${args.org}` : ""}`;
+        const next = code === "plan_limit" ? `When a slot is free, run: ${link}` : `Fix that, then run: ${link}`;
+        const message = `The folder is ready but the project was not created: ${reason}`;
+        // Same pattern as `nerd check --json`: the JSON goes to stdout, the exit code stays non-zero.
+        if (args.json)
+            printJson({ error: { code, message }, dir, slug, next });
+        throw new CliError(`${message}\n${next}`, 1, { code });
     }
     initGitRepo(root);
     log.ok(`Ready. Next:\n  cd ${dir}\n  pnpm install\n  nerd dev\n\nThen open the folder in your coding agent and ask it to build the first feature; the nerdsystem skill walks it through.\nDeploys go to ${project.url}`);
 }
 // Kept in sync with packages/sdk/package.json by the release script.
-const SDK_VERSION = "0.0.9";
+const SDK_VERSION = "0.0.11";

package/dist/commands/login.d.ts

@@ -2,7 +2,8 @@
  * `nerd login` with no token starts a device login: prints a link, the person approves it in the
  * dashboard (or from the email when --email is given), and the token arrives here. `--token` still
  * works for scripts. A pending login is remembered, so running `nerd login` again after approving
- * picks it up instead of starting over.
+ * picks it up instead of starting over. `--email` with a different address than the pending login's
+ * starts a fresh one, so a typo does not lock the person out until the code expires.
  */
 export declare function login(args: {
     token?: string;

package/dist/commands/login.js

@@ -8,7 +8,8 @@ const WAIT_S = 90;
  * `nerd login` with no token starts a device login: prints a link, the person approves it in the
  * dashboard (or from the email when --email is given), and the token arrives here. `--token` still
  * works for scripts. A pending login is remembered, so running `nerd login` again after approving
- * picks it up instead of starting over.
+ * picks it up instead of starting over. `--email` with a different address than the pending login's
+ * starts a fresh one, so a typo does not lock the person out until the code expires.
  */
 export async function login(args) {
     const cfg = loadConfig();
@@ -17,23 +18,30 @@ export async function login(args) {
     if (token)
         return finish(apiUrl, token, args.json);
     const anon = new ApiClient(apiUrl, undefined);
-    let pending = cfg.pendingLogin && cfg.pendingLogin.apiUrl === apiUrl && cfg.pendingLogin.expiresAt > Date.now() ? cfg.pendingLogin : undefined;
+    const email = args.email?.trim().toLowerCase() || undefined;
+    const saved = cfg.pendingLogin;
+    // Resume only a login for this API that has not expired and, when --email is given, that went to the same address.
+    const resumable = saved && saved.apiUrl === apiUrl && saved.expiresAt > Date.now() && (!email || saved.email === email);
+    let pending = resumable ? saved : undefined;
     if (!pending) {
         const client = `nerd CLI on ${os.hostname()} (${os.platform()})`;
-        const start = await anon.post("/session/device", { client, ...(args.email ? { email: args.email } : {}) });
-        pending = { apiUrl, deviceCode: start.deviceCode, userCode: start.userCode, verificationUrl: start.verificationUrl, interval: start.interval, expiresAt: Date.now() + start.expiresIn * 1000 };
+        const start = await anon.post("/session/device", { client, ...(email ? { email } : {}) });
+        pending = { apiUrl, deviceCode: start.deviceCode, userCode: start.userCode, verificationUrl: start.verificationUrl, interval: start.interval, expiresAt: Date.now() + start.expiresIn * 1000, ...(email ? { email } : {}) };
         saveConfig({ ...cfg, pendingLogin: pending });
         if (args.json)
             printJson({ status: "pending", userCode: start.userCode, verificationUrl: start.verificationUrl, expiresIn: start.expiresIn });
         else {
-            log.info(`Open this link in your browser and approve code ${start.userCode}:\n\n  ${start.verificationUrl}\n`);
-            if (args.email)
-                log.info(`An email went to ${args.email}: one click signs you in (creating your account if you are new) and approves.`);
+            if (email) {
+                log.info(`An email went to ${email}. Click the link in it (check spam if nothing arrives within a minute), then press Approve on the page it opens. The link works once and expires in 15 minutes. If it never arrives, open ${start.verificationUrl} and sign in there.`);
+            }
+            else {
+                log.info(`Open this link in your browser and approve code ${start.userCode}:\n\n  ${start.verificationUrl}\n`);
+            }
             log.info("Waiting for approval…");
         }
     }
     else if (!args.json) {
-        log.info(`Still waiting for code ${pending.userCode} to be approved at:\n\n  ${pending.verificationUrl}\n`);
+        log.info(`Still waiting for code ${pending.userCode} to be approved at:\n\n  ${pending.verificationUrl}\n\n(run nerd login --email <address> with a different address to start over)`);
     }
     const deadline = Math.min(Date.now() + WAIT_S * 1000, pending.expiresAt);
     while (Date.now() < deadline) {

package/dist/commands/verify.d.ts

@@ -17,6 +17,8 @@ export declare function runVerify(root: string, opts: {
     onlyRules?: string[] | undefined;
     trackAttempts?: boolean;
 }): Promise<VerifyOutput>;
+/** `--rule smoke/x` would select no gate and report "All 0 gates passed"; say which prefixes a gate owns instead. */
+export declare function assertRuleHasGate(rule: string): void;
 export declare function verify(opts: {
     json: boolean;
     "no-build": boolean;

package/dist/commands/verify.js

@@ -35,8 +35,19 @@ export async function runVerify(root, opts) {
     }
     return { ok: results.every((r) => r.status !== "fail"), failures, stop, results };
 }
+/** `--rule smoke/x` would select no gate and report "All 0 gates passed"; say which prefixes a gate owns instead. */
+export function assertRuleHasGate(rule) {
+    const prefixes = [...new Set([...SOURCE_GATES, ...BUILD_GATES].flatMap((g) => g.rulePrefixes))];
+    if (prefixes.some((p) => rule.startsWith(p)))
+        return;
+    if (rule.startsWith("smoke/"))
+        throw new CliError(`No gate runs ${rule} on the source: the live URL is probed by nerd deploy. Deploy again to re-check it.`, 2);
+    throw new CliError(`No gate runs ${rule}. Rule ids start with one of: ${prefixes.join(", ")}`, 2);
+}
 export async function verify(opts) {
     const root = findProjectRoot();
+    if (opts.rule)
+        assertRuleHasGate(opts.rule);
     const out = await runVerify(root, { withBuild: !opts["no-build"], stopOnFail: false, quiet: opts.json, onlyRules: opts.rule ? [opts.rule] : undefined });
     if (opts.json)
         process.stdout.write(`${JSON.stringify({ ok: out.ok, failures: out.failures, stop: out.stop, skipped: skippedGates(out.results) }, null, 2)}\n`);

package/dist/config.d.ts

@@ -1,7 +1,7 @@
 export interface GlobalConfig {
     apiUrl: string;
     token?: string;
-    /** A device login that was started but not yet approved; `nerd login` resumes it. */
+    /** A device login that was started but not yet approved; `nerd login` resumes it. `email` is the address the link went to, so `--email` with another address starts over. */
     pendingLogin?: {
         apiUrl: string;
         deviceCode: string;
@@ -9,6 +9,7 @@ export interface GlobalConfig {
         verificationUrl: string;
         interval: number;
         expiresAt: number;
+        email?: string;
     };
 }
 export declare const DEFAULT_API_URL = "https://api.nerdsystem.com";

package/dist/gates/code.js

@@ -73,14 +73,16 @@ export function depsRuleFor(severity) {
 }
 /** Known vulnerabilities in dependencies. Critical and high block; moderate warns. Package names come from the registry, not the repo. */
 /**
- * The lockfile for the project: in its root, or in an ancestor up to the repository root (the directory holding .git),
- * since a workspace member such as the template inside this monorepo shares the lockfile committed at the top.
+ * The lockfile for the project: in its root, or in an ancestor that is itself a package or workspace root
+ * (it holds a package.json or pnpm-workspace.yaml), searched up to the repository root (the directory holding
+ * .git). A workspace member such as the template inside this monorepo shares the lockfile committed at the top;
+ * a stray lockfile in an unrelated ancestor such as the home folder is never adopted.
  */
 function findLockfile(start) {
     let dir = start;
     for (;;) {
         const hit = ["pnpm-lock.yaml", "package-lock.json", "yarn.lock"].find((f) => existsSync(path.join(dir, f)));
-        if (hit)
+        if (hit && (dir === start || existsSync(path.join(dir, "package.json")) || existsSync(path.join(dir, "pnpm-workspace.yaml"))))
             return path.join(dir, hit);
         const parent = path.dirname(dir);
         if (parent === dir || existsSync(path.join(dir, ".git")))
@@ -101,7 +103,8 @@ export const depsGate = {
         if (!lock)
             findings.push(finding("deps/lockfile-required", {}));
         if (await hasTool("osv-scanner")) {
-            const r = await exec("osv-scanner", ["scan", "source", "--format", "json", "--lockfile", lockPath ?? path.join(ctx.root, "pnpm-lock.yaml")], ctx.root);
+            // Run from the lockfile's own folder with a bare name: on Windows the shell would split an absolute path with a space.
+            const r = await exec("osv-scanner", ["scan", "source", "--format", "json", "--lockfile", lock ?? "pnpm-lock.yaml"], lockPath ? path.dirname(lockPath) : ctx.root);
             try {
                 const json = JSON.parse(r.stdout);
                 for (const res of json.results ?? [])

package/dist/gates/smoke.js

@@ -14,8 +14,10 @@ function withTimeout(init) {
     const signal = typeof AbortSignal.timeout === "function" ? AbortSignal.timeout(PROBE_TIMEOUT_MS) : undefined;
     return { redirect: "manual", ...(signal ? { signal } : {}), ...init };
 }
+/** No gate owns the smoke/ prefix, so `nerd verify --rule smoke/...` would run nothing; the way to re-check is another deploy. */
+const VERIFY = "nerd deploy (the live URL is probed after every deploy)";
 function smokeFinding(ruleId, risk, key) {
-    return finding(ruleId, { risk, fingerprint: fingerprint(ruleId, key) });
+    return { ...finding(ruleId, { risk, fingerprint: fingerprint(ruleId, key) }), verify: VERIFY };
 }
 function probeResult(findings, startedAt) {
     const status = verdict(findings);
@@ -28,7 +30,7 @@ function probeResult(findings, startedAt) {
  * 404 for a script it does not know yet). Returns true as soon as it does; false after the last attempt.
  */
 export async function waitForDeployment(url, opts = {}) {
-    const attempts = opts.attempts ?? 3;
+    const attempts = opts.attempts ?? 8;
     const delayMs = opts.delayMs ?? 2000;
     const fetchImpl = opts.fetchImpl ?? defaultFetch;
     for (let i = 0; i < attempts; i++) {

package/dist/util.d.ts

@@ -10,22 +10,22 @@ export declare class CliError extends Error {
     });
 }
 /** The one sentence every unauthenticated command prints, with both ways in. */
-export declare const NOT_LOGGED_IN = "Not logged in. Run `nerd login --email you@example.com` (one click in the email signs you in and creates your account the first time), or set NERD_TOKEN to an API token for scripts.";
+export declare const NOT_LOGGED_IN = "Not logged in. Run `nerd login --email you@example.com` (the link in the email signs you in, creating your account the first time, and opens a page where you press Approve), or set NERD_TOKEN to an API token for scripts.";
 export declare const log: {
     info: (msg: string) => void;
     step: (msg: string) => void;
     ok: (msg: string) => void;
     warn: (msg: string) => void;
 };
-/** Runs a command, streaming output. Resolves with the exit code. */
-export declare function run(cmd: string, args: string[], opts?: {
-    cwd?: string;
-    env?: NodeJS.ProcessEnv;
-}): Promise<number>;
-export declare function runOrThrow(cmd: string, args: string[], opts?: {
+export interface RunOptions {
     cwd?: string;
     env?: NodeJS.ProcessEnv;
-}): Promise<void>;
+    /** Send the child's stdout to our stderr, so stdout stays reserved for `--json` output. */
+    stdoutToStderr?: boolean;
+}
+/** Runs a command, streaming output. Resolves with the exit code. */
+export declare function run(cmd: string, args: string[], opts?: RunOptions): Promise<number>;
+export declare function runOrThrow(cmd: string, args: string[], opts?: RunOptions): Promise<void>;
 export declare function printJson(value: unknown): void;
 export declare function table(rows: Record<string, unknown>[], columns: string[]): void;
 /** The dashboard that goes with an API origin (https://api.nerdsystem.com -> https://nerdsystem.com). */

package/dist/util.js

@@ -15,7 +15,7 @@ export class CliError extends Error {
     }
 }
 /** The one sentence every unauthenticated command prints, with both ways in. */
-export const NOT_LOGGED_IN = "Not logged in. Run `nerd login --email you@example.com` (one click in the email signs you in and creates your account the first time), or set NERD_TOKEN to an API token for scripts.";
+export const NOT_LOGGED_IN = "Not logged in. Run `nerd login --email you@example.com` (the link in the email signs you in, creating your account the first time, and opens a page where you press Approve), or set NERD_TOKEN to an API token for scripts.";
 export const log = {
     info: (msg) => console.error(`${msg}`),
     step: (msg) => console.error(`\x1b[36m›\x1b[0m ${msg}`),
@@ -25,7 +25,8 @@ export const log = {
 /** Runs a command, streaming output. Resolves with the exit code. */
 export function run(cmd, args, opts = {}) {
     return new Promise((resolve, reject) => {
-        const child = spawn(cmd, args, { cwd: opts.cwd, env: { ...process.env, ...opts.env }, stdio: "inherit", shell: process.platform === "win32" });
+        const child = spawn(cmd, args, { cwd: opts.cwd, env: { ...process.env, ...opts.env }, stdio: ["inherit", opts.stdoutToStderr ? "pipe" : "inherit", "inherit"], shell: process.platform === "win32" });
+        child.stdout?.pipe(process.stderr);
         child.on("error", reject);
         child.on("exit", (code) => resolve(code ?? 1));
     });

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "nerdsystem",
-  "version": "0.0.9",
+  "version": "0.0.11",
   "description": "nerd: start, check, and deploy a web app on nerdsystem from the terminal or a coding agent.",
   "type": "module",
   "bin": {
@@ -14,7 +14,7 @@
     "LICENSE"
   ],
   "engines": {
-    "node": ">=22"
+    "node": ">=22.12"
   },
   "devDependencies": {
     "@types/node": "^22.0.0",

package/template/.claude/skills/nerdsystem/SKILL.md

@@ -11,10 +11,10 @@ This app is deployed by nerdsystem, which also provides authentication, authoriz
 
 If this project still has the template's todo app (the `todos` table and `src/server/routes/todos.ts`), treat the person as new and offer a short walkthrough before building anything:
 
-1. Ask one question: what should the app do, in a sentence or two. Do not ask about stacks, databases, or hosting; those are decided.
+1. Ask one question: what should the app do, in a sentence or two, unless CLAUDE.md already says what the app does (`nerd init` writes the description at the top). Do not ask about stacks, databases, or hosting; those are decided.
 2. Say what you will build first, in plain words: the one table and the one screen that make the idea real. Keep the first feature small enough to deploy within the session.
 3. Replace the todo example with that feature: schema, migration (`pnpm db:generate`), a router under `/api/...`, and the client screen. The template is a normal website: a public homepage at `/`, auth pages at `/login`, `/signup`, `/forgot-password`, `/reset-password`, and a signed-in area. Reshape it to the idea (a public landing page with sign-in in the header, a members-only area, an admin section) rather than forcing a login wall; the forms already work.
-4. Run `nerd check`, then `nerd dev`, and tell the person to open the local URL, create an account, and try it. Fix what they report.
+4. Run `nerd check`. Then, unless the person asked to go straight to a live URL, run `nerd dev` and tell them to open the local URL, create an account, and try it. Fix what they report. When they want the live URL first, skip `nerd dev` and go to the next step; they can try it on the deployed app.
 5. Run `nerd deploy` and give them the live URL. Tell them to sign up on their own app first, then make themselves admin in the dashboard's Auth tab (the URL is printed after the deploy). Explain in two lines that every deploy is checked for leaked secrets and vulnerable dependencies, and that they can run `nerd check` any time.
 6. Offer the next steps once, briefly: link the GitHub repo for previews on pull requests (`nerd github connect`), add a custom domain, or invite a teammate from the dashboard.
 
@@ -36,14 +36,14 @@ Tell the person plainly what does not carry. Their users sign up again on the ne
 1. Make the change.
 2. `nerd check` (static rules, then typecheck). Fix anything it reports.
 3. `nerd dev` to run locally when you need to try it. The local app talks to the real auth service, so signup and login work exactly as in production.
-4. `nerd deploy` when it is ready. It runs the checks, builds, applies pending migrations, uploads, and prints the URL.
+4. `nerd deploy` when it is ready. It runs the checks, builds, applies pending migrations, uploads, prints the URL, and probes the live URL (headers and the sign-in routes). With `--json` the output carries `probes`, the same shape as a check result, with `status: "skip"` and the reason when it did not run; probe findings never fail the deploy.
 5. If something is wrong after deploying: `nerd logs` shows recent output from the deployed app (`--q` to search, `--pr 12` for a preview), `nerd deployments` shows status and errors, `nerd db query "..."` inspects production data.
 
 Run `nerd check --json` when you want a machine-readable list of problems. Its summary says how many gates ran and which were skipped (`skipped` in the JSON): semgrep and gitleaks only run locally when installed; git builds always run them in the builder.
 
 ## Deploying from GitHub
 
-Once the repo is linked (`nerd github connect`, then `nerd github link owner/repo`), every push to the production branch builds and deploys automatically (for accounts younger than seven days, counted from the nerdsystem account's creation, git builds are deferred: deploy with `nerd deploy` from the machine until then), and every pull request gets a preview at its own URL, posted as a PR comment. `nerd builds` lists builds; `nerd builds show <id>` prints the log when one fails. A failing build reports the same `nerd check` problems you would see locally, so fix and push again. Every preview gets its own database and bucket, and pending migrations are applied to it on each preview build, so a PR that changes the schema can be tried end to end before it merges.
+Once the repo is linked (`nerd github connect`, then `nerd github link owner/repo`), every push to the production branch builds and deploys automatically, and every pull request gets a preview at its own URL, posted as a PR comment. `nerd builds` lists builds; `nerd builds show <id>` prints the log when one fails. A failing build reports the same `nerd check` problems you would see locally, so fix and push again. Every preview gets its own database and bucket, and pending migrations are applied to it on each preview build, so a PR that changes the schema can be tried end to end before it merges.
 
 ## Where things go
 
@@ -127,7 +127,7 @@ Without MCP, `nerd check --json` returns the same shape, and `nerd check --rule
 
 - **Scheduled jobs**: put the work in the `POST /api/cron` handler (already in `src/server/index.ts`, guarded by `verifyCron()`), then turn the schedule on with `nerd cron hourly` or `nerd cron daily`. The platform calls it; the app never needs its own timer.
 - **Secrets** (Stripe keys, API tokens): never in code or in the client. Locally they live in `.dev.vars` (gitignored). For production, ask the person to run `nerd secret set NAME` and paste the value; it reaches the app as `c.env.NAME` on the next deploy. Pull request previews do not get it unless it was set with `--previews` (use that only for keys that are safe in a preview, such as a test-mode key). `nerd secret list` shows names only. Do not put a real secret value in any command you run yourself.
-- **Email**: `sendEmail(c.env, { to, subject, text, html? })` from `@nerdsystem/sdk` sends through the platform. It is limited per day by plan (50 on Free, 1,000 on Pro at $39 a month, 2,000 on Studio at $99 a month), so use it for transactional mail such as receipts and notifications, not bulk. Plans can be paid monthly or yearly at ten times the monthly price.
+- **Email**: `sendEmail(c.env, { to, subject, text, html? })` from `@nerdsystem/sdk` sends through the platform. The relay only sends to addresses that have an account on this app (someone who signed up); any other recipient is refused with a 400, and the sender name is always the app's name. It is limited per day by plan (50 on Free, 1,000 on Pro at $39 a month, 2,000 on Studio at $99 a month), so use it for transactional mail such as receipts and notifications, not bulk. Plans can be paid monthly or yearly at ten times the monthly price.
 
 ## Debugging production
 

package/template/.cursor/rules/nerdsystem.mdc

@@ -2,7 +2,7 @@
 description: How to build, run, and deploy this app on nerdsystem. Applies to server, database, auth, and deploy work.
 alwaysApply: true
 ---
-<!-- generated from .claude/skills/nerdsystem/SKILL.md (f8685cd08ad1); edit the skill, then run: nerd agents sync -->
+<!-- generated from .claude/skills/nerdsystem/SKILL.md (31894f024834); edit the skill, then run: nerd agents sync -->
 
 # Building on nerdsystem
 
@@ -12,10 +12,10 @@ This app is deployed by nerdsystem, which also provides authentication, authoriz
 
 If this project still has the template's todo app (the `todos` table and `src/server/routes/todos.ts`), treat the person as new and offer a short walkthrough before building anything:
 
-1. Ask one question: what should the app do, in a sentence or two. Do not ask about stacks, databases, or hosting; those are decided.
+1. Ask one question: what should the app do, in a sentence or two, unless CLAUDE.md already says what the app does (`nerd init` writes the description at the top). Do not ask about stacks, databases, or hosting; those are decided.
 2. Say what you will build first, in plain words: the one table and the one screen that make the idea real. Keep the first feature small enough to deploy within the session.
 3. Replace the todo example with that feature: schema, migration (`pnpm db:generate`), a router under `/api/...`, and the client screen. The template is a normal website: a public homepage at `/`, auth pages at `/login`, `/signup`, `/forgot-password`, `/reset-password`, and a signed-in area. Reshape it to the idea (a public landing page with sign-in in the header, a members-only area, an admin section) rather than forcing a login wall; the forms already work.
-4. Run `nerd check`, then `nerd dev`, and tell the person to open the local URL, create an account, and try it. Fix what they report.
+4. Run `nerd check`. Then, unless the person asked to go straight to a live URL, run `nerd dev` and tell them to open the local URL, create an account, and try it. Fix what they report. When they want the live URL first, skip `nerd dev` and go to the next step; they can try it on the deployed app.
 5. Run `nerd deploy` and give them the live URL. Tell them to sign up on their own app first, then make themselves admin in the dashboard's Auth tab (the URL is printed after the deploy). Explain in two lines that every deploy is checked for leaked secrets and vulnerable dependencies, and that they can run `nerd check` any time.
 6. Offer the next steps once, briefly: link the GitHub repo for previews on pull requests (`nerd github connect`), add a custom domain, or invite a teammate from the dashboard.
 
@@ -37,14 +37,14 @@ Tell the person plainly what does not carry. Their users sign up again on the ne
 1. Make the change.
 2. `nerd check` (static rules, then typecheck). Fix anything it reports.
 3. `nerd dev` to run locally when you need to try it. The local app talks to the real auth service, so signup and login work exactly as in production.
-4. `nerd deploy` when it is ready. It runs the checks, builds, applies pending migrations, uploads, and prints the URL.
+4. `nerd deploy` when it is ready. It runs the checks, builds, applies pending migrations, uploads, prints the URL, and probes the live URL (headers and the sign-in routes). With `--json` the output carries `probes`, the same shape as a check result, with `status: "skip"` and the reason when it did not run; probe findings never fail the deploy.
 5. If something is wrong after deploying: `nerd logs` shows recent output from the deployed app (`--q` to search, `--pr 12` for a preview), `nerd deployments` shows status and errors, `nerd db query "..."` inspects production data.
 
 Run `nerd check --json` when you want a machine-readable list of problems. Its summary says how many gates ran and which were skipped (`skipped` in the JSON): semgrep and gitleaks only run locally when installed; git builds always run them in the builder.
 
 ## Deploying from GitHub
 
-Once the repo is linked (`nerd github connect`, then `nerd github link owner/repo`), every push to the production branch builds and deploys automatically (for accounts younger than seven days, counted from the nerdsystem account's creation, git builds are deferred: deploy with `nerd deploy` from the machine until then), and every pull request gets a preview at its own URL, posted as a PR comment. `nerd builds` lists builds; `nerd builds show <id>` prints the log when one fails. A failing build reports the same `nerd check` problems you would see locally, so fix and push again. Every preview gets its own database and bucket, and pending migrations are applied to it on each preview build, so a PR that changes the schema can be tried end to end before it merges.
+Once the repo is linked (`nerd github connect`, then `nerd github link owner/repo`), every push to the production branch builds and deploys automatically, and every pull request gets a preview at its own URL, posted as a PR comment. `nerd builds` lists builds; `nerd builds show <id>` prints the log when one fails. A failing build reports the same `nerd check` problems you would see locally, so fix and push again. Every preview gets its own database and bucket, and pending migrations are applied to it on each preview build, so a PR that changes the schema can be tried end to end before it merges.
 
 ## Where things go
 
@@ -128,7 +128,7 @@ Without MCP, `nerd check --json` returns the same shape, and `nerd check --rule
 
 - **Scheduled jobs**: put the work in the `POST /api/cron` handler (already in `src/server/index.ts`, guarded by `verifyCron()`), then turn the schedule on with `nerd cron hourly` or `nerd cron daily`. The platform calls it; the app never needs its own timer.
 - **Secrets** (Stripe keys, API tokens): never in code or in the client. Locally they live in `.dev.vars` (gitignored). For production, ask the person to run `nerd secret set NAME` and paste the value; it reaches the app as `c.env.NAME` on the next deploy. Pull request previews do not get it unless it was set with `--previews` (use that only for keys that are safe in a preview, such as a test-mode key). `nerd secret list` shows names only. Do not put a real secret value in any command you run yourself.
-- **Email**: `sendEmail(c.env, { to, subject, text, html? })` from `@nerdsystem/sdk` sends through the platform. It is limited per day by plan (50 on Free, 1,000 on Pro at $39 a month, 2,000 on Studio at $99 a month), so use it for transactional mail such as receipts and notifications, not bulk. Plans can be paid monthly or yearly at ten times the monthly price.
+- **Email**: `sendEmail(c.env, { to, subject, text, html? })` from `@nerdsystem/sdk` sends through the platform. The relay only sends to addresses that have an account on this app (someone who signed up); any other recipient is refused with a 400, and the sender name is always the app's name. It is limited per day by plan (50 on Free, 1,000 on Pro at $39 a month, 2,000 on Studio at $99 a month), so use it for transactional mail such as receipts and notifications, not bulk. Plans can be paid monthly or yearly at ten times the monthly price.
 
 ## Debugging production
 

package/template/.github/copilot-instructions.md

@@ -1,4 +1,4 @@
-<!-- generated from .claude/skills/nerdsystem/SKILL.md (f8685cd08ad1); edit the skill, then run: nerd agents sync -->
+<!-- generated from .claude/skills/nerdsystem/SKILL.md (31894f024834); edit the skill, then run: nerd agents sync -->
 
 # Building on nerdsystem
 
@@ -8,10 +8,10 @@ This app is deployed by nerdsystem, which also provides authentication, authoriz
 
 If this project still has the template's todo app (the `todos` table and `src/server/routes/todos.ts`), treat the person as new and offer a short walkthrough before building anything:
 
-1. Ask one question: what should the app do, in a sentence or two. Do not ask about stacks, databases, or hosting; those are decided.
+1. Ask one question: what should the app do, in a sentence or two, unless CLAUDE.md already says what the app does (`nerd init` writes the description at the top). Do not ask about stacks, databases, or hosting; those are decided.
 2. Say what you will build first, in plain words: the one table and the one screen that make the idea real. Keep the first feature small enough to deploy within the session.
 3. Replace the todo example with that feature: schema, migration (`pnpm db:generate`), a router under `/api/...`, and the client screen. The template is a normal website: a public homepage at `/`, auth pages at `/login`, `/signup`, `/forgot-password`, `/reset-password`, and a signed-in area. Reshape it to the idea (a public landing page with sign-in in the header, a members-only area, an admin section) rather than forcing a login wall; the forms already work.
-4. Run `nerd check`, then `nerd dev`, and tell the person to open the local URL, create an account, and try it. Fix what they report.
+4. Run `nerd check`. Then, unless the person asked to go straight to a live URL, run `nerd dev` and tell them to open the local URL, create an account, and try it. Fix what they report. When they want the live URL first, skip `nerd dev` and go to the next step; they can try it on the deployed app.
 5. Run `nerd deploy` and give them the live URL. Tell them to sign up on their own app first, then make themselves admin in the dashboard's Auth tab (the URL is printed after the deploy). Explain in two lines that every deploy is checked for leaked secrets and vulnerable dependencies, and that they can run `nerd check` any time.
 6. Offer the next steps once, briefly: link the GitHub repo for previews on pull requests (`nerd github connect`), add a custom domain, or invite a teammate from the dashboard.
 
@@ -33,14 +33,14 @@ Tell the person plainly what does not carry. Their users sign up again on the ne
 1. Make the change.
 2. `nerd check` (static rules, then typecheck). Fix anything it reports.
 3. `nerd dev` to run locally when you need to try it. The local app talks to the real auth service, so signup and login work exactly as in production.
-4. `nerd deploy` when it is ready. It runs the checks, builds, applies pending migrations, uploads, and prints the URL.
+4. `nerd deploy` when it is ready. It runs the checks, builds, applies pending migrations, uploads, prints the URL, and probes the live URL (headers and the sign-in routes). With `--json` the output carries `probes`, the same shape as a check result, with `status: "skip"` and the reason when it did not run; probe findings never fail the deploy.
 5. If something is wrong after deploying: `nerd logs` shows recent output from the deployed app (`--q` to search, `--pr 12` for a preview), `nerd deployments` shows status and errors, `nerd db query "..."` inspects production data.
 
 Run `nerd check --json` when you want a machine-readable list of problems. Its summary says how many gates ran and which were skipped (`skipped` in the JSON): semgrep and gitleaks only run locally when installed; git builds always run them in the builder.
 
 ## Deploying from GitHub
 
-Once the repo is linked (`nerd github connect`, then `nerd github link owner/repo`), every push to the production branch builds and deploys automatically (for accounts younger than seven days, counted from the nerdsystem account's creation, git builds are deferred: deploy with `nerd deploy` from the machine until then), and every pull request gets a preview at its own URL, posted as a PR comment. `nerd builds` lists builds; `nerd builds show <id>` prints the log when one fails. A failing build reports the same `nerd check` problems you would see locally, so fix and push again. Every preview gets its own database and bucket, and pending migrations are applied to it on each preview build, so a PR that changes the schema can be tried end to end before it merges.
+Once the repo is linked (`nerd github connect`, then `nerd github link owner/repo`), every push to the production branch builds and deploys automatically, and every pull request gets a preview at its own URL, posted as a PR comment. `nerd builds` lists builds; `nerd builds show <id>` prints the log when one fails. A failing build reports the same `nerd check` problems you would see locally, so fix and push again. Every preview gets its own database and bucket, and pending migrations are applied to it on each preview build, so a PR that changes the schema can be tried end to end before it merges.
 
 ## Where things go
 
@@ -124,7 +124,7 @@ Without MCP, `nerd check --json` returns the same shape, and `nerd check --rule
 
 - **Scheduled jobs**: put the work in the `POST /api/cron` handler (already in `src/server/index.ts`, guarded by `verifyCron()`), then turn the schedule on with `nerd cron hourly` or `nerd cron daily`. The platform calls it; the app never needs its own timer.
 - **Secrets** (Stripe keys, API tokens): never in code or in the client. Locally they live in `.dev.vars` (gitignored). For production, ask the person to run `nerd secret set NAME` and paste the value; it reaches the app as `c.env.NAME` on the next deploy. Pull request previews do not get it unless it was set with `--previews` (use that only for keys that are safe in a preview, such as a test-mode key). `nerd secret list` shows names only. Do not put a real secret value in any command you run yourself.
-- **Email**: `sendEmail(c.env, { to, subject, text, html? })` from `@nerdsystem/sdk` sends through the platform. It is limited per day by plan (50 on Free, 1,000 on Pro at $39 a month, 2,000 on Studio at $99 a month), so use it for transactional mail such as receipts and notifications, not bulk. Plans can be paid monthly or yearly at ten times the monthly price.
+- **Email**: `sendEmail(c.env, { to, subject, text, html? })` from `@nerdsystem/sdk` sends through the platform. The relay only sends to addresses that have an account on this app (someone who signed up); any other recipient is refused with a 400, and the sender name is always the app's name. It is limited per day by plan (50 on Free, 1,000 on Pro at $39 a month, 2,000 on Studio at $99 a month), so use it for transactional mail such as receipts and notifications, not bulk. Plans can be paid monthly or yearly at ten times the monthly price.
 
 ## Debugging production
 

package/template/AGENTS.md

@@ -1,4 +1,4 @@
-<!-- generated from .claude/skills/nerdsystem/SKILL.md (f8685cd08ad1); edit the skill, then run: nerd agents sync -->
+<!-- generated from .claude/skills/nerdsystem/SKILL.md (31894f024834); edit the skill, then run: nerd agents sync -->
 
 # Building on nerdsystem
 
@@ -8,10 +8,10 @@ This app is deployed by nerdsystem, which also provides authentication, authoriz
 
 If this project still has the template's todo app (the `todos` table and `src/server/routes/todos.ts`), treat the person as new and offer a short walkthrough before building anything:
 
-1. Ask one question: what should the app do, in a sentence or two. Do not ask about stacks, databases, or hosting; those are decided.
+1. Ask one question: what should the app do, in a sentence or two, unless CLAUDE.md already says what the app does (`nerd init` writes the description at the top). Do not ask about stacks, databases, or hosting; those are decided.
 2. Say what you will build first, in plain words: the one table and the one screen that make the idea real. Keep the first feature small enough to deploy within the session.
 3. Replace the todo example with that feature: schema, migration (`pnpm db:generate`), a router under `/api/...`, and the client screen. The template is a normal website: a public homepage at `/`, auth pages at `/login`, `/signup`, `/forgot-password`, `/reset-password`, and a signed-in area. Reshape it to the idea (a public landing page with sign-in in the header, a members-only area, an admin section) rather than forcing a login wall; the forms already work.
-4. Run `nerd check`, then `nerd dev`, and tell the person to open the local URL, create an account, and try it. Fix what they report.
+4. Run `nerd check`. Then, unless the person asked to go straight to a live URL, run `nerd dev` and tell them to open the local URL, create an account, and try it. Fix what they report. When they want the live URL first, skip `nerd dev` and go to the next step; they can try it on the deployed app.
 5. Run `nerd deploy` and give them the live URL. Tell them to sign up on their own app first, then make themselves admin in the dashboard's Auth tab (the URL is printed after the deploy). Explain in two lines that every deploy is checked for leaked secrets and vulnerable dependencies, and that they can run `nerd check` any time.
 6. Offer the next steps once, briefly: link the GitHub repo for previews on pull requests (`nerd github connect`), add a custom domain, or invite a teammate from the dashboard.
 
@@ -33,14 +33,14 @@ Tell the person plainly what does not carry. Their users sign up again on the ne
 1. Make the change.
 2. `nerd check` (static rules, then typecheck). Fix anything it reports.
 3. `nerd dev` to run locally when you need to try it. The local app talks to the real auth service, so signup and login work exactly as in production.
-4. `nerd deploy` when it is ready. It runs the checks, builds, applies pending migrations, uploads, and prints the URL.
+4. `nerd deploy` when it is ready. It runs the checks, builds, applies pending migrations, uploads, prints the URL, and probes the live URL (headers and the sign-in routes). With `--json` the output carries `probes`, the same shape as a check result, with `status: "skip"` and the reason when it did not run; probe findings never fail the deploy.
 5. If something is wrong after deploying: `nerd logs` shows recent output from the deployed app (`--q` to search, `--pr 12` for a preview), `nerd deployments` shows status and errors, `nerd db query "..."` inspects production data.
 
 Run `nerd check --json` when you want a machine-readable list of problems. Its summary says how many gates ran and which were skipped (`skipped` in the JSON): semgrep and gitleaks only run locally when installed; git builds always run them in the builder.
 
 ## Deploying from GitHub
 
-Once the repo is linked (`nerd github connect`, then `nerd github link owner/repo`), every push to the production branch builds and deploys automatically (for accounts younger than seven days, counted from the nerdsystem account's creation, git builds are deferred: deploy with `nerd deploy` from the machine until then), and every pull request gets a preview at its own URL, posted as a PR comment. `nerd builds` lists builds; `nerd builds show <id>` prints the log when one fails. A failing build reports the same `nerd check` problems you would see locally, so fix and push again. Every preview gets its own database and bucket, and pending migrations are applied to it on each preview build, so a PR that changes the schema can be tried end to end before it merges.
+Once the repo is linked (`nerd github connect`, then `nerd github link owner/repo`), every push to the production branch builds and deploys automatically, and every pull request gets a preview at its own URL, posted as a PR comment. `nerd builds` lists builds; `nerd builds show <id>` prints the log when one fails. A failing build reports the same `nerd check` problems you would see locally, so fix and push again. Every preview gets its own database and bucket, and pending migrations are applied to it on each preview build, so a PR that changes the schema can be tried end to end before it merges.
 
 ## Where things go
 
@@ -124,7 +124,7 @@ Without MCP, `nerd check --json` returns the same shape, and `nerd check --rule
 
 - **Scheduled jobs**: put the work in the `POST /api/cron` handler (already in `src/server/index.ts`, guarded by `verifyCron()`), then turn the schedule on with `nerd cron hourly` or `nerd cron daily`. The platform calls it; the app never needs its own timer.
 - **Secrets** (Stripe keys, API tokens): never in code or in the client. Locally they live in `.dev.vars` (gitignored). For production, ask the person to run `nerd secret set NAME` and paste the value; it reaches the app as `c.env.NAME` on the next deploy. Pull request previews do not get it unless it was set with `--previews` (use that only for keys that are safe in a preview, such as a test-mode key). `nerd secret list` shows names only. Do not put a real secret value in any command you run yourself.
-- **Email**: `sendEmail(c.env, { to, subject, text, html? })` from `@nerdsystem/sdk` sends through the platform. It is limited per day by plan (50 on Free, 1,000 on Pro at $39 a month, 2,000 on Studio at $99 a month), so use it for transactional mail such as receipts and notifications, not bulk. Plans can be paid monthly or yearly at ten times the monthly price.
+- **Email**: `sendEmail(c.env, { to, subject, text, html? })` from `@nerdsystem/sdk` sends through the platform. The relay only sends to addresses that have an account on this app (someone who signed up); any other recipient is refused with a 400, and the sender name is always the app's name. It is limited per day by plan (50 on Free, 1,000 on Pro at $39 a month, 2,000 on Studio at $99 a month), so use it for transactional mail such as receipts and notifications, not bulk. Plans can be paid monthly or yearly at ten times the monthly price.
 
 ## Debugging production
 

package/template/GEMINI.md

@@ -1,4 +1,4 @@
-<!-- generated from .claude/skills/nerdsystem/SKILL.md (f8685cd08ad1); edit the skill, then run: nerd agents sync -->
+<!-- generated from .claude/skills/nerdsystem/SKILL.md (31894f024834); edit the skill, then run: nerd agents sync -->
 
 # Building on nerdsystem
 
@@ -8,10 +8,10 @@ This app is deployed by nerdsystem, which also provides authentication, authoriz
 
 If this project still has the template's todo app (the `todos` table and `src/server/routes/todos.ts`), treat the person as new and offer a short walkthrough before building anything:
 
-1. Ask one question: what should the app do, in a sentence or two. Do not ask about stacks, databases, or hosting; those are decided.
+1. Ask one question: what should the app do, in a sentence or two, unless CLAUDE.md already says what the app does (`nerd init` writes the description at the top). Do not ask about stacks, databases, or hosting; those are decided.
 2. Say what you will build first, in plain words: the one table and the one screen that make the idea real. Keep the first feature small enough to deploy within the session.
 3. Replace the todo example with that feature: schema, migration (`pnpm db:generate`), a router under `/api/...`, and the client screen. The template is a normal website: a public homepage at `/`, auth pages at `/login`, `/signup`, `/forgot-password`, `/reset-password`, and a signed-in area. Reshape it to the idea (a public landing page with sign-in in the header, a members-only area, an admin section) rather than forcing a login wall; the forms already work.
-4. Run `nerd check`, then `nerd dev`, and tell the person to open the local URL, create an account, and try it. Fix what they report.
+4. Run `nerd check`. Then, unless the person asked to go straight to a live URL, run `nerd dev` and tell them to open the local URL, create an account, and try it. Fix what they report. When they want the live URL first, skip `nerd dev` and go to the next step; they can try it on the deployed app.
 5. Run `nerd deploy` and give them the live URL. Tell them to sign up on their own app first, then make themselves admin in the dashboard's Auth tab (the URL is printed after the deploy). Explain in two lines that every deploy is checked for leaked secrets and vulnerable dependencies, and that they can run `nerd check` any time.
 6. Offer the next steps once, briefly: link the GitHub repo for previews on pull requests (`nerd github connect`), add a custom domain, or invite a teammate from the dashboard.
 
@@ -33,14 +33,14 @@ Tell the person plainly what does not carry. Their users sign up again on the ne
 1. Make the change.
 2. `nerd check` (static rules, then typecheck). Fix anything it reports.
 3. `nerd dev` to run locally when you need to try it. The local app talks to the real auth service, so signup and login work exactly as in production.
-4. `nerd deploy` when it is ready. It runs the checks, builds, applies pending migrations, uploads, and prints the URL.
+4. `nerd deploy` when it is ready. It runs the checks, builds, applies pending migrations, uploads, prints the URL, and probes the live URL (headers and the sign-in routes). With `--json` the output carries `probes`, the same shape as a check result, with `status: "skip"` and the reason when it did not run; probe findings never fail the deploy.
 5. If something is wrong after deploying: `nerd logs` shows recent output from the deployed app (`--q` to search, `--pr 12` for a preview), `nerd deployments` shows status and errors, `nerd db query "..."` inspects production data.
 
 Run `nerd check --json` when you want a machine-readable list of problems. Its summary says how many gates ran and which were skipped (`skipped` in the JSON): semgrep and gitleaks only run locally when installed; git builds always run them in the builder.
 
 ## Deploying from GitHub
 
-Once the repo is linked (`nerd github connect`, then `nerd github link owner/repo`), every push to the production branch builds and deploys automatically (for accounts younger than seven days, counted from the nerdsystem account's creation, git builds are deferred: deploy with `nerd deploy` from the machine until then), and every pull request gets a preview at its own URL, posted as a PR comment. `nerd builds` lists builds; `nerd builds show <id>` prints the log when one fails. A failing build reports the same `nerd check` problems you would see locally, so fix and push again. Every preview gets its own database and bucket, and pending migrations are applied to it on each preview build, so a PR that changes the schema can be tried end to end before it merges.
+Once the repo is linked (`nerd github connect`, then `nerd github link owner/repo`), every push to the production branch builds and deploys automatically, and every pull request gets a preview at its own URL, posted as a PR comment. `nerd builds` lists builds; `nerd builds show <id>` prints the log when one fails. A failing build reports the same `nerd check` problems you would see locally, so fix and push again. Every preview gets its own database and bucket, and pending migrations are applied to it on each preview build, so a PR that changes the schema can be tried end to end before it merges.
 
 ## Where things go
 
@@ -124,7 +124,7 @@ Without MCP, `nerd check --json` returns the same shape, and `nerd check --rule
 
 - **Scheduled jobs**: put the work in the `POST /api/cron` handler (already in `src/server/index.ts`, guarded by `verifyCron()`), then turn the schedule on with `nerd cron hourly` or `nerd cron daily`. The platform calls it; the app never needs its own timer.
 - **Secrets** (Stripe keys, API tokens): never in code or in the client. Locally they live in `.dev.vars` (gitignored). For production, ask the person to run `nerd secret set NAME` and paste the value; it reaches the app as `c.env.NAME` on the next deploy. Pull request previews do not get it unless it was set with `--previews` (use that only for keys that are safe in a preview, such as a test-mode key). `nerd secret list` shows names only. Do not put a real secret value in any command you run yourself.
-- **Email**: `sendEmail(c.env, { to, subject, text, html? })` from `@nerdsystem/sdk` sends through the platform. It is limited per day by plan (50 on Free, 1,000 on Pro at $39 a month, 2,000 on Studio at $99 a month), so use it for transactional mail such as receipts and notifications, not bulk. Plans can be paid monthly or yearly at ten times the monthly price.
+- **Email**: `sendEmail(c.env, { to, subject, text, html? })` from `@nerdsystem/sdk` sends through the platform. The relay only sends to addresses that have an account on this app (someone who signed up); any other recipient is refused with a 400, and the sender name is always the app's name. It is limited per day by plan (50 on Free, 1,000 on Pro at $39 a month, 2,000 on Studio at $99 a month), so use it for transactional mail such as receipts and notifications, not bulk. Plans can be paid monthly or yearly at ten times the monthly price.
 
 ## Debugging production