@rsconcept/rstool 1.9.0 → 2.0.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@rsconcept/rstool",
-  "version": "1.9.0",
+  "version": "2.0.0",
   "description": "Agent-facing library for incremental RSForm construction, RSLang analysis, diagnostics, modeling, and evaluation. Wraps @rsconcept/domain with a deterministic session contract.",
   "license": "MIT",
   "author": "IRBorisov",
@@ -32,6 +32,7 @@
       "types": "./dist/wrapper/client.d.ts",
       "import": "./dist/wrapper/client.js"
     },
+    "./skills/*": "./skills/*",
     "./skills/rstool-helper/*": "./skills/rstool-helper/*",
     "./skills/INSTALL.md": "./skills/INSTALL.md",
     "./docs/*": "./docs/*",
@@ -39,7 +40,8 @@
     "./package.json": "./package.json"
   },
   "bin": {
-    "rstool-wrapper": "dist/wrapper/stdio-wrapper.js"
+    "rstool-wrapper": "dist/wrapper/stdio-wrapper.js",
+    "rstool-skills": "skills/scripts/rstool-skills.mjs"
   },
   "files": [
     "dist",
@@ -51,18 +53,18 @@
     "LICENSE"
   ],
   "dependencies": {
-    "eslint": "^10.9.1",
-    "eslint-plugin-simple-import-sort": "^14.0.0",
-    "@rsconcept/domain": "3.1.1"
+    "@rsconcept/domain": "3.2.0",
+    "eslint": "^10.13.0",
+    "eslint-plugin-simple-import-sort": "^14.0.0"
   },
   "devDependencies": {
-    "@types/node": "^26.4.1",
-    "@vitest/coverage-v8": "^4.1.11",
-    "tsdown": "^0.22.14",
-    "tsx": "^4.23.13",
+    "@types/node": "^26.6.5",
+    "@vitest/coverage-v8": "^5.0.5",
+    "tsdown": "^0.23.1",
+    "tsx": "^4.23.15",
     "typescript": "^6.0.3",
     "unrun": "^0.3.1",
-    "vitest": "^4.1.11"
+    "vitest": "^5.0.5"
   },
   "publishConfig": {
     "access": "public"
@@ -84,6 +86,12 @@
     "example:build-movd-rsmodel": "tsx examples/movd/build-rsmodel.ts",
     "example:build-expression-bank-schema": "tsx examples/expression-bank/build-rsform.ts",
     "example:build-template-apply-schema": "tsx examples/template-apply/build-rsform.ts",
+    "example:build-subordination-schema": "tsx examples/subordination/build-rsform.ts",
+    "example:build-kinship-subordination-schema": "tsx examples/kinship-subordination/build-rsform.ts",
+    "example:build-library-loans-schema": "tsx examples/library-loans/build-rsform.ts",
+    "example:build-access-control-schema": "tsx examples/access-control/build-rsform.ts",
+    "example:build-clinic-booking-schema": "tsx examples/clinic-booking/build-rsform.ts",
+    "check-brief": "tsx skills/scripts/check-brief.ts",
     "example:audit-diagnostics": "tsx examples/audit-diagnostics.ts",
     "kinship:cli": "tsx examples/kinship/cli.ts"
   }

package/skills/INSTALL.md

@@ -1,35 +1,34 @@
-# Install `rstool-helper` (agent procedure)
+# Install the `rstool` skill (agent procedure)
 
 Use when the user has run `npm install @rsconcept/rstool` and asks to **install** or **enable** the rstool agent skill. The user should not copy files manually.
 
+The steps are agent-neutral. Map each one to the conventions of your own host (which instructions file it always loads, whether and where it loads project skills); if unsure, ask the user.
+
+The skill content stays in the package: the router `node_modules/@rsconcept/rstool/skills/rstool/SKILL.md`, the stage skills `skills/rs-*/`, `docs/`, `examples/`. Installing only adds pointers to the router, so nothing needs re-installing after a package update.
+
 ## Steps
 
 1. Confirm the package exists: `node_modules/@rsconcept/rstool/package.json`.
