@nitra/cursor 12.8.6 → 12.8.8

package/rules/js-bun-redis/js/imports.mdc

@@ -0,0 +1,47 @@
+## Сканування заборонених redis-імпортів у JS/TS-джерелах
+
+Правило сканує всі JS/TS-файли проєкту (`.js`, `.ts`, `.mjs`, `.cjs`, `.jsx`, `.tsx` тощо, без `.d.ts`) на наявність `import`, `require()` або динамічного `import()` з заборонених пакетів:
+
+- `ioredis` та підшляхи (`ioredis/…`)
+- `node-redis`
+- `redis` та підшляхи (`redis/…`)
+- `@redis/client`, `@redis/json`, `@redis/search`, `@redis/time-series`, `@redis/bloom`
+
+Усі ці пакети слід замінити на **Bun native Redis**: `import { redis } from 'bun'` — документація: <https://bun.com/docs/runtime/redis>.
+
+Сканування виконується через **oxc-parser** по AST (не regex по тексту) — статичні імпорти, `require()`-виклики і динамічні `import()` окремо.
+
+При синтаксичних помилках у файлі результат — порожній (спочатку виправити синтаксис).
+
+Директорії, зазначені у `.n-cursor-ignore` / `cursorignore` конфігурації, повністю пропускаються.
+
+### Повідомлення про порушення
+
+```
+js-bun-redis: src/conn/redis.ts:3 — заміни 'ioredis' на Bun native Redis (import { redis } from 'bun', https://bun.com/docs/runtime/redis): import IORedis from 'ioredis'
+```
+
+### Міграція
+
+```ts
+// До (ioredis)
+import IORedis from 'ioredis'
+const client = new IORedis({ host: 'localhost', port: 6379 })
+await client.set('key', 'value')
+
+// Після (Bun native Redis)
+import { redis } from 'bun'
+await redis.set('key', 'value')
+```
+
+```ts
+// До (node-redis / redis v4)
+import { createClient } from 'redis'
+const client = createClient()
+await client.connect()
+await client.set('key', 'value')
+
+// Після (Bun native Redis)
+import { redis } from 'bun'
+await redis.set('key', 'value')
+```

package/rules/js-bun-redis/js/package_json.mdc

@@ -0,0 +1,44 @@
+## Перевірка `dependencies` у `package.json` (Rego gate)
+
+Rego-полісі `js_bun_redis.package_json` перевіряє `package.json` кожного воркспейсу на наявність заборонених redis-залежностей у полі `dependencies`.
+
+**Namespace:** `js_bun_redis.package_json`
+
+Канон заборонених пакетів надходить через `--data` з файлу-шаблону:
+
+[package.json.deny.json](./policy/package_json/template/package.json.deny.json)
+
+Поточний список заборонених `dependencies`:
+
+| Пакет | Причина |
+|---|---|
+| `ioredis` | заміни на Bun native Redis |
+| `node-redis` | заміни на Bun native Redis |
+| `redis` | заміни на Bun native Redis |
+| `@redis/client` | заміни на Bun native Redis |
+| `@redis/json` | заміни на Bun native Redis |
+| `@redis/search` | заміни на Bun native Redis |
+| `@redis/time-series` | заміни на Bun native Redis |
+| `@redis/bloom` | заміни на Bun native Redis |
+
+### Повідомлення про порушення
+
+```
+dependencies.ioredis — заміни на Bun native Redis (js-bun-redis.mdc)
+```
+
+### Виправлення
+
+```jsonc
+// package.json — видалити зі списку dependencies:
+{
+  "dependencies": {
+    // "ioredis": "...",      ← видалити
+    // "node-redis": "...",   ← видалити
+    // "redis": "...",        ← видалити
+    // "@redis/client": "...",← видалити
+  }
+}
+```
+
+Після видалення пакетів з `dependencies` виконати також сканування джерел на заборонені імпорти — перевірка `js-bun-redis-imports`.

