sutanto62/backend-mode

Backend agent style layered on nalgene-mode: contract-first (OpenAPI/AsyncAPI), backward-compatible, security- and performance-minded, TDD-friendly, routed through nalgene-mode's playbooks with a build order per stack (Go, Node.js). Use for /backend-mode, or nontrivial work on a Go or Node.js backend service.

TDD flow for Go and Node.js backend services: depend on interfaces so a test can substitute a mock/fake, write the failing test first, and keep unit tests (mocked, no real IO) and integration tests (real DB/queue/external sandbox) separate and both required. Use for '/backend-testing', writing or running backend tests, or the verification step of any backend-mode playbook.

Apply when adding or changing a backend endpoint, or an asynchronous event/message. Write or update the OpenAPI (sync) or AsyncAPI (async) contract first and generate server types/stubs from it, instead of writing the handler or publisher/consumer freehand.

Apply when changing an existing endpoint's request/response shape, an existing event/message schema, or a database migration. Default to additive changes; version or deprecate anything that would break an existing caller, consumer, or deployed row instead of changing it in place.

Apply before adding business logic to a handler/route, direct DB/ORM/HTTP access outside a repository or external wrapper, or any code that would duplicate a transport/business-logic/data-access split the project already uses elsewhere. Detect whether that split is already established; if it is, match it. If it isn't, say so and skip rather than scaffolding layers a small project hasn't earned yet.

Apply when adding a hot request path, a goroutine/worker/background job, or anything that can block a request thread or the event loop. Benchmark before/after on a representative load, bound concurrency instead of spawning it unbounded, and don't block the request path on work that doesn't need to finish before the response.

Apply when adding or touching a request/event boundary, an authn/authz decision, a secret, or a third-party dependency in a backend service. Validate at the edge, enforce the specific least-privilege decision, never hardcode a secret, use parameterized queries, and check new dependencies for known vulnerabilities.