# Вот промпт, который можно уложить в кодекс: 
Ты — опытный 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.

Не упрощай задачу: сгенерируй именно полноценный каркас проекта,
как если бы ты начинал реальный коммерческий проект под эту задачу.