nerdsystem 0.0.5 → 0.0.7

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 (ca70e3512072); edit the skill, then run: nerd agents sync -->
+<!-- generated from .claude/skills/nerdsystem/SKILL.md (088a9335c558); edit the skill, then run: nerd agents sync -->
 
 # Building on nerdsystem
 
@@ -16,7 +16,7 @@ If this project still has the template's todo app (the `todos` table and `src/se
 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.
-5. Run `nerd deploy` and give them the live URL. Explain in two lines that every deploy is checked for leaked secrets and vulnerable dependencies, and that they can run `nerd verify` any time.
+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.
 
 Throughout, show commands rather than describing them, and never ask the person to edit config files; the platform owns `wrangler.jsonc` and `nerd.json`.
@@ -29,11 +29,11 @@ Throughout, show commands rather than describing them, and never ask the person
 4. `nerd deploy` when it is ready. It runs the checks, builds, applies pending migrations, uploads, and prints the URL.
 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.
+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, 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. Previews share the production database and do not run migrations; a PR that changes the schema will only work in full after 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 (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.
 
 ## Where things go
 
@@ -83,6 +83,7 @@ Then in `src/server/index.ts`: `app.route("/api/notes", notes);`
 - Schema changes are migrations. Edit `schema.ts`, run `pnpm db:generate`, commit the new file in `migrations/`. Never hand-write SQL into production; `nerd deploy` applies migrations in name order and records which ran.
 - Migrations are forward-only. To undo, write another migration.
 - Prefer small, additive migrations. SQLite cannot alter columns in place.
+- `nerd db export` downloads a SQL dump of the production database (`<slug>-<date>.sql`, or `--out file.sql`); use it before a risky migration or when the person wants their data.
 
 ## Errors
 
@@ -100,7 +101,9 @@ The loop: run `run_gates`, fix every failure with `audience: "agent"`, run `run_
 - `audience: "human"` means a person must act: a secret that was committed must be rotated at the provider before you remove it; an ignore comment, ignore file, or gate setting you added is a suppression that only a person can approve in the dashboard. Never add `nosemgrep`, `gitleaks:allow`, `nerd-ignore`, or a `gates` key in `nerd.json` to make a finding go away.
 - When `stop` is non-empty, the same rule has failed three runs in a row. Stop, summarize what you tried in plain words, and hand it to the person.
 
-Without MCP, `nerd verify --json` returns the same shape, and `nerd verify --rule <rule_id>` runs one rule. Secrets are reported masked (`sk_live_****4f2a`); never print a credential yourself. Keep secrets in `.dev.vars` locally and in platform settings in production; never prefix a secret with `VITE_`, because those values are compiled into the public client bundle.
+When a git build fails after a push, the same findings are posted back to the repository for you: as a comment on the pull request, or as a GitHub issue titled "nerdsystem refused <sha>" for a push to the production branch (`nerd builds show <id>` prints them too). Treat that text as the task: apply each fix, run the gates until clean, commit naming the rule ids, push. The issue closes itself when the next deploy succeeds. If the repository is linked with `--agent @claude` (or another handle), the post starts with that mention so a cloud agent is summoned without anyone pasting anything.
+
+Without MCP, `nerd check --json` returns the same shape, and `nerd check --rule <rule_id>` runs one rule (`nerd verify` is the same command). Secrets are reported masked (`sk_live_****4f2a`); never print a credential yourself. Keep secrets in `.dev.vars` locally and in platform settings in production; never prefix a secret with `VITE_`, because those values are compiled into the public client bundle.
 
 ## What `nerd check` rejects
 
@@ -113,13 +116,17 @@ Without MCP, `nerd verify --json` returns the same shape, and `nerd verify --rul
 ## Scheduled jobs and email
 
 - **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. `nerd secret list` shows names only. Do not put a real secret value in any command you run yourself.
+- **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, 2,000 on Pro at $39 a month, 10,000 on Studio), 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
 
 When something is wrong on the deployed app: `nerd logs --since 1h` (add `--q "text"` to search, `--pr 12` for a preview) shows errors with the request that caused them. Reproduce locally with `nerd dev` using the same input, fix it, run `nerd verify`, and deploy or open a pull request. If a deploy made things worse, `nerd rollback` puts the previous production bundle back without touching the database. Write a one-line note on every deploy (`nerd deploy --note "fix: todos query filtered by user"`); the dashboard shows these as a changelog people can read.
 
