Depter · 0.3

Долги магазина: справочники, ручное проведение прихода/продажи/оплаты с фото, сторно, заявки клиента и ссылка без входа. Внутреннее кодовое имя репозитория и npm-пакета — ongoy; в интерфейсе продукт называется Depter.

Реализовано

• Next.js 16, TypeScript, русский интерфейс, desktop sidebar и mobile navigation.
• Supabase Auth: вход email/password, обновление сессии, выход, проверка пользователя в каждом серверном действии.
• Создание организации атомарной RPC. Повтор с тем же ключом не создаёт вторую организацию.
• 13 таблиц плана + audit_events. RLS и составные внешние ключи разделяют данные организаций.
• Списки, поиск, создание, редактирование и карточки клиентов, поставщиков, товаров; по 25 записей на страницу.
• Read models для склада и долгов; показатели главной страницы и история создания магазина.
• Точные десятичные значения: numeric в PostgreSQL, строки в API read models, без Number при форматировании сумм.
• Прямое изменение регистров покупок, продаж, оплат и склада из клиентского приложения запрещено.
• Приход, продажа и оплата проводятся транзакционными PostgreSQL RPC с проверкой членства, идемпотентностью и аудитом.
• Продажа блокируется, если доступного остатка недостаточно; склад и долги считаются из проведённых регистров.
• Форма ручной операции показывает точные суммы, после проведения доступна история операций и расчёты с контрагентами.
• Базовые экраны ошибок и ожидания. Preview не доступен в production.

Что ещё не готово

Фото/upload, ADRE (Gemini) и проверка результата — сделано, см. docs/implementation.md. Ещё не готово: второй AI-провайдер как резерв, customer/product matching и управление aliases из UI, cloud deployment и end-to-end Auth. Данные бухгалтерских регистров не вводятся через SQL вручную для реального пилота. Тесты заполняют только одноразовую локальную БД.

Запуск

Требуется Node.js 24 LTS, npm. Lockfile включён.

npm ci
cp .env.example .env.local

1. Создайте отдельный Supabase проект ongoy-pilot после согласования организации и тарифа. Не используйте базы других приложений.
2. Примените SQL-файлы из supabase/migrations через SQL Editor в этом отдельном проекте, строго по имени: сначала foundation, затем ERP commands. Первая миграция рассчитана на пустой public schema; вторую не запускайте отдельно от foundation.
3. В Authentication отключите свободную регистрацию для закрытого пилота. Создайте тестового пользователя в Dashboard. Назначение ролей организации идёт через серверную RPC, не через user_metadata.
4. Заполните NEXT_PUBLIC_SUPABASE_URL и NEXT_PUBLIC_SUPABASE_PUBLISHABLE_KEY в .env.local. Secret/service-role key приложению не нужен.
5. Выполните npm run dev. Откройте http://localhost:3000, войдите, создайте магазин, добавьте товары и клиентов.

Проверки

npm test
npm run typecheck
npm run build
npm run test:smoke

npm test запускает реальный PostgreSQL engine PGlite с минимальным auth.uid shim. Это проверяет миграцию, права ролей, RLS, FK, views и ограничения. Это не проверка облачных Supabase Auth и PostgREST. npm run test:smoke после сборки запускает отдельный production сервер без Supabase credentials: проверяет редиректы защищённых маршрутов, экран настройки, запрет /preview даже при включённом флаге и noindex. После настройки реальных credentials выполните повторную сборку. NEXT_PUBLIC переменные должны быть заданы ДО build.

Посмотреть интерфейс без базы

docs/preview.html — статический снимок главной страницы из серверного рендера. Откройте файл в браузере. Цифры нулевые, кнопки не проводят операций.

Локально можно запустить ONGOY_PREVIEW=1 npm run dev и открыть /preview (для Windows PowerShell: $env:ONGOY_PREVIEW='1'; npm run dev). Этот маршрут не позволяет войти, читать или сохранять данные. В production возвращает 404.

Развёртывание Vercel

1. Создайте приватный GitHub репозиторий и загрузите исходники, исключая .env.local, node_modules и .next.
2. Импортируйте репозиторий в Vercel как Next.js проект; добавьте в Environment Variables ДО build: две Supabase переменные, и если нужно распознавание фото — GEMINI_API_KEY, GEMINI_MODEL (только там, не в файлах репозитория). Node 24.
3. Настройте Deployment Protection для закрытого пилота. Не включайте публичное раскрытие данных или обход Auth.
4. Установите Site URL проекта Supabase на фактический адрес приложения. Текущий вход использует пароль; email reset/magic-link ещё не реализованы.
5. Проверьте реальный вход/выход, создание организации, CRUD, обновление страницы, новую сессию и второй магазин. Проверьте мобильный браузер.

Архитектура

• src/lib/context.ts: request-scoped user/organization context, без service-role.
• src/lib/supabase/server.ts, src/proxy.ts: SSR cookies + session refresh.
• src/app/(workspace): закрытые страницы.
• src/app/(workspace)/[kind]/actions.ts: whitelist справочников, валидация и запись.
• src/app/(workspace)/money/actions.ts, src/components/operation-form.tsx: проверка ввода и формы ручных операций.
• src/lib/validation.ts: серверная валидация десятичных строк и справочников.
• supabase/migrations: схема, RLS, read models и атомарные RPC commit_purchase, commit_sale, commit_payment.
• tests: проверка изоляции, сумм, прав и duplicate constraints.
• docs/pilot-plan.md: исходный план, сохранён без изменений.

Для нескольких организаций пока выбирается первая по времени членства; переключатель не реализован. Создание ограничено тремя организациями на пользователя для пилота. Все участники пилота имеют одинаковые возможности справочников. ERP RPC блокируют организацию на время проведения, проверяют членство и остаток, сохраняют регистры и аудит одной транзакцией. Идемпотентный повтор с тем же ключом и теми же данными возвращает прежний результат; повтор ключа с другими данными отклоняется. Облачный Auth пока не подключён.

Цели скорости из исходного плана остаются acceptance criteria. Они ещё не измерены на облаке и реальных документах.