package/rules/js-bun-redis/main.mdc

@@ -5,16 +5,10 @@ alwaysApply: false
 version: '1.2'
 ---
 
-## Підтримувані версії redis
+Правило забороняє використання застарілих redis-клієнтів (`ioredis`, `node-redis`, `redis`, `@redis/*`) і вимагає переходу на **Bun native Redis** (`import { redis } from 'bun'`). Підтримувана версія Redis: **7.2+**.
 
-Redis 7.2+
+[js-bun-redis-imports](./js/imports.mdc)
 
-## Заміна на Bun native Redis
+[js-bun-redis-package_json](./js/package_json.mdc)
 
-Якщо в проєкті використовуються бібліотеки `ioredis`, `node-redis`, їх потрібно замінити на Bun native Redis: <https://bun.com/docs/runtime/redis>.
-
-- Видалити з `dependencies`: `ioredis`, `node-redis`.
-- Видалити з коду: усі `import` / `require` цих пакетів та власні обгортки над ними.
-- Замінити на `import { redis } from 'bun'`
-
-Канон заборонених `dependencies` (`ioredis`, `node-redis`, `redis`, `@redis/*`): [package.json.deny.json](./policy/package_json/template/package.json.deny.json).
+[js-bun-redis-policy-package_json](./policy/package_json/package_json.mdc)

package/rules/js-bun-redis/policy/package_json/package_json.mdc

@@ -0,0 +1,11 @@
+## Rego gate: заборонені redis-залежності у `package.json`
+
+Rego-пакет: `js-bun-redis.package_json`
+
+**Цільовий файл:** `package.json` (поле `dependencies`)
+
+Перевіряє наявність заборонених redis-пакетів у `dependencies`. Список заборон надходить через `--data` з канонічного шаблону:
+
+[package.json.deny.json](./template/package.json.deny.json)
+
+Повідомлення про порушення формується як `dependencies.<pkg> — <reason>`.

package/rules/js-mssql/js/mssql-in-list.mdc

@@ -0,0 +1,38 @@
+## Парсинг і guard для `IN (${...})`
+
+Якщо `IN (...)` все ж використовується (а не `JOIN` на TVP), значення в `${...}` **обов'язково** мають бути попередньо приведені числовим парсером і відфільтровані від `NaN`.
+
+Це знімає будь-яку можливість SQL injection: SQL-метасимволи в `Number`/`parseInt(...)` перетворюються на `NaN` і відсіюються.
+
+### Правила
+
+Додатково:
+
+- значення для `IN (${...})` потрібно **винести в окрему змінну** перед запитом (не підставляти вираз напряму в `${...}`);
+- цю змінну потрібно **перевірити на пустоту** і якщо список порожній — **throw error** (щоб не виконувати некоректний запит).
+
+### Приклади
+
+```javascript
+// ❌ НЕ МОЖНА: значення з req.body / зовнішнього джерела без парсингу
+const outIds = pgQ.rows.flatMap(x => x.req_body.Orders.map(o => o.OutletId))
+await pool.query(/* sql */ String.raw`
+  SELECT ... WHERE so.OutletId IN (${outIds})
+`)
+```
+
+```javascript
+// ✅ МОЖНА: parseInt + filter(!isNaN) гарантує, що в SQL потраплять лише числа
+// і перед запитом робимо guard на пустоту, щоб не виконувати некоректний SQL.
+const outIds = pgQ.rows
+  .flatMap(x => x.req_body.Orders.map(o => parseInt(o.OutletId)))
+  .filter(n => !isNaN(n))
+if (!outIds.length) throw new Error('outIds is empty')
+await pool.request().query`
+  SELECT ... WHERE so.OutletId IN (${outIds})
+`
+```
+
+Допустимі парсери: `parseInt(...)`, `parseFloat(...)`, `Number(...)`, `BigInt(...)` або унарний `+x`. Літеральні масиви чисел (`[1, 2, 3]`) теж безпечні — без парсера, але без жодних рядків.
+
+Це правило діє і для безпечного `pool.request().query\`...\`` (де mssql сам параметризує масив), і поготів для `pool.query(String.raw\`...\`)` чи `pool.query(\`...\`)`, де такий парсинг — єдиний бар'єр.

