@rsconcept/rstool 1.7.1 → 2.0.0

package/skills/rs-scope/SKILL.md

@@ -0,0 +1,67 @@
+---
+name: rs-scope
+description: >-
+  Этап 1 концептуализации: постановка. Выделить предметную область через задачу
+  и ограничения, расчистить источник, сформулировать требования к выразительным
+  средствам, различения и инварианты, задать вопросы раунда 1 и получить
+  подтверждённый бриф до формализации. Также — восстановить бриф существующей схемы.
+---
+
+# Этап 1 · Постановка
+
+Пути — от `<rstool>` (см. скилл `rstool`). Метод — `docs/METHOD.md` §«Этап 1»; формат брифа — `docs/BRIEF.md`.
+
+## Вход
+
+Запрос пользователя и источник (ТЗ, текст, описание объекта). Для развития или ревью — существующая схема (сессия, файл, Portal) и её бриф, если он есть.
+
+## Шаги
+
+1. **Назначение.** Определи `approach`: `research` (экспликация текста), `education` (обучение), `project` (основа для ПО / ОСС). Не ясно — это вопрос раунда 1.
+2. **Расчистка источника** — до любых `X#`. Пройди текст и разметь каждый фрагмент по статусу: определение · правило · пример · термин без определения · оценочное / нерелевантное. Сгруппируй по смысловым блокам. Разметку сохрани файлом `source-markup.md` в папке задачи. Оценочное и нерелевантное («удобный интерфейс») в схему не идёт.
+3. **Ограничения** (`restrictions`). Что сознательно исключаем: время и сроки, история, процедуры и действия, оплата, уведомления, интерфейс… Для каждого — перечень понятий, которые из-за этого станут **невыразимыми** («просроченная рецензия», «бывшие выдачи»). Исключённое из запроса — тоже ограничение, а не молчаливый пропуск.
+4. **Требования к выразительным средствам** (`expressiveness`) — понятия, ради которых просят схему, со ссылкой `ref` на источник. Формулируй их как понятия («доклады, ожидающие рецензий»), а не как действия системы («председатель видит список»).
+5. **Различения** (`distinctions`). Где в источнике одно слово может значить два понятия, или два понятия легко склеить: назначение ≠ рецензия, считает другом ≠ взаимная дружба, лекция потоку ≠ практика.
+6. **Инварианты** (`invariants`) — правила, которые должны стать аксиомами. Классификация (статусы, виды) — пара аксиом разбиения, не коды в `C#`.
+7. **Сценарии** — для главного понятия и каждого инварианта по примеру и контрпримеру, подписями элементов (`docs/BRIEF.md` §«Сценарии»). Ожидания на конституенты оставь на этап 3, но значения и смысл запиши сейчас в `title` и `note`.
+8. **Раунд 1 вопросов** — 3–5 вопросов **до формализации**, каждый с твоим предложенным ответом и следствием. Всегда (кроме лёгкого брифа):
+   - **назначение:** для чего схема (экспликация, обучение, ПО / синтез)?
+   - **исключения:** что исключаем? (назови, что станет невыразимым)
+   - **различения:** что обязательно различать? Предложи 1–2 пары из разметки — те, что легче всего склеить.
+
+   По пробелам разметки, пока не наберётся 5:
+   - пример и контрпример для главного понятия (для `project` и `education` — обязателен, если источник его не даёт);
+   - свойства, которые станут аксиомами, а источник их прямо не утверждает: «может ли человек быть другом самому себе?», «бывает ли у врача несколько специальностей?»;
+   - какие правила схема должна выражать;
+   - для развития схемы: что меняется и что должно остаться неизменным?
+
+   Задай вопросы и **закончи ход** — не строй схему, пока не получил ответы. Ответы запиши в `questions[].answer`. Пользователь подтвердил бриф → `status: confirmed`. Спросить нельзя (фоновый запуск) → ответы в `assumptions`, `status: assumed`.
+
+### Восстановление брифа (развитие и ревью)
+
+Для ревью без названной задачи: до разбора формул одним вопросом уточни назначение схемы и что она должна уметь (с предложенным ответом из запроса). Если брифа нет: восстанови его по схеме — термины и текстовые определения производных понятий дают кандидатов в требования, аксиомы — инварианты, конвенции — ограничения. Поставь `constituent` для каждого восстановленного требования и запиши восстановленный бриф с `status: draft`; задачу и что должно сохраниться уточни вопросом. Для развития старые понятия и аксиомы — требования, которые нельзя ломать; сохрани исходную сессию как базу (`--base` у `check-brief`).
+
+## Выход
+
+`brief.json` (статус `confirmed` или `assumed`) и `source-markup.md` в папке задачи. Бриф пиши напрямую (Write / Edit JSON), не генерируй скриптом; не дублируй в нём разметку. Ориентир объёма — до 15–20 КБ для схемы на 30–50 конституент.
+
+## Гейт
+
+- Задача, ограничения и невыразимое записаны.
+- Каждое требование и инвариант проверяемы: есть пример или контрпример.
+- Раунд 1 пройден, остальное — в допущениях.
+
+Дальше — `rs-core`.
+
+## Не делай
+
+- Не начинай с `X#` / `S#` и не пиши формулы на этом этапе.
+- Не переноси в схему всё, что есть в тексте: пересказ источника — не концептуализация.
+- Не задавай вопросы после того, как схема уже собрана, вместо раунда 1.
+- Не задавай больше 5 вопросов и вопросов без предложенного ответа.
+- Не пропускай вопрос о различениях: потерянное различение не найдёт ни анализатор, ни `check-brief`.
+- Не исключай молча: каждое исключение — `restriction` с `inexpressible`.
+
+## Читать по потребности
+
+`docs/METHOD.md` §«Этап 1», `docs/BRIEF.md`; для ТЗ и запросов на изменение — `docs/REQUIREMENTS.md`; разбор этапа на учебном примере — `examples/subordination/NOTES.md`, на требованиях к ПО — `examples/library-loans/NOTES.md`.