-2. Determine the host’s **project skills directory** (where that host loads `SKILL.md` files). Common layouts:
-   - `.agents/skills/<skill-name>/SKILL.md`
-   - `.cursor/skills/<skill-name>/SKILL.md`
-   - Other paths — use the host’s documentation if unsure.
-3. Create `<skills-dir>/rstool-helper/` if needed.
-4. Copy **one file** — the package entry skill:
-   - **From:** `node_modules/@rsconcept/rstool/skills/rstool-helper/SKILL.md`
-   - **To:** `<skills-dir>/rstool-helper/SKILL.md`
-5. Do **not** copy `GUIDE.md`, `REFERENCE.md`, `EXAMPLES.md`, or `docs/` into the project. The entry skill points at those files under `node_modules/@rsconcept/rstool/`.
-6. Confirm the destination `SKILL.md` exists and tell the user the skill is ready.
-
-### Example (`.agents/skills` layout)
-
-Bash:
-
-```bash
-mkdir -p .agents/skills/rstool-helper
-cp node_modules/@rsconcept/rstool/skills/rstool-helper/SKILL.md .agents/skills/rstool-helper/SKILL.md
-```
-
-PowerShell:
-
-```powershell
-New-Item -ItemType Directory -Force -Path .agents/skills/rstool-helper | Out-Null
-Copy-Item -Force node_modules/@rsconcept/rstool/skills/rstool-helper/SKILL.md .agents/skills/rstool-helper/SKILL.md
-```
-
-Use the equivalent path for your agent host if it does not use `.agents/skills`.
+2. **Routing line** — the required part. Add it to the project instructions file that your host always keeps in context: `AGENTS.md` if the project has one (create it if the project uses none), otherwise your host's own file. If your host reads `AGENTS.md` through another file (for example, `CLAUDE.md` with `@AGENTS.md`), the line in `AGENTS.md` is enough.
+
+   ```md
+   - Conceptual schemas (КС), RSLang (ЯРЭ), rstool or Portal → read `node_modules/@rsconcept/rstool/skills/rstool/SKILL.md` and follow it.
+   ```
+
+   If the file lists the project skills, put the line in that list.
+
+3. **Stub for auto-triggering** — optional, only if your host loads skills from a project folder. Use one folder: if the project already keeps its skills in a shared one (for example, `.agents/skills/`) and your host reads it, use that instead of adding a host-specific copy.
+
+   ```bash
+   npx rstool-skills install --dir <skills-dir>
+   ```
+
+   It writes `<skills-dir>/rstool/SKILL.md`: `name: rstool`, the router's `description` verbatim and one line «Прочитай `node_modules/@rsconcept/rstool/skills/rstool/SKILL.md` и следуй ему.» Without the bin: `npx rstool-skills stub` prints the same text, or write it by hand.
+
+4. If the project has an old copied `rstool-helper/SKILL.md`, delete that folder — `rstool` replaces it.
+5. Tell the user what was added and where.
+
+## Do not
+
+- Copy the stage skills (`rs-*`), `docs/` or `examples/` into the project: the router reads them from the package by path when a stage needs them.
+- Write stubs into several folders that one host reads: it shows the skill twice.

package/skills/README.md

@@ -1,21 +1,36 @@
 # Agent skills (`@rsconcept/rstool`)
 
-Each skill lives in its own subdirectory: `skills/<skill-name>/SKILL.md` (plus reference files). Shared install steps: `INSTALL.md`.
+One registered entry (`rstool`, the router) and stage / tool skills read by path. Skill text is Russian. Plan — [`../plans/skills-rework.html`](../plans/skills-rework.html).
 
 ## Layout
 
-- `INSTALL.md`: agent procedure after `npm install`
-- `rstool-helper/SKILL.md`: thin entry skill — copy into the project’s agent skills folder (see `INSTALL.md`)
-- `rstool-helper/GUIDE.md`: entry point — task→read matrix, workflows (incl. review), checklists (Russian)
-- `rstool-helper/REFERENCE.md`: API, stdio, MCP names, response shapes, help map (Russian)
-- `rstool-helper/EXAMPLES.md`: snippets, anti-patterns, diagnostics, `examples/` index (Russian)
-- `../docs/*.md`: language reference (DOMAIN, SYNTAX, CONSTRUCTIONS, DIAGNOSTICS, …)
+| Skill                                        | Role                                                                |
+| :------------------------------------------- | :------------------------------------------------------------------ |
+| [`rstool/`](rstool/SKILL.md)                 | Router: scenario → stages, brief, anti-greening rules, report       |
+| [`rs-scope/`](rs-scope/SKILL.md)             | Stage 1: scope, source markup, expressiveness requirements, round 1 |
+| [`rs-core/`](rs-core/SKILL.md)               | Stage 2: core hypotheses, properties as decisions, round 2          |
+| [`rs-explicate/`](rs-explicate/SKILL.md)     | Stage 3: RSLang formulas, diagnostics without losing meaning        |
+| [`rs-interpret/`](rs-interpret/SKILL.md)     | Stage 4: brief scenarios on small models                            |
+| [`rs-review/`](rs-review/SKILL.md)           | Stage 5: review against the brief, then form; report template       |
+| [`rs-synthesis/`](rs-synthesis/SKILL.md)     | Operation: synthesis of microtheories, OSS                          |
+| [`rs-explain/`](rs-explain/SKILL.md)         | Explaining a formula or construction                                |
+| [`rs-portal/`](rs-portal/SKILL.md)           | Tool: Portal REST, publish protocol                                 |
+| [`rstool-runtime/`](rstool-runtime/SKILL.md) | Tool: calling rstool; `REFERENCE.md` (contract), `EXAMPLES.md`      |
+| [`scripts/`](scripts/)                       | `check-brief.ts` (brief readiness), `rstool-skills.mjs` (install)   |
+| `rstool-helper/`                             | Deprecated stub → `rstool`; removed in the next minor release       |
+
+Only `rstool` is an entry point: a routing line in the project `AGENTS.md` and, where the host loads a project skills folder, a stub (name, description and the path; in the Portal workspace — `.agents/skills/rstool/` and `.claude/skills/rstool/`). Stage skills are not registered: the router and `check-brief` name the stage, the agent reads `skills/<name>/SKILL.md`. Paths inside skills are written from the package root `<rstool>` — `rsconcept/rstool/` in the Portal workspace, `node_modules/@rsconcept/rstool/` in an npm project.
+
+Language reference and method — [`../docs/`](../docs/README.md).
 
 ## npm workflow
 
 1. `npm install @rsconcept/rstool`