package/rules/js-mssql/js/mssql-pool.mdc

@@ -0,0 +1,56 @@
+## Singleton ConnectionPool і заборона shared Request
+
+Потрібно використовувати connection pool (`sql.ConnectionPool`) як singleton, а **НЕ** створювати підключення на кожен запит.
+
+```javascript
+// db.js
+import sql from 'mssql';
+
+let poolPromise;
+
+export function getPool() {
+  if (!poolPromise) {
+    const db = new sql.ConnectionPool(config);
+    poolPromise = db.connect().catch(err => {
+      poolPromise = undefined; // дозволити повторну спробу
+      throw err;
+    });
+  }
+  return poolPromise;
+}
+```
+
+```javascript
+// usage
+import { getPool } from './db.js';
+
+const pool = await getPool();
+const userId = 42;
+const status = 'active';
+
+// Tagged template на request — це працює
+const result = await pool.request().query`
+  SELECT * FROM users
+  WHERE id = ${userId} AND status = ${status}
+`;
+```
+
+Ключове: `pool.request().query\`...\`` — бектіки після `query`, без круглих дужок. Це tagged template, де mssql параметризує значення автоматично.
+
+### Заборона shared Request
+
+Заборонено робити singleton `request` на рівні модуля:
+
+```javascript
+// ❌ НЕ МОЖНА
+export const request = pool.request();
+```
+
+`Request` має створюватися **щоразу заново**:
+
+```javascript
+// ✅ МОЖНА
+const request = pool.request();
+```
+
+Це особливо важливо для **TVP** (табличні параметри) та будь-яких `.input(...)`.

package/rules/js-mssql/js/mssql-query-template.mdc

@@ -0,0 +1,33 @@
+## Безпечний tagged template vs небезпечний `query(...)`
+
+Різниця між `query\`...\`` і `query(\`...\`)` — критична.
+
+### Що НЕ робити: `query(\`...\`)`
+
+```javascript
+// ❌ Це не tagged template — це конкатенація рядка перед викликом
+await pool.request().query(`SELECT * FROM users WHERE id = ${userId}`);
+// ↑ круглі дужки замість бектіків = звичайна інтерполяція = SQL injection
+```
+
+### Що робити: `query\`...\``
+
+```javascript
+// ✅ Tagged template — mssql параметризує ${userId} автоматично
+await pool.request().query`SELECT * FROM users WHERE id = ${userId}`;
+```
+
+### Коментар під час виправлення SQL injection
+
+Коли виправляєш місце з потенційним SQL injection (заміна `query(\`...\`)` на `query\`...\`` або прибирання динамічних списків/конкатенації), **додай поруч короткий коментар** з описом причини.
+
+Вимоги до коментаря:
+
+- вказати **що було небезпечно** (звичайна інтерполяція в рядок, конкатенація, динамічний список);
+- вказати **чому новий варіант безпечний** (tagged template / параметризація / TVP);
+- 1–2 рядки, без дублювання очевидного.
+
+```javascript
+// SQLi fix: query`...` (tagged template) параметризує значення; query(`...`) небезпечний через інтерполяцію.
+await pool.request().query`SELECT * FROM users WHERE id = ${userId}`
+```

package/rules/js-mssql/js/mssql-tvp.mdc

