wenay-react2 1.0.40 → 1.0.42

package/doc/progress/public-surface-normalization.md

@@ -0,0 +1,368 @@
+# Public surface normalization
+
+Задача из target: пройти второй слой публичной поверхности `wenay-react2` и внедрять только те primitives, которые реально заменяют ручной код.
+
+## Status
+
+In progress.
+
+## Usage/example sources
+
+Обновляем вместе с кодом, если меняется canonical usage:
+- `doc/EXAMPLE_USAGE.md` — главный standards/example файл;
+- `src/common/testUseReact/qa.tsx` — QA cards как живые примеры использования, особенно cards 20-31;
+- `src/common/testUseReact/replayVideo.tsx` — Replay usage examples для cards 23-26;
+- `src/common/src/grid/agGrid4/example.tsx`, `README.md`, `WRAPPER.md`, `MIGRATION.md` — grid wrapper examples/docs.
+
+Legacy/compat examples (`src/common/testUseReact/use.tsx`, `useGrid.tsx`, отдельные старые cards) не переписывать автоматически; если они показывают low-level path, помечать как regression/compat, а не canonical pattern.
+
+Правило прохода: для каждого изменения проверять, есть ли affected card/example. Если публичный API не менялся и пример уже показывает правильный usage, фиксировать "пример проверен, менять не нужно".
+
+## Task scoring
+
+Перед выполнением следующего кандидата ставим оценку:
+- эффективность: high / medium / low;
+- простота: simple / medium / hard;
+- риск: low / medium / high.
+
+Делаем сразу только high/medium эффективность при simple/medium сложности и понятном риске. Low-effectiveness или hard/high-risk без явного выигрыша — пропускать и записывать причину.
+
+## Pass 1 — low-risk controller reuse
+
+### `createUpdateApi` / `useUpdateByApi`
+
+Проверено:
+- `src/common/src/hooks/useKeyboard.ts` содержит простой mutable singleton `keyboardState` и прямые вызовы `renderBy(keyboardState)`.
+
+Сделано:
+- `useKeyboard.ts` переведён на `createUpdateApi(keyboardState)` для локального render-controller.
+- Публичный API `keyboard`, `keyboardState`, `useKeyboard`, `keyboard.on/subscribe` не менялся.
+
+Почему это не высосано из пальца:
+- это ровно contract `createUpdateApi`: mutable object + render/subscribe controller;
+- изменение маленькое и не тянет UI-поведение.
+
+Ограничение:
+- широкая замена `updateBy/renderBy` в `Toolbar`, `SettingsDialog`, `columnState` пока не делалась. Там controller может быть полезен, но риск выше, потому что эти объекты имеют persistence, registry или grid side effects.
+
+## Pass 1 — tasks intentionally not implemented yet
+
+### `ArrayPromise`
+
+Статус: пока не внедрять.
+
+Причина:
+- в текущей библиотеке нет потребителя, где явно нужен именно последовательный набор promise-thunks с progress counters;
+- для параллельных batch operations counters у `ArrayPromise` не являются стабильным контрактом;
+- внедрение без конкретной batch-команды будет искусственным.
+
+Что считать подходящим местом позже:
+- реальные последовательные операции: массовое закрытие позиций, очистка лимиток, transfer step-by-step;
+- если операции параллельные, нужен другой progress contract, не `ArrayPromise` counters.
+
+### `DragBox` / `DragArea`
+
+Статус: не использовать в новом коде как high-level стандарт.
+
+Причина:
+- это low-level/legacy movement components;
+- для нового кода уже есть hook-first путь `useDraggableApi`, а для окон — `FloatingWindow`.
+
+
+## Pass 2 — grid helpers without grid lifecycle change
+
+### Log tables default column definition
+
+Проверено:
+- `src/common/src/logs/miniLogs.tsx` и `src/common/src/logs/logs.tsx` дублировали один и тот же `defaultColDef`: `headerClass`, `resizable`, centered `cellStyle`, `sortable`, `filter`, `wrapText`.
+
+Сделано:
+- оба места переведены на общий `colDefCentered` + локальный `wrapText: true`.
+- `AgGridReact` намеренно оставлен на месте: перевод на `AgGridTable` может изменить тему, row selection и lifecycle, поэтому это отдельная задача после визуальной проверки.
+
+Почему это не высосано из пальца:
+- helper `colDefCentered` уже существует именно для такого dense table default;
+- замена убирает ручное дублирование, но не трогает grid lifecycle.
+
+
+## Pass 3 — compatibility modal store controller
+
+### `createModalElementStore` / `createModalRenderStore`
+
+Проверено:
+- `src/common/src/components/Modal/Modal.tsx` содержит общий `createJsxStore`, где mutable object `data` одновременно используется как render subscription target.
+
+Сделано:
+- прямые `renderBy(data)` / `updateBy(data)` заменены на `createUpdateApi(data)` (`dataApi.render()` / `dataApi.use()`).
+- публичные compatibility APIs `createModalElementStore()` и `createModalRenderStore()` не менялись.
+
+Почему это не высосано из пальца:
+- store уже был построен на mutable object + render subscription;
+- `createUpdateApi` делает этот контракт явным без изменения поведения.
+## Pass 4 — persisted slot controller
+
+### `createUiSlot`
+
+Проверено:
+- `src/common/src/components/UiSlot/UiSlot.tsx` содержит persisted mutable store `st` из `memoryGetOrCreate` и прямые `renderBy(st)` / `updateBy(st)`.
+
+Сделано:
+- `createUiSlot` переведён на `createUpdateApi(st)` (`stApi.render()` / `stApi.use()`).
+- публичный API `Slot`, `PlacementSetting`, `getPlace`, `setPlace` не менялся.
+- usage example проверен: card 21 (createUiSlot - configurable block placement) уже использует публичный API; менять card не нужно, потому что refactor внутренний.
+
+Почему это не высосано из пальца:
+- это тот же contract, что в `useKeyboard` и compatibility modal store: mutable object + render subscription;
+- persistence через `memoryMarkDirty` оставлен без изменений.
+
+## Pass 5 — toolbar density registry controller
+
+### `registerToolbarDensity` / toolbar density consumers
+
+Оценка перед выполнением:
+- эффективность: medium;
+- простота: simple;
+- риск: low.
+
+Проверено:
+- `src/common/src/components/Toolbar/Toolbar.tsx` содержит module-level mutable registry `densities` и прямые `renderBy(densities)` / `updateBy(densities)`.
+- card 25 использует `registerToolbarDensity` как usage example.
+
+Сделано:
+- только registry `densities` переведён на `createUpdateApi(densities)` (`densitiesApi.render()` / `densitiesApi.use()`).
+- persisted toolbar config `st`, `sourceMode`, external `listSource`, `memoryMarkDirty` не трогались.
+- usage example проверен: card 25 (`createToolbar - customizable toolbar`) уже использует публичный `registerToolbarDensity`; менять card не нужно, потому что refactor внутренний.
+
+Почему это не высосано из пальца:
+- `densities` ровно module singleton + subscription target;
+- изменение уменьшает прямой `renderBy/updateBy` там, где нет persistence/grid side effects.
+
+## Pass 6 — settings section registry controller
+
+### `registerSettingsSection` / `SettingsDialog`
+
+Оценка перед выполнением:
+- эффективность: medium;
+- простота: medium;
+- риск: medium.
+
+Проверено:
+- `src/common/src/components/Settings/SettingsDialog.tsx` содержит module-level mutable registry `registry` и прямые `renderBy(registry)` / `updateBy(registry)`.
+- card 20 использует `registerSettingsSection` как usage example.
+
+Сделано:
+- только section registry переведён на `createUpdateApi(registry)` (`registryApi.render()` / `registryApi.use()`).
+- search history, tree UX, resize behavior и `settingsDialogLayout` не менялись.
+- usage example проверен: card 20 (`SettingsDialog - searchable settings tree + registry`) уже использует публичный `registerSettingsSection`; менять card не нужно, потому что refactor внутренний.
+
+Low-effectiveness skip:
+- `settingsDialogLayout` пока не переводился: сейчас нет явного `updateBy(settingsDialogLayout)` consumer, а nav width живёт в React state и сохраняется через `memoryMarkDirty`. Отдельный controller здесь мало что даст без изменения layout contract.
+
+## Pass 7 — columnState controller split
+
+### `createColumnState` runtime `rt` and persisted `st`
+
+Оценка перед выполнением:
+- `rt` present/presentGate: эффективность medium, простота simple, риск low-medium;
+- `st` persisted config: эффективность medium, простота medium, риск medium.
+
+Проверено:
+- `src/common/src/grid/columnState/columnState.ts` содержит runtime store `rt` для `present` / `presentGate` и persisted store `st` для column config.
+- cards 29/30 используют `usePresent` / `setPresentGate`; cards 28-31 используют persisted config через `useConfig`, grid adapter, menu, toolbar source.
+
+Сделано:
+- `rt` переведён на `createUpdateApi(rt)` (`rtApi.render()` / `rtApi.use()`).
+- `st` переведён на `createUpdateApi(st)` (`stApi.render()` / `stApi.use()`).
+- `commit`, `memoryMarkDirty`, `applyToGrid`, `emitChange`, `listSource` и grid adapter flow не менялись.
+- usage examples проверены: cards 28-31 уже используют публичный `createColumnState` API; менять cards не нужно, потому что refactor внутренний.
+
+## Pass 8 — search history controller
+
+### `createSearchHistory`
+
+Оценка перед выполнением:
+- эффективность: high;
+- простота: simple;
+- риск: low.
+
+Проверено:
+- `src/common/src/utils/searchHistory.ts` содержит persisted mutable store `st` и прямые `renderBy(st)` / `updateBy(st)`.
+- `SettingsDialog` и card 20 используют этот primitive для истории поиска.
+
+Сделано:
+- `createSearchHistory` переведён на `createUpdateApi(st)` (`stApi.render()` / `stApi.use()`).
+- публичный API `items`, `use`, `add`, `remove`, `clear` не менялся.
+- usage docs уже рекомендуют `createSearchHistory({key})`; менять пример не нужно.
+
+## Pass 9 — toolbar persisted config controller
+
+### `createToolbar` local `st`
+
+Оценка перед выполнением:
+- эффективность: medium;
+- простота: medium;
+- риск: medium.
+
+Проверено:
+- `src/common/src/components/Toolbar/Toolbar.tsx` после density-registry pass всё ещё содержал persisted config store `st` с прямыми `renderBy(st)` / `updateBy(st)`.
+- cards 25, 30, 31 используют `createToolbar` local/external source flows.
+
+Сделано:
+- local toolbar store `st` переведён на `createUpdateApi(st)` (`stApi.render()` / `stApi.use()`).
+- external source hook `ext?.useConfig()`, `sourceMode`, `memoryMarkDirty`, `emitChange` не менялись.
+- usage examples проверены: cards 25/30/31 уже используют публичный API; менять cards не нужно, потому что refactor внутренний.
+
+## Pass 10 — window/menu controller normalization
+
+### `FloatingWindow` open-window registry
+
+Оценка перед выполнением:
+- эффективность: medium;
+- простота: medium;
+- риск: medium.
+
+Проверено:
+- `src/common/src/components/Dnd/FloatingWindow.tsx` содержит module-level `openWindows` registry для z-index order и прямые `renderBy(openWindows)` / `updateBy(openWindows, cb)`.
+- card 2 и Settings/Dialog flows используют `FloatingWindow` как usage examples.
+
+Сделано:
+- `openWindows` переведён на `createUpdateApi(openWindows)` (`openWindowsApi.render()` / `openWindowsApi.use(cb)`).
+- drag/resize geometry, document listeners, `floatingWindowMap` persistence и `DragBox` не менялись.
+
+### `LeftModal` menu store
+
+Оценка перед выполнением:
+- эффективность: medium;
+- простота: simple;
+- риск: medium.
+
+Проверено:
+- `src/common/src/components/Modal/LeftModal.tsx` содержит local `menuStore` Map внутри `getApiLeftMenu()` и прямые `renderBy(menuStore)` / `updateBy(menuStore)`.
+
+Сделано:
+- `menuStore` переведён на `createUpdateApi(menuStore)` (`menuStoreApi.render()` / `menuStoreApi.use()`).
+- compatibility method `ApiLeftMenu.renderBy()` оставлен, но внутри вызывает `menuStoreApi.render()`.
+- `createModalElementStore()` path уже был переведён раньше; меню/модалка публично не менялись.
+
+
+## Pass 11 — log tables wrapper transition
+
+### `PageLogs` / `MiniLogs`
+
+Оценка перед выполнением:
+- эффективность: medium/high;
+- простота: medium;
+- риск: medium, потому что внешний вид/theme/resize могут измениться, но QA stand это покрывает вручную.
+
+Проверено:
+- `src/common/src/logs/logs.tsx` и `src/common/src/logs/miniLogs.tsx` после defaultColDef pass всё ещё использовали raw `AgGridReact`.
+- card 9 (`Logs - time format`) использует `logsApi.React.PageLogs` и подходит для ручной проверки основного log table path.
+
+Сделано:
+- `PageLogs` и `MiniLogs` переведены на `AgGridTable`.
+- logger state/timing, `logsApi`, `MessageEventLogs`, `contextMenu` copy action, filter update path и row transaction path не менялись.
+- `logsContext.tsx` намеренно не трогался: это отдельный older/context logger implementation with localStorage + raw grid.
+
+Ручная проверка:
+- card 9: нажать `add log`, время форматируется как `HH:mm:ss`, строка появляется в таблице, правый клик по ячейке даёт copy menu.
+- если `MiniLogs` есть в app/stand consumer, проверить: таблица растягивается по контейнеру, click callback на ячейке вызывается.
+
+## Pass 12 — MiniLogs hook/controller layering
+
+### `useMiniLogsTable` / `MiniLogsView` / `MiniLogsTable`
+
+Оценка перед выполнением:
+- эффективность: medium/high;
+- простота: medium;
+- риск: medium.
+
+Проверено:
+- прямых runtime-использований `MiniLogs` в repo не найдено, но public barrel уже экспортирует `miniLogs.tsx` через `src/common/api.tsx`;
+- card 9 покрывал `PageLogs`, но не `MiniLogs`, поэтому QA example требовал обновления;
+- row identity нельзя менять на `AgGridTable data={...}` / default `id`, потому логовый `id` может повторяться по source area.
+
+Сделано:
+- `MiniLogs` разделён на hook/controller `useMiniLogsTable`, pure visual `MiniLogsView`, convenience `MiniLogsTable` и compatibility wrapper `MiniLogs`;
+- hook отдаёт `props/tableProps/gridProps`, `apiRef`, `fit`, `getApi`, `withApi` и callbacks, но не создаёт внутренний `useAgGrid` controller;
+- сохранён `rowData` path и старый `CellMouseDownEvent<T>` click contract;
+- QA card 9 получил прямой `MiniLogsTable` block;
+- docs обновлены в `doc/EXAMPLE_USAGE.md`, `doc/wenay-react2.md`, `doc/wenay-react2-rare.md`;
+- добавлен `__test/miniLogs.test.tsx` на hook props/click/grid helpers.
+
+Почему store не добавлен:
+- MiniLogs сейчас table-view над внешним `data`; нет реального consumer для append/limit/history store;
+- MiniLogs-owned state лучше добавлять позже только вместе с `createLogsController` или конкретным app consumer.
+
+## Next candidates
+
+1. `logs.tsx` logger internals — эффективность medium, простота hard, риск medium-high. Там несколько stores, callback-subscriptions, notification timing и table rendering; не делать как small pass без отдельного logger plan.
+2. `logsContext.tsx` — эффективность medium, простота hard, риск medium-high. Есть прямой `localStorage` и голый `AgGridReact`, но split нужен отдельно: persistence contract + grid lifecycle/visual check.
+3. `memoryStore.tsx` direct `renderBy(cur)` — эффективность low/medium, простота medium, риск medium. Подробно:
+   - прямой вызов есть только в `memoryUpdate(key, mutate)`: он ререндерит подписчиков именно на объект `cur`, который лежит внутри `memoryProps`;
+   - `memoryProps` сам является `ObservableMap` и уже наблюдается `memoryCache`, поэтому `memorySet`, `memoryGetOrCreate`, `memoryMarkDirty` идут по map/cache dirty channel, а не по React-subscription API;
+   - перевод `memoryUpdate` на `createUpdateApi(cur)` технически возможен, но почти ничего не меняет для публичного contract, потому что API создаётся на лету для произвольного stored object;
+   - риск в том, что это core persistence helper: им пользуются toolbar/columnState/UiSlot/search history/settings/window/right menu flows, и ошибка ударит не по одному widget, а по всему сохранению UI-конфига;
+   - делать стоит только если появится конкретный consumer/test на `memoryUpdate` или если мы явно вводим стандарт “memory object update controller” и покрываем это тестом: subscribe to stored object -> `memoryUpdate` -> rerender + `memoryCache.onDirty`.
+4. `SettingsDialog.layout` controller — эффективность low, простота simple, риск low. Сейчас нет `updateBy(settingsDialogLayout)` consumer, поэтому пропущено как малоэффективное.
+5. `PageVisibilityProvider` candidates — эффективность low до появления реального polling/replay/canvas consumer. Сейчас не внедрять в обычный UI ради helper.
+6. Store/listen hooks — эффективность low внутри shared library без настоящего `Observe.Store` / `listen` consumer. Больше смысла искать в QA/app examples.
+
+## Verification
+
+- `npx tsc -p tsconfig.qa-check.json --noEmit` — passed after Pass 12.
+- `npm run testjest -- --runInBand miniLogs.test.tsx` — passed after Pass 12: 1 suite, 2 tests.
+- `npm run testjest -- --runInBand` — passed after Pass 12: 10 suites, 27 tests.
+- `npm run build` — passed after Pass 12.
+- `git diff --check` — passed after Pass 12; only LF/CRLF normalization warnings.
+
+## Pass 13 — final inventory of remaining primitive-reuse candidates
+
+Дата: 2026-07-09.
+
+Цель: после hook/controller-first очереди повторно проверить широкий пункт `Недоиспользуемые методы wenay-react2` и не делать задачи ради задач.
+
+Проверено:
+- raw `AgGridReact`: остался только внутри самого wrapper `agGrid4.tsx` и в `src/common/testUseReact/useGrid.tsx`;
+- `src/common/testUseReact/useGrid.tsx` уже документирован в `doc/EXAMPLE_USAGE.md` / `doc/PROJECT_FUNCTIONALITY.md` как legacy/regression example для низкоуровневого `applyGridRows`, а не canonical grid pattern;
+- `logsContext.tsx` всё ещё имеет прямой `localStorage`, но это публичное legacy/compat поведение provider-а; перевод на `memoryCache` изменит contract, потому что app должен будет сам вызывать `memoryCache.load/save`;
+- `PageVisibilityProvider` candidates есть только в тяжёлых timer/canvas/replay/chart местах (`useReplay`, chart engines, QA replay demos), где нужно отдельное policy-решение: продолжать catch-up в hidden tab или паузить;
+- ручные `listen.on` / `useEffect` в QA в основном демонстрируют compatibility APIs или сами hook implementations; единственный useful cleanup — card 25 toolbar `tb.api.onChange` — безопасно переведён на `useListenEffect`;
+- Settings/Toolbar registries уже показаны активными QA cards 20/25/30/31; новых low-risk registry migrations без app consumer не найдено;
+- ModalProvider/useModal уже есть active QA card 13; imperative modal stores оставлены documented compatibility path.
+
+Решение:
+- `qa.tsx` card 25: `tb.api.onChange.on(...)` заменён на `useListenEffect(tb.api.onChange, ...)`;
+- `useGrid.tsx` не переводить на `AgGridTable`, пока он нужен как regression для `applyGridRows`;
+- `logsContext` storage не менять без отдельной задачи “context logger persistence contract”;
+- PageVisibility/replay/chart timers не менять без явного UX-policy;
+- broad primitive-reuse target считать выполненным на текущем repository surface: оставшиеся пункты low-effectiveness или high-risk без нового consumer/test.
+
+## Verification update
+
+- `npx tsc -p tsconfig.qa-check.json --noEmit` — passed after FloatingWindow / final inventory / QA listen cleanup.
+- `npm run testjest -- --runInBand createToolbar.test.ts` — passed after QA listen cleanup.
+- `npm run testjest -- --runInBand floatingWindowController.test.tsx settingsDialog.test.tsx` — passed: 2 suites, 6 tests.
+- `npm run testjest -- --runInBand` — passed: 14 suites, 44 tests.
+- `npm run build` — passed.
+- `git diff --check` — passed; only LF/CRLF normalization warnings.
+## Pass 14 — Toolbar.Bar movement animation
+
+Дата: 2026-07-09.
+
+Задача: пользователь подтвердил card 30 как эталон и попросил такую же анимацию горизонтального меню в cards 25 и 31.
+
+Сделано:
+- `createToolbar().Bar` получил общий FLIP-pass (`useToolbarFlip`): при изменении order/visibility/density элементы получают временный `translate(dx,dy)` и возвращаются через `transform 180ms ease`;
+- card 25 and card 31 используют стандартный `Toolbar.Bar`, поэтому получили анимацию без копирования stand-only `Qa30AnimatedMenuBar`;
+- card 30 оставлен эталоном и не переписывался;
+- публичный API `createToolbar`, `ToolbarItem`, `ToolbarConfig` не менялся.
+
+Проверка:
+- `npx tsc -p tsconfig.qa-check.json --noEmit`;
+- `npm run testjest -- --runInBand createToolbar.test.ts`;
+- full test/build перед публикацией v1.0.40.
+
+Оценка пользы:
+- UI-польза: high для cards 25/31, потому order/density changes теперь визуально читаются так же, как в card 30;
+- архитектурная польза: medium/high, потому поведение находится в shared `Toolbar.Bar`, а не в каждом stand/example отдельно;
+- performance-польза: low/medium, это не ускорение вычислений, а FLIP-анимация с одним layout read pass на изменение меню.

