Этап: SQLite и запуск пайплайна

docs/ai_work_log.md

@@ -35,3 +35,35 @@
 **Решения и изменения.** csv.reader в строгом режиме читает UTF-8 с поддержкой BOM и нумерует логические записи после заголовка. Нечитаемый файл, ошибка разбора CSV или неверный заголовок прерывают обработку. Для читаемой записи неверной ширины сохраняются все исходные поля. Точный дубль получает только причину повтора. Для остальных структурно корректных записей собираются ошибки независимых полей. Выручка проверяется при пригодных для расчёта цене и количестве. Среди валидных заказов сначала определяется наличие конфликта во всей группе ID. Номер источника сохраняется и у принятого заказа, но исключён из сравнения нормализованных значений. План обновлён согласно уточнению о нескольких причинах.
 
 **Фактические проверки.** Полный запуск pytest дал 32 passed. На синтетическом raw_orders.csv обработаны 1500 записей, приняты 1482, отброшены 18. Из них 14 имели ошибки значений, одна оказалась точным дублем, одна — нормализованным, две отклонены из-за конфликта ID. Проверено, что номера от 1 до 1500 встречаются в совокупном результате ровно по одному разу. Байты CSV до и после обработки совпали, SHA-256 — `c4b9ffd2eb24c6c79b6a3e2436f3bd348ba86696a1aeb9b7e3083af65c799c67`.
+
+## 12 ноября 2026 — дополнительные проверки генерации, чтения и очистки
+
+**Запрос пользователя.** Проверить запланированные примеры в CSV, обработку ошибок файла, нумерацию, деньги и приоритет причин отбраковки. Устранить повтор схемы CSV и уточнить план экспорта и аналитики.
+
+**Изменения.** Генератор использует FIELDS из extract.py. Добавлено шесть тестов. Они проверяют содержимое созданного во временной папке CSV, неверную кодировку, отказ при открытии файла (подмена PermissionError), многострочное поле с CRLF и нумерацию после него, смешанную группу дублей и конфликтов с проверкой порядка обоих списков, расчёт большой суммы с точностью до копейки. Новые проверки прошли на существующей логике очистки.
+
+**План.** Уточнены состав clean_orders.csv и учёт нескольких причин у одной отброшенной записи. Для будущих отчётов принят календарь между крайними датами принятых заказов. Для аномалий каждой категории учитываются нулевые дни, используется стандартное отклонение генеральной совокупности и строгий двусторонний порог 2σ. При периоде короче семи дней или нулевой дисперсии результат пуст.
+
+**Проверки.** Через существующую .venv выполнен полный pytest до изменений (32 passed) и после (38 passed). На исходном CSV принято 1482 заказа, отклонено 18. SHA-256 перед работой и после проверок совпал — `c4b9ffd2eb24c6c79b6a3e2436f3bd348ba86696a1aeb9b7e3083af65c799c67`. Повторно сгенерированный во временной папке CSV побайтово совпал с исходным.
+
+## 12 ноября 2026 — уточнение аналитики и пути экспорта
+
+По запросу пользователя в плане закреплён путь `outputs/clean_orders.csv` относительно корня проекта. Динамику показываем по общей дневной выручке всех категорий, одной строкой на дату. Аномалии ищем отдельно по дневной выручке каждой категории, используя её собственные среднее и стандартное отклонение.
+
+## 12 ноября 2026 — статистика и экспорт результатов
+
+**Запрос пользователя.** Создать quality.py, выгрузить два CSV в UTF-8 с BOM и отчёт JSON, проверить баланс, повторный запуск и пустой снимок. Предусмотреть сохранение после успешной загрузки БД.
+
+**Решения.** Модуль принимает результаты очистки и отдельное число исходных записей. Проверяет сумму статусов и покрытие всех исходных номеров без повторов. Итоговая причина — первая из обнаруженных в порядке проверок. Отдельные счётчики проблем включают все обнаруженные причины и могут пересекаться. В CSV отбраковки заголовок источника, исходные значения и причины представлены JSON-массивами. Так сохраняются порядок колонок, пустые и лишние поля. Состав чистого CSV уточнён в плане до шести запрошенных колонок. При сборке пайплайна save_outputs будет вызываться после успешного завершения транзакции БД.
+
+**Фактические проверки.** Через существующую .venv выполнен полный pytest — 40 passed. Временный пример проверил несколько причин у одной записи, порядок, кодировку, обратное чтение значений, побайтовое совпадение при повторном экспорте и замену снимка пустым с долей null. Проверено отклонение несогласованных количеств и повторяющихся номеров. Для текущего этапа три файла созданы прямым вызовом экспорта после очистки. Чтение результатов из outputs подтвердило 1482 принятых и 18 отброшенных из 1500, доля 0,988. Суммы обоих счётчиков на этом наборе равны 18. SHA-256 исходного CSV до и после совпал.
+
+## 12 ноября 2026 — транзакционная загрузка и запуск пайплайна
+
+**Запрос пользователя.** Реализовать схему SQLite, полную загрузку заказов и дневных агрегатов и команду python main.py. Проверить повторяемость данных, согласованность CSV, обработку пустого снимка и сохранность предыдущих данных при сбое.
+
+**Решения.** В sql/schema.sql заданы первичные ключи и ограничения значений. src/database.py открывает одну транзакцию до создания и очистки таблиц, вставляет заказы с параметрами, строит daily_category_revenue одним группирующим запросом и фиксирует обе таблицы вместе. main.py проверяет статистику до записи базы. После фиксации он передаёт готовый отчёт в save_reports. Если экспорт завершается ошибкой, CLI указывает, что база уже обновлена, и сохраняет исходную диагностику. Ранее использовавшийся интерфейс save_outputs сохранён.
+
+**Фактические проверки.** В существующей .venv прошли все 45 тестов. Пять новых интеграционных тестов запускали копию проекта во временном каталоге из другой рабочей папки. Переполнение суммы группы откатило изменения обеих таблиц. Испорченный CSV сохранил прежний снимок. Набор без принятых заказов очистил обе таблицы. Сбой экспорта после фиксации базы завершил CLI с ненулевым кодом и сообщением об обновлённой БД.
+
+На рабочем синтетическом CSV команда python main.py создала outputs/orders.db. Вход — 1500 записей, приняты 1482, отброшены 18. Получено 438 групп по дате и категории. Суммарная выручка в обеих таблицах составила 1 687 705 899 копеек. Содержимое обеих таблиц сравнили до и после повторного запуска, заказы сверили по всем шести полям с clean_orders.csv. SHA-256 исходного CSV совпал с исходным замером. Аналитические запросы остаются следующим этапом.