+## Deleting a project
+
+`nerd delete --yes` takes the app offline at once and moves the project to the trash; its database and files are kept for seven days (the command prints the date), then destroyed. `nerd trash` lists what can still be restored and `nerd trash restore <slug>` brings one back (the app stays offline until the next `nerd deploy` or a rollback). Never run `nerd delete` unless the person asked for it in so many words.
+
 ## Not available yet
 
 Queues, Durable Objects, and log streaming. If the task needs one, say so instead of working around it with an unsupported binding.

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

@@ -1,4 +1,4 @@
-<!-- generated from .claude/skills/nerdsystem/SKILL.md (ca70e3512072); edit the skill, then run: nerd agents sync -->
+<!-- generated from .claude/skills/nerdsystem/SKILL.md (088a9335c558); edit the skill, then run: nerd agents sync -->
 
 # Building on nerdsystem
 
@@ -12,7 +12,7 @@ If this project still has the template's todo app (the `todos` table and `src/se
 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.
-5. Run `nerd deploy` and give them the live URL. Explain in two lines that every deploy is checked for leaked secrets and vulnerable dependencies, and that they can run `nerd verify` any time.
+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.
 
 Throughout, show commands rather than describing them, and never ask the person to edit config files; the platform owns `wrangler.jsonc` and `nerd.json`.
@@ -25,11 +25,11 @@ Throughout, show commands rather than describing them, and never ask the person
 4. `nerd deploy` when it is ready. It runs the checks, builds, applies pending migrations, uploads, and prints the URL.
 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.
+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, 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. Previews share the production database and do not run migrations; a PR that changes the schema will only work in full after 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 (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.
 
 ## Where things go
 
@@ -79,6 +79,7 @@ Then in `src/server/index.ts`: `app.route("/api/notes", notes);`
 - Schema changes are migrations. Edit `schema.ts`, run `pnpm db:generate`, commit the new file in `migrations/`. Never hand-write SQL into production; `nerd deploy` applies migrations in name order and records which ran.
 - Migrations are forward-only. To undo, write another migration.
 - Prefer small, additive migrations. SQLite cannot alter columns in place.
+- `nerd db export` downloads a SQL dump of the production database (`<slug>-<date>.sql`, or `--out file.sql`); use it before a risky migration or when the person wants their data.
 
 ## Errors
 
@@ -96,7 +97,9 @@ The loop: run `run_gates`, fix every failure with `audience: "agent"`, run `run_
 - `audience: "human"` means a person must act: a secret that was committed must be rotated at the provider before you remove it; an ignore comment, ignore file, or gate setting you added is a suppression that only a person can approve in the dashboard. Never add `nosemgrep`, `gitleaks:allow`, `nerd-ignore`, or a `gates` key in `nerd.json` to make a finding go away.
 - When `stop` is non-empty, the same rule has failed three runs in a row. Stop, summarize what you tried in plain words, and hand it to the person.
 
-Without MCP, `nerd verify --json` returns the same shape, and `nerd verify --rule <rule_id>` runs one rule. Secrets are reported masked (`sk_live_****4f2a`); never print a credential yourself. Keep secrets in `.dev.vars` locally and in platform settings in production; never prefix a secret with `VITE_`, because those values are compiled into the public client bundle.
+When a git build fails after a push, the same findings are posted back to the repository for you: as a comment on the pull request, or as a GitHub issue titled "nerdsystem refused <sha>" for a push to the production branch (`nerd builds show <id>` prints them too). Treat that text as the task: apply each fix, run the gates until clean, commit naming the rule ids, push. The issue closes itself when the next deploy succeeds. If the repository is linked with `--agent @claude` (or another handle), the post starts with that mention so a cloud agent is summoned without anyone pasting anything.
+
+Without MCP, `nerd check --json` returns the same shape, and `nerd check --rule <rule_id>` runs one rule (`nerd verify` is the same command). Secrets are reported masked (`sk_live_****4f2a`); never print a credential yourself. Keep secrets in `.dev.vars` locally and in platform settings in production; never prefix a secret with `VITE_`, because those values are compiled into the public client bundle.
 
 ## What `nerd check` rejects
 
@@ -109,13 +112,17 @@ Without MCP, `nerd verify --json` returns the same shape, and `nerd verify --rul
 ## Scheduled jobs and email
 
 - **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. `nerd secret list` shows names only. Do not put a real secret value in any command you run yourself.
+- **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, 2,000 on Pro at $39 a month, 10,000 on Studio), 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
 
 When something is wrong on the deployed app: `nerd logs --since 1h` (add `--q "text"` to search, `--pr 12` for a preview) shows errors with the request that caused them. Reproduce locally with `nerd dev` using the same input, fix it, run `nerd verify`, and deploy or open a pull request. If a deploy made things worse, `nerd rollback` puts the previous production bundle back without touching the database. Write a one-line note on every deploy (`nerd deploy --note "fix: todos query filtered by user"`); the dashboard shows these as a changelog people can read.
 