-2. User asks the agent to install the skill (no manual copy).
-3. Agent follows `node_modules/@rsconcept/rstool/skills/INSTALL.md`.
-4. Agent reads `GUIDE.md` and `docs/` from `node_modules/@rsconcept/rstool/` when working.
+2. Ask the agent to follow [`INSTALL.md`](INSTALL.md): an agent-neutral procedure that each agent maps to its own host.
+3. The agent reads the router and stage skills from `node_modules/@rsconcept/rstool/skills/`.
+
+## Editing
+
+The stub description must match `rstool/SKILL.md`; `scripts/skill-stubs.test.ts` checks the workspace stubs. After changing the router description, re-run from the repo root: `node rsconcept/rstool/skills/scripts/rstool-skills.mjs install --dir .agents/skills --dir .claude/skills`.
 
 Contract changes: see `AGENTS.md` in this package (sync checklist).

package/skills/rs-core/SKILL.md

@@ -0,0 +1,56 @@
+---
+name: rs-core
+description: >-
+  Этап 2 концептуализации: ядро. По подтверждённому брифу выбрать неопределяемые
+  понятия и основное отношение из 2–3 гипотез, решить свойства отношений
+  (аксиома или её отсутствие), задать вопросы раунда 2 и проверить, что каждое
+  требование выражается через ядро, — до формул.
+---
+
+# Этап 2 · Ядро
+
+Пути — от `<rstool>`. Метод — `docs/METHOD.md` §«Этап 2». Выбор `X#` / `C#` / `Z` — `docs/BASE-SELECTION.md`.
+
+## Вход
+
+`brief.json` со статусом `confirmed` или `assumed`.
+
+## Шаги
+
+1. **Кандидаты в неопределяемые понятия.** Из требований (не из словаря источника) выпиши кандидатов в `X#`, `C#`, `S#`. Для каждой пары кандидатов спроси: не виды ли это одного рода? «Может ли начальник быть подчинённым?», «может ли член ПК быть автором?» — если да, это одно базисное множество с ролями-отношениями, а не два `X#`.
+2. **Родовое, а не видовое.** Проверь, не взят ли вид вместо рода: функция там, где отношение («у экземпляра один читатель» — это аксиома, а не тип); симметричное отношение там, где «считает»; кортеж (группа, преподаватель, аудитория) там, где нужна сущность «занятие» с отношениями.
+3. **Основное отношение: 2–3 гипотезы.** Для каждой — что выражается, что нет («избыточно» / «недостаточно» для требований). Выбери и запиши в `decisions`: `topic`, `alternatives`, `choice`, `rationale`.
+4. **Свойства как решения.** Для каждой родовой структуры пройди перечень: рефлексивность, симметричность, транзитивность / ацикличность, однозначность, всюду определённость, несовместимость с другими структурами. По каждому свойству — решение в журнал: аксиома или **«без аксиомы»** с обоснованием. Отсутствие аксиомы — тоже решение.
+5. **Выразимость до формул.** Для каждого требования запиши `via` — одной строкой, как оно выразится через ядро: «`Pr1` назначений минус авторы рецензий», «замыкание блокировок через `R{}`». Не выражается — меняй гипотезу ядра (шаг 1–3), а не откладывай на формулы. Если требование нужно другой микротеории — `rs-synthesis`.
+6. **Разнообразие.** Перечисли 3–6 интересных термов первого ранга от ядра (проекции, дополнения вида `X1\Pr1(S1)`, пересечения однотипных структур). Их не добавляют в схему; это источник различений и вопросов раунда 2.
+7. **Раунд 2 вопросов** — 1–4 вопроса о развилках, которые появились только после гипотезы ядра: спорные свойства, которые не спросили в раунде 1, выбор между гипотезами, интересные термы из шага 6. Каждый с предложенным ответом и следствием для выразимости: «может ли задача блокировать сама себя? — предлагаю нет, тогда …». Задай и **закончи ход**. Ответы — в `questions` (`round: 2`) и в `decisions`.
+   - Раунд 2 не пропускается молча. «Продолжайте» или «на ваше усмотрение» в ответ на раунд 1 закрывает только те вопросы, что уже заданы.
+   - Нет развилок — запиши это в бриф одной строкой и скажи в отчёте.
+   - Спросить нельзя — `assumptions`, а в отчёте строка: «раунд 2 не задавался, эти аксиомы — допущения: …».
+8. **Размер.** 3–6 отношений и 2–4 уровня конкретизации. Больше — раздели на микротеории и запиши план синтеза в `decisions`.
+9. **Сценарии.** Допиши в сценарии значения неопределяемых понятий выбранного ядра (подписями), чтобы этап 4 мог их прогнать.
+
+## Выход
+
+В `brief.json`: `via` у каждого требования, решения по ядру и свойствам, вопросы и ответы раунда 2, сценарии со значениями. Конвенции для `X#` / `C#` / `S#` — текстом в решениях (на этапе 3 они уйдут в конституенты).
+
+## Гейт
+
+- Каждое требование имеет `via`; нет требования «потом придумаем».
+- Решения по основному отношению и по свойствам каждой структуры записаны, включая отсутствующие аксиомы.
+- Раунд 2 пройден или записаны допущения.
+- Размер в пределах микротеории или есть план синтеза.
+
+`check-brief` на этом этапе ещё покажет непокрытые требования (конституент нет) — это нормально; блокеров `core` быть не должно. Дальше — `rs-explicate`.
+
+## Не делай
+
+- Не вводи два `X#` для ролей одного рода.
+- Не вводи как `S#` то, что выводится из других структур (`D#` / `F#` / `P#` на этапе 3).
+- Не кодируй статусы и виды константами `C#` — классификация даёт структуры и аксиомы разбиения.
+- Не решай свойства молча: каждая отсутствующая аксиома — запись в журнале.
+- Не начинай писать формулы, пока хотя бы одно требование без `via`.
+
+## Читать по потребности
+
+`docs/METHOD.md` §«Этап 2»; `docs/CONCEPTUAL-SCHEMA.md` §«Неопределяемые понятия», §«Родовые структуры»; `docs/BASE-SELECTION.md`; разбор альтернатив и свойств — `examples/subordination/NOTES.md`.

