dev-booster 1.18.0 → 1.18.1

package/template/.devbooster/hub/knowledge/nodejs-patterns.md

@@ -0,0 +1,148 @@
+# Node.js Runtime Patterns
+
+> **Purpose:** Diagnose and prevent common Node.js runtime, module, environment, and script failures.
+> **Primary official sources:** [Node.js documentation](https://nodejs.org/docs/latest/api/) · [npm package.json documentation](https://docs.npmjs.com/cli/v11/configuring-npm/package-json) · [npm scripts documentation](https://docs.npmjs.com/cli/v11/using-npm/scripts)
+
+## Project Convention Decision Rule
+
+Before applying this guidance, verify the installed versions, local rules, existing abstractions, configuration, runtime environment, and tests. Preserve a valid established project convention; do not replace it only because another documented approach is also valid. Use official sources to verify API behavior, compatibility, constraints, and migrations. Recommend a change only when the developer requests it or evidence shows the current approach is incompatible, unsafe, deprecated, broken, or responsible for a verified issue.
+
+---
+
+## Table of Contents
+
+1. [Runtime and Engines Misalignment](#runtime-and-engines-misalignment)
+2. [ESM and CommonJS Interoperability](#esm-and-commonjs-interoperability)
+3. [Environment Loading and Validation](#environment-loading-and-validation)
+4. [Unhandled Async Failures](#unhandled-async-failures)
+5. [Portable npm Scripts and Lifecycle Hooks](#portable-npm-scripts-and-lifecycle-hooks)
+6. [Version Manager, CI, and Container Alignment](#version-manager-ci-and-container-alignment)
+
+---
+
+## Runtime and Engines Misalignment
+
+### Symptom
+A command works on one machine but fails in CI or production with syntax errors, unsupported APIs, native-module errors, or an `EBADENGINE` warning/error.
+
+### Verify first
+```sh
+node --version
+npm --version
+node -p "process.version"
+```
+Compare those values with the root `package.json` `engines`, the CI runtime setup, container base image, and any version-manager file. `engines` expresses compatibility metadata; enforcement depends on the package manager and its configuration. See [npm `engines`](https://docs.npmjs.com/cli/v11/configuring-npm/package-json#engines).
+
+### Fix
+- Define a tested Node range in `engines`; use an exact version only when reproducibility requires it.
+- Select a Node version explicitly in CI and containers rather than relying on a runner or image default.
+- Rebuild native dependencies after changing Node versions; do not reuse artifacts built against an incompatible ABI.
+- Keep local version-manager configuration aligned with the supported range.
+
+---
+
+## ESM and CommonJS Interoperability
+
+### Symptom
+`require is not defined`, `ERR_REQUIRE_ESM`, missing named exports, or different behavior between development and production builds.
+
+### Verify first
+Inspect the closest `package.json` for `"type"`, the file extension (`.mjs`, `.cjs`, `.js`), and the dependency's documented exports. Node determines module interpretation from these inputs. See [Node.js modules: packages](https://nodejs.org/docs/latest/api/packages.html) and [ECMAScript modules](https://nodejs.org/docs/latest/api/esm.html).
+
+### Fix
+- Choose one module system for new application code and declare it deliberately with `type` or explicit extensions.
+- In ESM, import CommonJS through its default export when necessary, then read properties from that value.
+- In CommonJS, use `import()` for an ESM-only dependency because synchronous `require()` has compatibility limits.
+- Do not depend on undocumented deep imports or inferred named exports; use the dependency's public export map.
+
+```js
+// CommonJS loading an ESM package
+const loadTool = () => import('an-esm-only-package')
+
+// ESM consuming CommonJS
+import legacyPackage from 'legacy-package'
+const { createClient } = legacyPackage
+```
+
+---
+
+## Environment Loading and Validation
+
+### Symptom
+A service starts with `undefined` configuration, uses development credentials in another environment, or fails only after handling traffic.
+
+### Verify first
+Identify where configuration is loaded, which process owns it, and whether the expected variables are present without printing secrets:
+
+```sh
+node -e "console.log(Boolean(process.env.REQUIRED_SETTING))"
+```
+Node exposes the process environment through [`process.env`](https://nodejs.org/docs/latest/api/process.html#processenv). Recent Node releases also document loading `.env` files with [`--env-file`](https://nodejs.org/docs/latest/api/cli.html#--env-fileconfig); verify availability in the exact Node version in use before relying on it.
+
+### Fix
+- Load configuration before importing or initializing code that reads it.
+- Validate required variables, types, allowed values, and cross-field constraints at process startup; fail with variable names, never secret values.
+- Treat environment values as strings until parsed and validated.
+- Keep secrets out of source control and inject them through the deployment environment or an approved secret mechanism.
+
+---
+
+## Unhandled Async Failures
+
+### Symptom
+A request hangs, an error appears as an unhandled rejection, or the process exits unexpectedly after an async operation fails.
+
+### Verify first
+Trace every promise-returning call to an `await`/`return`/`.catch()`. Review the runtime's unhandled-rejection behavior for the deployed Node version: [Node.js `unhandledRejection`](https://nodejs.org/docs/latest/api/process.html#event-unhandledrejection).
+
+### Fix
+- Await promises inside `try`/`catch` where recovery or translation is needed.
+- Return promises from wrapper functions so callers can observe failures.
+- At process boundaries, log actionable context, release resources, and exit or restart according to the service's supervision model.
+- Do not use a global rejection handler as a substitute for local error handling; it is an observability and last-resort shutdown boundary.
+
+```js
+async function readConfiguration() {
+  try {
+    return await fetchConfiguration()
+  } catch (error) {
+    throw new Error('Configuration could not be loaded', { cause: error })
+  }
+}
+```
+
+---
+
+## Portable npm Scripts and Lifecycle Hooks
+
+### Symptom
+A script passes on one operating system but fails in CI, or an install unexpectedly runs build, download, or publish-related code.
+
+### Verify first
+Review `scripts` and lifecycle names in `package.json`, then run the exact package-manager command used by CI. npm exposes lifecycle context through environment variables and has command-specific lifecycle behavior; see [npm scripts](https://docs.npmjs.com/cli/v11/using-npm/scripts) and [lifecycle scripts](https://docs.npmjs.com/cli/v11/using-npm/scripts#life-cycle-operation-order).
+
+### Fix
+- Prefer Node-based scripts or cross-platform tooling over shell-specific syntax, utilities, and environment assignments.
+- Make each script's inputs and outputs explicit; use package binaries through the package manager rather than assuming global installations.
+- Keep `prepare`, `prepack`, `prepublishOnly`, and install hooks small and intentional. Verify which commands trigger each hook before placing builds or side effects there.
+- Run install commands with lifecycle scripts disabled only as a diagnostic or controlled security measure, not as a permanent workaround for an unknown hook.
+
+---
+
+## Version Manager, CI, and Container Alignment
+
+### Problem
+Node is pinned locally but not in CI or the deployment image, creating a runtime matrix that is neither tested nor supported.
+
+### Fix
+Use one documented source of truth for the supported Node range, and make every execution environment select a compatible runtime:
+
+| Environment | Check |
+| --- | --- |
+| Local development | Version-manager configuration and `node --version` |
+| CI | Explicit setup action/task and cache key including Node and lockfile |
+| Container | Explicit base-image tag and rebuild after runtime changes |
+| Deployment | Platform runtime setting or image runtime |
+
+### Verify first
+Print `node --version` at the start of CI and from the built container. Install from the committed lockfile, then run the same test/build commands that validate local development. For supported release lines and schedules, use the [Node.js release page](https://nodejs.org/en/about/previous-releases).

package/template/.devbooster/hub/knowledge/package-manager-patterns.md

@@ -0,0 +1,143 @@
+# Package Manager Patterns
+
+> **Purpose:** Resolve reproducibility, dependency-resolution, workspace-scope, and security-report issues across npm, Yarn, and pnpm.
+> **Primary official sources:** [npm CLI documentation](https://docs.npmjs.com/cli/) · [Yarn documentation](https://yarnpkg.com/configuration/manifest) · [pnpm documentation](https://pnpm.io/)
+
+## Project Convention Decision Rule
+
+Before applying this guidance, verify the installed versions, local rules, package manager, lockfile, workspace layout, configuration, and tests. Preserve a valid established project convention; do not replace it only because another documented approach is also valid. Use official sources to verify API behavior, compatibility, constraints, and migrations. Recommend a change only when the developer requests it or evidence shows the current approach is incompatible, unsafe, deprecated, broken, or responsible for a verified issue.
+
+---
+
+## Table of Contents
+
+1. [Detect the Manager and Lockfile](#detect-the-manager-and-lockfile)
+2. [Override and Resolution Semantics](#override-and-resolution-semantics)
+3. [Peer Dependency Conflicts](#peer-dependency-conflicts)
+4. [Serialized Installs](#serialized-installs)
+5. [Audit Findings](#audit-findings)
+6. [Workspace Root Versus Package Scope](#workspace-root-versus-package-scope)
+7. [Frozen Lockfile Validation](#frozen-lockfile-validation)
+
+---
+
+## Detect the Manager and Lockfile
+
+### Symptom
+An install rewrites the lockfile, resolves a different tree, or fails because a command was run with the wrong manager.
+
+### Verify first
+Inspect the repository root for `packageManager` in `package.json`, manager configuration files, and lockfiles such as `package-lock.json`, `yarn.lock`, or `pnpm-lock.yaml`. The Corepack documentation explains the `packageManager` field and shims: [Node.js Corepack](https://nodejs.org/docs/latest/api/corepack.html).
+
+### Fix
+- Use the manager declared by the repository; do not introduce or regenerate another manager's lockfile.
+- Treat one committed lockfile as the install-resolution authority for a repository.
+- When the intended manager is ambiguous, inspect CI and contributor documentation before changing dependencies.
+- Pin the manager release through the repository's supported mechanism, then ensure CI uses the same release family.
+
+---
+
+## Override and Resolution Semantics
+
+### Problem
+A transitive dependency needs a security or compatibility fix, but editing a lockfile directly is fragile and will be overwritten.
+
+### Verify first
+Identify the full dependency path and confirm the replacement version is compatible. Then use the manager's native manifest field:
+
+| Manager | Manifest mechanism | Official reference |
+| --- | --- | --- |
+| npm | `overrides` | [npm `overrides`](https://docs.npmjs.com/cli/v11/configuring-npm/package-json#overrides) |
+| Yarn | `resolutions` | [Yarn manifest `resolutions`](https://yarnpkg.com/configuration/manifest#resolutions) |
+| pnpm | `pnpm.overrides` | [pnpm overrides](https://pnpm.io/package_json#pnpmoverrides) |
+
+### Fix
+- Put the override where that manager resolves dependencies, normally the root manifest for a workspace repository.
+- Scope it as narrowly as the manager supports; document the reason and remove it when upstream constraints no longer require it.
+- Reinstall with the declared manager, review the lockfile diff, and test the affected dependency path.
+- Do not assume the fields are interchangeable: selector syntax, allowed locations, and direct-dependency rules differ by manager.
+
+---
+
+## Peer Dependency Conflicts
+
+### Symptom
+Installation reports incompatible peers, installs multiple host versions, or runtime plugins fail because they are connected to an unexpected host package.
+
+### Verify first
+Read the peer range from the package reporting the conflict and identify the actual host version selected by the lockfile. A peer dependency expresses compatibility with a package supplied by the consumer; see [npm peer dependencies](https://docs.npmjs.com/cli/v11/configuring-npm/package-json#peerdependencies) and [pnpm peer dependencies](https://pnpm.io/npmrc#strict-peer-dependencies).
+
+### Fix
+1. Prefer versions whose peer ranges overlap.
+2. Upgrade or replace the dependent package if it does not support the selected host.
+3. Use a documented compatibility bridge only after testing the integration.
+4. Avoid permanently suppressing peer checks. A flag can unblock diagnosis, but it does not make an unsupported runtime combination safe.
+
+---
+
+## Serialized Installs
+
+### Symptom
+Concurrent jobs or processes corrupt a lockfile, contend for package-manager state, or publish nondeterministic dependency changes.
+
+### Fix
+- Make dependency updates a serialized workflow: one writer updates the manifest and lockfile, then commits both together.
+- Keep CI installs read-only with respect to the lockfile.
+- Avoid sharing mutable package-manager caches or store directories across concurrent jobs unless the tool and cache backend support it safely.
+- Separate dependency-update automation from build/test jobs that only consume the committed resolution.
+
+### Verify first
+Run a clean install twice in separate workspaces, then confirm the lockfile and dependency tree do not change. Use the manager's own listing/why command to verify the selected version.
+
+---
+
+## Audit Findings
+
+### Symptom
+An audit reports vulnerabilities and a bulk auto-fix proposes major upgrades, lockfile churn, or removal of required packages.
+
+### Verify first
+For each finding, determine whether the vulnerable package is reachable in the shipped runtime, which version introduces the fix, and whether the advisory applies to the supported deployment path. npm documents its audit command and report format in [npm audit](https://docs.npmjs.com/auditing-package-dependencies-for-security-vulnerabilities).
+
+### Fix
+- Prioritize direct, runtime-reachable, exploitable dependencies.
+- Upgrade the owning direct dependency when possible; use a narrowly scoped override only when necessary.
+- Review major-version changes and test behavior instead of blindly accepting forceful remediation.
+- Record accepted risk with scope and review conditions when no compatible fix exists.
+
+An audit is an input to risk assessment, not proof that an application is exploitable or safe.
+
+---
+
+## Workspace Root Versus Package Scope
+
+### Problem
+A command runs against the wrong package, configuration appears ignored, or a dependency is added to the root when it belongs to an application/library package.
+
+### Verify first
+Confirm the current directory, workspace declaration, and package target. npm documents workspace targeting in [npm workspaces](https://docs.npmjs.com/cli/v11/using-npm/workspaces); Yarn and pnpm have equivalent workspace-aware command support.
+
+### Fix
+- Put runtime and library dependencies in the package that imports them.
+- Keep root tooling dependencies at the root only when the root owns the command or configuration.
+- Use explicit workspace selectors for install, run, test, and publish operations.
+- Avoid assuming a command's default scope; root and workspace behavior is manager- and command-specific.
+
+---
+
+## Frozen Lockfile Validation
+
+### Symptom
+CI succeeds after silently modifying a lockfile, or a clean checkout cannot reproduce the committed dependency tree.
+
+### Fix
+Use the manager's immutable/frozen validation mode in CI:
+
+| Manager | Typical validation command | Reference |
+| --- | --- | --- |
+| npm | `npm ci` | [npm ci](https://docs.npmjs.com/cli/v11/commands/npm-ci) |
+| Yarn | `yarn install --immutable` | [Yarn install](https://yarnpkg.com/cli/install) |
+| pnpm | `pnpm install --frozen-lockfile` | [pnpm install](https://pnpm.io/cli/install) |
+
+### Verify first
+Start from a clean checkout, run the applicable command, then confirm no manifest or lockfile changes are produced. Use the exact manager release declared by the repository.

package/template/.devbooster/hub/knowledge/prisma-postgresql-patterns.md

@@ -0,0 +1,188 @@
+# Prisma + PostgreSQL Patterns
+
+> **Purpose:** Practical guidance for safe Prisma and PostgreSQL changes.
+> **Primary official sources:** [Prisma schema reference](https://www.prisma.io/docs/orm/reference/prisma-schema-reference) · [Prisma Migrate](https://www.prisma.io/docs/orm/prisma-migrate) · [Prisma transactions](https://www.prisma.io/docs/orm/prisma-client/queries/transactions) · [PostgreSQL EXPLAIN](https://www.postgresql.org/docs/current/using-explain.html) · [PostgreSQL indexes](https://www.postgresql.org/docs/current/indexes.html)
+
+## Project Convention Decision Rule
+
+Before applying this guidance, verify the installed versions, local rules, existing data-access abstractions, schema, migration history, configuration, and tests. Preserve a valid established project convention; do not replace it only because another documented approach is also valid. Use official sources to verify API behavior, compatibility, constraints, and migrations. Recommend a change only when the developer requests it or evidence shows the current approach is incompatible, unsafe, deprecated, broken, or responsible for a verified issue.
+
+---
+
+## Table of Contents
+
+1. [Schema–Client Generation Drift](#schemaclient-generation-drift)
+2. [Safe Migration Workflow](#safe-migration-workflow)
+3. [Expand–Contract Changes](#expandcontract-changes)
+4. [Relations, Selection, and N+1](#relations-selection-and-n1)
+5. [Transaction Boundaries](#transaction-boundaries)
+6. [Indexes and Query Plans](#indexes-and-query-plans)
+7. [Connection Pooling and Runtime Constraints](#connection-pooling-and-runtime-constraints)
+
+---
+
+## Schema–Client Generation Drift
+
+### Problem
+The Prisma schema, generated client, migration history, and deployed database describe different states. Typical symptoms are missing client properties, runtime errors for a new column, or a client that compiles locally but fails after deployment.
+
+### Verify first
+- Confirm the database URL and schema used by the failing runtime.
+- Compare the checked-in `prisma/schema.prisma`, committed migrations, and generated-client version.
+- Determine whether the change is intentional schema drift, a missed migration, or a stale generated artifact. Do not use `db push` to repair a production migration history without understanding the consequence.
+
+### Fix
+- Treat the Prisma schema and migration files as reviewed source of truth.
+- After changing the schema, create or update the migration in development, then run `prisma generate` where the client is built.
+- Deploy reviewed migrations with `prisma migrate deploy`; keep runtime images/functions responsible for generating or containing the matching client.
+- Use [`prisma migrate diff`](https://www.prisma.io/docs/orm/prisma-migrate/workflows/troubleshooting#using-prisma-migrate-diff) to inspect a suspected difference before resolving drift.
+
+### Verify
+- Run type checking and a narrow query that reads/writes the changed model against a representative database.
+- In the deployment artifact, confirm the generated client version matches the installed `prisma` package and schema.
+
+---
+
+## Safe Migration Workflow
+
+### Problem
+A migration succeeds on an empty development database but risks data loss, locking, or incompatible application behavior on a populated database.
+
+### Verify first
+- Inspect the generated SQL before it reaches a shared environment.
+- Estimate table size, write volume, existing nulls/duplicates, and lock sensitivity.
+- Identify PostgreSQL version and whether the operation can run inside a transaction; some operations, such as `CREATE INDEX CONCURRENTLY`, cannot.
+
+### Fix
+- Create migrations from the schema in development and commit both schema and migration SQL.
+- Make destructive or data-dependent changes explicit. Backfill data deliberately rather than relying on a nullable-to-required change to succeed by chance.
+- Test the actual migration against a production-like copy or representative dataset, including rollback or recovery procedures.
+- Use `migrate deploy` for controlled environments; do not use development reset workflows against data that must be retained.
+
+### Verify
+- Check the migration table and application health after deployment.
+- Confirm expected row counts, constraints, and query behavior rather than treating a zero exit status as sufficient.
+
+*Sources: [Prisma production and testing environments](https://www.prisma.io/docs/orm/prisma-migrate/workflows/development-and-production), [PostgreSQL ALTER TABLE](https://www.postgresql.org/docs/current/sql-altertable.html).*
+
+---
+
+## Expand–Contract Changes
+
+### Problem
+A single migration removes or renames a column while older application instances, queued jobs, or rollback images still use it.
+
+### Verify first
+- Identify every deployed version, asynchronous consumer, reporting query, and external integration that reads or writes the affected field.
+- Confirm how long old instances can remain alive and whether a rollback would require the old schema.
+
+### Fix
+1. **Expand:** Add the new nullable column/table/index without removing the old interface.
+2. Deploy code that can read the old representation and write the new one (or dual-read/dual-write when necessary).
+3. Backfill in observable, bounded batches; validate completeness.
+4. Switch reads to the new representation after all active writers are compatible.
+5. **Contract:** Remove the old column, constraint, or code only in a later release.
+
+Avoid dual writes when a database trigger, one-way compatibility read, or short maintenance window provides a simpler and safer invariant. The correct approach depends on consistency requirements and deployment overlap.
+
+### Verify
+- Measure records remaining to backfill and compare old/new values where both exist.
+- Before contraction, prove that no supported application version issues queries using the old schema.
+
+*Source: [Prisma custom migration SQL](https://www.prisma.io/docs/orm/prisma-migrate/workflows/customizing-migrations).*
+
+---
+
+## Relations, Selection, and N+1
+
+### Symptom
+An endpoint becomes slow as result count grows, emits one query per parent row, or transfers much more data than its response needs.
+
+### Verify first
+- Enable query logging or inspect database activity to count queries for one request.
+- Measure the response shape and identify exactly which scalar fields and relations are needed.
+- Check cardinality: a broad `include` across multiple to-many relations can create large result sets even without a classic N+1 loop.
+
+### Fix
+- Use `select` to request only needed scalar fields; use relation `select`/`include` deliberately.
+- Fetch relation data in a bounded query rather than awaiting `findUnique` inside an application loop.
+- Consider Prisma's relation load strategy only after measuring. `join` and `query` have different database and application trade-offs; availability depends on the provider and Prisma version.
+- Paginate parent and child collections with stable ordering. Do not solve unbounded response size solely by adding eager loading.
+
+### Verify
+- Assert query count and payload shape in an integration test or trace.
+- Recheck latency and database load with representative cardinality.
+
+*Source: [Prisma relation queries](https://www.prisma.io/docs/orm/prisma-client/queries/relation-queries).*
+
+---
+
+## Transaction Boundaries
+
+### Problem
+A workflow leaves partial state after a failure, or a transaction holds locks/connections while it performs network I/O or slow computation.
+
+### Verify first
+- Define the invariant that must be atomic and the acceptable behavior for retries.
+- Identify external side effects (email, HTTP calls, queues, files): they cannot be atomically committed with a PostgreSQL transaction.
+- Check contention, isolation requirements, and transaction duration under realistic concurrency.
+
+### Fix
+- Use nested writes or `$transaction([])` for independent Prisma operations that must commit together.
+- Use an interactive transaction only when later decisions depend on earlier reads, and keep its callback short.
+- Perform external effects after commit, or record an outbox event transactionally and deliver it separately.
+- Use database constraints and idempotency keys where possible; application-level check-then-insert logic alone races under concurrency.
+
+### Verify
+- Force a failure at each write boundary and confirm the invariant remains true.
+- Load-test conflicting operations and inspect retry/unique-constraint behavior.
+
+*Sources: [Prisma transaction guidance](https://www.prisma.io/docs/orm/prisma-client/queries/transactions#transaction-options), [PostgreSQL transaction isolation](https://www.postgresql.org/docs/current/transaction-iso.html).*
+
+---
+
+## Indexes and Query Plans
+
+### Symptom
+A correct query has rising latency, high I/O, sequential scans on a large table, or slow sorts after data growth.
+
+### Verify first
+- Capture the actual SQL and bind values for the slow query.
+- Run `EXPLAIN (ANALYZE, BUFFERS)` in a safe representative environment; it executes the statement, so do not use it casually on writes.
+- Check table statistics, row estimates, predicate selectivity, ordering, joins, and the write cost of a proposed index.
+
+### Fix
+- Add an index that matches the real filter, join, and ordering pattern. Composite index column order matters.
+- Use a partial index only when its predicate consistently matches the query and remains selective.
+- Prefer a separately managed migration for operationally sensitive indexes. PostgreSQL supports `CREATE INDEX CONCURRENTLY`, but it has transaction and failure-handling constraints.
+- Do not add indexes based only on model fields or a plan from a tiny local dataset.
+
+### Verify
+- Compare before/after plans, execution time, buffer reads, and write impact.
+- Confirm the planner uses the index for representative parameters, not just one favorable value.
+
+*Sources: [PostgreSQL EXPLAIN](https://www.postgresql.org/docs/current/using-explain.html), [multicolumn indexes](https://www.postgresql.org/docs/current/indexes-multicolumn.html), [CREATE INDEX](https://www.postgresql.org/docs/current/sql-createindex.html).*
+
+---
+
+## Connection Pooling and Runtime Constraints
+
+### Problem
+Deployments intermittently exhaust database connections, work locally but fail under serverless concurrency, or create a Prisma client per request.
+
+### Verify first
+- Determine the runtime model: long-lived process, containers with autoscaling, short-lived functions, edge runtime, or worker fleet.
+- Calculate worst-case connections across all instances and pools against PostgreSQL `max_connections`, reserving capacity for administration and other services.
+- Confirm whether the runtime supports the Prisma engine/client configuration in use; edge and serverless environments have specific constraints.
+
+### Fix
+- Reuse one `PrismaClient` per long-lived process rather than constructing it for every request.
+- Set pool limits based on total deployment concurrency, not a single instance. Use an external pooler where the platform topology requires it, and validate its compatibility with transaction/session behavior.
+- Bound serverless concurrency when needed; connection pooling cannot make unlimited concurrent database work safe.
+- Keep transactions short, because each active transaction consumes a connection.
+
+### Verify
+- Observe active, waiting, and idle connections during a concurrency test.
+- Test cold starts, scale-out, and failure recovery against the intended deployment topology.
+
+*Sources: [Prisma connection management](https://www.prisma.io/docs/orm/prisma-client/setup-and-configuration/databases-connections/connection-management), [Prisma serverless guidance](https://www.prisma.io/docs/orm/prisma-client/setup-and-configuration/databases-connections#serverless-environments), [PostgreSQL connection settings](https://www.postgresql.org/docs/current/runtime-config-connection.html).*