backend-code-quality-strictness

name	backend-code-quality-strictness
description	Enforces strict, production-grade backend code for TypeScript codebases. Use for backend code generation, refactors, APIs, services, billing, auth, storage, database, integrations, jobs, and production workflows.

---

Backend code quality strictness

purpose

Write backend code like a production engineer.

Optimize for:

• correctness
• type safety
• modularity
• explicitness
• maintainability
• tenant safety
• billing safety
• failure handling

Do not optimize for looking impressive.

---

core rules

TypeScript

If the codebase is TypeScript:

• use strict types everywhere
• do not use any
• do not widen types unnecessarily
• prefer narrow unions, inferred return types, and validated inputs
• use unknown only when immediately narrowed
• keep runtime validation aligned with static types

Modularity

Split code aggressively when the boundary is real.

Use multiple files and folders when:

• the file is becoming hard to read
• the operation contains multiple business steps
• the logic maps to distinct responsibilities
• the module will be reused
• the code crosses provider, DB, or storage boundaries

Do not keep a 3,000-line backend file intact just to avoid moving code.

Comments

Do not add comments unless they explain something non-obvious.

Allowed comments:

• business rules that are not obvious from code
• dangerous edge cases
• temporary workarounds
• external provider quirks
• intentional failure swallowing
• security or migration concerns

Do not comment obvious code.

Scope

Add only what the task needs.

Do not invent:

• extra abstractions
• extra wrappers
• extra schemas
• extra clients
• extra middleware
• extra helper layers
• extra config files

Use the existing architecture unless there is a clear reason not to.

---

backend thinking

Before writing code, identify:

• the core business operation
• the tenant boundary
• the billing boundary
• the provider contract
• the failure points
• the cleanup requirements
• the minimum return shape
• the files that must change

Then write the smallest correct implementation.

---

code quality rules

naming

Use domain names, not generic names.

Bad:

• handleThing
• processData
• doRequest
• result
• item

Good:

• createGeneration
• meterUsage
• uploadAudio
• customerState
• r2ObjectKey

abstractions

Do not abstract before the second real use case.

A helper is justified only if it protects a real boundary or removes meaningful duplication.

authorization

Put authorization as close to the data query as possible.

Do not duplicate authorization checks unless a second boundary actually exists.

provider usage

Use the existing official or project-standard client unless there is a concrete reason not to.

Do not bypass a working client with a custom fetch layer for no reason.

logging

Logs must reflect reality.

Log:

• operation start
• provider failures
• storage failures
• billing/metering failures
• security-relevant denials
• unexpected invalid responses

Do not log obvious success paths or private secrets.

errors

Errors should be useful and safe.

• do not throw vague errors
• do not leak internals in user-facing messages
• log internal details separately
• preserve the actual failure cause where useful

return shape

Return only what the caller needs.

Do not return internal fields, provider payloads, or private storage keys unless the caller explicitly needs them.

---

production workflow standard

For every mutation, preserve the actual sequence of the business operation.

Example order:

1. require tenant/org
2. verify subscription or access
3. authorize resource
4. perform core operation
5. create or update database record
6. persist storage/output
7. meter usage or charge
8. clean up partial failures
9. return minimal response

Do not hide this sequence behind generic wrappers if it makes the flow harder to review.

---

anti-patterns to reject

Reject code that:

• uses any
• has bloated comment blocks
• invents behavior around billing or permissions
• duplicates authorization logic
• bypasses existing clients without reason
• hides the main workflow behind generic helpers
• returns too much data
• ignores partial failure cleanup
• mixes tenant data without query-level protection
• adds files just to look organized

---

output standard

When generating backend code, respond with:

• Files changed
• Why these files
• Core workflow
• Production boundaries
• Code
• Remaining risks
• Verification needed

When reviewing backend code, respond with:

• Verdict
• Strict rating
• Core workflow preserved
• What is strong
• What is weak
• AI-generated residue
• Production risks
• Precise fixes

---

final rule

Write code that survives ownership.

If the code needs comments to make sense, fix the code first.