package/skills/rs-explain/SKILL.md

@@ -0,0 +1,28 @@
+---
+name: rs-explain
+description: >-
+  Объяснить человеку формулу ЯРЭ, конструкцию языка или учебную КС: роль
+  конституенты, разбор снаружи внутрь, ступень, при запросе — вычисление на данных.
+---
+
+# Объяснение
+
+Пути — от `<rstool>`. Карточки конструкций и полный сценарий — `docs/CONSTRUCTIONS.md`. Бриф не нужен.
+
+## Шаги
+
+1. **Роль.** Имя, тип и термин конституенты; что она выражает в предметной области (по конвенции и текстовому определению).
+2. **Формула как есть** — без переписывания.
+3. **Вид выражения:** теоретико-множественное (значение — множество, кортеж, число) или логическое (истина / ложь).
+4. **Снаружи внутрь:** главная операция, затем её аргументы; объясняй только конструкции, которые есть в формуле (`docs/CONSTRUCTIONS.md`).
+5. **Ступень и опоры:** типизация результата (`labelType`) и от каких конституент формула зависит.
+6. **Пример на данных** — только по запросу: маленькая модель подписями (сценарий брифа или `setModelValues` + `evaluate` на копии сессии).
+
+Для учебной схемы — ещё **решения по ядру**: почему выбраны эти неопределяемые понятия и отношения, какие аксиомы есть и каких сознательно нет (журнал решений брифа, если он есть; иначе — как гипотеза).
+
+## Не делай
+
+- Не меняй схему, объясняя её.
+- Не используй имена API в тексте: «формальное определение», а не `definitionFormal` (словарь — `skills/rstool-runtime/SKILL.md`).
+- Не называй `X#` «базисом», `T#` — «теоремой».
+- Не разбирай конструкции, которых нет в формуле.

package/skills/rs-explicate/SKILL.md