@@ -0,0 +1,75 @@
+## TVP (table-valued parameters) — рекомендований підхід для списків
+
+TVP дозволений і рекомендований для SQL Server 2019. Для списків значень та пар ключів **найкращий** шлях по безпеці/продуктивності — TVP.
+
+### 1) `IN (...)` для кодів → `JOIN` на TVP
+
+Замість складання SQL-рядка:
+
+```javascript
+// ❌ НЕ МОЖНА: динамічний список у SQL
+await pool.request().query`
+  SELECT *
+  FROM promo.SomeTable t
+  WHERE t.ExternalCode IN (${codes.map(c => `'${c}'`).join(',')})
+`;
+```
+
+Роби TVP з 1 колонкою:
+
+- створити `new sql.Table()`
+- `columns.add('ExternalCode', sql.NVarChar(N))`
+- `rows.add(code)` після `trim()` + валідації
+- `request.input('codes', table)`
+- в SQL: `JOIN @codes c ON c.ExternalCode = t.ExternalCode`
+
+Плюси:
+
+- 0% SQL injection
+- текст SQL **не росте** від довжини масиву
+- SQL Server часто оптимізує `JOIN` краще, ніж гігантський `IN (...)`
+
+### 2) `DELETE ... VALUES (...)` / `MERGE ... VALUES (...)` → TVP з 2 колонками
+
+Замість генерації списку рядків `(...),(...),...` у SQL (навіть якщо воно "через tagged template"):
+
+- сформуй TVP-таблицю `@Pairs` з колонками:
+  - `PromoActivitiesId` (INT або BIGINT — як у схемі БД)
+  - `SupplierOutletId` (INT або BIGINT — як у схемі БД)
+
+Delete:
+
+```sql
+DELETE abi
+FROM promo.ActivitiesByOutlet abi
+JOIN @Pairs p
+  ON p.PromoActivitiesId = abi.PromoActivitiesId
+ AND p.SupplierOutletId = abi.SupplierOutletId;
+```
+
+Insert (без `MERGE`, простіше і безпечніше):
+
+```sql
+INSERT INTO promo.ActivitiesByOutlet (PromoActivitiesId, SupplierOutletId, Status)
+SELECT p.PromoActivitiesId, p.SupplierOutletId, 2
+FROM @Pairs p
+WHERE NOT EXISTS (
+  SELECT 1
+  FROM promo.ActivitiesByOutlet abi
+  WHERE abi.PromoActivitiesId = p.PromoActivitiesId
+    AND abi.SupplierOutletId = p.SupplierOutletId
+);
+```
+
+Плюси:
+
+- не збираєш SQL-рядок із даних
+- менше шансів упіймати edge-case `MERGE` (у SQL Server історично багато "сюрпризів")
+
+### Мінімальна валідація перед наповненням TVP
+
+Навіть з TVP потрібно:
+
+- `ExternalCode`: `typeof === 'string'`, `trim()`, довжина `<= N` (під схему), відкинути пусті.
+- ліміт на кількість елементів (наприклад 5k/10k — залежить від вашого потоку).
+- `supplierId`/ID: число/BigInt, валідне та скінченне.

package/rules/js-mssql/js/mssql-version.mdc

@@ -0,0 +1,7 @@
+## Версія пакета `mssql`
+
+Якщо в проекті в будь-якому `package.json` в секції `dependencies` присутній пакет **`mssql`**, то його версія повинна бути не менше **12.5.0**.
+
+Правило орієнтоване на **SQL Server 2019**.
+
+Допустимі формати діапазону: `^12.5.0`, `>=12.5.0`, `12.5.0`, `workspace:*` (трактується як OK).

package/rules/js-mssql/main.mdc

@@ -5,210 +5,22 @@ alwaysApply: false
 version: '1.4'
 ---
 
-## Підтримувана версія SQL Server
+Правило охоплює безпечне використання пакету `mssql` у Node.js: мінімальну версію залежності, singleton ConnectionPool, заборону небезпечних шаблонів запитів і захист від SQL injection через TVP або числовий парсинг IN-списків.
 
-Правило орієнтоване на **SQL Server 2019**.
+[js-mssql-mssql-version](./js/mssql-version.mdc)
 
