Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@packages/registry/foundation/prisma-mysql-starter.json`:
- Around line 28-37: The package template currently lists "morgan" inside the
"dev" dependencies array, but morgan is a runtime middleware and must be
installed as a production dependency; move "morgan" out of the "dev" array and
add it to the runtime dependencies list (the top-level "dependencies" or
equivalent field in this JSON template) so that the "morgan" package is
available in production builds and imports (reference the "dev" array containing
"morgan" and the dependency list where runtime packages are declared).

In
`@packages/templates/node/express/foundation/prisma-mysql-starter/feature/package.json`:
- Line 19: The "docs" npm script currently runs "node swagger.config.ts" which
fails because Node can't execute TypeScript or ESM TypeScript files directly;
update the package.json "docs" script to invoke a TypeScript-aware runner (e.g.,
replace the command to use "tsx" so it runs swagger.config.ts correctly) and
ensure the target file swagger.config.ts is referenced unchanged; no other code
changes required.

In
`@packages/templates/node/express/foundation/prisma-mysql-starter/feature/src/shared/configs/swagger.ts`:
- Around line 6-8: The setupSwagger function currently always mounts the docs at
"/api/docs"; change it to gate the route by environment so docs are not exposed
by default in production — modify setupSwagger to check a config/env flag (e.g.
process.env.ENABLE_SWAGGER === "true" or NODE_ENV !== "production") before
calling app.use("/api/docs", swaggerUi.serve, swaggerUi.setup(swaggerDocument));
keep the same function name setupSwagger and the same route but only register it
when the opt-in condition is met.

In
`@packages/templates/node/express/foundation/prisma-mysql-starter/feature/src/shared/middlewares/error-handler.ts`:
- Around line 7-33: The errorHandler middleware can attempt to write a response
after headers have already been sent, causing ERR_HTTP_HEADERS_SENT; update the
errorHandler function to check res.headersSent at the start and if true call
next(err) to delegate handling; keep existing logging behavior (logger.error)
but only perform res.status(...).json(...) when res.headersSent is false;
reference the errorHandler function, the res.headersSent property and the
next(err) call when making the change.

In
`@packages/templates/node/express/foundation/prisma-mysql-starter/feature/src/shared/utils/api-response.ts`:
- Around line 19-41: The constructor of ApiResponse (constructor in
api-response.ts) sets data = null which conflicts with send()'s conditional
inclusion (send uses this.data !== undefined), causing data to always appear;
remove the default assignment (data = null) in the constructor parameter list or
change the param type so that absent data remains undefined, and ensure
ApiResponseParams<T> and the constructor initialize this.data only from the
provided value so that send()'s this.data !== undefined check correctly omits
data when not supplied.

In
`@packages/templates/node/express/foundation/prisma-mysql-starter/feature/src/shared/utils/logger.ts`:
- Line 2: The import in logger.ts uses a redundant relative path
("../../shared/configs/env"); update the import to the shorter path
"../configs/env" so it references the sibling shared/configs module directly;
locate the import statement in feature/src/shared/utils/logger.ts and change the
module specifier to "../configs/env" (no behavior changes required).

In
`@packages/templates/node/express/foundation/prisma-mysql-starter/mvc/package.json`:
- Line 19: The "docs" npm script currently uses Node to run a TypeScript file
("docs": "node swagger.config.ts") which fails; update the package.json scripts
entry for the "docs" script to run the TypeScript file with the same runtime
used by "dev" (e.g., use "tsx swagger.config.ts" or "npx tsx swagger.config.ts")
so swagger.config.ts is executed via tsx instead of node; locate the "docs" key
in package.json and replace the command accordingly.

In
`@packages/templates/node/express/foundation/prisma-mysql-starter/mvc/src/configs/swagger.ts`:
- Around line 6-8: The swagger docs are mounted unconditionally; update
setupSwagger to only register the route when explicitly enabled (e.g., via an
environment/config flag or when NODE_ENV !== 'production') so /api/docs is not
exposed in production by default; modify the setupSwagger function to check a
config flag (or process.env.NODE_ENV) before calling app.use("/api/docs",
swaggerUi.serve, swaggerUi.setup(swaggerDocument)) and document/validate the
flag name used for enabling docs.

In
`@packages/templates/node/express/foundation/prisma-mysql-starter/mvc/src/controllers/health.controller.ts`:
- Around line 23-43: The detailedHealthCheck handler currently exposes
environment, version, memory and cpu data publicly; update detailedHealthCheck
(the AsyncHandler-wrapped route) to only return the full detailed payload when
allowed: either gate it to non-production (check process.env.NODE_ENV !==
'production') or require a feature flag/auth (e.g.
process.env.ENABLE_DETAILED_HEALTH or an authentication/permission check on the
request) and otherwise return a minimal safe response (status/timestamp). Ensure
the decision logic is implemented at the start of detailedHealthCheck so the
sensitive fields (environment, version, memory, cpu) are omitted unless the
guard passes.

In
`@packages/templates/node/express/foundation/prisma-mysql-starter/mvc/src/middlewares/error-handler.ts`:
- Around line 16-32: The error handler currently discards structured details
from ApiError; update the middleware in error-handler.ts so when err is an
instance of ApiError (check err instanceof ApiError) you capture and include its
errors property into the JSON response (e.g., extend the response object with an
errors field) before calling res.status(...).json(...); ensure logger.error
still logs err and keep the existing stack inclusion for development.

In
`@packages/templates/node/express/foundation/prisma-mysql-starter/mvc/src/utils/async-handler.ts`:
- Around line 9-12: AsyncHandler currently calls Promise.resolve(fn(req, res,
next)) which evaluates fn synchronously and lets thrown sync errors bypass
.catch(next); update AsyncHandler to catch synchronous throws and forward them
to next by wrapping the call in a try/catch (i.e., in the returned function
catch errors from fn(req, res, next) and call next(err), otherwise attach
.catch(next) to the Promise) so both sync and async errors from fn (the
AsyncRouteHandler) are sent to NextFunction.

In
`@packages/templates/node/express/foundation/prisma-mysql-starter/mvc/src/utils/shutdown.ts`:
- Around line 4-27: The graceful shutdown handler in
configureGracefulShutdown(server) never disconnects Prisma; update
configureGracefulShutdown to accept either an injected Prisma client or an async
cleanup callback (e.g., configureGracefulShutdown(server, prisma) or
configureGracefulShutdown(server, asyncCleanup)), then in the signal handler
await the cleanup (await prisma.$disconnect() or await asyncCleanup()) before
calling process.exit, and ensure errors from prisma.$disconnect() are caught and
logged via logger.error inside the server.close callback and the forced shutdown
timeout remains as fallback.

---

Nitpick comments:
In
`@packages/templates/node/express/foundation/prisma-mysql-starter/feature/src/modules/health/health.controller.ts`:
- Around line 31-38: The memory block repeatedly calls process.memoryUsage();
cache its result once (e.g., const mem = process.memoryUsage()) inside the
health endpoint handler (the method in HealthController that builds the memory
object) and replace the duplicate calls with mem.heapUsed and mem.heapTotal so
you return consistent values and avoid redundant invocations in the memory {
used, total, unit } construction.

In
`@packages/templates/node/express/foundation/prisma-mysql-starter/mvc/package.json`:
- Around line 21-27: The lint-staged config currently runs "tsc --noEmit" which
invokes TypeScript per-file and can break project-level type checks; remove "tsc
--noEmit" from the "lint-staged" entry (the object keyed by "lint-staged" and
its array for "src/**/*.ts") and rely on the existing "typecheck" npm script or
CI to run full project type checking instead; ensure only "eslint --fix" and
"prettier --write" remain in that array so lint-staged runs fast and local
typechecks still occur via the "typecheck" script.

In
`@packages/templates/node/express/foundation/prisma-mysql-starter/mvc/src/configs/prisma.ts`:
- Around line 4-8: The PrismaClient instantiation can create multiple instances
during hot-reload; modify the module to export a singleton by storing the
PrismaClient on globalThis (e.g., globalThis.__prisma or
globalThis.__prismaClient) so repeated imports return the cached instance;
update the existing prisma variable creation (where PrismaClient is constructed)
to first check and reuse globalThis.__prisma, assign the new client to that
global when created, and export that singleton `prisma` (also consider only
attaching the cache in non-production environments).

Verify each finding against the current code and only fix it if needed.

Inline comments:
In
`@packages/templates/node/express/foundation/prisma-mysql-starter/feature/src/app.ts`:
- Around line 21-27: The CORS configuration using origin: env.CORS_ORIGIN treats
the env value as a single literal string and breaks when env.CORS_ORIGIN
contains multiple comma-separated origins; update the app.use(cors(...)) call to
parse env.CORS_ORIGIN into an array (split on commas, trim entries, handle "*"
or empty) and pass an origin validation function that checks reqOrigin against
that array and calls the callback accordingly; modify the cors setup around
app.use and the cors(...) invocation so origin is a function that accepts
(origin, callback) and validates against the parsed list rather than a single
string.

---

Nitpick comments:
In
`@packages/templates/node/express/foundation/prisma-mysql-starter/feature/src/app.ts`:
- Around line 34-36: Replace the direct process.env check with the validated
shared env value so the Swagger toggle uses the same parsing/validation as the
rest of config: import or reference the shared env object and change the
condition from process.env.ENABLE_SWAGGER === "true" to using env.ENABLE_SWAGGER
(e.g., if (env.ENABLE_SWAGGER) { setupSwagger(app); }), keeping the call to
setupSwagger(app) and the app reference unchanged.