Agentfy.ai 2.0

Русский

English
Українська

Русский

English
Українська

Appearance

Реализация ​

Build-промпт для агента-кодера: как поднять архитектурный фундамент Agentfy.ai 2.0 — монорепо, CleanSlice-скелет api, 8 слоёв-групп слайсов, инвариант «зависимости только вниз» и базовую схему Prisma. Фичовые слайсы наполняются позже (у каждого своя страница Implementation).

Это промпт для агента

У каждого раздела есть страница Implementation — точный copy-paste спек, который выполняет агент. Сначала прочти Обзор, Слои-слайсы и Схему БД — они источник правды, на который ссылается промпт.

Промпт ​

text
ROLE: You are scaffolding the FOUNDATION of Agentfy.ai 2.0 (NestJS + Prisma + CleanSlice). Not
features yet — the skeleton everything else is built on.

GOAL: A booting `api` with the 8 layered slice groups wired as empty-but-valid modules, the
"dependencies point only downward" rule ENFORCED in CI, Prisma connected with a baseline schema, and
the sibling apps scaffolded. Ready for feature slices to drop in.

DELIVERABLES
1) Monorepo: api/ (NestJS), app/ (Nuxt), admin/ (Nuxt), worker/, k8s/, docs/. Shared tooling
   (tsconfig base, eslint, prettier), `#`-path aliases per app.
2) `api` CleanSlice structure: src/slices/<group>/<slice>/{domain,data,dtos,<slice>.module.ts}.
   Create all 8 groups as wired modules (empty is fine):
   infra · setup · system · user · admin · runtime · agent · billing.
3) LAYERING ENFORCEMENT: a dependency-boundary check (eslint-plugin-boundaries or dependency-cruiser)
   that FAILS CI when a lower group imports a higher one. Order (low→high):
   infra → setup → system → user → admin → runtime → agent → billing.
4) infra + setup baseline: infra/prisma (PrismaService), infra/redis, infra/storage adapters;
   setup/core (config · error filter · health · rate-limit), setup/mcp (tool registry).
5) Prisma baseline: Team, User, UserTeam, Agent + the conventions (see DB schema). One migration.
6) A trivial GET /health that boots green.

CONTRACTS / CONVENTIONS (follow exactly)
- Slice anatomy: domain (gateway abstract class + entities/types), data (Prisma-backed concrete
  gateway + mapper), dtos (camelCase: createUser.dto.ts). Prisma IS the repository.
- Gateway pattern: an abstract class `IXxxGateway` in domain/ is the DI token; the concrete impl
  lives in data/ and is bound in the module.
- IDs: `{slice}-{uuid}`, generated in `mapper.toCreate`.
- `I`-prefixed abstract classes as DI tokens (IUserGateway, IUserData); `Types` suffix for enums
  (UserStatusTypes); no `any` — use `unknown` + type guards.
- Singular slice folder names (`user/`, not `users/`); routes are plural.

SECURITY: no secrets in the repo; config via env; Prisma URL + KEK from env only.

ACCEPTANCE: see the checklist below. Start at v0.1 scope.

Референс — чему агент должен следовать ​

8 слоёв-групп (инвариант) ​

L0  infra      адаптеры внешних систем (prisma · redis · storage · vector)
L0  setup      плумбинг фреймворка (core · mcp)
L1  system     общие сервисы (usage · setting · notification · llm · file)
L2  user       идентичность / тенантность
L3  admin      ops (читает другие через Prisma)
L4  runtime    эфемерное исполнение (tasks · worker · events)
L5  agent      домен агента + orchestrator (мозг)
L6  billing    чистый sink (его никто не импортирует)

Правило: каждая группа импортирует только группы ниже. Без циклов. Это хребет — CI-проверка границ существует, чтобы нарушение нельзя было замержить. См. Слои-слайсы.

Анатомия слайса ​

slices/<group>/<slice>/
├── domain/                 gateway (абстрактный IXxxGateway) · entities · types · errors
├── data/                   конкретный gateway (Prisma) · mapper (toCreate ставит id)
├── dtos/                   createXxx.dto.ts · updateXxx.dto.ts (файлы camelCase)
└── <slice>.module.ts       биндит IXxxGateway → concrete, экспонирует use-cases

База Prisma ​

Реализуй Team, User, UserTeam, Agent ровно как в Схеме БД (id {slice}-{uuid}, тенантность teamId, таймстемпы). Остальное приходит со своим фичовым слайсом.

Порядок задач ​

  1. v0.1 — фундамент (эта страница): монорепо + скелет api + 8 связанных групп + CI-проверка слоёв + база infra/setup + база Prisma + /health.
  2. v0.2 — core (без рантайма): наполнить agent, system/llm, agent/chat, agent/memory, agent/orchestrator.
  3. v0.3 — эфемерный рантайм: runtime/task, runtime/worker, runtime/event, приложение worker (см. Worker → Implementation).
  4. дальше: слайсы user/admin/billing, фронтенды, SDK — по Плану.

Критерии приёмки ​

  • [ ] api стартует; GET /health отдаёт 200; prisma migrate накатывает базу чисто.
  • [ ] Все 8 групп есть как валидные NestJS-модули под src/slices/<group>/.
  • [ ] CI-проверка границ падает, когда нижняя группа импортирует верхнюю (докажи временным плохим импортом, затем убери его).
  • [ ] Пример-слайс следует анатомии: абстрактный gateway в domain/, Prisma-имплементация в data/, id чеканится как {slice}-{uuid} в mapper.toCreate.
  • [ ] Нет any; DI-токены с префиксом I; singular-папки слайсов.

См. также ​