+## Deleting a project
+
+`nerd delete --yes` takes the app offline at once and moves the project to the trash; its database and files are kept for seven days (the command prints the date), then destroyed. `nerd trash` lists what can still be restored and `nerd trash restore <slug>` brings one back (the app stays offline until the next `nerd deploy` or a rollback). Never run `nerd delete` unless the person asked for it in so many words.
+
 ## Not available yet
 
 Queues, Durable Objects, and log streaming. If the task needs one, say so instead of working around it with an unsupported binding.

package/template/AGENTS.md

@@ -1,4 +1,4 @@
-<!-- generated from .claude/skills/nerdsystem/SKILL.md (ca70e3512072); edit the skill, then run: nerd agents sync -->
+<!-- generated from .claude/skills/nerdsystem/SKILL.md (088a9335c558); edit the skill, then run: nerd agents sync -->
 
 # Building on nerdsystem
 
@@ -12,7 +12,7 @@ If this project still has the template's todo app (the `todos` table and `src/se
 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.
-5. Run `nerd deploy` and give them the live URL. Explain in two lines that every deploy is checked for leaked secrets and vulnerable dependencies, and that they can run `nerd verify` any time.
+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.
 
 Throughout, show commands rather than describing them, and never ask the person to edit config files; the platform owns `wrangler.jsonc` and `nerd.json`.
@@ -25,11 +25,11 @@ Throughout, show commands rather than describing them, and never ask the person
 4. `nerd deploy` when it is ready. It runs the checks, builds, applies pending migrations, uploads, and prints the URL.
 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.