@@ -0,0 +1,71 @@
+---
+name: rs-explicate
+description: >-
+  Этап 3 концептуализации: экспликация — записать ядро и производные понятия на
+  ЯРЭ, развёртывая от требований брифа; починить формулу или разобрать
+  диагностики без потери смысла. Правила против подгонки под «зелёное».
+---
+
+# Этап 3 · Экспликация
+
+Пути — от `<rstool>`. Проектирование формул — `docs/CONCEPTUAL-SCHEMA.md`; синтаксис — `docs/SYNTAX.md`; коды диагностик — `docs/DIAGNOSTICS.md`; вызовы — `skills/rstool-runtime/SKILL.md`.
+
+## Вход
+
+Бриф с `via` у каждого требования и решениями по ядру. Для починки формулы — лёгкий бриф: смысл конституенты одной строкой (из термина, текстового определения или вопроса пользователю) и сценарий, который этот смысл проверяет. **Смысл фиксируется до правки.**
+
+## Шаги
+
+1. **Ядро.** `X#`, `C#`, `S#` с предметными конвенциями: что элемент, порядок компонент кортежа, ссылка на решение (`DC#`). Затем аксиомы из решений по свойствам.
+2. **Развёртывание от требований.** Для каждого требования по его `via` — конституента и только нужные поставщики. Не выводи все возможные термы.
+   - Раскрытие структуры: `D# := Pr1(S1)`, `Pr2,3(S1)`, `red(…)` — термины для компонент.
+   - Обособление: выражение со свободной переменной — `F#` / `P#`; повторяющийся фрагмент — `D#` / `F#`.
+   - Зависимость «аргумент → значение» — `F# ::= [ξ∈A] E(ξ)`, не множество пар `I{(ξ,σ) | …}`.
+   - (Не)пустота — `S ≠ ∅` / `S = ∅`, не `card(S) > 0`.
+   - Транзитивное замыкание, достижимость, ацикличность — через `R{}` в `F#`, а не квантор по `ℬ(X1)` (`invalidPropertyUsage`).
+   - Однозначность отношения — `card(S1)=card(Pr1(S1))`.
+3. **Порядок:** `X#`, `C#` → независимые `S#` → `D#`/`F#`/`P#` → `A#`/`T#`; поставщики раньше потребителей (`applySchemaPatch` упорядочивает пачку сам).
+4. **Перед сохранением** сомнительной формулы — `analyzeExpression`. Пачку правь одним `applySchemaPatch`.
+5. **Ссылки брифа.** Впиши в `expressiveness[].constituent` и `invariants[].constituent` имена конституент. Сохрани сессию (`exportSession`) в папку задачи.
+6. **Проверка:** `check-brief` (`docs/BRIEF.md`). Блокеров `core` и `explicate` быть не должно; дальше — `rs-interpret`.
+
+## Цикл диагностик
+
+1. `listDiagnostics()`: `kind` — `expression` (формула), `schema` (омонимы, дубликаты, конвенции), `model` (интерпретация).
+2. По `name` найди исправление в `docs/DIAGNOSTICS.md`; короткие «было → стало» — `skills/rstool-runtime/EXAMPLES.md` «Типичные диагностики». Для ошибок внутри `F#`/`P#` смотри `stack[0]`.
+3. Исправляй диапазон `from`–`to` в формуле так, чтобы **смысл из брифа сохранился**; проверь сценарием.
+4. Не повторяй вызов без изменения ввода.
+
+## Смысл важнее «зелёного»
+
+Нельзя ради чистых диагностик:
+
+- удалять или ослаблять аксиому, связанную с инвариантом брифа, без нового решения в журнале;
+- превращать производное понятие (`D#`/`F#`/`P#`) в `S#`, `X#` или `C#` — у неопределяемого нет формулы, поэтому нет и ошибок, но понятие перестаёт выводиться;
+- заменять формулу тривиальной (`∅`, `D5 := X1`, тавтология) или менять порог / условие (`≥ 2` → `≥ 1`);
+- удалять конституенту, на которую ссылается бриф, или оставлять непустой `failed` после `best_effort`;
+- оставлять пустую конвенцию у неопределяемого понятия.
+
+Если смысл не выражается: вернись в `rs-core` (другая гипотеза ядра, промежуточные `D#`/`F#`) и запиши решение. Если ЯРЭ этого не выражает — `openQuestions` в бриф и честное «готово частично» в отчёте. При развитии схемы запускай `check-brief` с `--base <прежняя сессия>`: он ловит удалённые и ослабленные понятия.
+
+## Выход
+
+Сессия в папке задачи; бриф со ссылками на конституенты.
+
+## Гейт
+
+- Диагностики чисты, `failed` пуст.
+- У каждого требования и инварианта есть конституента; ни одно не ослаблено.
+- Конвенции у всех `X#` / `C#` / `S#`.
+- Описание схемы (`comment` сессии, на Portal — описание) содержит назначение, ограничения с невыразимым и краткий журнал решений; конвенции и текстовые определения не ссылаются на `DC#` и имена конституент в простом тексте — бриф при синтезе не переносится, а конвенции не перенумеровываются. Бриф пока не уходит в Portal — без этого решения теряются при экспорте. Для `education` текст решений в схеме обязателен.
+
+## Не делай
+
+- Не вводи `S#` для отношения, которое выводится из других.
+- Не кодируй атрибуты и статусы константами `C#`.
+- Не добавляй `R1` как конституенту: радикал живёт только в `[…]` у `F#` / `P#`.
+- Не правь пакет `<rstool>` — скрипты и сессии в папке задачи.
+
+## Читать по потребности
+
+`docs/CONCEPTUAL-SCHEMA.md`, `docs/SYNTAX.md`, `docs/DIAGNOSTICS.md`, `docs/TYPIFICATION.md`, `docs/BASE-SELECTION.md`; антипримеры подгонки — `examples/subordination/NOTES.md` §«Антипримеры».

