# Veer Resheniy Do Chertezha

> «Разные физические конструкции», «веер решений, пять материалов», «разведи по технологиям», «не зацикливайся на носителе», «донести информацию». 5–7 концепций до чертежа.

- Skill: `kir-kopylov/veer-resheniy-do-chertezha` (Agent Skill, multi-file: 12 files)
- Install (CLI): `npx skillmds@latest add kir-kopylov/veer-resheniy-do-chertezha`
- Raw SKILL.md: https://api.skillmd.com/api/skills/kir-kopylov/veer-resheniy-do-chertezha/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: kir-kopylov (https://skillmd.com/u/kir-kopylov)
- Updated: 2026-09-21
- Page: https://skillmd.com/skills/kir-kopylov/veer-resheniy-do-chertezha

---


# Physical Solution Diversifier

## Запуск Навыка

При явном вызове или однозначном смысловом совпадении применяйте навык сразу. Перед первым шагом покажите ровно одну короткую контекстную строку (не более 30 слов) и продолжайте работу в том же ответе, не ожидая реакции:

Применяю экспериментальный навык **«Разнообразие физических решений»** (обратная связь — @kir-kopylov): <кратко назовите конкретную пользу для текущего запроса>; продолжаю без ожидания.

Не включайте в строку `author_github`, внутреннее имя папки или пересказ всего запроса. Не спрашивайте, применять ли навык.

Если одновременно подходят совместимые навыки, выберите минимальный набор и покажите одну общую строку. Если подходы ведут к несовместимым результатам и запрос не позволяет выбрать, спросите только о желаемом результате, не о разрешении применить навык.

Запуск навыка не расширяет полномочия. Выполните всю безопасную и уже разрешённую часть; запросите подтверждение только непосредственно перед ещё не разрешённым внешним или изменяющим действием. Не запрашивайте повторно уже данное разрешение и не дублируйте системное окно подтверждения.

## Обзор

Skill предотвращает две ошибки:

1. преждевременный выбор первой конструкции;
2. diversity theater — добавление слабых или экзотических вариантов только ради непохожести.

Результат по умолчанию — 5–7 концепций, которые сначала прошли feasibility gate, затем вместе покрыли достаточно разные материалы, технологии, физические поведения и взаимодействия. Каждая концепция обязана давать отдельную пользовательскую ценность. Повтор одной оси допустим, если он не создаёт дубликат механизма и явно объяснён.

## Входы

Зафиксируйте:

- `target_action`: что человек должен сделать или понять;
- аудиторию и среду применения;
- неизменяемый текст или смысл;
- размер, срок службы, частоту обновления и тираж;
- доступные технологии, ориентир бюджета и срок прототипа;
- ограничения с типом `hard`, `soft` или `unknown` и источником каждого ограничения.

`hard` — безопасность, закон, среда, совместимость и прямой запрет пользователя. Его нельзя ослаблять. `soft` — предпочтение, которое можно обсуждать. `unknown` — непроверенное условие; оно не становится фактом от уверенного текста модели.

Если без одного факта веер будет случайным, задайте один вопрос. Остальные пробелы запишите как предположения.

## Процесс

1. Прочитайте `known-exceptions.yaml` и примените совпавшее `do_next_time`.
2. Сформулируйте `target_action` и ledger ограничений: `id`, `kind`, `statement`, `source`.
3. Создайте 3–7 критериев сравнения. Обязателен `outcome_fit`; для остальных задайте вес 1–5. Все оценки трактуются в направлении «больше = лучше».
4. Откройте `references/diversity-gate.md`. Используйте раздельные словари материала, технологии, физического поведения и взаимодействия; не смешивайте материал с электронной системой или свойством.
5. Внутренне создайте 12–15 направлений.
6. Примените feasibility gate:
   - концепция с нарушенным `hard`-ограничением удаляется;
   - непроверенное `hard`-ограничение получает `unknown` и запрещает включение концепции в shortlist;
   - `soft`-компромисс остаётся видимым, а не маскируется.
7. Из оставшихся направлений соберите 5–7 концепций. Покрытие по каждой оси задаётся в `coverage_targets`; значение по умолчанию — минимум 4 разных категории на ось, если ограничения это допускают.
8. Для каждой концепции укажите:
   - название, целевое действие, пользовательскую ценность и механизм;
   - контролируемые категории материала, технологии, физического поведения и взаимодействия;
   - почему это не косметический дубль;
   - результаты проверки каждого ограничения;
   - условия применения и сложность изготовления;
   - предположение о тираже, относительную стоимость, её уверенность и драйверы стоимости;
   - риски;
   - прототипную гипотезу, наблюдаемый сигнал и условие провала;
   - оценки по всем критериям с доказательством и уровнем уверенности.
9. Проведите обязательную смысловую проверку по `references/diversity-gate.md`. Скрипт не заменяет её.
10. Постройте матрицу покрытия и сравнительную матрицу: `score`, `confidence`, `evidence` по каждому критерию.
11. Удалите решения, доминируемые другим feasible-решением по всем критериям. Верните 2–3 недоминируемых направления, причину выбора и следующий дешёвый тест.
12. Остановитесь до чертежа, закупки или изготовления. Продолжайте после выбора направления пользователем.

## Автоматическая Проверка

