nerdsystem 0.0.11 → 0.0.12

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "nerdsystem",
-  "version": "0.0.11",
+  "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": {
@@ -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

@@ -16,7 +16,7 @@ If this project still has the template's todo app (the `todos` table and `src/se
 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, 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.

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 (31894f024834); 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
 
@@ -17,7 +17,7 @@ If this project still has the template's todo app (the `todos` table and `src/se
 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, 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.

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

@@ -1,4 +1,4 @@
-<!-- generated from .claude/skills/nerdsystem/SKILL.md (31894f024834); 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
 
@@ -13,7 +13,7 @@ If this project still has the template's todo app (the `todos` table and `src/se
 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, 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.

package/template/AGENTS.md

@@ -1,4 +1,4 @@
-<!-- generated from .claude/skills/nerdsystem/SKILL.md (31894f024834); 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
 
@@ -13,7 +13,7 @@ If this project still has the template's todo app (the `todos` table and `src/se
 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, 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.

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 (31894f024834); 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
 
@@ -13,7 +13,7 @@ If this project still has the template's todo app (the `todos` table and `src/se
 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, 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.