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 и запустите:

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 либо после честного стопа, не посреди рабочего цикла. Если пользователь уже ответил «пропустить» в этой сессии, не переспрашивайте.

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

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

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 и недоминируемых направлений;
• для каждого финалиста есть следующий тест и условие провала;
• факты отделены от предположений;
• работа остановлена до изготовления и выбора пользователя.