nerdsystem 0.0.10 → 0.0.12

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "nerdsystem",
-  "version": "0.0.10",
+  "version": "0.0.12",
   "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",
@@ -26,6 +26,7 @@
     "./gates": "./dist/gates/index.js",
     "./gates/text": "./dist/gates/text.js",
     "./gates/rules": "./dist/gates/rules.js",
+    "./snapshot": "./dist/snapshot.js",
     "./project": "./dist/project.js",
     "./api": "./dist/api.js",
     "./commands/check": "./dist/commands/check.js",

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

@@ -11,12 +11,12 @@ 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.
+6. Tell them their code is saved on nerdsystem with every deploy and every `nerd save`, and that work since the last save is only on this computer. Then offer the next steps once, briefly: putting the code on GitHub as well (`nerd github connect`; explain that it adds deploys on push and a preview URL for each pull request), a custom domain, or inviting a teammate from the dashboard.
 
 Throughout, show commands rather than describing them, and never ask the person to edit config files; the platform owns `wrangler.jsonc` and `nerd.json`.
 
@@ -36,11 +36,19 @@ 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, 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.
+4. `nerd deploy` when it is ready. It runs the checks, builds, stores a copy of the code, 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.
 
+## Saving and restoring the code
+
+Every `nerd deploy` stores a copy of the code with the deployment, and `nerd save` stores one without deploying. Run `nerd save` at the end of every working session so the person's work is kept even when it was not deployed; it prints "Nothing changed since the last save." when there is nothing new. Work since the last save or deploy exists only on this computer, so say that whenever you tell the person their work is saved.
+
+On a new computer, or when the folder is lost: `nerd pull <org>/<project>`, then `pnpm install`, then `nerd dev`. `nerd pull` restores the newest saved copy into a new folder; `--deployment <id>` restores the code of a specific deploy. If `nerd deploy` stops because the live app was deployed from another copy of the code, run `nerd pull` to work from that copy, or `nerd deploy --force` only when the person confirms this copy should replace it.
+
+GitHub is optional. The next section says what connecting it adds.
+
 ## 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, 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.
@@ -127,7 +135,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 (10dcd79a44bd); edit the skill, then run: nerd agents sync -->
+<!-- generated from .claude/skills/nerdsystem/SKILL.md (0e64cbbdd978); edit the skill, then run: nerd agents sync -->
 
 # Building on nerdsystem
 
@@ -12,12 +12,12 @@ 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.
+6. Tell them their code is saved on nerdsystem with every deploy and every `nerd save`, and that work since the last save is only on this computer. Then offer the next steps once, briefly: putting the code on GitHub as well (`nerd github connect`; explain that it adds deploys on push and a preview URL for each pull request), a custom domain, or inviting a teammate from the dashboard.
 
 Throughout, show commands rather than describing them, and never ask the person to edit config files; the platform owns `wrangler.jsonc` and `nerd.json`.
 
@@ -37,11 +37,19 @@ 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, 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.
+4. `nerd deploy` when it is ready. It runs the checks, builds, stores a copy of the code, 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.
 
+## Saving and restoring the code
+
+Every `nerd deploy` stores a copy of the code with the deployment, and `nerd save` stores one without deploying. Run `nerd save` at the end of every working session so the person's work is kept even when it was not deployed; it prints "Nothing changed since the last save." when there is nothing new. Work since the last save or deploy exists only on this computer, so say that whenever you tell the person their work is saved.
+
+On a new computer, or when the folder is lost: `nerd pull <org>/<project>`, then `pnpm install`, then `nerd dev`. `nerd pull` restores the newest saved copy into a new folder; `--deployment <id>` restores the code of a specific deploy. If `nerd deploy` stops because the live app was deployed from another copy of the code, run `nerd pull` to work from that copy, or `nerd deploy --force` only when the person confirms this copy should replace it.
+
+GitHub is optional. The next section says what connecting it adds.
+
 ## 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, 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.
@@ -128,7 +136,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 (10dcd79a44bd); edit the skill, then run: nerd agents sync -->
+<!-- generated from .claude/skills/nerdsystem/SKILL.md (0e64cbbdd978); edit the skill, then run: nerd agents sync -->
 
 # Building on nerdsystem
 
@@ -8,12 +8,12 @@ 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.
+6. Tell them their code is saved on nerdsystem with every deploy and every `nerd save`, and that work since the last save is only on this computer. Then offer the next steps once, briefly: putting the code on GitHub as well (`nerd github connect`; explain that it adds deploys on push and a preview URL for each pull request), a custom domain, or inviting a teammate from the dashboard.
 
 Throughout, show commands rather than describing them, and never ask the person to edit config files; the platform owns `wrangler.jsonc` and `nerd.json`.
 
@@ -33,11 +33,19 @@ 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, 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.
+4. `nerd deploy` when it is ready. It runs the checks, builds, stores a copy of the code, 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.
 
