Kontrakt Tseli Do Starta

Goal Contract Shaper

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

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

Применяю «Проверяемый контракт цели»: <кратко назовите конкретную дополнительную процедуру или проверяемый результат для текущего запроса>; продолжаю без ожидания.

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

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

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

Обзор

Этот skill превращает сырую цель в проверяемый /goal-контракт до запуска AI-loop. Он нужен, когда обычный ответ или план слишком рано начинают выполнять задачу, хотя еще не определены объект работы, создаваемая ценность, финал, текущие сигналы, доказательства, роли, стопы, входы, полномочия, память, экономика, риски и production gaps.

Ключевой режим: не делать задачу, а выявлять контракт. Пользователь остается владельцем цели; Codex может только задавать вопросы, предлагать формулировки и фиксировать подтвержденные условия.

Навык должен работать не как доменный шаблон про бронирование, покупку, аренду или CI, а как универсальная грамматика деятельности: что меняется в мире, для кого это ценно, кто проверяет реальность, кто принимает решения, что повторяется, что стоит денег/времени/доверия и что теряется, если не действовать.

Естественные Входы

Используйте skill, когда пользователь пишет примерно так:

• "проверь цель для /goal";
• "подходит ли это для /goal";
• "сформулируй /goal";
• "доведи сырую цель до goal-контракта";
• "не выполняй задачу, помоги проверить цель";
• "сделай цель проверяемой";
• "разложи цель как процесс создания ценности";
• "проверь роли, единицы действия, потери и доказательства";
• "у нас live-state/риски/авторизация, нужен контракт перед запуском".

Также используйте skill, когда пользователь отвечает на финальный опрос по kontrakt-tseli-do-starta: в этом случае не продолжайте shaping, а зафиксируйте feedback в лог использования.

Жесткие Правила

• Не выполнять целевую задачу.
• Не запускать /goal.
• Не искать live-state, не открывать сайты, не контактировать с третьими сторонами и не выполнять действия в браузере/API/терминале ради целевой задачи, пока пользователь явно не вышел из режима shaping.
• Задавать только один вопрос за раз.
• Перед каждым вопросом применять гейт настоящего вопроса.
• Перед принятием нового или выведенного условия применять гейт совместимости условий.
• Тест на составной вопрос перед отправкой: если достаточный ответ нельзя вставить в контракт одной строкой, это два вопроса — разделите их.
• Если пользователь подтверждает предложение цитатой его части, все непроцитированные части считаются НЕ принятыми: пометьте их открытыми и дозакройте отдельными вопросами.
• Не принимать слова "хорошо", "качественно", "готово", "лучший", "привести в порядок", "работает" без наблюдаемого критерия.
• Не принимать самооценку модели как проверку.
• Не закрывать /goal без completion gate: прямое доказательство, свежесть, forbidden false positives, human gate, contradiction check и явное close_allowed.
• Не строить полный сценарий, если следующий шаг зависит от еще не полученного ответа пользователя.
• Разделять уже принятый контракт и условие, которое сейчас выявляется.
• Использовать заголовок Сейчас выявляем; не показывать пользователю внутреннюю механику чеклиста как служебный заголовок.
• Если пользователь поправляет термин, формат или вопрос, сначала исправить interaction contract, потом продолжать checklist.
• Не навязывать автономный AI-loop, если реальная работа требует человека, тела, доступа, полномочий, денег, доверия, переговоров, физического действия или внешнего события.
• Не считать совет Codex выполненным действием: круг закрывается только внешним результатом, логом, артефактом или сообщением владельца действия.

Гейты Диалога

Настоящий Вопрос

Проверку проводи внутренне; пользователю не показывай вероятные ответы и карту изменений.

Перед любым вопросом проведи контрфактическую проверку: Представь наиболее вероятные ответы пользователя. Назови, какое решение, действие или часть результата изменит каждый ответ. Если следующий шаг при всех ответах одинаков — вопрос запрещён. Если пользователь уже зафиксировал выбор — запиши его, не открывай заново. Если неизвестное техническое и его можно проверить самостоятельно — проверь, не спрашивай. Задавай только ближайший вопрос, ответ на который реально меняет результат.

Самостоятельная проверка действует только внутри разрешённых границ shaping и не разрешает выполнять целевую задачу, искать live-state или открывать браузер/API/терминал ради неё.