package/doc/progress/style-system-normalization.md

@@ -0,0 +1,121 @@
+# Style system normalization
+
+Status: done/released (v1.0.38, v1.0.39, v1.0.41); default inventory and column-state scoped token fixes implemented and shipped.
+
+## Source
+
+User clarification: compatibility can be an aggressive migration when it is
+clearly recorded in changelog, but default styles are dangerous to remove.
+If default styles disappear, the project can become visually broken even when
+the TypeScript/API migration is understandable.
+
+## Standard
+
+- Shared primitives must keep a usable default visual style.
+- A default style may be changed, but not silently removed.
+- Removing/replacing a default class requires a replacement class/token path,
+  changelog entry, and migration note.
+- New shared visual rules should use CSS custom properties first.
+- Runtime geometry may stay inline when it is state-derived, but color, spacing,
+  border, shadow, font, and hover/active states should move to classes/tokens.
+- Apps may override variables; primitives should not require apps to copy a full
+  CSS block to remain usable.
+
+## Token direction
+
+Current prefixes are a good start:
+
+- `--color-*`
+- `--menu-*`
+- `--wnd-*`
+- `--dlg-*`
+- `--tb-*`
+- `--logs-*`
+- `--cols-menu-*` for compact `ColumnsMenu/MenuStrip` visuals.
+- `--cols-dots-*` for `ColumnDots` visuals.
+- `--cols-card-*` for `CardList` visuals.
+
+Likely next prefixes:
+
+- `--cols-*` remains a family prefix; concrete prefixes now use `--cols-menu-*`, `--cols-dots-*`, and `--cols-card-*`.
+- `--input-*` for generic input/panel defaults if they stay public.
+- `--param-*` for `ParamsEditor` if it remains a shared primitive.
+
+## First audit candidates
+
+- `src/style/style.css`: old button/menu classes, `FloatingWindow`, `SettingsDialog`, `Toolbar`, `ColumnDots/CardList`, and raw hover colors.
+- `src/style/menuRight.css`: right-menu visual contract and default state styles.
+- `src/common/src/grid/columnState/*`: finish deciding whether mobile/card
+  visuals need `--cols-*` tokens.
+- `src/common/src/components/ParamsEditor.tsx`: move reusable editor visuals
+  out of component-owned inline styles if the API remains public.
+- `src/common/src/components/Input.tsx`: decide whether old input panels are
+  compatibility-only or need a proper tokenized default.
+
+## Acceptance
+
+- Default visual contract documented per public primitive group.
+- Token prefixes chosen before broad style rewrites.
+- No removal of default classes without replacement and changelog.
+- Scoped visual QA cards checked before and after style migration.
+## 2026-07-09 default style contract inventory
+
+Source of truth:
+
+- CSS tokens: `src/style/tokens.css`.
+- TS mirror for inline styles/theme builders: `src/common/src/styles/tokens.ts`.
+- Shared runtime CSS: `src/style/style.css` and `src/style/menuRight.css`.
+- Generated `dist/lib/style/*` is build output, not the edit target.
+
+Public/default visual contracts:
+
+- `Menu` / `MenuR` / mouse context menu: legacy `.MenuR`, `.toButton`, `.toButtonA` classes remain; colors/shadow/borders are already routed through `--menu-*` tokens. Keep the old class names as compatibility surface.
+- `RightMenu`: default classes `.menu-container`, `.menu-button`, `.dropdown-content`, `.menu-item`, `.submenu`, `.draggable-div` live in `src/style/menuRight.css` and already consume `--menu-*` / `--menu-outline-color`.
+- `FloatingWindow`: `.wenayWnd*` and `.wenayCloseBtn` live in `src/style/style.css`; defaults intentionally preserve the old transparent/striped window while allowing `--wnd-*` theme overrides.
+- `SettingsDialog`: `.wenayDlg*` classes live in `src/style/style.css`; default look is dark and tokenized through `--dlg-*` plus selected `--wnd-*` bridge variables on `.wenayDlgWindow`.
+- `Toolbar` / `createToolbar`: `.wenayTb*` classes live in `src/style/style.css`; defaults consume `--tb-*`; stand-specific skins should override through wrapper classes, not by changing shared defaults.
+- `Logs`: `src/common/src/logs/logStyles.ts` maps inline logger chrome to `--logs-*`; this is an accepted transitional contract while old logger JSX stays inline-heavy.
+- `ColumnDots` / `CardList`: `.wenayColDots*` and `.wenayCardList*` classes live in `src/style/style.css`; restored card-29 defaults are now tokenized through `--cols-dots-*` / `--cols-card-*` with the same fallback values.
+- `ColumnsMenu` / `MenuStrip`: behavior is already headless/presentation split. Visual button/container/divider states now use `.wenayColsMenu*` classes and `--cols-menu-*` tokens with the exact previous GitHub-like defaults; runtime reorder transform stays inline.
+- `ParamsEditor`: public and still mostly old class + inline style based (`toIndicatorMenuButton`, `miniEl`, `toButtonEasy`, `inputCan`). Do not token-migrate broadly until hook/API direction is decided; candidate prefix `--param-*`.
+- `Input` modal helpers: public compatibility helpers over `FloatingWindow`, `.msTradeAlt`, `.msTradeActive`, `.inputCan`, inline panel spacing. Candidate prefix `--input-*`, but may remain compatibility-only if newer app surfaces replace them.
+
+Done scoped fix:
+
+- `ColumnsMenu/MenuStrip` visual button/container/divider styles moved to classes/tokens; runtime reorder transform/drag geometry remains inline.
+
+Done scoped fixes:
+
+- `ColumnsMenu/MenuStrip` visual button/container/divider styles moved to classes/tokens; runtime reorder transform/drag geometry remains inline.
+- `ColumnDots/CardList` restored card-29 defaults moved to `--cols-dots-*` / `--cols-card-*` variables with unchanged fallback values.
+
+Next scoped candidate:
+
+- Leave `ParamsEditor` / `Input` broad visual migration until the hook-first/API direction is clearer; only do bug-level style fixes there.
+## 2026-07-09 scoped fix - ColumnsMenu/MenuStrip tokens
+
+Implemented the compact column menu style contract:
+
+- Added `--cols-menu-*` defaults to `src/style/tokens.css` and the TS mirror in `src/common/src/styles/tokens.ts`.
+- Added `.wenayColsMenu*` classes in `src/style/style.css` for container/list/button states, fixed/drag shadow, text abbreviation, marks, and divider.
+- Updated `src/common/src/grid/columnState/ColumnsMenu.tsx` so visual state uses classes; only consumer `style` and `useReorder` runtime transform remain inline.
+
+Verification: `npx tsc -p tsconfig.qa-check.json --noEmit`; `npm run testjest -- --runInBand`; `npm run build`; `git diff --check`.
+## 2026-07-09 scoped fix - ColumnDots/CardList tokens
+
+Implemented the mobile/card column-state style contract:
+
+- Added `--cols-dots-*` and `--cols-card-*` defaults to `src/style/tokens.css` and the TS mirror in `src/common/src/styles/tokens.ts`.
+- Rewrote `.wenayColDots*` and `.wenayCardList*` values in `src/style/style.css` to use variables with the exact previous fallbacks.
+- Kept component code unchanged; `ColumnDots` runtime geometry (`left`, drag transform) remains inline in the component where it belongs.
+
+Verification: `npx tsc -p tsconfig.qa-check.json --noEmit`; `npm run testjest -- --runInBand`; `npm run build`; `git diff --check`.
+## 2026-07-09 — Menu default contrast restore
+
+Сделано:
+- `--menu-bg-color` возвращён к непрозрачному dark fallback `#0c0c0c`, `--menu-blur` по умолчанию `0px`;
+- добавлены `--menu-item-active-*` и `--menu-item-pressed-*` tokens, старый `--menu-active-background` оставлен alias/fallback;
+- `MenuR` / mouse context menu and `RightMenu` CSS получили hard fallbacks: default dark background, white text, hover white with dark text, pressed yellow-ish contrast state;
+- причина: рабочие проекты могут ещё не переопределять новые CSS variables, поэтому дефолт не должен становиться glass/transparent.
+
+Проверка: CSS-only visual contract; прогнать `tsc`/`build`, card 4 вручную открыть правой кнопкой.