-## Версія пакета `mssql`
+[js-mssql-mssql-pool](./js/mssql-pool.mdc)
 
-Якщо в проекті в будь-якому `package.json` в секції `dependencies` присутній пакет **`mssql`**, то його версія повинна бути не менше **12.5.0**.
+[js-mssql-mssql-query-template](./js/mssql-query-template.mdc)
 
-Потрібно використовувати connection pool (sql.ConnectionPool) як singleton, а НЕ створювати підключення на кожен запит.
+[js-mssql-mssql-tvp](./js/mssql-tvp.mdc)
 
-## Як виконувати запити (безпечно)
+[js-mssql-mssql-in-list](./js/mssql-in-list.mdc)
 
-tagged template треба викликати на request-обʼєкті цього пулу:
+## Швидкий gate через conftest
 
-```javascript
-javascript// db.js
-import sql from 'mssql';
+Rego-перевірки (`policy/`) — швидкий синхронний gate для одиничного `package.json` без JS-рантайму:
 
-let poolPromise;
+[js-mssql-package_json](./policy/package_json/package_json.mdc)
 
-export function getPool() {
-  if (!poolPromise) {
-    const db = new SQL.ConnectionPool(config);
-    poolPromise = pool.connect().catch(err => {
-      poolPromise = undefined; // дозволити повторну спробу
-      throw err;
-    });
-  }
-  return poolPromise;
-}
-```
-
-```javascript
-// usage
-import { getPool } from './db.js';
-
-const pool = await getPool();
-const userId = 42;
-const status = 'active';
-
-// Tagged template на request — це працює
-const result = await pool.request().query`
-  SELECT * FROM users
-  WHERE id = ${userId} AND status = ${status}
-`;
-
-```
-
-Ключове: pool.request().query\...`— бекті́ки післяquery`, без круглих дужок. Це той самий tagged template, тільки контекст — конкретний пул, а не глобальний.
-
-## Коментар під час виправлення SQL injection
-
-Коли виправляєш місце з потенційним **SQL injection** (наприклад, заміна `query(\`...\`)` на `query\`...\`` або прибирання динамічних списків/конкатенації), **додай поруч короткий коментар** з описом причини.
-
-Вимоги до коментаря:
-
-- вказати **що було небезпечно** (звичайна інтерполяція в рядок, конкатенація, динамічний список);
-- вказати **чому новий варіант безпечний** (tagged template / параметризація / TVP);
-- 1–2 рядки, без дублювання очевидного.
-
-Приклад:
-
-```javascript
-// SQLi fix: query`...` (tagged template) параметризує значення; query(`...`) небезпечний через інтерполяцію.
-await pool.request().query`SELECT * FROM users WHERE id = ${userId}`
-```
-
-## Що НЕ робити
-
-### Не робити `query(\`...\`)`
-
-javascript// ❌ Це не tagged template — це конкатенація рядка перед викликом
-
-```javascript
-await pool.request().query(`SELECT * FROM users WHERE id = ${userId}`);
-// ↑ круглі дужки замість бекті́ків = звичайна інтерполяція = SQL injection
-```
-
-Різниця між query\...`іquery(`...`)` — критична. Перше безпечне, друге — діра.
-Потрібно використовувати перше. Потрібно шукати в коді друге і заміняти на перше.
-
-### Не шарити `Request` між запитами
-
-Заборонено робити singleton `request` на рівні модуля на кшталт:
-
-```javascript
-// ❌ НЕ МОЖНА
-export const request = pool.request();
-```
-
-`Request` має створюватися **щоразу заново**:
-
-```javascript
-// ✅ МОЖНА
-const request = pool.request();
-```
-
-Це особливо важливо для **TVP** (табличні параметри) та будь-яких `.input(...)`.
-
-## TVP дозволений і рекомендований (SQL Server 2019)
-
-Для списків значень та пар ключів **найкращий** шлях по безпеці/продуктивності — **TVP** (table-valued parameters).
-
-### 1) `IN (...)` для кодів → `JOIN` на TVP
-
-Замість складання SQL-рядка:
-
-```javascript
-// ❌ НЕ МОЖНА: динамічний список у SQL
-await pool.request().query`
-  SELECT *
-  FROM promo.SomeTable t
-  WHERE t.ExternalCode IN (${codes.map(c => `'${c}'`).join(',')})
-`;
-```
-
-Роби TVP з 1 колонкою:
-
-- створити `new sql.Table()`
-- `columns.add('ExternalCode', sql.NVarChar(N))`
-- `rows.add(code)` після `trim()` + валідації
-- `request.input('codes', table)`
-- в SQL: `JOIN @codes c ON c.ExternalCode = t.ExternalCode`
-
-Плюси:
-
-- 0% SQL injection
-- текст SQL **не росте** від довжини масиву
-- SQL Server часто оптимізує `JOIN` краще, ніж гігантський `IN (...)`
-
-### 2) `DELETE ... VALUES (...)` / `MERGE ... VALUES (...)` → TVP з 2 колонками
-
-Замість генерації списку рядків `(...),(...),...` у SQL (навіть якщо воно “через tagged template”):
-
-- сформуй TVP-таблицю `@Pairs` з колонками:
-  - `PromoActivitiesId` (INT або BIGINT — як у схемі БД)
-  - `SupplierOutletId` (INT або BIGINT — як у схемі БД)
-
-Delete:
-
-```sql
-DELETE abi
-FROM promo.ActivitiesByOutlet abi
-JOIN @Pairs p
-  ON p.PromoActivitiesId = abi.PromoActivitiesId
- AND p.SupplierOutletId = abi.SupplierOutletId;
-```
-
-Insert (без `MERGE`, простіше і безпечніше):
-
-```sql
-INSERT INTO promo.ActivitiesByOutlet (PromoActivitiesId, SupplierOutletId, Status)
-SELECT p.PromoActivitiesId, p.SupplierOutletId, 2
-FROM @Pairs p
-WHERE NOT EXISTS (
-  SELECT 1
-  FROM promo.ActivitiesByOutlet abi
-  WHERE abi.PromoActivitiesId = p.PromoActivitiesId
-    AND abi.SupplierOutletId = p.SupplierOutletId
-);
-```
-
-Плюси:
-
-- не збираєш SQL-рядок із даних
-- менше шансів упіймати edge-case `MERGE` (у SQL Server історично багато “сюрпризів”)
-
-## Мінімальна валідація перед наповненням TVP
-
-Навіть з TVP потрібно:
-
-- `ExternalCode`: `typeof === 'string'`, `trim()`, довжина `<= N` (під схему), відкинути пусті.
-- ліміт на кількість елементів (наприклад 5k/10k — залежить від вашого потоку).
-- `supplierId`/ID: число/BigInt, валідне та скінченне.
-
-## Парсинг значень для `IN (${...})`
-
-Якщо `IN (...)` все ж використовується (а не `JOIN` на TVP), значення в `${...}` **обовʼязково** мають бути попередньо приведені числовим парсером і відфільтровані від `NaN`. Це знімає будь-яку можливість SQL injection: SQL-метасимволи в `Number`/`parseInt(...)` перетворюються на `NaN` і відсіюються.
-
-Додатково:
-
-- значення для `IN (${...})` потрібно **винести в окрему змінну** перед запитом (не підставляти вираз напряму в `${...}`);
-- цю змінну потрібно **перевірити на пустоту** і якщо список порожній — **throw error** (щоб не виконувати некоректний запит).
-
-```javascript
-// ❌ НЕ МОЖНА: значення з req.body / зовнішнього джерела без парсингу
-const outIds = pgQ.rows.flatMap(x => x.req_body.Orders.map(o => o.OutletId))
-await pool.query(/* sql */ String.raw`
-  SELECT ... WHERE so.OutletId IN (${outIds})
-`)
-```
-
-```javascript
-// ✅ МОЖНА: parseInt + filter(!isNaN) гарантує, що в SQL потраплять лише числа
-// і перед запитом робимо guard на пустоту, щоб не виконувати некоректний SQL.
-const outIds = pgQ.rows
-  .flatMap(x => x.req_body.Orders.map(o => parseInt(o.OutletId)))
-  .filter(n => !isNaN(n))
-if (!outIds.length) throw new Error('outIds is empty')
-await pool.request().query`
-  SELECT ... WHERE so.OutletId IN (${outIds})
-`
-```
-
-Допустимі парсери: `parseInt(...)`, `parseFloat(...)`, `Number(...)`, `BigInt(...)` або унарний `+x`. Літеральні масиви чисел (`[1, 2, 3]`) теж безпечні — без парсера, але без жодних рядків.
-
-Це правило діє і для безпечного `pool.request().query\`...\`` (де mssql сам параметризує масив), і поготів для `pool.query(String.raw\`...\`)` чи `pool.query(\`...\`)`, де такий парсинг — єдиний бар'єр.
+JS-перевірка (`deps.mjs`) — authoritative: охоплює всі `package.json` репо, AST-скан JS/TS-джерел і повний semver-triple-compare. Rego-gate — доповнення, не заміна.