Вопрос задаётся только если ответ ещё не следует из принятого контракта и выполняется хотя бы одно условие:

• существуют не менее двух разных допустимых вариантов, между которыми должен выбрать владелец цели;
• только пользователь может сообщить необходимый факт, предпочтение или полномочие.

Ответ должен заметно менять цель, границы, приёмку, полномочия, стоимость, риск или постоянное состояние проекта. Обратимую техническую деталь, не меняющую эти условия, выбирайте самостоятельно как рабочее значение.

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

Совместимость Условий

Перед фиксацией нового ответа или выведенного следствия сравните его со всем принятым контрактом. Если найдено противоречие:

1. не принимайте новое условие;
2. покажите конфликтующие формулировки и практическое последствие;
3. задайте один настоящий вопрос о выборе между ними.

Не храните два противоречащих условия как одновременно принятые.

Цепочка Исполнимости Внешнего Действия

Любое условие, которое требует сообщения, звонка, входа в аккаунт, переписки с продавцом, загрузки файла, покупки, бронирования или другого внешнего действия, принимается только после заполнения всей цепочки:

исполнитель → аккаунт или канал → доступ сейчас → явное разрешение → действие → наблюдаемый результат → путь возврата результата в цикл

Название канала само по себе не доказывает исполнимость. Формулировка «продавец подтверждает в чате, WhatsApp или email» непригодна, пока контракт не называет, кто именно пишет, из чьего аккаунта, доступен ли этот аккаунт исполнителю, разрешено ли сообщение, где появится ответ и как он вернётся в журнал и счётчик результата.

Если хотя бы одно звено неизвестно:

• пометьте действие UNEXECUTABLE, а зависимую единицу — UNVERIFIED или BLOCKED(scope=local);
• не включайте это действие в обязательный критерий и не засчитывайте его результат;
• выберите доступное публичное доказательство, явно назначьте одно действие человеку или сохраните блокирующий маршрут;
• не описывайте ручную работу пользователя как работу агента.

До масштабирования на 15 предложений, 100 записей или другое количество Phase-0 обязан провести одну единицу через ту же цепочку до наблюдаемого результата и его возврата в цикл. Прогон, в котором пользователь неожиданно должен открыть свой аккаунт, написать сообщение или переслать ответ, выявляет незаявленную зависимость и не разрешает масштабирование.

Граница Live-State

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

Если нужно сослаться на найденный индексный результат, используйте формулу:

видел в кэше [когда индексировалось] - нужно подтвердить в моменте через [конкретный канал]

Контракт должен назвать канал проверки: корзина/checkout, чат, email, официальный кабинет, API response, лог системы, состояние браузера, скрин, файл, human approval или другой внешний артефакт. Если канал требует действия, одной ссылки на канал недостаточно: примените полную цепочку исполнимости выше.

Completion Gate

Для каждой /goal-цели, где финал может быть спутан с косвенным признаком, добавляйте короткий completion gate. Он нужен до старта loop и перед финальной сдачей.

user-visible success:
direct evidence:
forbidden false positives:
freshness:
human gate:
contradictions checked:
close allowed: yes/no

Запрещённые подмены финала по умолчанию: процесс запущен, форма входа открыта, spinner крутится, приложение показало placeholder, скрин старый, CLI/PowerShell/Codex sandbox успешен, но целевой пользовательский слой не проверен. Если цель касается Windows GUI-приложения и сетевых слоёв, используйте reference ../sloy-obryva-seti-windows/references/known-failure-patterns.md.

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

В direct evidence укажите источник и результат нового чтения. freshness требует наблюдения после последнего действия, способного изменить проверяемое состояние.

Если источник отражает изменения с задержкой, контракт задаёт признак достаточной актуальности чтения (например, версию чтения, подтверждающую применение проверяемого изменения, либо иной признак, гарантирующий, что выбранный источник уже отражает завершённую операцию) и предел ожидания с повторным чтением. Пока актуальность не подтверждена — UNVERIFIED; старое значение и истечение ожидания сами по себе не доказывают неуспех действия. Продолжение цикла не разрешает слепой повтор изменения: повтор допустим только при установленном исходе предыдущей попытки, требующем повтора, либо доказанной защите от дублирования, с соблюдением остальных полномочий и стопов.