package/doc/target/README.md

@@ -0,0 +1,33 @@
+# Target Backlog Rules
+
+`doc/target` is the durable task backlog for dictated or imported work. It is not a scratchpad and it is not a changelog.
+
+## Files
+
+- `doc/target/my.md` is the user-owned inbox/queue for dictated tasks. Keep it clean and actionable.
+- `target/*.md` are source prompt files imported into this repo. Treat them as task specs; do not edit or delete them just to mark progress unless the user asks for that exact cleanup.
+- `doc/progress/*.md` are temporary working notes for an active task. They may be deleted when the task is finished, so they must never be the only place where queue status lives.
+- `doc/changes/vX.Y.Z.md` records durable completed changes when code, public docs, theme contracts, dependencies, or policy changed.
+
+## Workflow
+
+1. When the user says to start from `target`, read this README first, then `doc/target/my.md`, then relevant files under `target/`.
+2. Before coding, normalize dictated text into concrete tasks in `doc/target/my.md`: a short title, current status, source note, and acceptance checks if they are known.
+3. When taking a task, move it to `In Progress` in `doc/target/my.md` and point to the progress file if one is created.
+4. Use `doc/progress/<task>.md` only for checkpoints, decisions, blockers, and verification while work is active.
+5. When implementation is believed complete, move the task to `Verify` in `doc/target/my.md` with the concrete checks that prove it: commands, QA stand checks, screenshots, or manual acceptance points.
+6. Remove a task from `doc/target/my.md` only after `Verify` checks pass and the durable result exists: code/docs are updated, verification is recorded, and changelog is updated when required.
+7. If the task is paused or blocked, leave it in `doc/target/my.md` under `In Progress` or `Blocked` with the next concrete action. Do not delete the progress file in that case.
+8. If a task from `target/*.md` is found already implemented, move it to `Verify` first and check its acceptance criteria before removing it. Do not rely on a deleted progress file as proof.
+
+## Status Sections For `my.md`
+
+Use these sections:
+
+- `Inbox` - raw or lightly cleaned tasks not yet triaged.
+- `Ready` - concrete tasks that can be started.
+- `In Progress` - the task currently being worked on, with a progress-file link when applicable.
+- `Verify` - implementation is believed complete, but acceptance checks still need to be run or reviewed.
+- `Blocked` - tasks waiting for user input, another repository, credentials, or an external change.
+
+Completed tasks are normally removed from `my.md`; the final response, commit message, and changelog carry the durable completion record.