@mrciphersmith/keryx 0.2.9

package/src/gdskills/bundled/skills/review/code-b091-review/SKILL.zed.md

@@ -0,0 +1,209 @@
+---
+name: code-b091-review
+description: "Performs strict b091-style code review following code-review-b091-profile.mdc. Reviews current branch changes from merge-base. Direct, no-fluff feedback focused on logic correctness. Use when: b091 review requested, strict validation needed."
+triggers:
+  - "Review as b091"
+  - "b091 style review"
+  - "b091 review"
+metadata:
+  author: "MrCipherSmith"
+  version: "1.0.0"
+  category: "review"
+license: "MIT"
+compatibility: "cursor,codex,zed,opencode"
+---
+
+
+# Code Review as b091 (только текущая ветка)
+
+## Workflow
+
+Copy this checklist and track progress:
+
+```
+b091 Review Progress:
+- [ ] Step 1: Determine parent branch and calculate merge-base
+- [ ] Step 2: Collect git diff (committed + local changes)
+- [ ] Step 3: Apply b091 principles (logic in correct layer, no ducttape)
+- [ ] Step 4: Check types (no any, typed mocks)
+- [ ] Step 5: Verify conventions (currentState, I prefix, etc.)
+- [ ] Step 6: Challenge all assumptions
+- [ ] Step 7: Generate direct report with patches
+```
+
+## Обязательные правила
+
+1) **Скоуп по умолчанию (без commit hash/range в запросе)**: ревью включает **все** изменения в текущей ветке от точки ответвления (merge-base) от родительской ветки:
+   - закоммиченные (`BASE_SHA..HEAD`)
+   - локальные незакоммиченные (staged/unstaged/untracked)
+2) **Скоуп при явном commit hash/range**: если пользователь явно передал hash или диапазон, ревьюй только запрошенный диапазон; локальные незакоммиченные изменения не добавляй, если это отдельно не попросили.
+3) **Стиль/принципы b091**: ревью строго по `.metaproject/rules/core/code-review-b091-profile.mdc` (разделы правил и промпт).
+4) **Результат**: подробный отчёт по проблемам с объяснением и предложением исправлений (минимальные патчи там, где это просто).
+
+## Определение parent ref (детерминированно, именно родитель ветки)
+
+Используй первый существующий вариант:
+
+1. `origin/main`
+2. `origin/master`
+3. `main`
+4. `master`
+5. `@{upstream}` **только если это не текущая feature-ветка**
+
+```bash
+BRANCH="$(git rev-parse --abbrev-ref HEAD)"
+UPSTREAM_REF="$(git rev-parse --abbrev-ref --symbolic-full-name @{upstream} 2>/dev/null || true)"
+
+PARENT=""
+if git rev-parse --verify -q "origin/main" >/dev/null; then
+  PARENT="origin/main"
+elif git rev-parse --verify -q "origin/master" >/dev/null; then
+  PARENT="origin/master"
+elif git rev-parse --verify -q "main" >/dev/null; then
+  PARENT="main"
+elif git rev-parse --verify -q "master" >/dev/null; then
+  PARENT="master"
+elif [ -n "$UPSTREAM_REF" ] && [ "$UPSTREAM_REF" != "$BRANCH" ] && [ "$UPSTREAM_REF" != "origin/$BRANCH" ]; then
+  PARENT="@{upstream}"
+else
+  echo "Cannot determine parent ref" >&2
+  exit 1
+fi
+
+BASE_SHA="$(git merge-base HEAD "$PARENT")"
+```
+
+## Команды, чтобы собрать “срез” для ревью
+
+### A) Режим по умолчанию (пользователь НЕ дал hash/range)
+
+```bash
+git status
+
+# Закоммиченная часть ветки
+git log --oneline "${BASE_SHA}..HEAD"
+git diff --stat "${BASE_SHA}..HEAD"
+git diff --name-status "${BASE_SHA}..HEAD"
+git diff "${BASE_SHA}..HEAD"
+
+# Полный текущий срез от merge-base до рабочего дерева:
+# включает commit'ы + staged + unstaged
+# (untracked смотри через git status / git ls-files)
+git diff --stat "${BASE_SHA}"
+git diff --name-status "${BASE_SHA}"
+git diff "${BASE_SHA}"
+git ls-files --others --exclude-standard
+```
+
+### B) Режим с явным hash/range
+
+Если пользователь дал конкретный hash/range, используй его буквально:
+
+```bash
+# Примеры:
+git show --stat --name-status --patch <COMMIT_SHA>
+git log --oneline <FROM_SHA>..<TO_SHA>
+git diff --stat <FROM_SHA>..<TO_SHA>
+git diff --name-status <FROM_SHA>..<TO_SHA>
+git diff <FROM_SHA>..<TO_SHA>
+```
+
+## Как ревьюить (по b091)
+
+Применяй чек-лист и промпт из `.metaproject/rules/core/code-review-b091-profile.mdc`. Ключевые акценты b091:
+
+- Логика должна жить в правильном слое (часто — в store), чтобы её можно было нормально тестировать.
+- Против “patch/glue/ducttape”: требуй чинить причину, а не маскировать симптомы.
+- В новом коде никаких `any`, `as any`, небезопасных кастов; моки — типизированные и не наследуются от реальных реализаций.
+- Не плодить дублирование правил/проверок: один источник правды, переиспользовать сеттеры/методы.
+- Конвенции проекта обязательны (например, `currentState`, `I` для интерфейсов, консистентные типы).
+- Магические числа / `setTimeout(0)` / "страшные" хаки — только с чётким "почему", либо перепроектировать.
+- **Accessibility модификаторы в сторах**: inter-store callbacks (`onChangeX`, `onFireX`, `handleX`, `syncX`) обязаны быть `private`. Публичный метод допустим только если он вызывается из React-компонента. Спросить: "Вызывается ли этот метод из JSX?" Если нет — `private`.
+- С MobX по умолчанию **не добавлять** `useCallback`/`useMemo` без явной необходимости.
+- Предложения должны проходить линт; не нитпикать автоформатирование.
+- Не раздувать scope: большие рефакторы “not today”, если вне задачи.
+
+## Формат вывода (подробный отчёт + тон b091)
+
+Пиши по-русски, но допускай короткие b091-маркеры (например, `not today ;P`, “ducttape”, “broken thinking”) только по делу и без перехода на личности.
+
+Используй структуру:
+
+```markdown
+## Вердикт (b091)
+<OK / needs work / fundamentally wrong> + 1–3 самых важных тезиса.
+
+## Скоуп ревью (только текущая ветка)
+- Ветка: `<BRANCH>`
+- Parent ref: `<PARENT>`
+- Merge-base: `<BASE_SHA>`
+- Режим скоупа: `<default-with-uncommitted | explicit-hash-range>`
+- Коммиты (merge-base..HEAD): <N>
+- Изменённые файлы: <список или количество>
+
+## Находки (подробно)
+### Архитектура и место логики
+<находки>
+
+### Типы, касты, моки
+<находки>
+
+### Корректность и семантика состояний
+<находки>
+
+### Конвенции и консистентность
+<находки>
+
+### Линт/формат/шум
+<находки>
+
+### UX/edge cases
+<находки>
+
+### Тестируемость
+<находки>
+
+## Предложенные исправления (patches)
+<минимальные unified diff-патчи для очевидных правок>
+```
+
+### Формат каждой находки (обязательно)
+
+Для каждой находки укажи:
+
+- **Severity**: `blocker` / `major` / `minor`
+- **Location**: путь файла + релевантный hunk/фрагмент из diff
+- **Problem**: что не так
+- **Why it matters**: почему это важно (корректность/тестируемость/конвенции/поддерживаемость)
+- **Suggested fix**: что конкретно сделать (точечно, без раздувания scope)
+- **Optional patch**: если фикс простой — unified diff
+
+Пример блока патча:
+
+```diff
+diff --git a/path/file.ts b/path/file.ts
+index 0000000..1111111 100644
+--- a/path/file.ts
++++ b/path/file.ts
+@@ -1,3 +1,3 @@
+-const x = 1;
++const x = 2;
+```
+
+---
+
+## Job Context Awareness
+
+When dispatched by `job-orchestrator` as part of a job pipeline, the prompt MAY include:
+
+```
+JOB_NAME:     <job-name>
+CONTEXT_PATH: .metaproject/jobs/<job-name>/ai/context.md
+```
+
+If provided and the file exists, read the context document before starting the review. Use it to:
+- Understand which libraries and patterns were intentionally chosen for the implementation
+- Avoid flagging correct library usage as issues
+- Provide more accurate findings by understanding the project's architectural decisions
+
+If the file does not exist or is not provided, proceed normally — context is optional and non-blocking.