package/skills/rs-interpret/SKILL.md

@@ -0,0 +1,67 @@
+---
+name: rs-interpret
+description: >-
+  Этап 4 концептуализации: интерпретация — проверить смысл КС на маленьких КМ
+  по сценариям брифа: примеры и контрпримеры для требований, аксиом и
+  различений. При провале вернуться к ядру, а не подгонять формулу.
+---
+
+# Этап 4 · Интерпретация
+
+Пути — от `<rstool>`. Формат сценариев — `docs/BRIEF.md` §«Сценарии»; формы значений КМ и тесты — `docs/MODEL-TESTING.md`.
+
+## Вход
+
+Схема без ошибок диагностик (сессия, сохранённая `exportSession`) и `brief.json` со сценариями.
+
+## Шаги
+
+1. **Ожидания на конституенты.** В каждый сценарий допиши `expect`: для требований — `value` или `contains` / `excludes` на их конституенты; для `F#` / `P#` — `args` подписями; для инвариантов — `holds` на аксиому. Ожидания выводи из смысла требования и источника, **не** из того, что вычисляет текущая формула.
+2. **Покрытие сценариями.**
+   - У каждого инварианта — `positive` (аксиома истинна) и `negative` (ложна). Негатив нарушает ровно это правило, иначе он ничего не доказывает.
+   - У каждого различения — `witness`: сценарий, где значения двух понятий различаются.
+   - При развитии схемы старые сценарии остаются — это регрессия.
+   - Граничные случаи там, где в требовании есть число или порог (`≥ 3`, `≤ 20`): ровно на границе и за ней.
+3. **Прогон.**
+
+   ```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 …`. Сценарии выполняются на копии сессии — рабочая модель не портится. Матрица приёмки: сценарий × ожидание → факт.
+
+4. **Разбор провала.** Прежде чем менять формулу, ответь, где ошибка:
+   - **в ожидании** (неправильно понят источник) — уточни у пользователя или в источнике, исправь сценарий и запиши почему;
+   - **в формуле** при верном ядре — `rs-explicate`, правка без изменения смысла требования;
+   - **в ядре** (понятие не выражается, различение склеилось, вид вместо рода) — вернись в `rs-core`, новая гипотеза и запись в журнал решений.
+
+   Менять ожидание под результат формулы без такого разбора — подгонка.
+
+5. Повторяй прогон, пока блокеров `interpret` нет.
+
+## Выход
+
+Сценарии с ожиданиями в `brief.json`; вывод `check-brief` с матрицей приёмки — в отчёт.
+
+## Гейт
+
+- Все сценарии проходят.
+- У каждого инварианта есть позитивный и негативный сценарий.
+- Каждое различение подтверждено сценарием, на котором значения различаются. Предупреждение «различение не проверено» — не сдавать: добавь сценарий с `expr`, на котором значения различаются, или скажи в отчёте, что различение не проверено.
+
+Дальше — `rs-review`. При провале — `rs-core` или `rs-explicate` по шагу 4.
+
+## Не делай
+
+- Не проверяй только «нет диагностик» или только позитивные данные.
+- Не пиши ожидание, подсмотрев значение формулы.
+- Не добавляй в рабочую схему конституенты «для теста» — используй `expr` в сценарии.
+- Не задавай значения производным понятиям: только `X#`, `C#`, `S#`.
+
+## Если скрипт не подходит
+
+Сложная проверка (перебор по `Z`, функции с радикалами) — вручную на копии сессии: `setModelValues` и `evaluate` (`docs/MODEL-TESTING.md`, `skills/rstool-runtime/SKILL.md`). Результат всё равно запиши сценарием в бриф, если ожидание выражается.
+
+## Читать по потребности
+
+`docs/BRIEF.md`, `docs/MODEL-TESTING.md`; пример брифа со сценариями — `examples/subordination/brief.json`.