+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, 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. Previews share the production database and do not run migrations; a PR that changes the schema will only work in full after 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 (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.
 
 ## Where things go
 
@@ -79,6 +79,7 @@ Then in `src/server/index.ts`: `app.route("/api/notes", notes);`
 - Schema changes are migrations. Edit `schema.ts`, run `pnpm db:generate`, commit the new file in `migrations/`. Never hand-write SQL into production; `nerd deploy` applies migrations in name order and records which ran.
 - Migrations are forward-only. To undo, write another migration.
 - Prefer small, additive migrations. SQLite cannot alter columns in place.
+- `nerd db export` downloads a SQL dump of the production database (`<slug>-<date>.sql`, or `--out file.sql`); use it before a risky migration or when the person wants their data.
 
 ## Errors
 
@@ -96,7 +97,9 @@ The loop: run `run_gates`, fix every failure with `audience: "agent"`, run `run_
 - `audience: "human"` means a person must act: a secret that was committed must be rotated at the provider before you remove it; an ignore comment, ignore file, or gate setting you added is a suppression that only a person can approve in the dashboard. Never add `nosemgrep`, `gitleaks:allow`, `nerd-ignore`, or a `gates` key in `nerd.json` to make a finding go away.
 - When `stop` is non-empty, the same rule has failed three runs in a row. Stop, summarize what you tried in plain words, and hand it to the person.
 
-Without MCP, `nerd verify --json` returns the same shape, and `nerd verify --rule <rule_id>` runs one rule. Secrets are reported masked (`sk_live_****4f2a`); never print a credential yourself. Keep secrets in `.dev.vars` locally and in platform settings in production; never prefix a secret with `VITE_`, because those values are compiled into the public client bundle.
+When a git build fails after a push, the same findings are posted back to the repository for you: as a comment on the pull request, or as a GitHub issue titled "nerdsystem refused <sha>" for a push to the production branch (`nerd builds show <id>` prints them too). Treat that text as the task: apply each fix, run the gates until clean, commit naming the rule ids, push. The issue closes itself when the next deploy succeeds. If the repository is linked with `--agent @claude` (or another handle), the post starts with that mention so a cloud agent is summoned without anyone pasting anything.
+
+Without MCP, `nerd check --json` returns the same shape, and `nerd check --rule <rule_id>` runs one rule (`nerd verify` is the same command). Secrets are reported masked (`sk_live_****4f2a`); never print a credential yourself. Keep secrets in `.dev.vars` locally and in platform settings in production; never prefix a secret with `VITE_`, because those values are compiled into the public client bundle.
 
 ## What `nerd check` rejects
 
@@ -109,13 +112,17 @@ Without MCP, `nerd verify --json` returns the same shape, and `nerd verify --rul
 ## Scheduled jobs and email
 
 - **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. `nerd secret list` shows names only. Do not put a real secret value in any command you run yourself.
+- **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, 2,000 on Pro at $39 a month, 10,000 on Studio), 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
 
 When something is wrong on the deployed app: `nerd logs --since 1h` (add `--q "text"` to search, `--pr 12` for a preview) shows errors with the request that caused them. Reproduce locally with `nerd dev` using the same input, fix it, run `nerd verify`, and deploy or open a pull request. If a deploy made things worse, `nerd rollback` puts the previous production bundle back without touching the database. Write a one-line note on every deploy (`nerd deploy --note "fix: todos query filtered by user"`); the dashboard shows these as a changelog people can read.
 
+## Deleting a project
+
+`nerd delete --yes` takes the app offline at once and moves the project to the trash; its database and files are kept for seven days (the command prints the date), then destroyed. `nerd trash` lists what can still be restored and `nerd trash restore <slug>` brings one back (the app stays offline until the next `nerd deploy` or a rollback). Never run `nerd delete` unless the person asked for it in so many words.
+
 ## Not available yet
 
 Queues, Durable Objects, and log streaming. If the task needs one, say so instead of working around it with an unsupported binding.

package/template/GEMINI.md

@@ -1,4 +1,4 @@
-<!-- generated from .claude/skills/nerdsystem/SKILL.md (ca70e3512072); edit the skill, then run: nerd agents sync -->
+<!-- generated from .claude/skills/nerdsystem/SKILL.md (088a9335c558); edit the skill, then run: nerd agents sync -->
 
 # Building on nerdsystem
 
@@ -12,7 +12,7 @@ If this project still has the template's todo app (the `todos` table and `src/se
 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.
-5. Run `nerd deploy` and give them the live URL. Explain in two lines that every deploy is checked for leaked secrets and vulnerable dependencies, and that they can run `nerd verify` any time.
+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.
 
 Throughout, show commands rather than describing them, and never ask the person to edit config files; the platform owns `wrangler.jsonc` and `nerd.json`.
@@ -25,11 +25,11 @@ Throughout, show commands rather than describing them, and never ask the person
 4. `nerd deploy` when it is ready. It runs the checks, builds, applies pending migrations, uploads, and prints the URL.
 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.
