anker-na-20
244 lines
14 KiB
Markdown
244 lines
14 KiB
Markdown
# Вот промпт, который можно уложить в кодекс:
|
||
Ты — опытный senior full‑stack архитектор и разработчик.
|
||
Твоя задача — спроектировать и сгенерировать ПОЛНЫЙ каркас проекта
|
||
(backend + frontend + инфраструктура), который будет использоваться
|
||
для конвейера PDF→структурированный JSON→DOCX по шаблонам Word.
|
||
|
||
ВАЖНО:
|
||
- Нужен готовый проект с понятной файловой структурой, рабочим билдом
|
||
и запуском в Docker.
|
||
- Нужна поддержка git: .gitignore, базовые скрипты, README.
|
||
- Шаблоны Word создавать НЕ нужно. Нужно предусмотреть каталог,
|
||
конфигурацию и код для их загрузки/использования, чтобы я мог сам
|
||
положить .docx и сразу ими пользоваться.
|
||
- Проект должен быть написан максимально понятно и аккуратно, с
|
||
комментариями в ключевых местах.
|
||
|
||
---
|
||
|
||
## Технологический стек (можешь предлагать улучшения, но по умолчанию так):
|
||
|
||
### Общие требования
|
||
- Ориентируемся на развёртывание в Linux‑среде, запуск через docker-compose.
|
||
- Backend и frontend запускаются в отдельных контейнерах.
|
||
- В перспективе backend будет общаться с локальной LLM (Qwen) через
|
||
OpenAI‑совместимый API на внешнем сервере (например, Ollama),
|
||
но до развёртывания этой модели мы будем ходить в облачную LLM.
|
||
- Поэтому нужна конфигурируемая переменная окружения
|
||
`LLM_BASE_URL` и `LLM_API_KEY`, а логика работы с LLM должна быть
|
||
изолирована в отдельном слое‑адаптере.
|
||
|
||
### Backend
|
||
- Язык: TypeScript.
|
||
- Фреймворк: Node.js + NestJS ИЛИ Express + modular architecture
|
||
(если считаешь, что Nest избыточен, обоснуй в комментариях README).
|
||
- HTTP API (REST), без GraphQL.
|
||
- Работа с файлами: загружать PDF, временно хранить их на диске,
|
||
отдавать готовый DOCX, хранить метаданные задач в БД.
|
||
- База данных: PostgreSQL (через Prisma или TypeORM — выбери один и
|
||
задокументируй выбор).
|
||
- Логирование: простой логгер (winston/pino) с выводом в консоль.
|
||
- Конфигурация: через .env (используй библиотеку наподобие
|
||
dotenv / @nestjs/config).
|
||
- Поддержка CORS для фронтенда.
|
||
|
||
### Frontend
|
||
- Язык: TypeScript.
|
||
- Фреймворк: React + Vite или Next.js (на твой выбор, но без SSR‑сложностей,
|
||
достаточно SPA, если берёшь Vite/React).
|
||
- UI‑задача:
|
||
- Страница с формой загрузки PDF:
|
||
- поле выбора файла;
|
||
- выбор типа документа/шаблона (просто select с dummy‑значениями
|
||
вроде "ГОСТ‑1", "ГОСТ‑2" — пока они только передаются на backend);
|
||
- кнопка «Отправить на обработку».
|
||
- Отображение списка задач:
|
||
- идентификатор задачи;
|
||
- имя исходного файла;
|
||
- статус (QUEUED / PROCESSING / DONE / ERROR);
|
||
- ссылка для скачивания результата, если есть DOCX.
|
||
- Простая страница деталей задачи (по id):
|
||
- метаданные;
|
||
- простой лог/ошибки, если были.
|
||
- Верстка может быть минимальной, без сложного дизайна, главное —
|
||
чистая архитектура и удобство доработки.
|
||
|
||
---
|
||
|
||
## Бизнес‑логика, которую нужно учесть
|
||
|
||
Цель системы: офисные сотрудники загружают PDF‑файл с технической документацией (ТЗ по ГОСТу и т.п.).
|
||
Backend:
|
||
|
||
1. Принимает PDF и создаёт “задачу обработки” в БД.
|
||
2. Сохраняет PDF в файловой системе (например, каталог `storage/input`).
|
||
3. Отправляет PDF в отдельный n8n‑workflow ИЛИ обрабатывает локально
|
||
цепочкой шагов (сейчас — просто заглушка, позже я подвяжу n8n).
|
||
4. В перспективе pipeline будет такой:
|
||
- PDF → парсер (вытаскиваем текст/Markdown);
|
||
- Markdown → LLM (Qwen) → унифицированный JSON структуры документа;
|
||
- JSON + Word‑шаблон → генератор DOCX;
|
||
- результат сохраняем как DOCX в `storage/output`.
|
||
Но в рамках этого задания тебе нужно:
|
||
- СДЕЛАТЬ кодовые заготовки для этих шагов (интерфейсы, классы,
|
||
абстракции, контроллеры, DTO, сервисы),
|
||
- Реализовать «заглушки» (например, вместо реального вызова LLM и
|
||
генератора DOCX возвращать фиктивный JSON/файл),
|
||
- Чётко показать точки интеграции, где я потом подключу реальную
|
||
обработку.
|
||
|
||
5. Backend должен предоставлять API:
|
||
- `POST /api/jobs` — загрузка PDF:
|
||
- multipart/form-data, поле `file`, опционально `templateType`.
|
||
- возвращает объект задачи `{ id, status, fileName, createdAt }`.
|
||
- `GET /api/jobs` — список задач (с пагинацией, query‑параметры).
|
||
- `GET /api/jobs/:id` — детальная информация о задаче, включая
|
||
путь/URL к результату, лог ошибок.
|
||
- `GET /api/jobs/:id/result` — скачивание готового DOCX.
|
||
- `GET /api/templates` — список доступных Word‑шаблонов (backend
|
||
должен сканировать папку `templates/` и возвращать названия файлов /
|
||
метаданные; сами .docx я положу вручную).
|
||
- `POST /api/templates/reload` — принудительное перечитывание списка
|
||
шаблонов (на будущее).
|
||
|
||
6. Статусы задач:
|
||
- QUEUED, PROCESSING, DONE, ERROR.
|
||
- Нужен enum и таблица/модель `Job` с полями:
|
||
- id (uuid),
|
||
- originalFileName,
|
||
- storedFilePath,
|
||
- resultFilePath (nullable),
|
||
- status,
|
||
- errorMessage (nullable),
|
||
- templateType (строка),
|
||
- createdAt, updatedAt.
|
||
|
||
7. Адаптер к LLM:
|
||
- Нужен отдельный сервис/модуль (например, `llm/llmClient.ts`),
|
||
который:
|
||
- берёт на вход текст/markdown и возвращает JSON структуры
|
||
документа (пока можно вернуть фиктивный JSON).
|
||
- конфигурируется через переменные окружения:
|
||
- `LLM_BASE_URL` — URL OpenAI‑совместимого API
|
||
(в будущем это будет адрес локального Qwen на сервере Ollama).
|
||
- `LLM_API_KEY` — токен для облачной модели (сейчас).
|
||
- `LLM_MODEL` — имя модели (например, `gpt-4.1-mini` или другое).
|
||
- Весь остальной код НЕ должен знать детали формата API конкретного
|
||
поставщика, только использовать этот клиент/адаптер.
|
||
|
||
8. Адаптер генерации DOCX:
|
||
- Отдельный сервис (например, `docx/docxGenerator.ts`), который:
|
||
- принимает JSON структуры и имя шаблона;
|
||
- находит шаблон в папке `templates/` (но сам шаблон не создаёт);
|
||
- создаёт DOCX в `storage/output/<jobId>.docx`.
|
||
- На этом этапе достаточно сделать заглушку:
|
||
- например, создать простой текстовый DOCX через любую
|
||
библиотеку (или даже временно создавать `.txt` файл, но
|
||
оставить интерфейс и структуру под DOCX).
|
||
- Важно: предусмотреть удобное место, куда я положу свои .docx
|
||
шаблоны, и в README описать, как они должны называться
|
||
и как выбираются.
|
||
|
||
***
|
||
|
||
## Инфраструктура и структура проекта
|
||
|
||
Пожалуйста, СГЕНЕРИРУЙ и ОПИШИ:
|
||
|
||
1. Общая структура репозитория (monorepo или два отдельных проекта — opиши выбор).
|
||
Пример, если это monorepo:
|
||
- `backend/`
|
||
- `frontend/`
|
||
- `docker/` (общие конфиги)
|
||
- `templates/` (каталог для Word‑шаблонов)
|
||
- `storage/input/` (исходные PDF, .gitignore внутри)
|
||
- `storage/output/` (результирующие DOCX, .gitignore внутри)
|
||
- `README.md`
|
||
- `.gitignore`
|
||
- `docker-compose.yml`
|
||
|
||
2. Файловая структура backend:
|
||
- `src/main.ts`, `src/app.module.ts` (для Nest) или аналог для Express.
|
||
- Модуль/пакет `jobs`:
|
||
- контроллер для API задач;
|
||
- сервис работы с задачами;
|
||
- DTO и entity/модель для БД.
|
||
- Модуль/пакет `files`:
|
||
- загрузка файлов;
|
||
- валидация типов;
|
||
- работа с путями хранения.
|
||
- Модуль/пакет `llm`:
|
||
- клиент для LLM;
|
||
- интерфейсы типов ответов.
|
||
- Модуль/пакет `docx`:
|
||
- генератор DOCX;
|
||
- адаптер к будущему шаблонизатору Docx (docxtemplater/Pandoc/и т.п.).
|
||
- Общий модуль `config` для работы с .env.
|
||
- Конфиг Prisma/TypeORM и миграции для таблицы `Job`.
|
||
|
||
3. Файловая структура frontend:
|
||
- Точка входа и маршрут `/` с формой загрузки и списком задач.
|
||
- Компоненты:
|
||
- `UploadForm`
|
||
- `JobsList`
|
||
- `JobDetails`
|
||
- Сервис для общения с backend (например, `api/client.ts`), где:
|
||
- базовый URL API берётся из env (`VITE_API_BASE_URL` и т.п.).
|
||
- Простая система типов TypeScript для сущностей Job и Template.
|
||
|
||
4. .gitignore:
|
||
- Исключить:
|
||
- node_modules,
|
||
- build‑артефакты,
|
||
- .env и другие секреты,
|
||
- `storage/input`, `storage/output`,
|
||
- временные файлы IDE.
|
||
|
||
5. Docker:
|
||
- `Dockerfile` для backend.
|
||
- `Dockerfile` для frontend.
|
||
- `docker-compose.yml`, который поднимает:
|
||
- `backend` (с зависимостью от `db`);
|
||
- `frontend`;
|
||
- `db` (PostgreSQL);
|
||
- Переменные окружения для docker‑compose с примером (файл `.env.example`).
|
||
|
||
6. README:
|
||
- Пошаговая инструкция:
|
||
- как установить зависимости;
|
||
- как запустить проект локально без Docker;
|
||
- как запустить через `docker-compose up`;
|
||
- как добавить новый Word‑шаблон (куда положить .docx, как он
|
||
подхватывается API `/api/templates`).
|
||
- Пример запроса к API загрузки файла (curl).
|
||
- Краткое объяснение архитектуры:
|
||
- где слой LLM‑адаптера;
|
||
- где слой генерации DOCX;
|
||
- как в будущем подключить n8n и локальную Qwen.
|
||
|
||
***
|
||
|
||
## Формат ответа
|
||
|
||
Сформируй ответ в три части:
|
||
|
||
1. Краткое текстовое объяснение архитектуры (2–3 абзаца).
|
||
2. Подробная структура файлов/папок в формате дерева с комментариями.
|
||
3. Основные файлы кода как СНИППЕТЫ:
|
||
- `docker-compose.yml`;
|
||
- `backend/Dockerfile`, `frontend/Dockerfile`;
|
||
- key‑файлы backend (main, контроллер задач, модель Job, LLM‑клиент,
|
||
заглушка генератора DOCX);
|
||
- key‑файлы frontend (главная страница, клиент API);
|
||
- `.gitignore`;
|
||
- `.env.example`;
|
||
- выдержки из README с инструкциями.
|
||
|
||
Код можно не доводить до идеального продакшена, но он должен быть:
|
||
- компилируемым,
|
||
- структурированным,
|
||
- с понятными комментариями, что и где доработать, чтобы подключить
|
||
реальную LLM и реальный генератор DOCX по шаблонам Word.
|
||
|
||
Не упрощай задачу: сгенерируй именно полноценный каркас проекта,
|
||
как если бы ты начинал реальный коммерческий проект под эту задачу. |