From fdc709f87249effbff6d5677f5c2ae14bbc4d562 Mon Sep 17 00:00:00 2001
From: Maksim Kostromin <daggerok@gmail.com>
Date: Tue, 13 Oct 2026 15:16:02 -0400
Subject: [PATCH] docs: move still-open review findings into readme and drop
 docs folder

Re-checked the 2026-07-13 architecture review (docs/FINDINGS.en.md and its Russian copy) against the current code. Seven findings are still open and now live in a Known Issues section at the end of README.md. The row truncation part of F-03 was fixed in #19 and is dropped.
---
 README.md           |  46 +++++
 docs/FINDINGS.en.md | 481 --------------------------------------------
 docs/FINDINGS.ru.md | 481 --------------------------------------------
 3 files changed, 46 insertions(+), 962 deletions(-)
 delete mode 100644 docs/FINDINGS.en.md
 delete mode 100644 docs/FINDINGS.ru.md

diff --git a/README.md b/README.md
index c66928b..dd72e7f 100644
--- a/README.md
+++ b/README.md
@@ -84,3 +84,49 @@ architecture or local offline workspace.
 This application executes entirely client-side inside your web browser. No financial data, statements, ledger indices,
 or CSV filenames are transmitted to external cloud systems, tracking networks, or third-party servers. Your investment
 data remains isolated and completely secure.
+
+## ⚠️ Known Issues
+
+Still open from the architecture review of 2026-07-13 (re-checked 2026-10-13). Fixed since then and dropped from
+this list: over-wide rows are no longer cut (PR #19)
+
+### Monolithic `src/main.tsx`
+Parser, type detection, filter engine, export, persistence, loading orchestration and every UI component live in one
+1800+ line file, so domain logic cannot be tested on its own and every change touches the render file. Fix: move
+the domain code to `csv-parser.ts`, `column-types.ts`, `filters.ts`, `export.ts`, `settings-storage.ts` and the
+components to their own files, keeping the UX unchanged
+
+### Large files block the browser
+Files are read whole, parsed on the main thread, kept in React state and rendered without virtualization in both
+tab and merge views. Big exports or many files at once freeze the tab. Fix: parse in a Web Worker, virtualize rows,
+keep remembered datasets in IndexedDB instead of `localStorage`
+
+### Parser trims quoted values
+`parseCSVText` calls `field.trim()` on every field, quoted ones included, so `"  keep spaces  "` loses its spaces.
+Fix: trim only unquoted fields and add parser fixtures (embedded quotes, whitespace, multiline values, extra and
+missing columns, Fidelity preambles and footers)
+
+### Financial data is remembered by default
+`rememberData` defaults to `true`, so imported datasets stay in `localStorage` on shared or managed machines, while
+the Data Privacy Notice below only talks about network isolation. Fix: default to `false`, word the toggle as
+"Store imported data in this browser", mention local retention in the notice
+
+### Column settings are shared by index across files
+Custom names, type overrides, filters and sort are keyed by column index only, so renaming or filtering column 0 in
+one file applies to column 0 of every file. Pinned columns are already per file in tab view. Fix: key the rest by
+file (or schema) plus column index and decide per setting whether it is global or per file
+
+### README and dependencies drift from the code
+This README says Vite, the build is Parcel. `clsx`, `lucide-react`, `recharts`, `tailwind-merge`, `papaparse` and
+`@types/papaparse` are declared but never imported. `bun audit` reports 33 vulnerabilities, all in dev tooling
+(`pm2`, Parcel, Jest), the production graph is clean. Fix: describe the real stack, drop unused packages, drop or
+upgrade `pm2`
+
+### No tests
+`bun run test` only runs the build and CI only builds. Fix: unit tests for the parser, filter grammar, type
+detection and export, fixture tests on real Fidelity CSVs, run them in CI
+
+### Accessibility and error reporting
+The empty-state upload area is a clickable `<div>` (not reachable by keyboard), per-file import errors only go to
+`console.error`, and invalid JSON or oversized data is reported with `alert()`. Fix: a real `<button>` or labeled
+control, inline non-blocking notifications with per-file import warnings
diff --git a/docs/FINDINGS.en.md b/docs/FINDINGS.en.md
deleted file mode 100644
index a1a85f0..0000000
--- a/docs/FINDINGS.en.md
+++ /dev/null
@@ -1,481 +0,0 @@
-# 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
deleted file mode 100644
index 21b62ea..0000000
--- a/docs/FINDINGS.ru.md
+++ /dev/null
@@ -1,481 +0,0 @@
-# Глубокий архитектурный обзор — `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
-- стратегия производительности для больших данных
-
-Коротко:
-
-> Хорошая продуктовая интуиция, полезная реализация, но следующий шаг — не расширение фич, а архитектурное усиление.