Соберите рабочую карточку в JSON по схеме из `references/diversity-gate.md` и запустите:

```bash
python3 scripts/validate_concept_fan.py concept-fan.json
```

Структурный `PASS` означает только следующее: количество равно 5–7, типы полей корректны, категории известны, coverage targets достигнуты, ограничения и критерии покрыты, shortlist feasible и не содержит явно доминируемых вариантов.

`PASS` не доказывает инженерную реализуемость или смысловую новизну. До завершения обязательна отдельная `semantic_review` со статусом `pass`, проверенными осями и заметками. Если Python недоступен, выполните все структурные и смысловые пункты вручную и обозначьте это как `Проверка: ручная`.

## Diversity И Feasibility Gates

1. Сначала пригодность, затем разнообразие.
2. Веер содержит 5–7 концепций.
3. Default coverage — минимум 4 категории материала, технологии, поведения и взаимодействия; цель можно снизить только из-за явных ограничений и с объяснением.
4. Не требуется уникальность каждой оси у каждой концепции. Требуется уникальная совокупность механизма и ценности.
5. Повтор категории сопровождается `difference_rationale`.
6. Цвет, стиль, размер или переименование не создают новую концепцию.
7. `hard`-ограничение никогда не предлагается ослабить.
8. Неизвестная безопасность, совместимость или нормативное соответствие запрещают shortlist до проверки.
9. Точная стоимость, наличие, сертификация и физическая надёжность не объявляются фактами без текущего доказательства.

## Convergence Gate

Shortlist допустим, только если:

- все `hard`-ограничения имеют `pass`;
- нет другого feasible-решения с не меньшей оценкой по всем критериям и большей хотя бы по одному;
- включено хотя бы одно направление с максимальным weighted score по заданным весам;
- причина выбора опирается на `evidence` и показывает trade-off;
- относительная стоимость привязана к предположению о тираже и драйверам затрат;
- для направления определён следующий тест и условие отказа.

Низкая уверенность не скрывается итоговым баллом. Если данных недостаточно, shortlist становится гипотезой для прототипа, а не рекомендацией к производству.

## Eval Gate

Текущий статус skill — `experimental`. Перед повышением до `team-ready` выполните независимую оценку по `references/eval-rubric.md`: минимум 10 разных запросов, два оценщика, ноль нарушений `hard`-ограничений, ноль доминируемых shortlist-вариантов и заданные пороги по дублям, полноте и полезности.

Зелёный repo CI проверяет структуру и регрессии, но не доказывает качество решений модели.

## Границы

Используйте skill до выбора конструкции: для широкого поиска, feasibility-фильтра и проверяемого сравнения направлений.

Не используйте его:

- когда конструкция уже выбрана и нужны чертёж, развёртка, макет или файл для печати;
- для цветовых, композиционных или стилистических вариантов одного объекта;
- вместо инженерного расчёта, сертификации или проверки безопасности;
- для поиска живых цен и наличия материалов;
- когда пользователь прямо просит реализовать один конкретный вариант без дивергенции.

## Опрос После Использования

Опрос задаётся один раз — после выдачи веера и shortlist либо после честного стопа, не посреди рабочего цикла. Если пользователь уже ответил «пропустить» в этой сессии, не переспрашивайте.

```text
Опрос по skill:
1. Что в этом использовании veer-resheniy-do-chertezha было полезно?
2. Что стоит доработать в skill или его формате?
Можно ответить коротко или написать "пропустить".
```

Если пользователь ответил, сохраните санированную карточку в `~/.codex/skill-runs/veer-resheniy-do-chertezha/usage-feedback.jsonl` — лучше через bundled script:

```bash
python3 scripts/log_usage_feedback.py --liked "..." --improve "..." --outcome "..."
```

Script перед записью редактирует приватные пути, контакты и token-like строки и сохраняет в JSONL `redaction_applied` и `redaction_types`. Если запись невозможна из-за sandbox, прав или отсутствия tools, не делайте вид, что лог сохранён: скажите об этом и покажите короткую JSONL-карточку для ручного сохранения. Raw-ответы, контакты, пути и секреты не коммитить.

## Логирование Сбоев

Перед выполнением прочитайте локальный `known-exceptions.yaml` как список уже известных случаев и применяйте подходящее `do_next_time` без нового поиска.

Если пользователь поправил skill, tool/API/browser упал, нарушен режим работы, пришлось искать workaround или skill сделал ложное предположение, запишите приватную карточку в `~/.codex/skill-runs/veer-resheniy-do-chertezha/exception-log.jsonl`.

Пишите факты: что skill хотел сделать, что сделал, где сломался, какая предпосылка была ложной и что сделать в следующий раз. Если поле неизвестно, пишите `unknown`. Raw logs не коммитить.

## Definition Of Done

Работа завершена, когда:

- цель, контекст, тираж, бюджетные предположения и ограничения зафиксированы;
- все `hard`-ограничения проверены или честно отмечены `unknown`;
- есть 5–7 feasible-концепций с достигнутым coverage target;
- структурный валидатор и обязательная смысловая проверка дали `pass`;
- оценки содержат доказательства и уверенность;
- shortlist состоит из 2–3 feasible и недоминируемых направлений;
- для каждого финалиста есть следующий тест и условие провала;
- факты отделены от предположений;
- работа остановлена до изготовления и выбора пользователя.