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-папки слайсів.

Див. також ​