package/skills/rs-synthesis/SKILL.md

@@ -0,0 +1,52 @@
+---
+name: rs-synthesis
+description: >-
+  Операция синтеза микротеорий: когда делить схему на части, как выбирать
+  таблицу отождествлений (исходное / производное), синтетические аксиомы и бриф
+  результата; встраивание в rstool и операции ОСС на Portal.
+---
+
+# Синтез микротеорий
+
+Пути — от `<rstool>`. Метод — `docs/METHOD.md` §«Синтез микротеорий»; термины — `docs/DOMAIN.md` §«Синтез», §«ОСС»; ОСС на Portal — `docs/PORTAL-OSS.md`.
+
+## Когда
+
+- Требований больше, чем помещается в микротеорию (3–6 отношений, 2–4 уровня конкретизации) — решение на этапе `rs-core`.
+- Развитие схемы **новым независимым аспектом**, а не уточнением имеющегося.
+- Правило, которое связывает понятия разных аспектов (синтетическая аксиома).
+- Работа с ОСС на Portal.
+
+## Шаги
+
+1. **Деление.** Каждая микротеория — отдельная схема со своим брифом: требования, инварианты, сценарии своего аспекта. Каждая проходит этапы 1–4 отдельно.
+2. **Порядок конкретизации** — под задачу: сначала общий аспект, затем те, что его уточняют.
+3. **Таблица отождествлений.** Для каждой пары кандидатов — вид и решение в журнал:
+   - исходное с исходным — можно (люди родства = сотрудники);
+   - исходное одной схемы с производным другой — можно, понятие становится конкретнее;
+   - производное с производным — только при полном совпадении структуры.
+4. **Встраивание в rstool:** `synthesize({ sourceSessionId, substitutions: [{ original, substitution }] })` — `original` из источника, `substitution` из приёмника. Имена источника получают следующие свободные номера по типу (`X2`, `S3`, …), соответствие — в `aliasMapping` ответа. На Portal синтез в ОСС после отождествлений ещё упорядочивает конституенты и перенумеровывает все имена подряд — итоговые имена смотри в `/details` результата.
+   - Перенумеровываются формулы, типизация и ссылки в термине и текстовом определении. **Конвенции не перенумеровываются**: не пиши в них имена конституент и номера решений брифа (`DC#`) — только предметный смысл словами.
+5. **Синтетические аксиомы и понятия** — то, что не выражалось ни в одной части; рядом с аксиомой полезно понятие нарушения («какие пары конфликтуют»).
+6. **Бриф результата — новый.** Брифы аргументов не переносятся: у каждой схемы ОСС свой бриф. Он пишется после синтеза, по итоговым именам, и описывает только то, что даёт синтез:
+   - таблицу отождествлений и новые отношения — решения журнала;
+   - новые выводимые понятия, которых не было ни в одном аргументе, — требования к выразительным средствам;
+   - синтетические аксиомы — инварианты с позитивом и негативом.
+
+   Синтез без новых отношений или отождествлений и без новых выводимых понятий ничего не добавляет — пересмотри, зачем он нужен. Аксиомы аргументов проверяются и так: в допустимых сценариях `check-brief` требует истинности всех аксиом схемы.
+
+7. **Проверка:** `check-brief` на результате; унаследованные конституенты в списке «сирот» — норма, их требования живут в брифах аргументов. Дальше — `rs-review`.
+
+## На Portal (ОСС)
+
+Загрузки (`create-schema`, `import-schema`), синтез (`create-synthesis` с отождествлениями по **id** конституент из `/details` аргументов), `execute-operation` — `docs/PORTAL-OSS.md`. Сначала собери и проверь синтез в rstool, затем повтори на Portal.
+
+## Не делай
+
+- Не отождествляй производные понятия с разной структурой.
+- Не расширяй одну микротеорию чужими понятиями вместо синтеза, если аспекты независимы.
+- Не копируй бриф аргумента в бриф результата и не ссылайся из конвенций на его решения.
+
+## Пример
+
+`examples/kinship-subordination/` — родство и подчинение, отождествление людей и правило конфликта интересов (`NOTES.md`).

package/skills/rstool/SKILL.md