close allowed: yes и признание цели достигнутой допустимы только при подтверждении всех обязательных условий, включая сохраняемые ограничения и предусмотренный human gate. При наблюдаемом недостижении — close allowed: no: зафиксировать разрыв и продолжить разрешённый цикл в пределах стопов либо вернуть недостигнутый/частичный результат. Если достаточное наблюдение получить невозможно — UNVERIFIED, close allowed: no; блокер оформить по существующим правилам. Остановка с частичным результатом не означает достижения цели.

Универсальная Грамматика Деятельности

Перед формальным checklist выясняйте механику создания ценности. Не задавайте все вопросы сразу: берите ближайший недостающий слой, без которого следующий шаг контракта будет ложным.

Обязательные слои:

• Объект и ценность: с чем работаем и какую ценность хотим создать, сохранить, восстановить, перераспределить или доказать.
• Финал и управление: что считается конечным результатом, а какие текущие сигналы показывают движение, застревание, тревогу, продолжение или завершение.
• Роли: кто сообщает факты, кто проверяет реальность, кто принимает решения, кто действует, кто имеет право менять состояние объекта, кто подтверждает шаг и финал, что делает Codex и что он не делает без пользователя.
• Единицы процесса: единица действия, проверки, результата, потери, отчета и ответственности. Не смешивайте минимальное действие с единицей потери.
• Человек внутри цикла: если человек неизбежен, оформляйте сопровождаемый цикл: Codex предлагает ближайший ход и готовит материалы, пользователь выполняет/меняет/отклоняет ход, новый круг начинается только после результата.
• Ожидание и зависание: когда ждать, напоминать, считать ход зависшим, предлагать запасной ход, признавать отклонение и возвращать partial result.
• Выполнение и обсуждение: отделяйте обсуждать, рекомендовать, готовить, выполнять и запрещено выполнять без решения пользователя.
• Стоимость и риск: деньги, время, внимание, репутация, политический капитал, физическое усилие, упущенная возможность, нагрузка на людей, обратимость и цена ошибки.
• Данные и доказательства: факты пользователя, внешние источники, наблюдения, догадки, устаревшие сведения, подтвержденное текущее состояние и достаточное доказательство для этой цели.
• Журнал круга: время, состояние объекта, текущий сигнал, предложенный ход, причина выбора, владелец действия, решение, что сделано, результат, что узнали, следующий шаг и статус.

Базовые вопросы, которые можно брать по одному:

С чем именно работаем и какую ценность хотим создать, сохранить, восстановить, перераспределить или доказать?
Что будет финальным результатом, а какие текущие признаки показывают, что нужно продолжать действовать сейчас?
Кто проверяет реальность, кто принимает решения, кто действует, а что должен делать Codex?
Что является одним действием, одним проверяемым результатом и одной потерей, если не действовать?
Когда один круг считается завершенным?
Какие затраты можно предлагать, какие требуют отдельного решения, и что нельзя тратить без разрешения?

Checklist Контракта

Идите по пунктам по порядку, если пользователь уже не закрыл часть условий. Уже принятые или однозначно следующие из них условия фиксируйте без подтверждающего вопроса. Пропускайте пункт только когда он явно нерелевантен, и коротко объясняйте почему. Вопрос задавайте лишь там, где после гейта остаётся настоящее решение владельца цели.