package/rules/js-mssql/policy/package_json/package_json.mdc

@@ -0,0 +1,9 @@
+## Rego-gate: версія `mssql` у `package.json`
+
+Rego-пакет: `js_mssql.package_json`
+
+Цільові файли: `**/package.json`
+
+Перевіряє поле `dependencies.mssql` — якщо присутнє, версія має бути `>= 12.5.0`. Підтримувані формати: `^12.5.0`, `>=12.5.0`, `12.5.0`, `workspace:*` (OK). Версії нижче 12.5.x генерують `deny`.
+
+Це швидкий синхронний gate для одиничного `package.json`. Authoritative-перевірка (повний semver-triple-compare, усі `package.json` репо) — у JS (`fix.mjs`).

package/rules/js-run/js/check-env.mdc

@@ -0,0 +1,35 @@
+## CheckEnv та заборона прямого `process.env`
+
+### CheckEnv
+
+Усі змінні оточення, які використовуються в коді, повинні бути перевірені за допомогою `checkEnv` з пакету `@nitra/check-env`. Це гарантує, що всі необхідні змінні оточення встановлені перед запуском програми.
+
+```javascript title="Приклад підключення до PostgreSQL в /src/conn/pg.mjs"
+import { checkEnv, env } from '@nitra/check-env'
+import { SQL } from 'bun'
+
+checkEnv(['PG_CONN'])
+
+export const db = new SQL({ url: env.PG_CONN })
+
+```
+
+### process.env
+
+Прямий доступ до `process.env.X` у коді заборонений — його треба замінити на `env`:
+
+> Стосується лише backend-пакетів (див. **Область застосування**). У frontend-пакетах (`vite` у `devDependencies`) — **не змінюй** `process.env.*` і **не додавай** імпорт `node:process`.
+
+- **обов'язкова змінна** — `import { checkEnv, env } from '@nitra/check-env'` плюс `checkEnv(['X'])`
+  у тому ж файлі (приклад див. вище в розділі **CheckEnv**);
+- **опційна змінна** — `import { env } from 'node:process'`:
+
+```javascript title="Опційна змінна — env з node:process"
+import { env } from 'node:process'
+
+console.log(env.OPTIONAL_ENV_VAR)
+```
+
+Тимчасово приглушити перевірку для конкретного рядка можна коментарем
+`// @nitra/cursor ignore-next-line checkEnv` безпосередньо перед використанням
+(escape-hatch для legacy-коду, не для нових файлів).