@@ -0,0 +1,70 @@
+---
+name: rstool
+description: >-
+  Концептуальные схемы (КС), ЯРЭ, rstool и Portal: построить КС по тексту или
+  требованиям, развить или отревьюить схему (в том числе по ссылке Portal),
+  починить формулу, объяснить конструкцию, проверить смысл на концептуальной
+  модели. Маршрутизатор: определяет сценарий и этап и называет скилл этапа.
+---
+
+# rstool — маршрутизатор
+
+Цель работы — КС, которая **отвечает запросу пользователя**. Чистые диагностики — необходимое, но не достаточное условие. Метод — `<rstool>/docs/METHOD.md`.
+
+`<rstool>` — корень пакета: `rsconcept/rstool/` в workspace Portal, `node_modules/@rsconcept/rstool/` в npm-проекте. Все пути ниже — от него. Скиллы этапов читай по пути, когда маршрут до них дошёл; заранее не открывай.
+
+## 1. Выбери сценарий
+
+| Запрос                                          | Маршрут (скиллы по порядку)                                                                                                                                                                                   |
+| :---------------------------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
+| Новая КС по тексту, ТЗ, описанию объекта        | `rs-scope` → `rs-core` → `rs-explicate` ⇄ `rs-interpret` → `rs-review` (самопроверка) → экспорт / `rs-portal`                                                                                                 |
+| Развить существующую КС (файл, сессия, Portal)  | (`rs-portal`: чтение) → `rs-scope` (восстановить бриф + новые требования) → `rs-core`: новый аспект или уточнение? → `rs-explicate` → `rs-interpret` (старые сценарии — регрессия) → `rs-review` → публикация |
+| Оценить / отревьюить КС                         | загрузка → `rs-scope` (восстановить задачу и бриф) → `rs-review`; `rs-interpret` — для подтверждения находок                                                                                                  |
+| Починить формулу, разобрать диагностики         | `rs-explicate` с лёгким брифом: смысл фиксируется до правки. Если смысл приходится менять — `rs-core` и запись решения                                                                                        |
+| Объяснить формулу или конструкцию человеку      | `rs-explain` (без брифа)                                                                                                                                                                                      |
+| Требований больше, чем на одну микротеорию; ОСС | `rs-scope` → `rs-core` (деление) → `rs-synthesis`                                                                                                                                                             |
+| Вопрос по синтаксису ЯРЭ                        | `docs/SYNTAX.md` (без брифа)                                                                                                                                                                                  |
+| Как вызвать rstool (библиотека, stdio, MCP)     | `rstool-runtime`                                                                                                                                                                                              |
+
+Скилл этапа: `<rstool>/skills/<имя>/SKILL.md`. Запуск rstool и скриптов — `<rstool>/skills/rstool-runtime/SKILL.md`; ссылки и REST Portal — `<rstool>/skills/rs-portal/SKILL.md`.
+
+## 2. Держи бриф
+
+Бриф — `brief.json` в папке задачи рядом с сессией: постановка, требования к выразительным средствам, различения, инварианты, журнал решений, сценарии. Формат — `docs/BRIEF.md`. Для точечной правки достаточно лёгкого брифа (одно требование, один сценарий).
+
+После любого шага проверь готовность:
+
+```bash
+npx tsx <rstool>/skills/scripts/check-brief.ts --session <abs>/session.json --brief <abs>/brief.json
+```
+
+(в workspace Portal: `pnpm --filter @rsconcept/rstool exec tsx skills/scripts/check-brief.ts …`). Вывод называет **этап**, блокеры и **следующий шаг** — иди туда. Этапы: `scope` → `rs-scope`, `core` → `rs-core`, `explicate` → `rs-explicate`, `interpret` → `rs-interpret`, `review` → `rs-review`.
+
+## 3. Общие правила
+
+**Пользователь — предметник, ты — методник.** До формализации задай вопросы раунда 1 (`rs-scope`), после гипотезы ядра — раунда 2 (`rs-core`). У каждого вопроса — твой предложенный ответ. «Продолжайте» или «на ваше усмотрение» закрывает только уже заданные вопросы, а не следующий раунд. Если спросить нельзя — запиши допущения, статус брифа `assumed`, и скажи об этом в отчёте.
+
+**Смысл важнее «зелёного».** Ради чистых диагностик нельзя:
+
+- удалять или ослаблять аксиому, связанную с инвариантом брифа, без нового решения в журнале;
+- превращать производное понятие (`D#`/`F#`/`P#`) в `S#`, `X#` или `C#`;
+- заменять формулу тривиальной (`∅`, `D5 := X1`, тавтология);
+- удалять конституенту, на которую ссылается бриф, или оставлять непустой `failed` после `best_effort`;
+- оставлять пустую конвенцию у неопределяемого понятия.
+
+Не получается выразить смысл — вернись к ядру или запиши `openQuestions` и честно скажи «готово частично».
+
+**Границы правок.** Задача по КС не означает правку `<rstool>`. Скрипты, сессии, бриф и экспорт — в папке задачи (каталог пользователя, `.tmp/`), не в пакете. Пакет правь только по явной просьбе.
+
+**Язык ответа.** Пиши терминами предметной области, а не именами API: «формальное определение», «конституента», «диагностики», «правка схемы», а не `definitionFormal`, `applySchemaPatch`. Имена конституент (`X1`, `D3`) и формулы ЯРЭ приводи как есть, лучше с термином: «терм `D3` (просроченные выдачи)». Словарь API → текст — `skills/rstool-runtime/SKILL.md`.
+
+**Термины КС** — только из `docs/DOMAIN.md`, раздел «Термины: не путать». Никогда «базис» / «базисы»: для `X#` — **базисное множество**, для слоя `X#`/`C#`/`S#` — **неопределяемые понятия**. `T#` — высказывание, не «теорема». `R#` — радикал, не конституента. Буквы из учебника (`D` для родовой структуры, `T` для терма) не используй.
+
+## 4. Отчёт пользователю
+
+Шаблон — в `rs-review`. Минимум для любой сборки или правки:
+
+1. Как схема отвечает на запрос: таблица «требование → конституента → сценарий».
+2. Что сознательно не выражено (ограничения и невыразимое), допущения, открытые вопросы.
+3. Решения по ядру, которые пользователь должен знать.
+4. Диагностики и результат проверки брифа; файлы (сессия, бриф, экспорт).

package/skills/rstool-helper/GUIDE.md