package/skills/rs-portal/SKILL.md

@@ -0,0 +1,51 @@
+---
+name: rs-portal
+description: >-
+  Portal REST для агента: ссылка Portal → API-запрос, чтение схемы, модели или
+  ОСС с API-ключом или анонимно, импорт в rstool, протокол публикации
+  (версия → замена → сверка), лимиты.
+---
+
+# Portal
+
+Пути — от `<rstool>`. Указатель REST — `docs/PORTAL-API.md`.
+
+## Ссылка → API
+
+UI-ссылку (`https://portal.acconcept.ru/rsforms/856?tab=editor`) не открывай и не парси HTML: преобразуй в REST — `https://api.portal.acconcept.ru/api/rsforms/856/details` (query и hash отбрасываются). Правила, поиск, доступ — `docs/PORTAL-READ.md`.
+
+- С API-ключом пользователя: `/api/agents/...` и `Authorization: Bearer rcp_…`.
+- Без ключа видны только публичные схемы в `/S` и `/L`. Для непубличной — попроси ключ, JSON `/details` или временную публикацию; **не** cookie.
+- Нужны только название или доступ — метаданные, не `/details`.
+
+## Чтение и импорт
+
+1. `GET …/rsforms/:id/details` → файл в папке задачи (UTF-8).
+2. `importData(payload)` — `auto` распознает JSON Portal; не передавай его как `kind: 'session'`.
+3. `listDiagnostics()`; дальше по маршруту (`skills/rstool/SKILL.md`): ревью, развитие.
+4. Сохрани сессию-базу (`exportSession`) — для `check-brief --base` и сводки изменений.
+
+Модели — `docs/PORTAL-MODELS.md`; ОСС — `docs/PORTAL-OSS.md`.
+
+## Бриф на Portal
+
+Пока бриф на Portal не хранится (план — блок «Задание» в паспорте схемы): держи `brief.json` в папке задачи. При ревью или развитии схемы Portal без брифа восстанови его (`rs-scope` §«Восстановление брифа»).
+
+## Публикация
+
+Протокол — `docs/PORTAL-PUBLISH.md` §«Протокол публикации»:
+
+1. Работа по этапам, пока `check-brief` не покажет этап `review` без блокеров (или пользователь согласился с «готово частично»).
+2. Сводка изменений относительно сессии-базы → **подтверждение пользователя**.
+3. Описание схемы содержит назначение, ограничения и краткий журнал решений (гейт `rs-explicate`). `create-version` (если есть права) → `replace` с `exportPortal({ kind: 'schema' })`.
+4. Повторно прочитай `/details`, импортируй и сверь. Отчёт со ссылкой на схему в UI.
+
+## Лимиты
+
+Правки: 30 в минуту, 300 в час; `replace`, `create-version` и создание КС — ещё не больше 15 в час. `429` — бюджет кончился, не повторяй в цикле. Подробно — `docs/PORTAL-PUBLISH.md` §«Лимиты».
+
+## Не делай
+
+- Не заменяй схему без сводки изменений и подтверждения.
+- Не предлагай авторизацию через session cookie.
+- Не перебирай id подряд — используй контекстный поиск.

package/skills/rs-review/SKILL.md