+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, 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. Previews share the production database and do not run migrations; a PR that changes the schema will only work in full after 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 (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.
 
 ## Where things go
 
@@ -79,6 +79,7 @@ Then in `src/server/index.ts`: `app.route("/api/notes", notes);`
 - Schema changes are migrations. Edit `schema.ts`, run `pnpm db:generate`, commit the new file in `migrations/`. Never hand-write SQL into production; `nerd deploy` applies migrations in name order and records which ran.
 - Migrations are forward-only. To undo, write another migration.
 - Prefer small, additive migrations. SQLite cannot alter columns in place.
+- `nerd db export` downloads a SQL dump of the production database (`<slug>-<date>.sql`, or `--out file.sql`); use it before a risky migration or when the person wants their data.
 
 ## Errors
 
@@ -96,7 +97,9 @@ The loop: run `run_gates`, fix every failure with `audience: "agent"`, run `run_
 - `audience: "human"` means a person must act: a secret that was committed must be rotated at the provider before you remove it; an ignore comment, ignore file, or gate setting you added is a suppression that only a person can approve in the dashboard. Never add `nosemgrep`, `gitleaks:allow`, `nerd-ignore`, or a `gates` key in `nerd.json` to make a finding go away.
 - When `stop` is non-empty, the same rule has failed three runs in a row. Stop, summarize what you tried in plain words, and hand it to the person.
 
-Without MCP, `nerd verify --json` returns the same shape, and `nerd verify --rule <rule_id>` runs one rule. Secrets are reported masked (`sk_live_****4f2a`); never print a credential yourself. Keep secrets in `.dev.vars` locally and in platform settings in production; never prefix a secret with `VITE_`, because those values are compiled into the public client bundle.
+When a git build fails after a push, the same findings are posted back to the repository for you: as a comment on the pull request, or as a GitHub issue titled "nerdsystem refused <sha>" for a push to the production branch (`nerd builds show <id>` prints them too). Treat that text as the task: apply each fix, run the gates until clean, commit naming the rule ids, push. The issue closes itself when the next deploy succeeds. If the repository is linked with `--agent @claude` (or another handle), the post starts with that mention so a cloud agent is summoned without anyone pasting anything.
+
+Without MCP, `nerd check --json` returns the same shape, and `nerd check --rule <rule_id>` runs one rule (`nerd verify` is the same command). Secrets are reported masked (`sk_live_****4f2a`); never print a credential yourself. Keep secrets in `.dev.vars` locally and in platform settings in production; never prefix a secret with `VITE_`, because those values are compiled into the public client bundle.
 
 ## What `nerd check` rejects
 
@@ -109,13 +112,17 @@ Without MCP, `nerd verify --json` returns the same shape, and `nerd verify --rul
 ## Scheduled jobs and email
 
 - **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. `nerd secret list` shows names only. Do not put a real secret value in any command you run yourself.
+- **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, 2,000 on Pro at $39 a month, 10,000 on Studio), 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
 
 When something is wrong on the deployed app: `nerd logs --since 1h` (add `--q "text"` to search, `--pr 12` for a preview) shows errors with the request that caused them. Reproduce locally with `nerd dev` using the same input, fix it, run `nerd verify`, and deploy or open a pull request. If a deploy made things worse, `nerd rollback` puts the previous production bundle back without touching the database. Write a one-line note on every deploy (`nerd deploy --note "fix: todos query filtered by user"`); the dashboard shows these as a changelog people can read.
 
+## Deleting a project
+
+`nerd delete --yes` takes the app offline at once and moves the project to the trash; its database and files are kept for seven days (the command prints the date), then destroyed. `nerd trash` lists what can still be restored and `nerd trash restore <slug>` brings one back (the app stays offline until the next `nerd deploy` or a rollback). Never run `nerd delete` unless the person asked for it in so many words.
+
 ## Not available yet
 
 Queues, Durable Objects, and log streaming. If the task needs one, say so instead of working around it with an unsupported binding.

package/template/package.json

@@ -19,6 +19,12 @@
     "react": "^19.3.1",
     "react-dom": "^19.3.1"
   },
+  "pnpm": {
+    "onlyBuiltDependencies": [
+      "esbuild",
+      "workerd"
+    ]
+  },
   "devDependencies": {
     "@cloudflare/vite-plugin": "^1.67.0",
     "@cloudflare/workers-types": "^5.20261102.1",

package/template/src/client/auth.tsx

@@ -7,7 +7,7 @@ import { auth, ApiError, type User } from "./api";
 import { navigate } from "./router";
 
 // Optional bot protection on signup: set VITE_TURNSTILE_SITE_KEY (client) and NERD_TURNSTILE_SECRET
-// (server, via `nerd secrets`) from a Cloudflare Turnstile widget. Without them, signup is open.
+// (server, via `nerd secret set`) from a Cloudflare Turnstile widget. Without them, signup is open.
 const TURNSTILE_SITE_KEY = import.meta.env.VITE_TURNSTILE_SITE_KEY as string | undefined;
 
 function Turnstile({ onToken }: { onToken: (t: string) => void }) {