@@ -1,272 +1,18 @@
-# ЯРЭ и rstool
-
-Краткий входной гайд для агентов. Детали — в связанных документах.
-
-**ЯРЭ** (язык родоструктурной экспликации) — формальная нотация концептуальных схем: понятия, отношения, операции, утверждения. Основа: принадлежность `x∈y`, теоретико-множественные и логические выражения, типизация.
-
-**rstool** — API агента для сессий, редактирования схемы, анализа, диагностик, значений модели, вычисления, экспорта/импорта.
-
-- Библиотека: `@rsconcept/rstool`.
-- Анализатор: `@rsconcept/domain`.
-- Stdio-обёртка: `npx rstool-wrapper`, JSON построчно.
-- Node-клиент: `RSToolWrapperClient`.
-- MCP: `@rsconcept/rstool-mcp` (tools в `snake_case` — [REFERENCE.md](REFERENCE.md)).
-
-## Быстрый контракт для агента
-
-- Library API: `tool.applySchemaPatch(input, sessionId?)` — основной путь правки схемы; `synthesize` — встраивание конституент из другой сессии (синтез с таблицей отождествлений).
-- Stdio/MCP: **плоские** `params` — поля метода и optional `sessionId` на одном уровне (без `params.input`).
-- Состояние: `getSessionState()` (summary) или `getSessionState('full')`.
-- Импорт/экспорт Portal: `importData`, `exportPortal({ kind })`.
-- Модель: `setModelValues`, `evaluate`, `recalculateModel`.
-- Перед сохранением сомнительной формулы — `analyzeExpression`.
-
-## Задача → чтение
-
-Не открывай все `docs/` сразу. Выбери строку по запросу пользователя, прочитай **минимум**, остальное — только если упрёшься в пробел.
-
-| Задача пользователя                                      | Читать (минимум)                                                                                                                                                                                                                     | Не читать сразу                          |
-| :------------------------------------------------------- | :----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :--------------------------------------- |
-| Собрать / существенно развить КС из текста               | этот GUIDE → [концептуализация](#концептуализация-кс-из-содержания-источника); [CONCEPTUAL-SCHEMA.md](../../docs/CONCEPTUAL-SCHEMA.md); [BASE-SELECTION.md](../../docs/BASE-SELECTION.md); при сомнении — [EXAMPLES.md](EXAMPLES.md) | PORTAL-API целиком; TYPIFICATION целиком |
-| Оценить / отревьюить готовую КС (без запроса «перепиши») | этот GUIDE → [ревью / оценка](#ревью--оценка-готовой-кс); [чеклист ревью](#ревью-концептуальной-схемы); [CONCEPTUAL-SCHEMA.md](../../docs/CONCEPTUAL-SCHEMA.md); при импорте — [PORTAL-API.md](../../docs/PORTAL-API.md)             | EXAMPLES с batch patch; полный SYNTAX    |
-| Точечные правки существующей схемы                       | этот GUIDE → [редактирование](#редактирование-и-проверка-схемы); [REFERENCE.md](REFERENCE.md) при вызовах                                                                                                                            | CONCEPTUAL-SCHEMA целиком                |
-| Починить формулу / диагностики                           | этот GUIDE → [цикл диагностик](#цикл-диагностик); [DIAGNOSTICS.md](../../docs/DIAGNOSTICS.md); [EXAMPLES.md](EXAMPLES.md) «типичные диагностики»                                                                                     | CONCEPTUAL-SCHEMA; PORTAL-API            |
-| Импорт / правка по ссылке Portal                         | этот GUIDE → [Portal](#оценка-или-правка-кс-из-portal); [PORTAL-API.md](../../docs/PORTAL-API.md)                                                                                                                                    | SYNTAX; BASE-SELECTION                   |
-| Проверить смысл на данных / КМ                           | этот GUIDE → [КМ](#проверка-на-маленькой-км); [MODEL-TESTING.md](../../docs/MODEL-TESTING.md)                                                                                                                                        | DOMAIN/ОСС; CONCEPTUAL-SCHEMA            |
-| Объяснить синтаксис / генераторы / `F#`/`P#`             | [SYNTAX.md](../../docs/SYNTAX.md); при необходимости [EXAMPLES.md](EXAMPLES.md)                                                                                                                                                      | воркфлоу сессий                          |
-| Разобрать типизацию / ступени                            | [TYPIFICATION.md](../../docs/TYPIFICATION.md)                                                                                                                                                                                        | PORTAL-API                               |
-| Вызовы API / stdio / MCP                                 | [REFERENCE.md](REFERENCE.md)                                                                                                                                                                                                         | docs языка                               |
-| Термины КС, ядро/тело, не путать ярлыки                  | [DOMAIN.md](../../docs/DOMAIN.md)                                                                                                                                                                                                    | —                                        |
-
-Полный индекс справочников — [ниже](#что-читать) и в [docs/README.md](../../docs/README.md).
-
-## Границы правок: не трогай пакет rstool без запроса
-
-Задача по КС, Portal или источнику пользователя **не означает** правку дерева `rsconcept/rstool/`.
-Пакет — библиотека и справочник; каталог `examples/` — **штатные** демо пакета, а не место для разовых скриптов агента.
-
-Правки в rstool уместны только если пользователь **явно** просит, например:
-
-- доработать API, stdio, контракт, тесты rstool;
-- добавить **общий** пример в пакет;
-- обновить skill/docs rstool (в т.ч. это руководство).
-
-### Как запускать rstool, не кладя скрипт в пакет
-
-Из корня workspace Portal (после `pnpm install` и сборки `@rsconcept/domain`):
-
-```bash
-pnpm --filter @rsconcept/rstool exec tsx path/to/your/build-schema.ts
-```
-
-В скрипте импортируй API пакета (`@rsconcept/rstool` или относительный путь к `rsconcept/rstool/src` только если скрипт лежит вне пакета и это осознанный выбор). Либо используй stdio/MCP без отдельного файла.
-
-## Что читать
-
-Пути — относительно этого файла.
-
-- API, методы, stdio, MCP: [REFERENCE.md](REFERENCE.md).
-- Примеры и антипаттерны: [EXAMPLES.md](EXAMPLES.md).
-- Термины предметной области: [../../docs/DOMAIN.md](../../docs/DOMAIN.md).
-- **`X#` / `C#` / `Z`:** [../../docs/BASE-SELECTION.md](../../docs/BASE-SELECTION.md).
-- Концептуализация, создание схемы: [../../docs/CONCEPTUAL-SCHEMA.md](../../docs/CONCEPTUAL-SCHEMA.md).
-- Конституенты и валидация: [../../docs/CONSTITUENTA.md](../../docs/CONSTITUENTA.md).
-- Синтаксис ЯРЭ: [../../docs/SYNTAX.md](../../docs/SYNTAX.md).
-- Типизация: [../../docs/TYPIFICATION.md](../../docs/TYPIFICATION.md).
-- Проверка определений на КМ: [../../docs/MODEL-TESTING.md](../../docs/MODEL-TESTING.md).
-- Диагностики: [../../docs/DIAGNOSTICS.md](../../docs/DIAGNOSTICS.md).
-- REST Portal: [../../docs/PORTAL-API.md](../../docs/PORTAL-API.md).
-- Репозиторий Portal: [ConceptPortal на GitHub](https://github.com/IRBorisov/ConceptPortal).
-
-## Воркфлоу
-
-Все пошаговые сценарии собраны здесь. Справочные документы дают правила и детали.
-
-### Редактирование и проверка схемы
-
-Когда схема уже есть и нужны точечные правки, новые конституенты или проверка формул.
-
-1. Продолжи текущую сессию или вызови `ensureSession`; большинство методов создают сессию лениво.
-2. Развивай схему через `applySchemaPatch`: можно опускать `id` и `cstType` — они выводятся из префикса `alias` (`X/C/S/D/F/P/A/T/N`).
-3. Для пачки конституент передавай все элементы вместе — `applySchemaPatch` упорядочит поставщиков раньше потребителей.
-4. Перед patch в `applySchemaPatch` при сомнении вызывай `analyzeExpression`.
-5. Исправляй диагностики по диапазону `from` / `to` в `definitionFormal` ([DIAGNOSTICS.md](../../docs/DIAGNOSTICS.md)).
-6. При сомнении в семантике собери маленькую КМ и проверь тестовые данные ([цикл КМ](#проверка-на-маленькой-км)).
-7. Задай значения модели: `setModelValues`; вычисли: `evaluate`, `recalculateModel`.
-8. `commitStep` или `commitMessage` в `applySchemaPatch`, когда состояние согласовано.
-9. Сохрани: `exportSession` / `importData`.
-10. Для загрузки в Portal: `exportPortal({ kind: 'schema' })` или `{ kind: 'model' }`.
-
-### Оценка или правка КС из Portal
-
-Когда пользователь даёт UI-ссылку вида `https://portal.acconcept.ru/rsforms/:id`,
-не открывай SPA и не парси HTML: преобразуй ссылку в REST-запрос по правилам
-[PORTAL-API.md](../../docs/PORTAL-API.md) — там пути, контекстный поиск, правила доступа и curl.
-
-Portal JSON из `/details` не является форматом `exportSession`. Используй `importData(payload)` —
-kind `auto` (default) определит `portal-details` или `portal-schema`. Явный kind: `'portal-details'`, `'portal-schema'`, `'session'`.
-
-Если задача — **оценка** схемы из Portal, а не правка: после импорта иди в [ревью / оценка](#ревью--оценка-готовой-кс), не начинай массовый refactor.
-
-### Концептуализация (КС из содержания источника)
-
-Когда нужно построить или существенно развить КС по тексту ПО, требованиям или предметному описанию. Правила редукции, слоёв и паттернов — [CONCEPTUAL-SCHEMA.md](../../docs/CONCEPTUAL-SCHEMA.md).
-
-1. Собери словарь: неопределяемые понятия, ключевые отношения, сценарий синтеза.
-2. Добавь независимые неопределяемые понятия `X#`, `C#`, `S#` с конвенциями из источника (не копируй дословно). Для выбора `X#` vs `C#` vs `Z` — [BASE-SELECTION.md](../../docs/BASE-SELECTION.md).
-3. Всё, что выводится из уже введённых понятий, оформляй как `D#` / `F#` / `P#`, а не как новое `X#` / `C#` / `S#`.
-4. Вводи промежуточные `D#`, `F#`, `P#` для проекций, функциональных связей и повторяющихся фрагментов формул. Если зависимость имеет вид «для `ξ` вычислить значение», оформляй её как `F#`, а не как множество пар `I{(ξ,σ)|…}` ([CONCEPTUAL-SCHEMA.md](../../docs/CONCEPTUAL-SCHEMA.md), «Терм-функция вместо множества пар»).
-5. Добавь `A#` и `T#` после терминов, на которые они опираются.
-6. Перед каждым patch — `analyzeExpression`; при ошибках — [цикл диагностик](#цикл-диагностик).
-7. Сомнительную семантику проверь на маленькой КМ ([цикл КМ](#проверка-на-маленькой-км), [MODEL-TESTING.md](../../docs/MODEL-TESTING.md)).
-8. Перед показом результата пройди [чеклист ревью КС](#ревью-концептуальной-схемы).
-
-Дальше — обычное [редактирование и проверка](#редактирование-и-проверка-схемы): commit, export.
-
-### Ревью / оценка готовой КС
-
-Когда пользователь просит **оценить**, **проревьюить**, **найти проблемы** в уже существующей схеме (сессия, JSON, ссылка Portal) — и **не** просит сразу переписать её.
-
-**Правило:** без явного запроса на правку не делай массовый рефакторинг и не заменяй схему «улучшенной версией». Сначала отчёт; правки — только по согласованию или если пользователь сразу сказал «исправь».
-
-1. Загрузи схему: текущая сессия, `importData`, или Portal → [PORTAL-API.md](../../docs/PORTAL-API.md).
-2. `listDiagnostics()` — раздели `expression` / `schema` / `model`; зафиксируй ошибки и предупреждения.
-3. `getSessionState('summary')` — обзор состава; при необходимости `full` для формул.
-4. Структурный проход по [чеклисту ревью](#ревью-концептуальной-схемы) и [CONCEPTUAL-SCHEMA.md](../../docs/CONCEPTUAL-SCHEMA.md):
-   - неопределяемые vs производные (`S#` там, где должно быть `D#`/`F#`/`P#`);
-   - `X#` / `C#` / `Z` ([BASE-SELECTION.md](../../docs/BASE-SELECTION.md));
-   - терм-функции vs множества пар;
-   - радикалы `R#` не объявлены конституентами;
-   - покрытие задачи vs избыточность.
-5. Severity в отчёте:
-   - **блокер** — диагностики `error`, схема не анализируется / ломает вычисление;
-   - **важно** — нарушение правил проектирования (лишнее `S#`, график вместо `F#`, смешение экспликаций);
-   - **замечание** — стиль, именование, возможные упрощения, пробелы покрытия.
-6. Ответ — по [шаблону ревью](#шаблон-ответа-ревью). Предлагай конкретные правки списком; применяй их только по запросу.
-
-### Цикл диагностик
-
-Когда `analysis.success === false` или `listDiagnostics` не пуст. Коды и типичные ошибки — [DIAGNOSTICS.md](../../docs/DIAGNOSTICS.md); короткие «было → стало» — [EXAMPLES.md](EXAMPLES.md).
-
-1. Вызови `listDiagnostics()` — смотри `kind`: `expression` (формула), `schema` (омонимы, дубликаты, термин/конвенция), `model` (интерпретация).
-2. Для черновика формулы — `analyzeExpression` (без сохранения).
-3. Прочитай `name`, `severity`, `alias`, `from`, `to`, `params`, при вычислении — ещё `stack` (цепочка `F#`/`P#`, см. [DIAGNOSTICS.md](../../docs/DIAGNOSTICS.md)), в `analysis.diagnostics` или через `listDiagnostics({ kind })`.
-4. Сопоставь `name` (или `code`) с исправлением в [DIAGNOSTICS.md](../../docs/DIAGNOSTICS.md). Для runtime-ошибок внутри вызова смотри `stack[0]` — там реальный locus, а не только call site в корневом выражении.
-5. Исправь именно диапазон в `definitionFormal` (expression) или метаданные/данные модели (schema/model).
-6. Не повторяй вызов без изменения ввода.
-7. После успеха — ещё один `applySchemaPatch` / `setModelValues` с исправлением.
-
-### Проверка на маленькой КМ
-
-Когда синтаксис верен, но смысл формулы неочевиден. Подробности и форма данных — [MODEL-TESTING.md](../../docs/MODEL-TESTING.md).
-
-1. Отдельная `createSession` или изолированная копия текущей сессии.
-2. Только нужные поставщики: `X#`, `C#`, `S#` и проверяемые `D#` / `F#` / `P#` / `A#`.
-3. `analyzeExpression` и `applySchemaPatch`.
-4. Значения: `setModelValues`.
-5. `evaluate`; сравни с ожидаемым `value`.
-6. При нескольких зависимых определениях — `recalculateModel`.
-
-Для регрессий вынеси проверку в скрипт или colocated `*.test.ts` (см. [MODEL-TESTING.md](../../docs/MODEL-TESTING.md)).
-
-### Порядок объявления конституент
-
-В начале схемы — `basic` и `constant`, затем независимые `structure`, затем производные (`term`, `function`, `predicate`, `axiom`, `statement`) в топологическом порядке. Производные при родовой структуре держи рядом с ней, если это не ломает зависимости.
-
-Правила валидации по типам — [CONSTITUENTA.md](../../docs/CONSTITUENTA.md); разворачивание понятий при проектировании — [CONCEPTUAL-SCHEMA.md](../../docs/CONCEPTUAL-SCHEMA.md).
-
-## Формат ответа агента
-
-Выбери шаблон по типу задачи. Не вставляй большой JSON в чат без запроса пользователя.
-
-### Сборка / правка схемы
-
-В конце работы сообщи:
-
-- что изменено в схеме или модели;
-- есть ли активные диагностики;
-- какой экспорт получен: сессия / схема для Portal / модель для Portal;
-- какие проверки выполнены: анализ выражений / вычисление / пересчёт модели / тесты.
-
-### Шаблон ответа: ревью
-
-1. **Краткий вердикт** (1–2 предложения): пригодна ли схема к задаче, главный риск.
-2. **Диагностики:** число ошибок / предупреждений по `expression` / `schema` / `model` (без полного JSON).
-3. **Находки** списком: блокер → важно → замечание; у каждой — имя конституенты и суть.
-4. **Покрытие:** что из задачи отражено; чего не хватает.
-5. **Рекомендации:** конкретные правки; не применяй их без запроса.
-6. **Проверки:** что уже сделано (import, listDiagnostics, выборочный анализ).
-
-### Шаблон ответа: диагностики
-
-- какие конституенты / формулы затронуты;
-- `name` диагностики и смысл простым языком;
-- что изменено в формальном определении (или почему правка не нужна);
-- повторная проверка: чисто / осталось.
-
-### Шаблон ответа: объяснение формулы
-
-- роль конституенты и термин;
-- формула как есть;
-- по шагам: что вычисляется / утверждается;
-- на какие понятия опирается; типизация.
-
-### Язык ответа
-
-С пользователем говори на языке предметной области, а не контракта API. Английские идентификаторы (`definitionFormal`, `applySchemaPatch`, `cstType`...) уместны только в коде, patch-ах, JSON и при обсуждении самого API. В обычном тексте заменяй их терминами (полный словарь — [DOMAIN.md](../../docs/DOMAIN.md)):
-
-| В API                             | В тексте ответа                     |
-| :-------------------------------- | :---------------------------------- |
-| `alias`                           | имя конституенты                    |
-| `cstType`                         | тип конституенты                    |
-| `definitionFormal`                | формальное определение (формула)    |
-| `term`                            | термин                              |
-| `definitionText`                  | текстовое определение               |
-| `convention`                      | конвенция                           |
-| `comment`                         | комментарий                         |
-| `applySchemaPatch`                | правка схемы                        |
-| `synthesize`                      | встраивание / синтез схем           |
-| `analyzeExpression`               | проверка / анализ выражения         |
-| `listDiagnostics`, `diagnostics`  | диагностики                         |
-| `setModelValues`, `getModelState` | интерпретация, значения модели      |
-| `evaluate`, `recalculateModel`    | вычисление, пересчёт модели         |
-| `commitStep`, `commitMessage`     | фиксация шага (ревизия)             |
-| `exportSession` / `exportPortal`  | экспорт сессии / экспорт для Portal |
-| `importData`                      | импорт данных                       |
-| session, `sessionId`              | сессия                              |
-
-Имена конституент (`X1`, `S2`, `D3`) и формулы ЯРЭ — часть схемы, их приводи как есть; лучше вместе с термином: «терм `D3` (родитель)». Названия методов упоминай, только если пользователь спрашивает про rstool как инструмент.
-
-Словарь выше — про поля rstool. Для **понятий схемы** каноничный источник — [DOMAIN.md](../../docs/DOMAIN.md).
-
-## Чеклисты
-
-### Сессия и rstool
-
-- [ ] Используется текущая сессия (`getSessionState`) или явный `sessionId`, если сессий несколько.
-- [ ] Для стандартных `X/C/S/D/F/P/A/T/N` можно не указывать `cstType` в `applySchemaPatch`.
-- [ ] Для пачки конституент предпочитай один `applySchemaPatch` с массивом `items`.
-
-### Перед показом, commit и export
-
-- [ ] Схема проверена; ошибки исправлены.
-- [ ] Диагностики обработаны до фиксации шага и экспорта.
-- [ ] В тексте ответа нет английских имён полей и методов API — использованы термины из раздела [Язык ответа](#язык-ответа).
-- [ ] Нет неофициальных ярлыков («базис», «базисы», «базисный слой», «базовые понятия») — термины КС из [DOMAIN.md](../../docs/DOMAIN.md), раздел **«Термины: не путать»**. Для `X#` говори **базисное множество**, не «базис».
-
-### Ревью концептуальной схемы
-
-Перед завершением концептуализации, крупного изменения или как проход в [воркфлоу ревью](#ревью--оценка-готовой-кс). Правила — [CONCEPTUAL-SCHEMA.md](../../docs/CONCEPTUAL-SCHEMA.md).
-
-- [ ] Атрибутивная и родоструктурная экспликации не смешаны без явного запроса.
-- [ ] Нет избыточной проверки принадлежности к собственной типизации (`x∈X1`, если `x` уже в `X1`).
-- [ ] Неопределяемые понятия независимы; производные отношения вынесены в `D#` / `F#` / `P#`, а не объявлены новыми структурами.
-- [ ] `X#` — только предметные сущности; `C#` — только если нужны порядок/арифметика над именованным конечным набором в КМ; чистая целочисленная математика — `Z` без лишней конституенты ([BASE-SELECTION.md](../../docs/BASE-SELECTION.md)).
-- [ ] Покрыты главные сущности, роли, отношения, утверждения.
-- [ ] В текстовых определениях используются только понятия из схемы.
-- [ ] Повторяющиеся части формальных определений вынесены в производные понятия `D#` и `F#`.
-- [ ] Вычисляемые зависимости «аргумент → значение» оформлены как `F#` с вызовами, а не как пары / тройки + `Pr`/`Fi` (см. [CONCEPTUAL-SCHEMA.md](../../docs/CONCEPTUAL-SCHEMA.md), «Терм-функция вместо множества пар»).
-- [ ] Пары / `I{(ξ,σ)|…}` оставлены только для истинных отношений, графиков как объектов или многозначных связей.
-- [ ] `R#` в `[…]` у `F#` / `P#` не считается пропущенной конституентой; радикалы не добавляют в схему как `X#` / `S#` / `D#`.
-- [ ] Сомнительная семантика проверена на маленькой КМ при наличии тестовых данных.
-- [ ] При чистом ревью: отчёт по [шаблону](#шаблон-ответа-ревью) выдан **до** любых массовых правок.
+# ЯРЭ и rstool (указатель)
+
+Монолитный гайд разделён на маршрутизатор и скиллы этапов. Начни с [`../rstool/SKILL.md`](../rstool/SKILL.md).
+
+| Было в GUIDE                                        | Теперь                                                                                                                                           |
+| :-------------------------------------------------- | :----------------------------------------------------------------------------------------------------------------------------------------------- |
+| «Задача → чтение», границы правок, язык ответа      | [`rstool`](../rstool/SKILL.md) — маршрутизатор                                                                                                   |
+| Концептуализация (постановка)                       | [`rs-scope`](../rs-scope/SKILL.md), [`rs-core`](../rs-core/SKILL.md)                                                                             |
+| Редактирование, цикл диагностик, порядок объявления | [`rs-explicate`](../rs-explicate/SKILL.md)                                                                                                       |
+| Проверка на маленькой КМ                            | [`rs-interpret`](../rs-interpret/SKILL.md), [`docs/BRIEF.md`](../../docs/BRIEF.md)                                                               |
+| Ревью, чеклист ревью, шаблоны ответа                | [`rs-review`](../rs-review/SKILL.md)                                                                                                             |
+| Шаблон объяснения формулы                           | [`rs-explain`](../rs-explain/SKILL.md)                                                                                                           |
+| Синтез                                              | [`rs-synthesis`](../rs-synthesis/SKILL.md)                                                                                                       |
+| Portal                                              | [`rs-portal`](../rs-portal/SKILL.md), [`docs/PORTAL-API.md`](../../docs/PORTAL-API.md)                                                           |
+| Быстрый контракт, запуск скриптов, словарь API      | [`rstool-runtime`](../rstool-runtime/SKILL.md), [`REFERENCE.md`](../rstool-runtime/REFERENCE.md), [`EXAMPLES.md`](../rstool-runtime/EXAMPLES.md) |
+| Метод                                               | [`docs/METHOD.md`](../../docs/METHOD.md)                                                                                                         |
+
+Файл будет удалён вместе с `rstool-helper`.

package/skills/rstool-helper/SKILL.md

@@ -1,64 +1,17 @@
 ---
 name: rstool-helper
 description: >-
-  ЯРЭ и концептуальные схемы через rstool: концептуализация, ревью/оценка КС,
-  правки и диагностики формул, проверка на КМ (evaluate), выбор X#/C#/Z,
-  импорт/экспорт Portal (/rsforms, /details). Читай GUIDE и docs из node_modules.
+  Устаревший вход: используй скилл rstool. ЯРЭ и концептуальные схемы через
+  rstool, ревью КС, диагностики, Portal.
 ---
 
-# rstool-helper
+# rstool-helper (устарел)
 
-Тонкий **входной** skill. Полный гайд и документация остаются в пакете — читай через Read tool по путям ниже (от корня проекта).
+Скилл заменён маршрутизатором **`rstool`** и скиллами этапов. Прочитай `skills/rstool/SKILL.md` пакета и следуй ему:
 
-## Если входной skill ещё не установлен
+- в workspace Portal — `rsconcept/rstool/skills/rstool/SKILL.md`;
+- в npm-проекте — `node_modules/@rsconcept/rstool/skills/rstool/SKILL.md`.
 
-Пользователь выполнил `npm install @rsconcept/rstool`, но не зарегистрировал agent skill в проекте. **Выполни процедуру установки** из:
+Чтобы заменить эту заглушку в проекте, выполни `node_modules/@rsconcept/rstool/skills/INSTALL.md`, затем удали папку `rstool-helper/` из каталога скиллов проекта.
 
-`node_modules/@rsconcept/rstool/skills/INSTALL.md`
-
-Затем продолжай с каноническими файлами ниже.
-
-## Канонические файлы
-
-Префикс путей: `node_modules/@rsconcept/rstool/`.
-
-| Что                                                 | Путь                                |
-| :-------------------------------------------------- | :---------------------------------- |
-| **Начни здесь** — матрица задач, воркфлоу, чеклисты | `skills/rstool-helper/GUIDE.md`     |
-| API, stdio, MCP, контракт                           | `skills/rstool-helper/REFERENCE.md` |
-| Примеры, антипаттерны                               | `skills/rstool-helper/EXAMPLES.md`  |
-| Язык и предметная область                           | `docs/*.md`                         |
-| Установка skill                                     | `skills/INSTALL.md`                 |
-
-## Задача → что читать
-
-Не читай все `docs/` подряд. Открой **GUIDE.md** (раздел «Задача → чтение»), затем только нужные файлы:
-
-| Задача                            | Минимум                                                                        |
-| :-------------------------------- | :----------------------------------------------------------------------------- |
-| Собрать / развить КС из текста    | GUIDE: концептуализация; `docs/CONCEPTUAL-SCHEMA.md`; `docs/BASE-SELECTION.md` |
-| Оценить / отревьюить готовую КС   | GUIDE: ревью; чеклист ревью; `docs/CONCEPTUAL-SCHEMA.md`                       |
-| Починить формулу / диагностики    | GUIDE: цикл диагностик; `docs/DIAGNOSTICS.md`                                  |
-| Импорт / правка по ссылке Portal  | GUIDE: Portal; `docs/PORTAL-API.md`                                            |
-| Проверить смысл на данных         | GUIDE: КМ; `docs/MODEL-TESTING.md`                                             |
-| Синтаксис / типизация / вызов API | `docs/SYNTAX.md` / `TYPIFICATION.md` / `REFERENCE.md`                          |
-
-Перед работой всегда открой **GUIDE.md**; остальное — по строке таблицы.
-
-## Не правь пакет rstool без запроса
-
-Разовые скрипты и JSON для Portal — вне дерева пакета (каталог задачи, `.tmp/`, путь пользователя). См. **«Границы правок»** в GUIDE.md.
-
-## Язык ответа пользователю
-
-В тексте для пользователя используй термины предметной области («формальное определение», «конституента», «диагностики»), а не английские имена полей и методов API (`definitionFormal`, `applySchemaPatch`). Идентификаторы API — только в коде, patch-ах и JSON. Словарь API → текст: раздел «Язык ответа» в GUIDE.md. Термины КС (**неопределяемые понятия**, **базисное множество**, ядро) — только из `docs/DOMAIN.md`, раздел **«Термины: не путать»**. Не сокращай «базисное множество» до «базис» / «базисы».
-
-## Portal (приложение)
-
-REST API и curl — `node_modules/@rsconcept/rstool/docs/PORTAL-API.md`.
-
-## Кратко
-
-- Пакет: `@rsconcept/rstool`; обёртка: `npx rstool-wrapper`
-- MCP: `@rsconcept/rstool-mcp` (имена tools — `snake_case`, см. REFERENCE)
-- `@rsconcept/domain` устанавливается как зависимость (анализатор и коды ошибок)
+Заглушка будет удалена в следующем минорном релизе.