--- .rs (32 files, 3043 lines) ---
452 domain\formulas.rs
286 presentation\table_render.rs
280 infrastructure\repository.rs
265 infrastructure\xlsx_xml.rs
198 services\cell_change_service.rs
127 presentation\controller.rs
121 infrastructure\excel_loader.rs
110 services\export_service.rs
106 presentation\html_views.rs
103 domain\dto.rs
85 services\errors.rs
81 services\calc_service.rs
75 presentation\flows.rs
74 infrastructure\sheet_list.rs
69 app_state.rs
67 infrastructure\auth.rs
66 infrastructure\user_ctx.rs
60 main.rs
57 services\viewer_queries.rs
56 services\adapters.rs
53 domain\styles.rs
48 infrastructure\report_registry.rs
42 domain\utils.rs
40 domain\merges.rs
38 infrastructure\sessions.rs
26 infrastructure\errors.rs
20 presentation\view_models.rs
12 domain\errors.rs
9 infrastructure\mod.rs
6 domain\mod.rs
6 services\mod.rs
5 presentation\mod.rs

--- .sql (6 files, 278 lines) ---
78 migrations\03_templates_mod.sql
56 migrations\04_reports_mod.sql
44 migrations\06_test_users.sql
40 migrations\05_add_postgres_extentions.sql
37 migrations\01_templates.sql
23 migrations\02_reports.sql

--- .html (3 files, 106 lines) ---
54 presentation\templates\reports.html
26 presentation\templates\report_header.html
26 presentation\templates\login.html

Первая попытка (C# + EPPlus):

Мутабельный ООП-движок формул (готовая библиотека):
├─ Проблема: блокировки при конкурентном доступе
├─ Вариант 1: Полная блокировка - слишком медленно
├─ Вариант 1Б: Полная блокировка листа - и медленно и сложно
├─ Вариант 2: Батч накапливает изменения от всех пользователей + подписка на результат - сложно делать подписку
├─ Вариант 2Б: Таймеры-дятлы (контроллеры спрашивают батч "готово?") - растет лаг до ответа
├─ Вариант 3: Воркер на клиента + синхронизация через БД - очень много ОЗУ, придется делать время жизни воркера, снижать нагрузку на БД путем добавления write through cache с батч записью в БД и gracefull degradation
└─ Результат: каждый вариант сложен или ухудшает свойства системы, непонятно как выбрать

Проблема: оптимизации stateful (чертов ООП!) системы, слишком сложно проектировать,
         нельзя доверить LLM (tacit контекст, trade-offs, partial failure)

Вторая попытка (Rust + ручная реализация):

Иммутабельная модель + функциональное ядро:
├─ Парсер формул по EBNF грамматике
├─ Интерпретатор (чистые функции)
├─ Топологический анализ зависимостей формул (обнаружение циклов)
└─ Eventual consistency (LWW для конфликтов), но мелко гранулярная

Результат: формализованные задачи LLM сделала безупречно,
          а архитектурные решения (консистентность, конкурентность) 
          я зафиксировал сам до генерации кода.

Третья попытка (снова С#, батчинг и дятлы):

Таймеры-дятлы (контроллеры спрашивают у батча "готово?" 10-20 раз в секунду) оказались все же проще. То, что я считал за недостаток - таймер увеличивает лаг ответа на свой интервал - оказалось благом: мы избавились от "удара грома", когда система должна одновременно ответить сотням и тысячам пользователей сразу после завершения батча, создавая пиковую нагрузку. Дятлы-таймеры же вносят небольшой естественный джиттер в доли секунды.

Но у этого варианта было сложно доказать пригодность по НФТ (низкий лаг, не упираемся в ресурсы) и он уже не был реализован. К тому же, недостаток опыта не позволил мне сразу реализовать дятлов красиво.