@@ -0,0 +1,79 @@
+---
+name: rs-review
+description: >-
+  Этап 5 концептуализации: ревью КС и отчёт. «Оцени», «проверь», «найди
+  проблемы» в схеме или самопроверка перед сдачей своей работы. Два прохода:
+  соответствие брифу (требования, различения, инварианты, невыразимое, решения),
+  затем форма ЯРЭ. Отчёт начинается с таблицы «требование → конституента → доказательство».
+---
+
+# Этап 5 · Ревью и сдача
+
+Пути — от `<rstool>`. Правила формы — `docs/CONCEPTUAL-SCHEMA.md`.
+
+## Вход
+
+Схема (сессия, файл, Portal) и бриф. Ревью чужой схемы без брифа: сначала `rs-scope` §«Восстановление брифа» — задача из запроса пользователя, требования из терминов и текста запроса.
+
+**Без явного запроса на правку не создавай ни исправленную, ни новую («предложенную») сессию.** Сначала отчёт. Рекомендации — текстом: формула и чем она проверена (анализ выражения, `evaluate({ expression })` на модели исходной сессии или сценарий брифа с `expr`). Нужна правка — спроси в конце отчёта.
+
+## Проход 1. Соответствие брифу
+
+1. `check-brief --review` (см. `rs-interpret`): покрытие, матрица приёмки, блокеры. Для чужой схемы блокеры — находки отчёта, а не план правки.
+2. Для каждого требования: конституента **действительно** выражает понятие? Сверь термин, текстовое определение и формулу; подтверди сценарием. Термин сильнее формулы («сыгранные матчи» = все матчи календаря) — блокер.
+3. Различения разведены: два понятия не совпадают на сценарии-свидетеле.
+4. Инварианты: аксиома ловит нарушение (негативный сценарий ложен) и не запрещает лишнего (позитив истинен).
+5. Невыразимое: то, что пользователь хотел, но схема не выражает, названо и согласовано (ограничение или открытый вопрос), а не пропущено молча.
+6. Журнал решений: выбор ядра и свойств отношений обоснован; схема не противоречит записанному решению (решение «без аксиомы транзитивности» — а аксиома есть).
+7. Пересказ: в схеме нет понятий из исключённого (`restrictions`) и нерелевантного.
+
+## Проход 2. Форма ЯРЭ
+
+- [ ] Диагностики: `listDiagnostics` по `expression` / `schema` / `model`. `analysisSuccess: true` в summary не означает отсутствия диагностик.
+- [ ] Неопределяемые понятия независимы; производное не объявлено `S#`.
+- [ ] `X#` — предметные сущности; `C#` — только если нужны порядок и арифметика над именованным набором; чистые числа — `Z` (`docs/BASE-SELECTION.md`). Статусы и виды не кодируются в `C#`.
+- [ ] Роли одного рода — одно базисное множество, не два.
+- [ ] Вычисляемая зависимость «аргумент → значение» — `F#`, а не множество пар с `Pr`/`Fi`.
+- [ ] (Не)пустота — `S ≠ ∅` / `S = ∅`, не `card(S) > 0`.
+- [ ] Повторяющиеся фрагменты формул обособлены в `D#` / `F#`.
+- [ ] Конвенции у `X#` / `C#` / `S#` предметные: что элемент, порядок компонент кортежа.
+- [ ] Текстовые определения используют только понятия схемы.
+- [ ] `R#` в `[…]` у `F#` / `P#` — радикал, не пропущенная конституента.
+- [ ] Нет «сирот» — конституент вне путей к требованиям и аксиомам (для `project` — ошибка).
+- [ ] Атрибутивная (`N#`) и родоструктурная экспликации не смешаны без запроса.
+
+## Ранжирование находок
+
+По смыслу, а не по полю `severity` инструмента:
+
+- **блокер** — требование не выражено или выражено неверно (термин ≠ формула, проверено сценарием); склеенное различение; аксиома не ловит нарушение инварианта; формула не разбирается или невычислима; `schemaDependencyCycle`, `schemaFormalDuplicate`, `schemaHomonym`;
+- **важно** — нарушение правил проектирования: лишнее `S#`, коды в `C#`, вид вместо рода, график вместо `F#`, нет решения по спорному свойству, `card(S) > 0`;
+- **замечание** — `schemaMissingConvention`, `schemaMissingTerm`, стиль, именование.
+
+## Отчёт
+
+1. **Вердикт** (1–2 предложения): отвечает ли схема запросу; главный риск. «Диагностик нет» — не вердикт.
+2. **Как схема отвечает на запрос** — таблица:
+
+   | Требование                     | Конституента | Доказательство                          |
+   | :----------------------------- | :----------- | :-------------------------------------- |
+   | E1 доклады, ожидающие рецензий | `D3`         | SC1 ✓, SC2 ✓                            |
+   | E3 доступный экземпляр         | —            | не выражено: не хватает понятия «бронь» |
+
+   Плюс инварианты (аксиома, позитив / негатив) и различения (свидетель).
+
+3. **Не выражено сознательно:** ограничения и невыразимое; допущения; открытые вопросы.
+4. **Решения по ядру**, которые пользователь должен знать.
+5. **Находки** (для ревью): блокер → важно → замечание; у каждой — имя конституенты, суть, как подтверждено.
+6. **Рекомендации:** конкретные правки, проверенные анализом и сценарием; не применены без запроса.
+7. **Проверки:** диагностики (числа, без JSON), вывод `check-brief`, файлы (сессия, бриф, экспорт).
+
+Готово частично — так и скажи и перечисли, что не покрыто и почему: не хватает исходного понятия, понятие не выведено или нужен синтез с другой схемой.
+
+## Перед публикацией
+
+Перед заменой схемы на Portal — сводка изменений относительно опубликованной версии и подтверждение пользователя (`rs-portal`).
+
+## Читать по потребности
+
+`docs/CONCEPTUAL-SCHEMA.md`, `docs/METHOD.md` §«Этап 5»; образец ревью — `examples/subordination/NOTES.md` §«Антипримеры».