docs/implementation_plan.md

@@ -21,6 +21,7 @@
 3. Проверить число полей. Для записи правильной ширины собрать все ошибки независимых полей в порядке таблицы. Проверить произведение, только если количество и цена прошли проверку. Сохранять один итоговый статус и список фактически установленных причин на запись.
 4. Сгруппировать только валидные записи по нормализованному ID. Сравнивать дату, категорию, количество и цену в копейках. Если значения совпадают у всей группы, принять запись с наименьшим номером, остальные отметить как нормализованные дубли. Если есть хотя бы два варианта значений, отклонить всю валидную группу как конфликт ID, включая повторившиеся варианты. Уже отброшенные точные дубли сохраняют исходную причину.
 5. Вывести количество прочитанных, принятых и отброшенных записей, разбивку по причинам и номера отклонённых записей. Число прочитанных должно равняться сумме принятых и отброшенных. Сумма счётчиков причин может быть больше числа отброшенных записей.
+6. Перед загрузкой БД сформировать статистику через `build_report`, передав число прочитанных записей. После фиксации транзакции вызвать `save_reports(accepted, rejected, report)`. В `outputs/clean_orders.csv` записать колонки `order_id`, `order_date`, `category`, `quantity`, `unit_price_kopecks`, `revenue_kopecks` в исходном порядке записей. В `outputs/rejected_rows.csv` сохранить номер записи, исходный заголовок, значения и причины. В `outputs/quality_report.json` сохранить статистику. Каждый запуск заменяет файлы, пустые CSV содержат заголовки.
 
 ## Модули и загрузка
 
@@ -28,24 +29,27 @@
 |---|---|
 | `src/extract.py` | `read_records(path) -> Iterator[RawRecord]`. Передаёт номер записи и исходные значения, проверяет заголовок и ширину записи. |
 | `src/transform.py` | `clean_orders(records) -> tuple[list[Order], list[RejectedRecord]]`. Рассчитывает выручку одного заказа и возвращает принятые заказы и отбраковку с причинами. |
-| `src/storage.py` | `reload_database(path, orders) -> None`. Обновляет обе таблицы атомарно и рассчитывает дневные агрегаты в SQLite. |
+| `src/database.py` | `reload_database(path, orders) -> None`. Обновляет обе таблицы атомарно и рассчитывает дневные агрегаты в SQLite. |
 | `main.py` | Определяет корень по расположению самого файла, собирает пути к ресурсам, вызывает этапы и выводит отчёт. |
 
-В `orders` хранить одну принятую запись на `order_id` (первичный ключ), включая номер записи, дату, категорию, количество, цену и выручку в копейках. В `daily_revenue` хранить сумму выручки в копейках с составным первичным ключом из даты и категории.
+В `orders` хранить одну принятую запись на `order_id` (первичный ключ), включая дату, категорию, количество, цену и выручку в копейках. В `daily_category_revenue` хранить количество заказов и сумму выручки в копейках с составным первичным ключом из даты и категории.
 