+## Saving and restoring the code
+
+Every `nerd deploy` stores a copy of the code with the deployment, and `nerd save` stores one without deploying. Run `nerd save` at the end of every working session so the person's work is kept even when it was not deployed; it prints "Nothing changed since the last save." when there is nothing new. Work since the last save or deploy exists only on this computer, so say that whenever you tell the person their work is saved.
+
+On a new computer, or when the folder is lost: `nerd pull <org>/<project>`, then `pnpm install`, then `nerd dev`. `nerd pull` restores the newest saved copy into a new folder; `--deployment <id>` restores the code of a specific deploy. If `nerd deploy` stops because the live app was deployed from another copy of the code, run `nerd pull` to work from that copy, or `nerd deploy --force` only when the person confirms this copy should replace it.
+
+GitHub is optional. The next section says what connecting it adds.
+
 ## 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, 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.
@@ -124,7 +132,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 (10dcd79a44bd); edit the skill, then run: nerd agents sync -->
+<!-- generated from .claude/skills/nerdsystem/SKILL.md (0e64cbbdd978); edit the skill, then run: nerd agents sync -->
 
 # Building on nerdsystem
 
@@ -8,12 +8,12 @@ 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.
+6. Tell them their code is saved on nerdsystem with every deploy and every `nerd save`, and that work since the last save is only on this computer. Then offer the next steps once, briefly: putting the code on GitHub as well (`nerd github connect`; explain that it adds deploys on push and a preview URL for each pull request), a custom domain, or inviting a teammate from the dashboard.
 
 Throughout, show commands rather than describing them, and never ask the person to edit config files; the platform owns `wrangler.jsonc` and `nerd.json`.
 
@@ -33,11 +33,19 @@ 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, 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.
+4. `nerd deploy` when it is ready. It runs the checks, builds, stores a copy of the code, 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.
 
+## Saving and restoring the code
+
+Every `nerd deploy` stores a copy of the code with the deployment, and `nerd save` stores one without deploying. Run `nerd save` at the end of every working session so the person's work is kept even when it was not deployed; it prints "Nothing changed since the last save." when there is nothing new. Work since the last save or deploy exists only on this computer, so say that whenever you tell the person their work is saved.
+
+On a new computer, or when the folder is lost: `nerd pull <org>/<project>`, then `pnpm install`, then `nerd dev`. `nerd pull` restores the newest saved copy into a new folder; `--deployment <id>` restores the code of a specific deploy. If `nerd deploy` stops because the live app was deployed from another copy of the code, run `nerd pull` to work from that copy, or `nerd deploy --force` only when the person confirms this copy should replace it.
+
+GitHub is optional. The next section says what connecting it adds.
+
 ## 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, 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.
@@ -124,7 +132,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/CLAUDE.md

@@ -6,7 +6,8 @@ nerdsystem deploys this app to Cloudflare and provides authentication and author
 
 - `nerd dev` starts the app locally with a real session flow against the platform auth service.
 - `nerd check` typechecks both sides and verifies the platform rules below. Run it before `nerd deploy`.
-- `nerd deploy` builds, applies pending migrations to the production database, and ships the app. Prints the URL.
+- `nerd deploy` builds, stores a copy of the code, applies pending migrations to the production database, and ships the app. Prints the URL.
+- `nerd save` keeps a copy of the code on nerdsystem without deploying; `nerd pull <org>/<project>` restores it on another computer.
 - `nerd db query "select ..."` runs SQL against the production database. `nerd deployments` lists recent deploys.
 - With a linked GitHub repo, pushes to the production branch and pull requests deploy automatically. `nerd builds` and `nerd builds show <id>` show what happened.
 - `pnpm db:generate` creates a migration after editing `src/server/db/schema.ts`. Never edit the database by hand.

package/template/GEMINI.md

@@ -1,4 +1,4 @@
-<!-- generated from .claude/skills/nerdsystem/SKILL.md (10dcd79a44bd); edit the skill, then run: nerd agents sync -->
+<!-- generated from .claude/skills/nerdsystem/SKILL.md (0e64cbbdd978); edit the skill, then run: nerd agents sync -->
 
 # Building on nerdsystem
 
@@ -8,12 +8,12 @@ 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.
+6. Tell them their code is saved on nerdsystem with every deploy and every `nerd save`, and that work since the last save is only on this computer. Then offer the next steps once, briefly: putting the code on GitHub as well (`nerd github connect`; explain that it adds deploys on push and a preview URL for each pull request), a custom domain, or inviting a teammate from the dashboard.
 
 Throughout, show commands rather than describing them, and never ask the person to edit config files; the platform owns `wrangler.jsonc` and `nerd.json`.
 
@@ -33,11 +33,19 @@ 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, 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.
+4. `nerd deploy` when it is ready. It runs the checks, builds, stores a copy of the code, 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.
 
+## Saving and restoring the code
+
+Every `nerd deploy` stores a copy of the code with the deployment, and `nerd save` stores one without deploying. Run `nerd save` at the end of every working session so the person's work is kept even when it was not deployed; it prints "Nothing changed since the last save." when there is nothing new. Work since the last save or deploy exists only on this computer, so say that whenever you tell the person their work is saved.
+
+On a new computer, or when the folder is lost: `nerd pull <org>/<project>`, then `pnpm install`, then `nerd dev`. `nerd pull` restores the newest saved copy into a new folder; `--deployment <id>` restores the code of a specific deploy. If `nerd deploy` stops because the live app was deployed from another copy of the code, run `nerd pull` to work from that copy, or `nerd deploy --force` only when the person confirms this copy should replace it.
+
+GitHub is optional. The next section says what connecting it adds.
+
 ## 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, 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.
@@ -124,7 +132,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