You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: AGENTS.md
+89-41Lines changed: 89 additions & 41 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -2,22 +2,43 @@
2
2
3
3
ЦЕЛЬ: Создавать математически доказуемые решения через функциональную парадигму с полным разделением чистых вычислений и контролируемых эффектов.
4
4
5
-
Всегда начинай свой ответ с постановки задачи Deep Research "I am looking for code that does <requestedfunctionality>, is there existing code that can do this?" Любое решение строится на математических инвариантах, доказуемых свойствах и проверяемых источниках. Код создается только после формального понимания проблемы и построения архитектурной модели.
5
+
МОДЕЛЬ РАССУЖДЕНИЯ:
6
+
7
+
- Не выдавать “личные мнения”. Формировать вывод как результат симуляции профессионального обсуждения релевантных ролей
- Если запрос сформулирован как “что думаешь”, отвечать в терминах аргументов ролей и выбирать решение
10
+
по критериям инвариантов, типовой безопасности и тестируемости (если пользователь явно просит выбор — выбрать и обосновать).
11
+
12
+
ПРАВИЛО ПРОЦЕССА (НЕ ФОРМАТ ОТВЕТА):
13
+
В начале работы (внутренне) формулировать Deep Research вопрос:
14
+
"I am looking for code that does <requestedfunctionality>, is there existing code that can do this?"
15
+
Далее:
16
+
17
+
- если доступен проект/код — сперва искать и переиспользовать существующие паттерны (минимальный корректный diff),
18
+
- если проект недоступен — опираться на предоставленный контекст и явно фиксировать допущения,
19
+
- код писать только после формального понимания задачи (типы/инварианты → архитектура → код → тесты),
20
+
- источники указывать только если реально использован внешний материал; иначе `SOURCE: n/a`.
21
+
22
+
Любое решение строится на математических инвариантах, доказуемых свойствах и проверяемых источниках. Код создается только после формального понимания проблемы и построения архитектурной модели.
6
23
7
24
АРХИТЕКТУРНЫЕ ПРИНЦИПЫ:
8
25
═══════════════════════════════
9
26
10
27
🏗️ **FUNCTIONAL CORE, IMPERATIVE SHELL**:
11
28
12
29
- CORE: Исключительно чистые функции, неизменяемые данные, математические операции
13
-
- SHELL: Все эффекты (IO, сеть, БД) изолированы в тонкой оболочке
30
+
- SHELL: Все эффекты (IO, сеть, БД, env/process) изолированы в тонкой оболочке
14
31
- Строгое разделение: CORE никогда не вызывает SHELL
15
32
- Зависимости: SHELL → CORE (но не наоборот)
16
33
17
34
🔒 **ТИПОВАЯ БЕЗОПАСНОСТЬ**:
18
35
19
-
- Никогда: `any`, `unknown`, `eslint-disable`, `ts-ignore`, `as` (кроме обоснованных случаев)
20
-
- Всегда: исчерпывающий анализ union types через `.exhaustive()`
36
+
- Никогда: `any`, `eslint-disable`, `ts-ignore`
37
+
-`unknown`: допускается ТОЛЬКО на boundary (SHELL) как вход в декодирование (например, `@effect/schema`);
38
+
после декодинга `unknown` не должен выходить наружу boundary-модуля
39
+
-`as`: запрещён в обычном коде; допускается ТОЛЬКО в одном “аксиоматическом” модуле (бренды/конструкторы/константы),
40
+
дальше использование без кастов
41
+
- Всегда: исчерпывающий анализ union types через `.exhaustive()` / `Match.exhaustive`
21
42
- Внешние зависимости: только через типизированные интерфейсы
22
43
- Ошибки: типизированы в сигнатурах функций, не runtime exceptions
23
44
@@ -27,19 +48,24 @@
27
48
- Композиция через `pipe()` и `Effect.flatMap()`
28
49
- Dependency injection через Layer pattern
29
50
- Обработка ошибок без try/catch
51
+
- Запрещено в продукт-коде: `async/await`, raw Promise chains (`then/catch`), `Promise.all`
52
+
- Interop с Promise/исключениями — только в SHELL через `Effect.try` / `Effect.tryPromise` (с типизированным маппингом ошибок)
53
+
- Ресурсы с финализацией — только через `Effect.acquireRelease` + `Effect.scoped`
0 commit comments