package/src/gdskills/bundled/skills/review/code-mobx-store-review/SKILL.codex.md

@@ -0,0 +1,263 @@
+---
+name: code-mobx-store-review
+description: "Targeted MobX store and state logic review. Checks store/actions/computed/reactions, async runInAction, state typing, View↔Store boundaries. Use when: reviewing MobX changes, state management validation."
+triggers:
+  - "Review MobX store"
+  - "Check store changes"
+  - "MobX review"
+metadata:
+  author: "MrCipherSmith"
+  version: "1.1.0"
+  category: "review"
+license: "MIT"
+compatibility: "cursor,codex,zed,opencode"
+---
+
+---
+
+# Code MobX Store Review (только текущая ветка)
+
+Проводи ревью только изменений текущей ветки от merge-base с родительской веткой. Фокусируйся на корректности состояния, MobX-паттернах и границах архитектуры.
+
+## Scope
+
+- Если пользователь **не передал commit hash/range**, ревьюируй полный срез от merge-base до рабочего дерева:
+  - закоммиченные изменения (`BASE_SHA..HEAD`)
+  - локальные (`staged/unstaged/untracked`)
+- Если пользователь **явно передал commit hash/range**, ревьюируй только его.
+- Не ревьюй легаси вне измененного скоупа.
+- Привязывай замечания к измененным строкам в diff.
+
+## Git workflow (определение parent и merge-base)
+
+```bash
+BRANCH="$(git rev-parse --abbrev-ref HEAD)"
+UPSTREAM_REF="$(git rev-parse --abbrev-ref --symbolic-full-name @{upstream} 2>/dev/null || true)"
+
+PARENT=""
+if git rev-parse --verify -q "origin/main" >/dev/null; then
+  PARENT="origin/main"
+elif git rev-parse --verify -q "origin/master" >/dev/null; then
+  PARENT="origin/master"
+elif git rev-parse --verify -q "main" >/dev/null; then
+  PARENT="main"
+elif git rev-parse --verify -q "master" >/dev/null; then
+  PARENT="master"
+elif [ -n "$UPSTREAM_REF" ] && [ "$UPSTREAM_REF" != "$BRANCH" ] && [ "$UPSTREAM_REF" != "origin/$BRANCH" ]; then
+  PARENT="@{upstream}"
+else
+  echo "Cannot determine parent ref" >&2
+  exit 1
+fi
+
+BASE_SHA="$(git merge-base HEAD "$PARENT")"
+```
+
+### Команды сбора изменений
+
+```bash
+git status
+git log --oneline "${BASE_SHA}..HEAD"
+git diff --name-status --find-renames "${BASE_SHA}..HEAD"
+git diff --find-renames "${BASE_SHA}..HEAD"
+git diff --name-status --find-renames "${BASE_SHA}"
+git diff --find-renames "${BASE_SHA}"
+git ls-files --others --exclude-standard
+```
+
+## MobX review checklist
+
+### Store structure
+- Store-класс должен иметь `makeObservable(this)` в конструкторе.
+- Состояние хранится в `@observable`/`@observable.shallow`/`@observable.ref`.
+- Производные значения в `@computed`, а не в View.
+
+### Member ordering
+Проверяй порядок членов класса (соответствие `@typescript-eslint/member-ordering` и проектной конвенции):
+1. `@observable` поля (публичное состояние, без модификатора)
+2. `private` поля (внутреннее состояние: `disposed`, `initialized`, и т.д.)
+3. `constructor`
+4. `@computed` геттеры
+5. `dispose()` — lifecycle очистки
+6. `init()` / `onMount()` — lifecycle инициализации
+7. `@action.bound` методы — UI-facing actions
+8. `private` методы — API-вызовы и внутренняя логика
+
+### Member accessibility modifiers
+ESLint: `@typescript-eslint/explicit-member-accessibility: ["error", { accessibility: "no-public" }]` — слово `public` **запрещено**.
+
+- *(без модификатора)*: `@observable` поля, `@computed` геттеры, `@action.bound` методы, `dispose()`, `init()` — публичный API стора.
+- `private`: внутреннее состояние (`disposed`, `initialized`), хелпер-методы, методы с API-вызовами (`fetchX`, `performX`), inter-store callbacks (`onChangeX`, `onFireX`, `handleX`, `syncX`).
+- `private readonly`: инжектированные через конструктор зависимости, неизменяемая конфигурация (`id`, `context`).
+- `readonly`: неизменяемые публичные identity-поля (`pipelineType`, `contextActions`).
+- `protected`: только в абстрактных базовых классах для точек расширения.
+
+Флаги ревью:
+- Использование слова `public` — **ошибка ESLint** (error level).
+- `private` поле которое можно сделать `private readonly` — предложи `readonly`.
+- Отсутствие `private` на внутреннем состоянии или хелпер-методах — **warning**.
+
+### Actions and async
+- Любая мутация состояния в действиях (`@action.bound` или через `runInAction`).
+- После `await` для мутаций использовать `runInAction`.
+- Избегать прямых мутаций store извне action-слоя.
+
+### Action binding rules
+- **`@action.bound`**: только для методов вызываемых из UI (компонентов). Это тонкие обёртки которые делегируют в private-методы.
+- **Private метод + `runInAction`**: для методов содержащих API-вызовы и мутации состояния.
+- **Никогда** не использовать `@action.bound` на private-методах.
+- **Исключение**: `@action.bound private` допустим для inter-store callbacks — методов, передаваемых как bound-ссылки в дочерние/сиблинг сторы (например `new CodeEditorStore(this.onChangeEditorState)`).
+
+Флаги ревью:
+- `@action.bound` метод содержит API-вызов напрямую — **warning**: вынести API в private метод.
+- `@action.bound` на private методе (кроме inter-store callbacks) — **warning**: убрать декоратор, использовать `runInAction` внутри.
+- Метод вызываемый из другого стора помечен `@action.bound` вместо plain method — **suggestion**.
+
+### Inter-store callbacks and internal handlers
+Методы служащие **внутренними callback'ами** между сторами или внутренними обработчиками событий ОБЯЗАНЫ быть `private`. Они НЕ являются частью публичного API стора.
+
+**Паттерны имён которые ОБЯЗАНЫ быть `private`:**
+- `onChangeEditorState(state)` — callback получающий состояние от дочернего/сиблинг стора
+- `onFireExecutorChange()` — внутренний sync-обработчик при смене executor
+- `onChangeX(value)` — обработчик для внутренней синхронизации состояния между сторами
+- `handleX()`, `syncX()` — любой метод внутренней координации
+
+**Правило решения:** Спроси "Этот метод вызывается из React-компонента через JSX/event handler?" Если НЕТ — он `private`.
+
+Флаги ревью:
+- Публичный метод с паттерном `onChangeX`, `onFireX`, `handleX`, `syncX` который не вызывается из компонентов — **warning**: сделать `private`.
+- Inter-store callback без `private` — **warning**: нарушение инкапсуляции стора.
+
+### Bidirectional sync bounce protection
+Когда два стора синхронизируют состояние **в обоих направлениях** (Store A → Store B и Store B → Store A), как минимум одно направление ОБЯЗАНО иметь equality guard (`if (newValue !== currentValue)`) перед записью в другой стор, чтобы предотвратить бесконечный цикл callback'ов.
+
+```typescript
+// CORRECT — equality guard prevents bounce
+private onChangeEditorState(editorState: ICodeEditorState) {
+  this.setRawScript(editorState.script);
+  const codeExecutorId = this.codeExecutor?.id;
+  if (codeExecutorId && this.codeEditorStore.executorId !== codeExecutorId) {
+    this.codeEditorStore.setExecutorId(codeExecutorId);
+  }
+}
+
+// WRONG — no guard, infinite loop
+private onChangeEditorState(editorState: ICodeEditorState) {
+  this.setRawScript(editorState.script);
+  const codeExecutorId = this.codeExecutor?.id;
+  if (codeExecutorId) {
+    this.codeEditorStore.setExecutorId(codeExecutorId); // bounces back
+  }
+}
+```
+
+Флаги ревью:
+- Bidirectional store sync без equality guard — **critical**: риск бесконечного цикла callback'ов.
+- Store A пишет в Store B в callback'е от Store B без проверки `!==` — **critical**.
+
+### Truthy vs equality guards for optional values
+Для guard'ов обновления состояния предпочитай **equality comparison** (`!==`) вместо **truthy checks** (`if (value && ...)`) для optional/nullable полей. Truthy guard блокирует пропагацию легитимных `undefined`/`null`/`0`/`""` значений.
+
+```typescript
+// WRONG — truthy guard blocks clearing
+if (executor && executor.id !== this.executorId) {
+  this.setExecutorId(executor.id);
+}
+// executor = undefined → ничего не происходит → stale value
+
+// CORRECT — equality guard allows clearing
+if (executor?.id !== this.executorId) {
+  this.setExecutorId(executor?.id);
+}
+// executor = undefined → executorId = undefined → поле очищено
+```
+
+Флаги ревью:
+- Truthy guard (`if (x && x !== y)`) на optional/nullable поле — **warning**: блокирует пропагацию `undefined`/falsy clearing.
+- `if (value)` вместо `if (value !== currentValue)` в sync-логике между сторами — **warning**: потенциально блокирует clearing.
+
+### API calls placement
+- API/IO вызовы **только** в `private` методах стора.
+- `@action.bound` методы — тонкие: guard-check → делегирование в private метод.
+- Компоненты **никогда** не вызывают API напрямую.
+
+Флаги ревью:
+- API-вызов внутри `@action.bound` метода — **warning**: вынести в private метод.
+- API-вызов в компоненте — **critical**: перенести в стор.
+
+### Lifecycle initialization
+- `init()` / `onMount()` дочернего стора вызывается из **родительского стора**, не из component `useEffect`.
+- Компоненты **не должны** триггерить загрузку данных стора через `useEffect`. Родительский стор оркестрирует lifecycle дочерних сторов.
+- `dispose()` вызывается родительским стором в его `onUnmount()` для предотвращения stale-state обновлений.
+
+Флаги ревью:
+- Component `useEffect` вызывает `store.loadX()` или `store.init()` — **warning**: перенести вызов в родительский стор `onMount`.
+- Отсутствие `dispose()` / disposed guard в сторе с async операциями — **warning**.
+- Parent store не вызывает `child.dispose()` в `onUnmount()` — **warning**.
+
+### View ↔ Store boundaries
+- Бизнес-логика и IO остаются в Store/Service, не во View.
+- Компоненты, читающие observable, должны быть `observer(...)`.
+- `useEffect` не должен подменять lifecycle store-логики.
+
+### TypeScript safety
+- Не использовать `any` и небезопасные касты.
+- Использовать явные интерфейсы для state и публичного API store.
+- Избегать `!` без строгого доказательства инициализации.
+
+## Output format
+
+```markdown
+## Summary
+- [1-3 bullets по итогам]
+
+## Scope
+- Branch: `<BRANCH>`
+- Parent ref: `<PARENT>`
+- Merge-base: `<BASE_SHA>`
+- Scope mode: `<default-with-uncommitted | explicit-hash-range>`
+
+## Critical issues (must fix)
+### [Короткий заголовок]
+- **Rule**: [core/mobx-store-template.mdc / core/code-style-patterns.mdc]
+- **Why**: [почему это риск]
+- **Where**: `path/to/file.ts` (строки из diff)
+- **Fix**: [минимальное исправление]
+- **Proposed patch**:
+```diff
+[unified diff]
+```
+
+## Warnings
+[тот же формат]
+
+## Suggestions
+[точечные улучшения без расширения scope]
+
+## File-by-file notes
+- `path/to/file`: [краткие заметки]
+```
+
+## Rules of engagement
+
+- Не предлагай новые библиотеки без запроса.
+- Если есть несколько вариантов, дай один default и один краткий альтернативный.
+- Исправления предлагай как минимальные патчи, не переписывай крупные блоки без необходимости.
+
+---
+
+## Job Context Awareness
+
+When dispatched by `job-orchestrator` as part of a job pipeline, the prompt MAY include:
+
+```
+JOB_NAME:     <job-name>
+CONTEXT_PATH: .metaproject/jobs/<job-name>/ai/context.md
+```
+
+If provided and the file exists, read the context document before starting the review. Use it to:
+- Understand which libraries and patterns were intentionally chosen for the implementation
+- Validate MobX patterns against documented project conventions
+- Avoid flagging intentional architectural decisions as issues
+
+If the file does not exist or is not provided, proceed normally — context is optional and non-blocking.