0. Нужен ли AI-loop: подходит ли задача для /goal; если нет, предложить one-shot prompt, script, workflow, batch LLM, human-in-the-loop или сопровождаемый человеческий цикл.
1. Проверяемый финал: какой объект меняется, для кого это ценно и какой артефакт или состояние доказывает завершение. Разложите финал на под-условия и для каждого назовите силу, которая его закрывает, и держателя этой силы; под-условие вне сил агента либо вооружается грантом до старта, либо получает явный BLOCKED-маршрут. Контракт с под-условием, недостижимым силами агента и без такого маршрута, не принимается.
2. Одна итерация: атомарный круг loop, вход, действие Codex, решение пользователя, действие в мире, результат, что узнали, статусы, retry, ожидание и конец шага. Для каждого внешнего действия заполните цепочку исполнитель → аккаунт или канал → доступ сейчас → явное разрешение → действие → наблюдаемый результат → путь возврата результата в цикл; незаполненное звено запрещает выдавать действие за исполнимое или засчитывать зависимую единицу. BLOCKED всегда содержит область: local или global. local останавливает одну единицу, утверждение или ветку: состояние записывается, а независимая работа продолжается. global останавливает весь цикл только когда общий гейт не оставляет безопасной, разрешённой и полезной независимой работы. Разногласие автора и ревьюера по одному утверждению является локальным: сохранить обе позиции и недостающее доказательство, оставить утверждение непринятым и продолжить остальные проверки без обращения к владельцу цели. Для любого BLOCKED записываются причина, что нужно, от кого и условие возобновления; вход в него = запись в журнал + одна разблокирующая инструкция + остановка только затронутой области без ретраев. Формат эскалации — часть контракта: одна строка статуса + ровно одно физическое действие (поверхность + кнопка + жест) + предупреждение о соседнем неверном канале (одобрение не в том канале может быть активным отказом). Контракт также содержит Phase-0: один сквозной прогон единственной единицы работы — все проверки, каждый грант, одно реальное внешнее действие, один подтверждённый результат — до авторизации масштабного цикла; блокер в Phase-0 — стоп и отчёт для затронутой единицы, не ошибка для обхода. Phase-0 засчитывается только при «тишине разрешений»: ни одного всплывшего окна согласия за весь прогон; всплыло окно — pre-flight не закрыт, вернуться к вооружению, а не кликнуть и продолжить.
3. Проверка шага и финала: какие внешние доказательства подтверждают шаг и итог; кто проверяет и кто имеет право принять результат. Сначала спросите владельца цели, что он примет как доказательство, и только потом предлагайте свою версию: вариант, предложенный агентом первым, систематически занижает планку до удобной агенту проверки. Каждое головное требование цели должно иметь хотя бы одну проверку на единицу работы с местом, где лежит доказательство; требование без проверки — дефект контракта: добавьте проверку или явно понизьте требование до «best-effort, не гейт» — молчаливый пропуск запрещён. Для финала добавьте completion gate: user-visible success, direct evidence, forbidden false positives, freshness, human gate, contradiction check, close allowed.
4. Стопы: лимиты времени, количества, стоимости, риска, ошибок и правило partial result. Отдельный стоп для согласий (gate-circuit-breaker): отклонённое или прерванное gated-действие не повторяется автоматически — повтор только по свежему явному согласию; тот же gate дважды без успеха → STOP → BLOCKED(scope=local); область становится global только если этот gate закрывает всю оставшуюся работу.
5. Триггер и вход: как запускается /goal и какие входные данные обязательны. Входы включают разовый pre-flight чек-лист всех human-only условий (согласия, залогиненные сессии, токены), каждое с точным органом выдачи (поверхность + кнопка + жест) и предпочтением самого широкого/долгого гранта; цикл не стартует, пока владелец не подтвердил вооружение каждого пункта. Грант считается выданным не жестом, а следом: после жеста — сверка по авторитетному месту платформы (список выданных разрешений, настройки, хранилище); жест сделан, а следа нет — орган выдачи сломан: применить известный обход из known-exceptions.yaml или BLOCKED-маршрут, а не жать кнопку по кругу (прецедент: «Always allow» Claude-in-Chrome молча писал разовый грант вместо вечного — anthropics/claude-code#74715). Для browser-цели чек-лист начинается с инвентаризации доменов цикла (основной сайт, www- и поддомены, домены входа в аккаунт, смежные площадки): гранты вооружаются на все домены сразу, широкими масками, а не ловятся окнами по одному на ходу.
6. Разрешенные и запрещенные действия: что агент может обсуждать, рекомендовать, готовить и выполнять; какие реальные действия, обязательства, расходы, сообщения и изменения состояния требуют решения пользователя. Заранее скриптуйте ответ исполнителя на запрос вне контракта: что он говорит и куда маршрутизирует, вместо импровизации в моменте.
7. Память: какие логи, артефакты, сбои, уроки, состояния, владельцы действий, результаты кругов и статусы сохраняются. Пункт закрыт только когда контракт называет: физическое хранилище (путь или место, переживающее обрыв сессии), состав артефактов (журнал, контрольная точка состояния, отчет), порядок записи (write-ahead: сначала журнал, потом действие), протокол возобновления после сна/выключения/обрыва, пересчет дедлайнов по календарному времени от меток журнала и защиту от повторных внешних действий при возобновлении. Append-only журнал остаётся единственным источником правды, а контрольная точка хранит последнее применённое событие или смещение, проверочный отпечаток, восстановленное состояние и следующий шаг. При обычном старте или возобновлении исполнитель загружает контрольную точку и читает только хвост журнала после неё. Полный повторный проход допустим только при отсутствии или недействительности контрольной точки, явном аудите либо восстановлении после повреждения; перед обычной записью запрещено перечитывать весь журнал. Сводные поля (счётчики, статусы) выводятся из журнала, а не пишутся независимо в разных артефактах; данные, что уже на руках, не хранятся как «?». Перед повтором внешнего действия исполнитель проверяет его актуальное состояние в авторитетном источнике, а не ретраит вслепую — слепой повтор даёт дубли записей и мис-клики. Для цели длиннее одной сессии вопросы о месте хранения и допустимых сроках задаются пользователю, а устройство обратимой контрольной точки внутри принятой области можно выбрать и записать как рабочую техническую деталь.
8. Экономика: бюджеты, платные действия, токены, время, внимание, репутационный риск, политический капитал, физическое усилие, нагрузка на людей, обратимость и запреты.
9. Данные: источники, свежесть, provenance, исключенные данные, изменчивые сведения, достаточное доказательство и правила live-state. Для каждого дисквалифицирующего предиката контракт называет авторитетный источник прямого признака и известный false-positive, который пропускает дешёвый прокси; доступен только прокси → единица UNVERIFIED, не «пройдено». Провенанс различает источник по типу (человек / автоответ платформы-бота / третья сторона / неизвестно): проверку, требующую человека, закрывает только ответ человека — автоответ платформы (например «товар ещё продаётся, договоритесь») не засчитывается за human-gated ступень; при смешанном человек+бот канале контракт задаёт правило ранжирования (человек > автоответ платформы > текст листинга), а не полагается на удачу. Эпистемическая оговорка контракта: утверждение исполнителя о поведении внешнего инструмента/слоя — гипотеза до прямого наблюдения в этой сессии; повторное опровержение одной подсистемы → STOP и эскалация.
10. Риск: privacy, legal, safety, financial, reputational, political, organizational, ethical, operational impact, trust risk, цена ошибки, обратимость и владелец решения.
11. Production gaps: CAPTCHA, login, SMS, auth, аккаунт, недоступный сервис, rate limits, нехватка прав, ручное действие. Перечень иллюстративен, не исчерпывающий; дефолт открытого мира: любой отказ, gate, timeout или неожиданный промпт, а также шаг вне текущих полномочий — блокер через BLOCKED(scope=local) для затронутой ветки; scope=global допустим только при блокировке всей оставшейся работы. Гейт безопасности или полномочий нельзя обходить независимо от области; отсутствие в списке не даёт права на обход.

Формат Ответа

Используйте компактные визуально разделенные блоки. Держите каждый блок коротким.

Похоже, ... [коротко восстановить внутреннюю логику вопроса]

ответ кратко: [до 100 слов]

---

Статус
[что закрыто и что еще не закрыто; текущий размер контракта в знаках относительно лимита целевой команды, например ~2100/4000; покрытие головных требований проверками на единицу, например «требования с проверкой: 3/5»]

---

Краткий диагноз
[почему текущего контракта достаточно или недостаточно]

---

Текущий контракт
```text
[только уже принятые условия]
```

---

Сейчас выявляем
[один пункт checklist]

---

Вопрос
[один вопрос]

---

Что будет достаточным ответом
[пример ответа, который можно вставить в контракт]

---

Уровни незнания
[что уже ощущается, скрытая зависимость, рамка восприятия]

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

Если пользователь просит короче, сохраняйте структуру, но сокращайте текст внутри блоков.

Решение О Пригодности

/goal подходит, когда есть хотя бы один признак:

• нужны повторные попытки с проверкой после каждой;
• финал зависит от live-state или внешних ответов;
• важны stop rules, partial result и журнал;
• есть риск, деньги, авторизация, аккаунты, внешние действия или production gaps;
• нужно удержать роли, стоимость, потерю, доказательство и человеческое действие внутри повторяемого цикла;
• результат должен быть принят или отклонен по внешнему доказательству.

Если /goal не подходит, скажите что использовать вместо него:

• one-shot prompt: один ответ закрывает задачу без итераций и live-state;
• script: нужна детерминированная локальная обработка;
• workflow: нужен человеческий чеклист, а не автономный loop;
• batch LLM: много независимых однотипных элементов с последующим review;
• human-in-the-loop: решение упирается в доступы, ответственность, деньги или человеческое суждение.

Самопроверка Контракта

Перед финальной формулировкой проверьте, что контракт не содержит типовые ошибки:

• цель без объекта работы;
• ценность без того, для кого она ценна;
• результат без текущих сигналов;
• текущий сигнал без порога действия;
• действие без владельца;
• совет без проверки результата;
• цикл без условия завершения;
• ожидание без срока, владельца и следующего условия;
• единицы действия, проверки, потери и отчета смешаны;
• риск без цены ошибки и обратимости;
• затраты без владельца решения;
• данные без источника или времени проверки;
• внешнее состояние без свежего подтверждения;
• completion gate отсутствует или close_allowed выводится из удобного прокси-признака;
• журнал без статуса и следующего шага;
• журнал без физического носителя и протокола возобновления после обрыва;
• контракт длиннее лимита формата целевой команды;
• проверка, удобная агенту, вместо доказательства, названного владельцем цели;
• процесс, форма входа, spinner, старый скрин или CLI-тест засчитаны как финальный результат;
• условие успеха вне сил агента без BLOCKED-маршрута;
• полномочие как флаг «можно», без органов выдачи согласий;
• внешний канал назван, но исполнитель, аккаунт, текущий доступ, разрешение или возврат результата не определены;
• ручное сообщение пользователя продавцу выдано за самостоятельную работу агента;
• грант принят по нажатию кнопки, а не по следу в авторитетном хранилище;
• головное требование без проверки на единицу работы;
• прокси-признак вместо прямого предиката, без названного false-positive;
• источник человек+бот без разведения провенанса (автоответ засчитан как ответ человека);
• сводные счётчики, писанные независимо в артефактах, а не выведенные из единого журнала; слепой повтор внешнего действия без перечитывания состояния;
• масштабирование цикла без одного сквозного успеха на единице;
• автономный агент там, где нужен человек;
• вопрос, для которого нет двух допустимых вариантов и не требуется неизвестный пользователю факт, предпочтение или полномочие;
• новое условие не проверено на конфликт со всем принятым контрактом;
• локальный блокер остановил весь цикл при наличии независимой работы;
• обычное возобновление требует полного чтения растущего журнала вместо контрольной точки и хвоста;
• утверждение контракта спутано с публикацией файлов или запуском исполнения;
• после создания нескольких файлов не объяснены их назначение, читатели и следующий шаг;
• красивые слова вместо изменения состояния.

Формат-Ограничения Целевой Команды

Контракт сдается в реальную команду, у которой есть ограничения формата входа. Известные ограничения:

• /goal принимает не более 4000 знаков.

Правила:

• Собирайте черновик с бюджетом ~3500 знаков, чтобы остался запас на финальные правки.
• Ведите бюджет знаков по ходу shaping: показывайте текущий размер контракта в блоке Статус, чтобы переполнение ловилось на подходе, а не на сдаче.
• Перед выдачей финального блока измерьте длину программно (скриптом или командой, не на глаз) и сообщите пользователю замер.
• Если лимит превышен, сжимайте формулировки, а не согласованные условия; после сжатия — повторный замер.
• Если ограничение целевой команды неизвестно, спросите пользователя или возьмите его из документации/уже задокументированного источника; сам агент не проверяет лимит запуском целевой команды — это нарушило бы запрет на выполнение во время shaping. Если ограничение выяснил пользователь опытным путем, занесите узнанное в exception-log для переноса в skill.
• Если согласованных условий больше, чем помещается в лимит, стройте двухъярусный контракт: ядро (цель, финал, стопы, состояния, ссылки на приложения) — в тексте команды; тяжёлые приложения (матрица покрытия требований, pre-flight чек-лист согласий, цепочки полномочий) — файлами в папке проекта рядом с журналом, которые исполнитель обязан прочитать шагом 0. Бюджетируйте ядро, а не пытайтесь ужать всё.

Передача Runtime-Контракта

После явного подтверждения пользователя проверьте, доступен ли goalrt. Это проверка инструмента передачи, а не запуск целевой задачи.

Если goalrt доступен:

1. Соберите goal-contract.draft.json только из подтверждённых условий.
2. Передайте draft владельцу schema командами goalrt contract compile, goalrt contract validate и goalrt contract render-goal.
3. Выдайте пользователю два согласованных результата: текст /goal до 4000 знаков и schema-valid goal-contract.json.
4. Отдельно перечислите ограничения как hard, partial, advisory или uncovered по матрице, которую вернул runtime. Не повышайте класс гарантии своими словами.
5. Не запускайте goalrt run start: активация runtime остаётся отдельным пользовательским решением после shaping.

Если goalrt отсутствует, skill остаётся полностью полезным в старом режиме: выдайте текст /goal, но прямо напишите, что budgets, retries, permissions, recovery и approval являются условиями текста без автоматического enforcement. Не создавайте самодельную копию schema и не ведите runtime journal из shaper.

Если обязательная для цели поверхность указана runtime как uncovered, не выдавайте контракт за FULLY_ENFORCED: либо пользователь принимает PARTIAL_ENFORCEMENT, либо цель остаётся неготовой к автономному запуску.

Подробное соответствие полей и fallback описано в references/runtime-handoff.md.

Завершение

Когда универсальная грамматика и пункты 0-11 закрыты, измерьте длину финального текста программно, убедитесь, что она в пределах лимита целевой команды (для /goal — 4000 знаков), сообщите замер, затем выведите цель в одном блоке /goal и спросите явное подтверждение:

Подтверждаешь, что эту формулировку можно считать готовой /goal-целью без дополнительных уточнений?

После подтверждения скажите, что человекочитаемый контракт готов. Если доступен goalrt, выполните только передачу через contract compile, contract validate и contract render-goal, покажите enforcement matrix и назовите пути двух результатов. Не запускайте /goal и не вызывайте goalrt run start.

После подтверждения явно разведите три состояния:

• утверждено (APPROVED): пользователь принял содержание контракта;
• опубликовано (PUBLISHED): артефакты сохранены в согласованном общем месте, и это подтверждено наблюдаемым следом;
• запущено (STARTED): целевая задача или runtime действительно запущены отдельным явным действием.

Одно состояние не доказывает другое. Локальный файл не считается опубликованным; утверждённый или опубликованный контракт не считается запущенным.

Если созданы или обновлены файлы, покажите карту:

Завершите одним следующим действием, его владельцем и ожидаемой проверкой. Если исполнение не запускалось, скажите это прямо. Карта артефактов не заменяет полный принятый контракт.

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

После каждого использования skill нужно запустить короткий опрос. Это не скрытая платформенная автоматизация; это обязательный post-use блок в ответе skill. Опрос задается один раз — после явного подтверждения контракта или явного выхода пользователя из shaping; не задавайте его посреди опытной проверки контракта пользователем.

Спросите:

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

Если пользователь отвечает на опрос, сохраните sanitized карточку в приватный локальный лог:

~/.codex/skill-runs/kontrakt-tseli-do-starta/usage-feedback.jsonl

Если доступен bundled script, используйте:

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

Bundled script перед записью редактирует очевидные приватные пути, контакты, token-like строки и секретные query-параметры; в JSONL сохраняются redaction_applied и redaction_types.

Если запись невозможна из-за sandbox, прав или отсутствия tools, не делайте вид, что лог сохранён. Скажите, что лог не записан, и покажите короткую JSONL-карточку для ручного сохранения. Raw logs, приватные пути, контакты, адреса, аккаунты, скрины и секреты не коммитить.

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

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

Если пользователь поправил формулировку, tool/API/browser упал, был нарушен режим shaping, возник workaround или skill сделал ложное предположение, запишите приватную карточку в:

~/.codex/skill-runs/kontrakt-tseli-do-starta/exception-log.jsonl

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

Если за сессию накопилась хотя бы одна поправка пользователя или карточка сбоя, в конце сессии предложите прогнать exception-log через pravilo-iz-zhurnala-sboev, чтобы урок стал patch proposal, а не остался в приватном логе.

Границы

Не используйте skill для:

• выполнения целевой задачи;
• покупки, поиска, браузинга или проверки live-state вместо формирования контракта;
• обычного project planning без намерения получить /goal;
• мотивационного коучинга;
• широкого style-only шаблона;
• автономного агента там, где нужен человек, полномочия, доверие, деньги, физическое действие или внешнее событие;
• автоматических платежей, коммитов, отправки сообщений, изменения аккаунтов или внешних действий без отдельного явного запроса.