Ридми. Делал все сам, но дай бог поможет

2026-05-25 14:42:24 +03:00
parent 6e5d9e978b
commit 71d7d77ecd
1 changed files with 244 additions and 0 deletions
@@ -0,0 +1,244 @@
+# Вот промпт, который можно уложить в кодекс: 
+Ты — опытный 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.
+
+Не упрощай задачу: сгенерируй именно полноценный каркас проекта,
+как если бы ты начинал реальный коммерческий проект под эту задачу.