diff --git a/docs/FINDINGS.en.md b/docs/FINDINGS.en.md
new file mode 100644
index 0000000..a1a85f0
--- /dev/null
+++ b/docs/FINDINGS.en.md
@@ -0,0 +1,481 @@
+# Deep Architecture Review — `daggerok/csv`
+
+Review date: 2026-07-13  
+Reviewer role: Solution / Software Architect
+
+## Scope
+
+This review covers the current state of the repository, with focus on:
+
+- runtime architecture
+- parsing correctness
+- scalability and performance
+- privacy and security posture
+- maintainability and delivery quality
+- developer experience and documentation consistency
+
+## Validation performed
+
+I validated the repository with the following checks:
+
+- source review of `README.md`, `package.json`, `src/main.tsx`, `src/index.css`, `.github/workflows/ci.yaml`
+- `npm install --ignore-scripts`
+- `npm run build` ✅
+- ad-hoc TypeScript compile of `src/main.tsx` with `tsc --noEmit` ✅
+- `npm test -- --runInBand` ❌ — fails because no tests exist
+- `npm audit --json` ⚠️ — 3 vulnerabilities, all coming from `pm2` in dev dependencies
+- `npm audit --omit=dev --json` ✅ — production dependency graph is clean
+
+## Executive summary
+
+This repository is already a useful **local-first CSV utility** and shows strong product intuition for the target use case: messy brokerage exports, quick inspection, filters, sorting, merge mode, sticky headers, and client-only processing.
+
+However, from an architectural perspective, I would classify the codebase as:
+
+- **good prototype / strong personal tool**
+- **not yet a safe long-term product foundation**
+
+The biggest architectural concerns are:
+
+1. **too much logic concentrated in one file**
+2. **all parsing and rendering happens on the browser main thread**
+3. **the custom CSV heuristic can silently alter data**
+4. **sensitive financial data is persisted locally by default**
+5. **settings are global by column index, which causes cross-file collisions**
+6. **quality gates are weak: no tests, no lint/typecheck gate in CI**
+7. **documentation/toolchain drift increases maintenance cost**
+
+## Overall rating
+
+| Dimension | Rating | Notes |
+|---|---:|---|
+| Product usefulness | 8/10 | Very good utility for interactive review of CSV exports |
+| Architectural maturity | 5/10 | Works now, but difficult to scale safely |
+| Maintainability | 4/10 | Monolithic implementation and weak isolation of concerns |
+| Correctness confidence | 5/10 | Build passes, but parser/filter/export logic is under-tested |
+| Performance headroom | 4/10 | Fine for small/medium files; risky for large data sets |
+| Privacy posture | 5/10 | Client-only is good, but default persistence is risky |
+
+## Key strengths
+
+### 1. Clear product intent
+The application is focused and coherent. It solves a real user problem instead of trying to become a generic spreadsheet clone.
+
+### 2. Local-first design
+The app keeps data in the browser and avoids backend complexity. That is a strong fit for privacy-sensitive financial CSV exploration.
+
+### 3. Thoughtful UX features
+The repository already includes useful user-facing capabilities:
+
+- sticky headers / sticky first column
+- natural file sorting
+- per-column sorting and filtering
+- merged and per-file CSV export
+- dark mode
+- configuration export/import
+
+### 4. Good awareness of React StrictMode issues
+The boot-restore flow and paint-aware loading state show above-average attention to UI lifecycle edge cases.
+
+### 5. Build is currently healthy
+The app builds successfully, and an ad-hoc TypeScript compile passed.
+
+---
+
+# Findings
+
+## F-01 — Monolithic architecture with very high change coupling
+**Severity:** High
+
+### Evidence
+
+- `src/main.tsx` is ~1,673 lines and contains:
+  - parsing logic
+  - type detection
+  - filtering engine
+  - CSV export
+  - localStorage persistence
+  - loading orchestration
+  - UI components
+  - app composition / bootstrap
+- See especially `src/main.tsx:249-404`, `658-722`, `745-1662`.
+
+### Why it matters
+
+This structure makes the code easy to start, but expensive to evolve.
+
+Current risks:
+
+- one change can break unrelated behavior
+- parser logic is hard to test independently
+- UI reviews are noisy because domain logic and presentation are interleaved
+- onboarding time increases as the file grows
+- future features will likely increase merge conflicts and regression risk
+
+### Architectural impact
+
+The codebase is optimized for **speed of initial delivery**, not for **safe iteration**.
+
+### Recommendation
+
+Refactor into a small modular architecture:
+
+- `domain/csv-parser.ts`
+- `domain/column-types.ts`
+- `domain/filters.ts`
+- `domain/export.ts`
+- `state/settings-storage.ts`
+- `components/LoadingOverlay.tsx`
+- `components/ColumnHeader.tsx`
+- `components/ColumnFilterInput.tsx`
+- `App.tsx`
+
+Keep the UX the same, but move domain logic out of the render file.
+
+---
+
+## F-02 — Performance architecture will struggle on large files
+**Severity:** High
+
+### Evidence
+
+- full files are loaded into memory as strings: `src/main.tsx:715-720`
+- parsing is performed on the main thread: `src/main.tsx:1260-1279`
+- the app stores full datasets in React state: `src/main.tsx:962`, `1279`
+- merged mode renders all rows/cells without virtualization: `src/main.tsx:1589-1622`
+- non-merged mode also renders every row directly: `src/main.tsx:1639-1645`
+
+### Why it matters
+
+The app is described as “high-performance”, but the current runtime model is still:
+
+- read whole file
+- parse whole file
+- keep whole data in memory
+- render whole table DOM
+
+That model will degrade rapidly when users open large brokerage exports or many files at once.
+
+Typical symptoms:
+
+- long input delay
+- browser tab freezes
+- large memory pressure
+- very slow merge mode
+- bad UX on older laptops
+
+### Architectural impact
+
+The spinner improves perceived responsiveness, but it does not change the underlying scaling model.
+
+### Recommendation
+
+Priority improvements:
+
+1. move parsing into a **Web Worker**
+2. introduce **row virtualization** for both single-file and merged views
+3. consider **streaming / chunked parsing** instead of full-file `readAsText`
+4. move persistent large datasets from `localStorage` to **IndexedDB**
+5. define performance budgets for rows, columns, and total cells
+
+---
+
+## F-03 — Custom CSV heuristic can silently modify or truncate data
+**Severity:** High
+
+### Evidence
+
+- fields are trimmed during parse: `src/main.tsx:376`, `380`
+- rows with `targetColLength + 1` columns are accepted and then truncated: `src/main.tsx:398-400`
+
+### Why it matters
+
+For financial data tooling, **silent data mutation** is more dangerous than a visible parsing failure.
+
+Two concrete issues are present:
+
+#### A. Quoted whitespace is lost
+Because `currentValue.trim()` is applied to every cell, quoted values such as:
+
+```csv
+" ACME ","  keep spaces  "
+```
+
+become:
+
+```text
+ACME
+keep spaces
+```
+
+That changes the source data.
+
+#### B. Over-wide rows are silently truncated
+A row with one extra column is accepted and cut to the target width.
+Example:
+
+```csv
+a,b,c
+1,2,3,4
+5,6,7
+```
+
+becomes effectively:
+
+```csv
+a,b,c
+1,2,3
+5,6,7
+```
+
+The fourth value is lost without warning.
+
+### Architectural impact
+
+The current parser is optimized for “best effort cleanup”, but it needs a stronger correctness contract.
+
+### Recommendation
+
+1. do not trim quoted field content by default
+2. treat schema drift explicitly:
+   - reject row
+   - quarantine row
+   - or surface warning to the user
+3. add parser test fixtures for:
+   - embedded quotes
+   - leading/trailing whitespace
+   - multiline quoted values
+   - extra/missing columns
+   - Fidelity-style preambles/postambles
+4. consider using `PapaParse` as the RFC parser layer and keep heuristics as a separate cleanup stage
+
+---
+
+## F-04 — Sensitive data persistence is enabled by default
+**Severity:** High
+
+### Evidence
+
+- privacy notice says data remains isolated and secure: `README.md:82-86`
+- `rememberData` defaults to `true`: `src/main.tsx:309-320`
+- datasets are persisted in `localStorage`: `src/main.tsx:658-669`
+
+### Why it matters
+
+The app is used for brokerage / financial CSVs. Default local persistence creates privacy risk on:
+
+- shared laptops
+- family computers
+- managed corporate endpoints
+- public demo environments
+
+This is not a network leak, but it is still a **data retention risk**.
+
+### Architectural impact
+
+The product message is “client-only and secure”, but the default behavior is actually “client-only and retained locally”. Those are not the same thing.
+
+### Recommendation
+
+1. change default `rememberData` to `false`
+2. require explicit opt-in with clear wording:
+   - “Store imported data in this browser on this device”
+3. add a visible retention notice near the toggle
+4. optionally add TTL / auto-expiration
+5. document the behavior clearly in README and UI
+
+---
+
+## F-05 — Column settings are global by index, causing cross-file collisions
+**Severity:** High
+
+### Evidence
+
+- settings model uses `Record<number, ...>` for custom names, types, filters: `src/main.tsx:255-261`
+- headers reuse `settings.columnCustomNames[i]`: `src/main.tsx:1334-1336`
+- filters are global and reused across files: `src/main.tsx:1357`, `1404`, `1448`, `1609`, `1634`
+- sort state is also global: `src/main.tsx:260-261`, `1345-1348`
+
+### Why it matters
+
+In a multi-file app, “column 0” is not enough identity.
+
+Example:
+
+- file A column 0 = `Ticker`
+- file B column 0 = `Date`
+
+If the user renames, filters, or overrides the type for column 0 in one file, the same setting leaks into the other file.
+
+### Architectural impact
+
+This is the main domain-model problem in the repository. The UI supports multi-file workflows, but the settings model is still effectively single-schema.
+
+### Recommendation
+
+Introduce a dataset-aware key:
+
+- `datasetId + columnIndex`
+- or `schemaHash + columnIndex`
+
+Suggested model:
+
+```ts
+Record<string, Record<number, T>>
+```
+
+Where the outer key is stable per imported dataset or per detected schema.
+
+Also decide explicitly which settings should be:
+
+- global
+- per dataset
+- per schema
+
+---
+
+## F-06 — Documentation and toolchain drift increase maintenance cost
+**Severity:** Medium
+
+### Evidence
+
+- README says the app is built with **Bun** and **Vite**: `README.md:2-4`, `34-39`, `45-77`
+- actual scripts use **Parcel**: `package.json:10-18`
+- CI uses Bun to execute Parcel-based scripts: `.github/workflows/ci.yaml:21-23`, `40-44`
+- several direct dependencies appear unused in source review:
+  - `clsx`
+  - `lucide-react`
+  - `recharts`
+  - `tailwind-merge`
+  - `papaparse`
+  - `@types/papaparse`
+- `npm audit --json` reports 3 vulnerabilities coming from `pm2` / `ws` / `js-yaml`
+
+### Why it matters
+
+Even when the app builds, drift causes:
+
+- onboarding confusion
+- harder upgrades
+- unclear ownership of runtime choices
+- larger dependency surface than necessary
+
+### Architectural impact
+
+This is a governance issue rather than a runtime bug, but governance issues accumulate and eventually slow the team more than code defects.
+
+### Recommendation
+
+1. choose one documented stack and describe it accurately
+2. update README to match reality
+3. remove unused dependencies
+4. remove or upgrade `pm2` if it is not essential
+5. add dependency hygiene checks to CI
+
+---
+
+## F-07 — Quality gates are insufficient for parser-heavy logic
+**Severity:** Medium
+
+### Evidence
+
+- `package.json` defines `"test": "jest src"`: `package.json:17`
+- running tests fails with “No tests found”
+- CI does not run tests, lint, or typecheck; it only builds: `.github/workflows/ci.yaml:21-23`, `40-44`
+
+### Why it matters
+
+The highest-risk parts of the application are exactly the areas that need repeatable checks:
+
+- CSV parsing heuristics
+- filter expression grammar
+- export correctness
+- persistence / restore flows
+
+Without tests, correctness depends on manual usage and memory.
+
+### Recommendation
+
+Minimum test suite:
+
+1. **unit tests** for parser, filter grammar, type detection, export helpers
+2. **fixture tests** with real messy brokerage CSV samples
+3. **integration tests** for import → filter → export flows
+4. **CI gates** for:
+   - tests
+   - typecheck
+   - build
+
+Optional next step: add browser E2E smoke tests.
+
+---
+
+## F-08 — Accessibility and user-facing error handling need improvement
+**Severity:** Medium
+
+### Evidence
+
+- empty-state upload target is a clickable `<div>` only: `src/main.tsx:1566-1570`
+- file processing errors go to console only: `src/main.tsx:1268-1273`
+- invalid JSON import uses `alert(...)`: `src/main.tsx:1252`
+
+### Why it matters
+
+Current issues:
+
+- keyboard users may not be able to activate the empty-state uploader
+- failures are not surfaced in a structured way
+- `alert()` is disruptive and not ideal UX
+
+### Recommendation
+
+1. replace clickable `<div>` with a semantic `<button>` or labeled control
+2. add keyboard and screen-reader friendly affordances
+3. introduce non-blocking error toasts / inline notifications
+4. collect per-file import warnings and show them in UI
+
+---
+
+# Recommended roadmap
+
+## Phase 1 — Quick wins (1–2 weeks)
+
+- set `rememberData` default to `false`
+- update README to match Parcel/Bun reality
+- remove unused dependencies
+- remove or upgrade `pm2`
+- add parser fixtures and basic unit tests
+- fix whitespace trimming and row truncation behavior
+
+## Phase 2 — Structural hardening (2–4 weeks)
+
+- split `main.tsx` into domain/state/UI modules
+- redesign settings to be dataset-aware
+- add CI gates: test + typecheck + build
+- improve error reporting in UI
+
+## Phase 3 — Scale readiness (4–8 weeks)
+
+- move parse work into Web Worker
+- add row virtualization
+- evaluate IndexedDB for large retained datasets
+- define load/performance thresholds and regression tests
+
+---
+
+# Final architectural verdict
+
+I would **approve this repository as a strong prototype / internal utility**.
+
+I would **not yet approve it as the long-term baseline for a growing production-grade product** without the following first:
+
+- parser correctness hardening
+- privacy default change
+- modularization
+- dataset-aware settings model
+- automated tests in CI
+- large-data performance strategy
+
+In short:
+
+> Good product instinct, useful implementation, but the next step should be architecture hardening rather than feature expansion.
diff --git a/docs/FINDINGS.ru.md b/docs/FINDINGS.ru.md
new file mode 100644
index 0000000..21b62ea
--- /dev/null
+++ b/docs/FINDINGS.ru.md
@@ -0,0 +1,481 @@
+# Глубокий архитектурный обзор — `daggerok/csv`
+
+Дата обзора: 2026-07-13  
+Роль ревьюера: Solution / Software Architect
+
+## Область обзора
+
+В этом ревью я проверил текущее состояние репозитория с упором на:
+
+- runtime-архитектуру
+- корректность парсинга
+- масштабируемость и производительность
+- приватность и безопасность
+- сопровождаемость и качество поставки
+- DX и консистентность документации
+
+## Что было провалидировано
+
+Я выполнил следующие проверки:
+
+- ревью исходников `README.md`, `package.json`, `src/main.tsx`, `src/index.css`, `.github/workflows/ci.yaml`
+- `npm install --ignore-scripts`
+- `npm run build` ✅
+- ad-hoc TypeScript compile для `src/main.tsx` через `tsc --noEmit` ✅
+- `npm test -- --runInBand` ❌ — падает, потому что тестов нет
+- `npm audit --json` ⚠️ — найдено 3 уязвимости, все приходят через `pm2` в dev dependencies
+- `npm audit --omit=dev --json` ✅ — production dependency graph чистый
+
+## Executive summary
+
+Репозиторий уже представляет собой полезную **local-first утилиту для CSV** и показывает хорошее продуктовое понимание целевого кейса: грязные брокерские выгрузки, быстрый просмотр, фильтры, сортировка, merge mode, sticky headers и полностью client-side обработка.
+
+Но с архитектурной точки зрения я бы классифицировал кодовую базу так:
+
+- **хороший прототип / сильный personal tool**
+- **пока не лучшая долгосрочная основа для продукта**
+
+Главные архитектурные проблемы:
+
+1. **слишком много логики сосредоточено в одном файле**
+2. **весь парсинг и рендеринг выполняются в main thread браузера**
+3. **кастомная CSV-эвристика может тихо менять данные**
+4. **чувствительные финансовые данные по умолчанию сохраняются локально**
+5. **настройки глобальны по индексу колонки, из-за чего возникают cross-file collisions**
+6. **слабые quality gates: нет тестов, нет lint/typecheck gate в CI**
+7. **дрейф документации и toolchain повышает стоимость сопровождения**
+
+## Общая оценка
+
+| Направление | Оценка | Комментарий |
+|---|---:|---|
+| Product usefulness | 8/10 | Очень полезная утилита для интерактивного анализа CSV-выгрузок |
+| Architectural maturity | 5/10 | Сейчас работает, но безопасно масштабировать будет трудно |
+| Maintainability | 4/10 | Монолитная реализация и слабая изоляция ответственности |
+| Correctness confidence | 5/10 | Сборка проходит, но parser/filter/export почти не защищены тестами |
+| Performance headroom | 4/10 | Нормально для small/medium файлов, рискованно для больших наборов |
+| Privacy posture | 5/10 | Client-only — плюс, но persistence по умолчанию рискованен |
+
+## Сильные стороны
+
+### 1. Понятный product intent
+Приложение сфокусировано и последовательно. Оно решает реальную пользовательскую задачу, а не пытается стать очередным spreadsheet clone.
+
+### 2. Local-first design
+Приложение держит данные в браузере и не тащит backend-сложность. Для анализа чувствительных финансовых CSV это очень удачное решение.
+
+### 3. Продуманные UX-фичи
+В репозитории уже есть полезные возможности:
+
+- sticky headers / sticky first column
+- natural sorting файлов
+- per-column sorting и filtering
+- merged и per-file CSV export
+- dark mode
+- export/import конфигурации
+
+### 4. Хорошее понимание особенностей React StrictMode
+Boot-restore flow и paint-aware loading state сделаны внимательнее среднего, особенно для edge-cases жизненного цикла UI.
+
+### 5. Сборка сейчас здорова
+Приложение успешно собирается, и ad-hoc TypeScript compile тоже проходит.
+
+---
+
+# Findings
+
+## F-01 — Монолитная архитектура с очень высокой связностью изменений
+**Severity:** High
+
+### Evidence
+
+- `src/main.tsx` содержит ~1,673 строки и внутри него находятся:
+  - parsing logic
+  - type detection
+  - filtering engine
+  - CSV export
+  - localStorage persistence
+  - loading orchestration
+  - UI components
+  - app composition / bootstrap
+- См. особенно `src/main.tsx:249-404`, `658-722`, `745-1662`.
+
+### Почему это важно
+
+Такой подход помогает быстро стартовать, но делает развитие дорогим.
+
+Текущие риски:
+
+- одно изменение может сломать несвязанный функционал
+- parser-логику трудно тестировать изолированно
+- UI-ревью становятся шумными, потому что доменная логика и presentation переплетены
+- onboarding становится длиннее по мере роста файла
+- новые фичи будут увеличивать merge conflicts и regression risk
+
+### Архитектурное влияние
+
+Текущая структура оптимизирована под **быструю первую поставку**, а не под **безопасную итерацию**.
+
+### Recommendation
+
+Разбить решение на небольшие модули:
+
+- `domain/csv-parser.ts`
+- `domain/column-types.ts`
+- `domain/filters.ts`
+- `domain/export.ts`
+- `state/settings-storage.ts`
+- `components/LoadingOverlay.tsx`
+- `components/ColumnHeader.tsx`
+- `components/ColumnFilterInput.tsx`
+- `App.tsx`
+
+UX можно оставить тем же, но доменную логику нужно вынести из render-файла.
+
+---
+
+## F-02 — Текущая performance-архитектура будет плохо масштабироваться на больших файлах
+**Severity:** High
+
+### Evidence
+
+- целый файл читается в память как строка: `src/main.tsx:715-720`
+- парсинг идет в main thread: `src/main.tsx:1260-1279`
+- полные datasets хранятся в React state: `src/main.tsx:962`, `1279`
+- в merge mode рендерятся все строки и все ячейки без virtualization: `src/main.tsx:1589-1622`
+- в обычном режиме также рендерятся все строки напрямую: `src/main.tsx:1639-1645`
+
+### Почему это важно
+
+Приложение позиционируется как “high-performance”, но его текущая runtime-модель все еще такая:
+
+- прочитать весь файл
+- распарсить весь файл
+- держать весь dataset в памяти
+- отрендерить весь table DOM
+
+На больших брокерских выгрузках или при загрузке многих файлов одновременно эта модель будет деградировать довольно быстро.
+
+Ожидаемые симптомы:
+
+- длинный input delay
+- зависания вкладки браузера
+- высокий memory pressure
+- очень медленный merge mode
+- плохой UX на не самых мощных ноутбуках
+
+### Архитектурное влияние
+
+Spinner улучшает воспринимаемую отзывчивость, но не меняет базовую модель масштабирования.
+
+### Recommendation
+
+Приоритетные улучшения:
+
+1. перенести parsing в **Web Worker**
+2. добавить **row virtualization** и для single-file, и для merged view
+3. рассмотреть **streaming / chunked parsing** вместо полного `readAsText`
+4. перенести хранение больших datasets из `localStorage` в **IndexedDB**
+5. ввести performance budgets по строкам, колонкам и total cells
+
+---
+
+## F-03 — Кастомная CSV-эвристика может незаметно модифицировать или обрезать данные
+**Severity:** High
+
+### Evidence
+
+- поля trim-ятся во время parse: `src/main.tsx:376`, `380`
+- строки с `targetColLength + 1` колонками принимаются, а потом обрезаются: `src/main.tsx:398-400`
+
+### Почему это важно
+
+Для финансовых данных **тихая модификация данных** опаснее, чем явная ошибка парсинга.
+
+Сейчас есть минимум две конкретные проблемы.
+
+#### A. Теряются пробелы внутри quoted values
+Так как к каждой ячейке применяется `currentValue.trim()`, значения вида:
+
+```csv
+" ACME ","  keep spaces  "
+```
+
+превращаются в:
+
+```text
+ACME
+keep spaces
+```
+
+То есть исходные данные уже изменены.
+
+#### B. Более широкие строки тихо обрезаются
+Строка с одной лишней колонкой принимается и режется до целевой ширины.
+Пример:
+
+```csv
+a,b,c
+1,2,3,4
+5,6,7
+```
+
+фактически превращается в:
+
+```csv
+a,b,c
+1,2,3
+5,6,7
+```
+
+Четвертое значение потеряно без предупреждения.
+
+### Архитектурное влияние
+
+Текущий parser оптимизирован под “best effort cleanup”, но ему не хватает более строгого контракта корректности.
+
+### Recommendation
+
+1. не trim-ить quoted field content по умолчанию
+2. обрабатывать schema drift явно:
+   - reject row
+   - quarantine row
+   - или показывать warning пользователю
+3. добавить parser test fixtures для:
+   - embedded quotes
+   - leading/trailing whitespace
+   - multiline quoted values
+   - extra/missing columns
+   - Fidelity-style preambles/postambles
+4. рассмотреть `PapaParse` как RFC-compliant parser layer, а эвристику оставить отдельным cleanup stage
+
+---
+
+## F-04 — Сохранение чувствительных данных включено по умолчанию
+**Severity:** High
+
+### Evidence
+
+- privacy notice говорит, что данные остаются изолированными и безопасными: `README.md:82-86`
+- `rememberData` по умолчанию равен `true`: `src/main.tsx:309-320`
+- datasets сохраняются в `localStorage`: `src/main.tsx:658-669`
+
+### Почему это важно
+
+Приложение работает с брокерскими / финансовыми CSV. Локальное сохранение по умолчанию создает privacy risk на:
+
+- shared laptops
+- family computers
+- managed corporate endpoints
+- публичных demo environments
+
+Это не network leak, но это все равно **риск хранения данных**.
+
+### Архитектурное влияние
+
+Сообщение продукта звучит как “client-only and secure”, но фактическое поведение — “client-only and retained locally”. Это не одно и то же.
+
+### Recommendation
+
+1. поменять default `rememberData` на `false`
+2. сделать явный opt-in с понятной формулировкой:
+   - “Store imported data in this browser on this device”
+3. добавить заметное пояснение о retention рядом с toggle
+4. при желании добавить TTL / auto-expiration
+5. явно описать это поведение в README и UI
+
+---
+
+## F-05 — Настройки колонок глобальны по индексу и конфликтуют между файлами
+**Severity:** High
+
+### Evidence
+
+- модель настроек использует `Record<number, ...>` для custom names, types и filters: `src/main.tsx:255-261`
+- заголовки берут `settings.columnCustomNames[i]`: `src/main.tsx:1334-1336`
+- filters глобальны и переиспользуются между файлами: `src/main.tsx:1357`, `1404`, `1448`, `1609`, `1634`
+- sort state тоже глобальный: `src/main.tsx:260-261`, `1345-1348`
+
+### Почему это важно
+
+В multi-file приложении “column 0” — недостаточный идентификатор.
+
+Пример:
+
+- file A column 0 = `Ticker`
+- file B column 0 = `Date`
+
+Если пользователь переименует, отфильтрует или задаст type override для column 0 в одном файле, те же настройки утекут и во второй файл.
+
+### Архитектурное влияние
+
+Это, вероятно, главная проблема доменной модели в репозитории. UI уже поддерживает multi-file workflows, а модель настроек фактически остается single-schema.
+
+### Recommendation
+
+Нужно ввести dataset-aware key:
+
+- `datasetId + columnIndex`
+- или `schemaHash + columnIndex`
+
+Рекомендуемая модель:
+
+```ts
+Record<string, Record<number, T>>
+```
+
+Где внешний ключ стабилен для импортированного dataset или для детектированной схемы.
+
+Также стоит явно решить, какие настройки должны быть:
+
+- global
+- per dataset
+- per schema
+
+---
+
+## F-06 — Дрейф документации и toolchain повышает стоимость сопровождения
+**Severity:** Medium
+
+### Evidence
+
+- README говорит, что приложение построено на **Bun** и **Vite**: `README.md:2-4`, `34-39`, `45-77`
+- реальные scripts используют **Parcel**: `package.json:10-18`
+- CI использует Bun для запуска Parcel-based scripts: `.github/workflows/ci.yaml:21-23`, `40-44`
+- несколько direct dependencies по результатам source review выглядят неиспользуемыми:
+  - `clsx`
+  - `lucide-react`
+  - `recharts`
+  - `tailwind-merge`
+  - `papaparse`
+  - `@types/papaparse`
+- `npm audit --json` показывает 3 уязвимости через `pm2` / `ws` / `js-yaml`
+
+### Почему это важно
+
+Даже если приложение собирается, такой drift приводит к:
+
+- путанице при onboarding
+- более тяжелым upgrade'ам
+- неясности, кто и зачем выбрал текущий runtime stack
+- избыточной dependency surface
+
+### Архитектурное влияние
+
+Это скорее governance-проблема, чем runtime bug, но такие governance issues со временем начинают тормозить команду сильнее, чем отдельные дефекты кода.
+
+### Recommendation
+
+1. выбрать один явно задокументированный stack и честно его описать
+2. обновить README под реальное состояние
+3. удалить unused dependencies
+4. удалить или обновить `pm2`, если он не критичен
+5. добавить dependency hygiene checks в CI
+
+---
+
+## F-07 — Quality gates недостаточны для parser-heavy логики
+**Severity:** Medium
+
+### Evidence
+
+- в `package.json` есть `"test": "jest src"`: `package.json:17`
+- запуск тестов падает с “No tests found”
+- CI не запускает tests, lint или typecheck; он только собирает проект: `.github/workflows/ci.yaml:21-23`, `40-44`
+
+### Почему это важно
+
+Самые рискованные части приложения — именно те, которые требуют повторяемых проверок:
+
+- CSV parsing heuristics
+- grammar фильтров
+- корректность export
+- persistence / restore flows
+
+Без тестов корректность держится на ручном использовании и памяти разработчика.
+
+### Recommendation
+
+Минимальный набор тестов:
+
+1. **unit tests** для parser, filter grammar, type detection, export helpers
+2. **fixture tests** на реальных грязных brokerage CSV samples
+3. **integration tests** для цепочки import → filter → export
+4. **CI gates** на:
+   - tests
+   - typecheck
+   - build
+
+Опционально на следующем шаге можно добавить browser E2E smoke tests.
+
+---
+
+## F-08 — Accessibility и user-facing error handling требуют улучшения
+**Severity:** Medium
+
+### Evidence
+
+- empty-state upload target — это только кликабельный `<div>`: `src/main.tsx:1566-1570`
+- ошибки обработки файлов отправляются только в console: `src/main.tsx:1268-1273`
+- неверный JSON import использует `alert(...)`: `src/main.tsx:1252`
+
+### Почему это важно
+
+Текущие проблемы:
+
+- keyboard users могут не получить доступ к empty-state uploader
+- ошибки не показываются пользователю структурировано
+- `alert()` — довольно грубый UX
+
+### Recommendation
+
+1. заменить кликабельный `<div>` на семантический `<button>` или корректный labeled control
+2. добавить keyboard и screen-reader friendly affordances
+3. ввести non-blocking error toasts / inline notifications
+4. собирать per-file import warnings и показывать их в UI
+
+---
+
+# Recommended roadmap
+
+## Phase 1 — Quick wins (1–2 недели)
+
+- поставить `rememberData` по умолчанию в `false`
+- обновить README под реальность Parcel/Bun
+- удалить unused dependencies
+- удалить или обновить `pm2`
+- добавить parser fixtures и базовые unit tests
+- исправить trim whitespace и row truncation behavior
+
+## Phase 2 — Structural hardening (2–4 недели)
+
+- разделить `main.tsx` на domain/state/UI modules
+- переделать settings model в dataset-aware
+- добавить CI gates: test + typecheck + build
+- улучшить error reporting в UI
+
+## Phase 3 — Scale readiness (4–8 недель)
+
+- перенести parse work в Web Worker
+- добавить row virtualization
+- оценить IndexedDB для больших persisted datasets
+- зафиксировать load/performance thresholds и regression tests
+
+---
+
+# Финальный архитектурный вердикт
+
+Я бы **одобрил этот репозиторий как сильный prototype / internal utility**.
+
+Но я бы **пока не утверждал его как долгосрочную основу для production-grade продукта**, пока не сделано следующее:
+
+- усиление корректности parser'а
+- смена privacy default
+- модульная декомпозиция
+- dataset-aware settings model
+- automated tests в CI
+- стратегия производительности для больших данных
+
+Коротко:
+
+> Хорошая продуктовая интуиция, полезная реализация, но следующий шаг — не расширение фич, а архитектурное усиление.