Cursor rules for Node API
A TypeScript HTTP service with thin handlers and validated input.
.cursor/rules/node-api.mdc
--- description: Conventions and guardrails for the Node API service globs: src/**/*.ts,tests/**/*.ts alwaysApply: false --- # Node API service ```bash npm install # install dependencies npm run dev # start the server with reload npm run lint # lint npx tsc --noEmit # type-check ``` Run the tests after every code change. - TypeScript strict mode. Validate every request body, query and header at the edge with a schema before using it. - Return consistent error shapes with the right status code. Never leak stack traces or internal messages to clients. - Log with the project logger, not console.log, and never log tokens, passwords or full request bodies. Rules for every edit: - Never read, print, edit or commit .env files, credentials, API keys or private keys. - Database changes go through migration files in the repo. Never edit a migration that has shipped; add a new one. - Never deploy to production. I run production deploys myself. - Never run git push --force, git reset --hard, git clean, git checkout -- <file>, git stash or git rebase, and never use --no-verify. Ask first. - Lockfiles: do not edit by hand, and do not add or upgrade dependencies without asking.
Why it says what it says
Thin handlers
Agents tend to pile logic into route handlers. Stating the split keeps code testable and reviews short.
Validate at the edge
Unvalidated input is the usual source of API bugs. A single rule covers every new route the agent writes.
No secrets in logs
Agents add debug logging freely. Naming what must never be logged prevents leaks that are easy to miss in review.
Migrations and queries
Destructive database commands and string-built SQL are the two ways an agent can do lasting damage. Both are named.
Contracts stay put
Clients depend on route paths and response shapes. Asking before changing them avoids silent breakage.