itube-specs 0.0.794 → 0.0.795

package/README.md

@@ -21,39 +21,32 @@ runtime-хелперы, типы и lib-данные. Приложения ра
 
 ## Как работать со слоем
 
-Слой публикуется в npm, приложения используют **опубликованную** копию (`node_modules/itube-specs`).
-**Локальные правки не видны приложению, пока не опубликована новая версия.**
+Слой публикуется в npm, прод/CI собираются с **опубликованной** копии (`node_modules/itube-specs`).
+Локально приложение подсасывает слой напрямую через симлинк — правки видны сразу, без публикации.
 
-1. Коммитим правки в слое.
-2. `npm run patch` — патчим версию → пуш → мерж.
-3. В проекте: `npm run spec` (`npm install itube-specs@latest`), при необходимости `npx nuxi prepare`
-   (если не подхватились автоимпорты composables/компонентов).
-4. При runtime-проблемах — `npm run dev` в слое перегенерит `tsconfig` и `eslint.config.mjs`.
+### Локальная разработка (авто-линк из приложения)
 
-> **npm install и другие команды, меняющие зависимости, в этом репозитории не запускаем** — зависимости
-> и публикацию ведёт мейнтейнер вручную. Править `package.json` можно, ставить пакеты — нет.
+В приложении `npm run dev` перед стартом (хук `predev`) вешает симлинк
+`node_modules/itube-specs` → `LAYER_PATH` (путь берётся из `.env` приложения). Дальше:
 
-### Отладка из приложения
+1. Правим слой прямо здесь (по `LAYER_PATH`) — изменения видны на локалке приложения сразу (HMR),
+   cmd+click по сущностям слоя ведёт в эти исходники.
+2. Правки готовы: коммит в слое → `npm run patch` → пуш → мерж → публикация.
+3. В приложении: `npm run spec` (`npm install itube-specs@latest`) тянет опубликованную версию
+   (симлинк заменяется реальным пакетом), коммит, пуш на прод.
 
-Правим слой прямо здесь (по `LAYER_PATH`), затем `npm run patch` + `npm run spec` в приложении.
+`npm run dev:published` в приложении — дев против опубликованной версии, минуя авто-линк.
 
-Приоритет авто-импорта в приложении: `*-debug` > проектные `components/`/`composables/` > слой.
+> **npm install и другие команды, меняющие зависимости, в этом репозитории не запускаем** — зависимости
+> и публикацию ведёт мейнтейнер вручную. Править `package.json` можно, ставить пакеты — нет.
 
-**Постоянная кастомизация:** приложение может завести файл с **тем же именем**, что сущность слоя
-(напр. `<UiBtn>`), в своих `components/`/`composables/` — победит проектный (он выше слоя). Так форк
-меняет вёрстку/логику под себя **без переименования**. Осмысленно: если разницу решает пропс — делать
-пропсом, а не форкать весь компонент.
+### Проектные оверрайды
 
-**Отладка слоя:** копируем сущность слоя в `components-debug/` / `composables-debug/` приложения
-(без сегмента `components/`/`composables/` слоевого пути), `npx nuxi prepare` — копия перекрывает слой
-(отдельные авто-корни, наивысший приоритет). При необходимости оверрайд можно закоммитить и выкатить
-в бой для отладки (папки не в git-ignore). Правим, переносим в слой (или скилл `debug-clean`),
-`npm run patch` + `npm run spec`, копию удаляем. Импорты в копии — пакетные
-(`itube-specs/runtime|types|lib|services|utils`). **Дисциплина: держать пусто, когда нет активной задачи** —
-копия перекрывает слой только для одного проекта, правки должны уходить в слой и расходиться на все форки.
+Приоритет авто-импорта в приложении: проектные `components/`/`composables/` > слой.
 
-Для мелких утилит/runtime можно и грубее — временный disk-импорт с диска
-(`import { test } from '../../../../specs/runtime/utils'`), только для локальной отладки, в коммит не идёт.
+Приложение может завести файл с **тем же именем**, что сущность слоя (напр. `<UiBtn>`), в своих
+`components/`/`composables/` — победит проектный (он выше слоя). Так форк меняет вёрстку/логику под себя
+**без переименования**. Осмысленно: если разницу решает пропс — делать пропсом, а не форкать весь компонент.
 
 ---
 

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "itube-specs",
   "type": "module",
-  "version": "0.0.794",
+  "version": "0.0.795",
   "main": "./nuxt.config.ts",
   "types": "./types/index.d.ts",
   "scripts": {