-В одной явной транзакции создать таблицы при первом запуске, очистить обе, загрузить принятые заказы и заполнить `daily_revenue` запросом с `SUM` и `GROUP BY order_date, category` из `orders`. Это единственное место построения дневной витрины. Зафиксировать транзакцию после успешного завершения всех операций. Ошибка загрузки или переполнение суммы группы отменяет транзакцию целиком, сохраняя предыдущие данные.
+В одной явной транзакции создать таблицы при первом запуске, очистить обе, загрузить принятые заказы и заполнить `daily_category_revenue` запросом с `SUM` и `GROUP BY order_date, category` из `orders`. Это единственное место построения дневной витрины. Зафиксировать транзакцию после успешного завершения всех операций. Ошибка загрузки или переполнение суммы группы отменяет транзакцию целиком, сохраняя предыдущие данные.
 
 ## Неоднозначности и рабочие допущения
 
-- Исходного CSV пока нет. Предлагаемый формат — UTF-8 с поддержкой BOM, запятая между полями, двойные кавычки для значений с запятой или переводом строки. Для синтетического набора явно указать происхождение в README. Исходный файл открывать только на чтение.
+- Исходный синтетический набор находится в `data/raw_orders.csv`. Формат — UTF-8 с поддержкой BOM при чтении, запятая между полями, двойные кавычки для значений с запятой или переводом строки. Указать происхождение в README. При обработке исходный файл открывать только на чтение.
 - Колонки сопоставлять по именам. Отсутствующее, повторное или лишнее имя в заголовке считать ошибкой файла. Неверное число полей в читаемой записи считать ошибкой записи. Если из-за повреждения CSV границы записей определить невозможно, остановить запуск до загрузки.
 - Файл с корректным заголовком и нулём принятых заказов считать пустым снимком. При полной перезагрузке обе таблицы станут пустыми.
-- Для аналитики предлагаются три запроса к витрине. Топ — пять категорий по суммарной выручке с сортировкой по имени при равенстве. Динамика — сумма по дате и изменение в копейках к предыдущей доступной дате. Аномалия — дневная выручка категории более чем вдвое выше предыдущего наблюдения той же категории. Первое наблюдение пропускается, пропущенные даты нулями не заполняются. Порог — рабочее допущение для тестового задания.
+- Для аналитики использовать календарь от первой до последней даты принятого заказа включительно. В отчётах заполнять нулями дни без продаж, в том числе для каждой категории, встречающейся в снимке. Для пустого снимка календарь пуст.
+- Топ — пять категорий по суммарной выручке с сортировкой по имени при равенстве. Для динамики суммировать выручку всех категорий за каждый календарный день. Выводить одну строку на дату с общей выручкой и её изменением в копейках к предыдущему дню. Для первого дня изменение не определено.
+- Аномалии искать отдельно для каждой категории. По всему календарю, включая нулевые дни, по дневной выручке этой категории рассчитать среднее и стандартное отклонение генеральной совокупности (дисперсия с делением на число дней). Отмечать день при абсолютном отклонении от среднего строго больше двух стандартных отклонений. Проверять как рост, так и падение. При числе дней меньше 7 или нулевой дисперсии аномалии не выдавать.
 
 ## Критерии готовности реализации
 
 - На pytest проверить оба формата дат, невозможные даты, пробелы, пустые поля, дробное количество, варианты цены и переполнение на границе INTEGER. Проверить нумерацию на CSV с многострочным полем.
 - На размеченном примере сверить статус каждой исходной записи, причины и баланс счётчиков. Включить повтор невалидной записи, одинаковые нормализованные заказы, конфликт из трёх записей с двумя совпадающими вариантами и валидную запись рядом с невалидной того же ID.
 - Сверить копейки по известному примеру. Две единицы по 10,25 рубля и одна за 0,50 рубля в тот же день и в той же категории должны дать одну строку витрины на 2100 копеек.
+- Сверить строки `outputs/clean_orders.csv` с принятыми заказами. Для аналитики проверить календарный пропуск, периоды в 6 и 7 дней, постоянную выручку и значения ниже, выше и точно на границе двух стандартных отклонений.
 - Запустить пайплайн дважды с тем же CSV, в том числе из другой рабочей папки. Сравнить содержимое обеих таблиц, отчёты и контрольную сумму исходного файла. На изменённом снимке проверить удаление устаревших заказов и агрегатов. На переполнении суммы группы проверить откат обеих таблиц.
 - Перед сдачей подготовить готовую SQLite-базу, три SQL-запроса с фактическими результатами, README с командами запуска и тестов и журнал фактически выполненных проверок.