# Goal Contract Shaper V3 > v3 kontrakt-tseli-do-starta, только явно: «подходит ли сырая цель для /goal», «сформулируй проверяемый /goal-контракт», «completion gate»; роли, единицы, потери, ценность. - Skill: `kir-kopylov/goal-contract-shaper-v3` (Agent Skill, multi-file: 11 files) - Install (CLI): `npx skillmds@latest add kir-kopylov/goal-contract-shaper-v3` - Raw SKILL.md: https://api.skillmd.com/api/skills/kir-kopylov/goal-contract-shaper-v3/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/goal-contract-shaper-v3 --- # Goal Contract Shaper v3 (экспериментальная) > Это независимая v3-версия для сравнительного тестирования. Отличия от базовой версии перечислены в `skill.yaml` (`changes_from_base`) и вплетены в текст ниже пометками **[v3]**. Вызывать явно (`/goal-contract-shaper-v3`), чтобы не смешивать с plugin-версией. ## Запуск Навыка Этот экспериментальный навык запускайте только при явном вызове `goal-contract-shaper-v3`. Смысловой запрос без прямого вызова маршрутизируйте в базовый `kontrakt-tseli-do-starta`; не запускайте v3 и не спрашивайте о его применении. При явном вызове перед первым шагом покажите ровно одну короткую контекстную строку (не более 30 слов) и продолжайте работу в том же ответе, не ожидая реакции: Применяю экспериментальный навык **«Усиленная проверка контракта цели»** (обратная связь — @kir-kopylov): <кратко назовите конкретную пользу для текущего запроса>; продолжаю без ожидания. Не включайте в строку `author_github`, внутреннее имя папки или пересказ всего запроса. Не спрашивайте, применять ли навык. Если одновременно подходят совместимые навыки, выберите минимальный набор и покажите одну общую строку. Если подходы ведут к несовместимым результатам и запрос не позволяет выбрать, спросите только о желаемом результате, не о разрешении применить навык. Запуск навыка не расширяет полномочия. Выполните всю безопасную и уже разрешённую часть; запросите подтверждение только непосредственно перед ещё не разрешённым внешним или изменяющим действием. Не запрашивайте повторно уже данное разрешение и не дублируйте системное окно подтверждения. ## Обзор Этот skill превращает сырую цель в проверяемый `/goal`-контракт до запуска AI-loop. Он нужен, когда обычный ответ или план слишком рано начинают выполнять задачу, хотя еще не определены объект работы, создаваемая ценность, финал, текущие сигналы, доказательства, роли, стопы, входы, полномочия, память, экономика, риски и production gaps. Ключевой режим: не делать задачу, а выявлять контракт. Пользователь остается владельцем цели; Codex может только задавать вопросы, предлагать формулировки и фиксировать подтвержденные условия. Навык должен работать не как доменный шаблон про бронирование, покупку, аренду или CI, а как универсальная грамматика деятельности: что меняется в мире, для кого это ценно, кто проверяет реальность, кто принимает решения, что повторяется, что стоит денег/времени/доверия и что теряется, если не действовать. ## Естественные Входы Используйте skill, когда пользователь пишет примерно так: - "проверь цель для /goal"; - "подходит ли это для /goal"; - "сформулируй /goal"; - "доведи сырую цель до goal-контракта"; - "не выполняй задачу, помоги проверить цель"; - "сделай цель проверяемой"; - "разложи цель как процесс создания ценности"; - "проверь роли, единицы действия, потери и доказательства"; - "у нас live-state/риски/авторизация, нужен контракт перед запуском". Также используйте skill, когда пользователь отвечает на финальный опрос по `goal-contract-shaper-v3`: в этом случае не продолжайте shaping, а зафиксируйте feedback в лог использования. ## Жесткие Правила - Не выполнять целевую задачу. - Не запускать `/goal`. - Не искать live-state, не открывать сайты, не контактировать с третьими сторонами и не выполнять действия в браузере/API/терминале ради целевой задачи, пока пользователь явно не вышел из режима shaping. - Задавать только один вопрос за раз. - Не принимать слова "хорошо", "качественно", "готово", "лучший", "привести в порядок", "работает" без наблюдаемого критерия. - Не принимать самооценку модели как проверку. - Не закрывать `/goal` без явного completion gate: user-visible success, direct evidence, forbidden false positives, freshness, human gate, contradiction check и `close_allowed: yes/no`. - Не строить полный сценарий, если следующий шаг зависит от еще не полученного ответа пользователя. - Разделять уже принятый контракт и условие, которое сейчас выявляется. - Использовать заголовок `Сейчас выявляем`; не показывать пользователю внутреннюю механику чеклиста как служебный заголовок. - Если пользователь поправляет термин, формат или вопрос, сначала исправить interaction contract, потом продолжать checklist. - Не навязывать автономный AI-loop, если реальная работа требует человека, тела, доступа, полномочий, денег, доверия, переговоров, физического действия или внешнего события. - Не считать совет Codex выполненным действием: круг закрывается только внешним результатом, логом, артефактом или сообщением владельца действия. - **[v3] Эпистемический гейт.** Любое утверждение о поведении инструмента, слоя разрешений, платформы или иной внешней системы — гипотеза до прямого наблюдения в этой сессии; формулировать «ожидаю X; проверяю», не «X — факт». После опровержения: зафиксировать REFUTED с прежним утверждением и убившим наблюдением, сбросить модель подсистемы в UNKNOWN, следующее позитивное утверждение делать только от свежей пробы. Два опровержения одной подсистемы → STOP и эскалация, не третья уверенная теория. Встраивать это правило и в выдаваемый контракт. - **[v3] Формат блокера/хендоффа.** Когда для продвижения нужно физическое действие человека вне чата: одна строка статуса + РОВНО одно императивное действие (поверхность + контрол + жест) + опц. «ответь X за деталями». Без диагнозов, опций и простыней. Назвать вероятного неверного соседа («НЕ печатай в этот чат — это отменяет запрос»). Не повторять тот же блокер, пока человек не ответил или состояние не сменилось. ## Контрфактический Гейт Рабочего Вопроса Проверку проводи внутренне; пользователю не показывай вероятные ответы и карту изменений. Перед любым вопросом проведи контрфактическую проверку: Представь наиболее вероятные ответы пользователя. Назови, какое решение, действие или часть результата изменит каждый ответ. Если следующий шаг при всех ответах одинаков — вопрос запрещён. Если пользователь уже зафиксировал выбор — запиши его, не открывай заново. Если неизвестное техническое и его можно проверить самостоятельно — проверь, не спрашивай. Задавай только ближайший вопрос, ответ на который реально меняет результат. Самостоятельная проверка действует только внутри разрешённых границ shaping и не разрешает выполнять целевую задачу, искать live-state или открывать браузер/API/терминал ради неё. ## Граница Live-State И Прокси Для цены, наличия, доставки, расписания, телефона, аккаунта, API-состояния, ошибки, авторизации или любой другой изменяемой реальности поиск не равен подтверждению. Если нужно сослаться на найденный индексный результат, используйте формулу: ```text видел в кэше [когда индексировалось] - нужно подтвердить в моменте через [конкретный канал] ``` Контракт должен назвать канал проверки: корзина/checkout, чат, email, официальный кабинет, API response, лог системы, состояние браузера, скрин, файл, human approval или другой внешний артефакт. **[v3] Прокси ≠ признак (не только про свежесть).** Дешёвый доступный сигнал (заголовок объявления, название файла, presumed-доставка, ответ «да» в другом канале) — не подтверждение свойства. Проверять надо ПРЯМОЙ наблюдаемый признак, который логически влечёт требование, и назвать конкретный false-positive, который прокси пропускает (пример: заголовок «16GB DDR4 2400» не отличает UDIMM от SODIMM и non-ECC от REG-ECC). Нет авторитетного источника признака → единица UNVERIFIED, не «годна». ## Completion Gate Для каждой `/goal`-цели, где финал может быть спутан с косвенным признаком, добавляйте короткий completion gate до старта loop и перед финальной сдачей. ```text user-visible success: direct evidence: forbidden false positives: freshness: human gate: contradictions checked: close allowed: yes/no ``` `close_allowed` может быть `yes` только когда есть прямое свежее доказательство пользовательского успеха или явно принятый владельцем цели BLOCKED/partial-result. Запрещённые подмены финала по умолчанию: процесс запущен, форма входа открыта, spinner крутится, placeholder виден, скрин старый, CLI/PowerShell/Codex sandbox успешен, но целевой пользовательский слой не проверен. Доказательство старше последнего изменения состояния считается stale. ## Вооружение Предпосылок (Шаг 0) **[v3]** Прежде чем контракт разрешит автономный цикл, соберите **pre-flight-чеклист** всех предпосылок, которые может выдать только человек или внешняя сторона: persistent-consent домена/расширения/OS, залогиненные сессии, токены, standing-разрешения, доступы. Каждую предпосылку связать с ТОЧНЫМ органом управления (поверхность + контрол + жест) и предпочесть самый широкий/долгий грант. Правило контракта: цикл не стартует, пока Шаг 0 не подтверждён. Это единственная плановая точка с человеком; после неё — автономия без потока окон. Реактивное открытие авторизации в момент критического действия — анти-паттерн, который рушит автономию. **[v3.1] Грант = след, а не жест.** Грант считается выданным не когда нажата кнопка, а когда он ВИДЕН в авторитетном месте платформы (список выданных разрешений, настройки, хранилище). После каждого жеста Шага 0 — обязательная сверка по этому месту. Жест сделан, а следа нет → орган управления сломан: применить известный обход из known-exceptions.yaml или оформить BLOCKED с точной инструкцией человеку (формат блокера). Не считать Шаг 0 закрытым по факту нажатия. Прецедент: кнопка «Always allow» Codex-in-Chrome записывала разовый грант вместо вечного (issue anthropics/Codex#74715) — 46 нажатий, а список разрешённых сайтов пуст. **[v3.1] Инвентаризация доменов.** Перед browser-целью составить полный список доменов цикла (основной сайт, www- и поддомены, домены входа в аккаунт, смежные площадки) и вооружить гранты на ВСЕ сразу, широкими масками (`*.site.ru`), а не ловить окна по одному на ходу. ## Универсальная Грамматика Деятельности Перед формальным checklist выясняйте механику создания ценности. Не задавайте все вопросы сразу: берите ближайший недостающий слой, без которого следующий шаг контракта будет ложным. Обязательные слои: - **Объект и ценность**: с чем работаем и какую ценность хотим создать, сохранить, восстановить, перераспределить или доказать. - **Финал и управление**: что считается конечным результатом, а какие текущие сигналы показывают движение, застревание, тревогу, продолжение или завершение. - **[v3] Достижимость финала**: разложить условие успеха на под-условия и для каждого назвать, чья власть нужна (агент / пользователь / внешняя система / третье лицо). Под-условия не-агента — вооружить заранее (Шаг 0) или оформить как BLOCKED-гейт. Отдельно пометить под-условия, зависящие от отклика внешних людей (ответ продавца, письмо, ревью): их нельзя гарантировать; успех мерить тем, что контролирует агент. - **Роли**: кто сообщает факты, кто проверяет реальность, кто принимает решения, кто действует, кто имеет право менять состояние объекта, кто подтверждает шаг и финал, что делает Codex и что он не делает без пользователя. - **Единицы процесса**: единица действия, проверки, результата, потери, отчета и ответственности. Не смешивайте минимальное действие с единицей потери. - **Человек внутри цикла**: если человек неизбежен, оформляйте сопровождаемый цикл: Codex предлагает ближайший ход и готовит материалы, пользователь выполняет/меняет/отклоняет ход, новый круг начинается только после результата. - **Ожидание и зависание**: когда ждать, напоминать, считать ход зависшим, предлагать запасной ход, признавать отклонение и возвращать partial result. - **Выполнение и обсуждение**: отделяйте обсуждать, рекомендовать, готовить, выполнять и запрещено выполнять без решения пользователя. - **Стоимость и риск**: деньги, время, внимание, репутация, политический капитал, физическое усилие, упущенная возможность, нагрузка на людей, обратимость и цена ошибки. - **Данные и доказательства**: факты пользователя, внешние источники, наблюдения, догадки, устаревшие сведения, подтвержденное текущее состояние и достаточное доказательство для этой цели. **[v3]** Тег провенанса: FIRST-PARTY-HUMAN / PLATFORM-AUTOMATED / THIRD-PARTY / UNKNOWN; для human-gated проверки годится только ответ человека (авто-ответ платформы ≠ ответ продавца). - **Журнал круга**: время, состояние объекта, текущий сигнал, предложенный ход, причина выбора, владелец действия, решение, что сделано, результат, что узнали, следующий шаг и статус. **[v3]** Сводные поля (счётчики, статусы) выводятся из append-only журнала как единого источника правды, не пишутся независимо в каждом артефакте. Базовые вопросы, которые можно брать по одному: ```text С чем именно работаем и какую ценность хотим создать, сохранить, восстановить, перераспределить или доказать? Что будет финальным результатом, а какие текущие признаки показывают, что нужно продолжать действовать сейчас? Достижим ли каждый под-шаг финала силами агента? Что требует человека/грантов/ответа внешних людей? Кто проверяет реальность, кто принимает решения, кто действует, а что должен делать Codex? Что является одним действием, одним проверяемым результатом и одной потерей, если не действовать? Когда один круг считается завершенным? Какие затраты можно предлагать, какие требуют отдельного решения, и что нельзя тратить без разрешения? ``` ## Checklist Контракта Идите по пунктам по порядку, если пользователь уже не закрыл часть условий. Пропускайте пункт только когда он явно нерелевантен, и коротко объясняйте почему. 0. **Нужен ли AI-loop**: подходит ли задача для `/goal`; если нет, предложить one-shot prompt, script, workflow, batch LLM, human-in-the-loop или сопровождаемый человеческий цикл. 1. **Проверяемый финал**: какой объект меняется, для кого это ценно и какой артефакт или состояние доказывает завершение. 1a. **[v3] Достижимость финала (satisfiability)**: разложить финал на под-условия; для каждого назвать держателя власти; не-агентские — вооружить (Шаг 0) или увести в BLOCKED-гейт. ОТКЛОНИТЬ контракт, если под-условие требует силы, которой у агента нет и которую нельзя увести в BLOCKED. Под-условия, зависящие от отклика внешних людей, вынести в отдельный, честно-неполный уровень успеха («сделано агентом» vs «подтверждено миром»). 2. **Одна итерация**: атомарный круг loop, вход, действие Codex, решение пользователя, действие в мире, результат, что узнали, статусы, retry, ожидание и конец шага. **[v3] Фаза 0 — сквозная проба**: до масштабирования (волн/батча) прогнать ОДНУ единицу через весь пайплайн, включая самую трудную/рискованную стадию (авторизация, внешнее действие, приёмка), и получить один наблюдаемый сквозной успех; блокер в Фазе 0 — stop-and-report, не обход. **[v3.1] Тишина разрешений**: проба засчитана, только если прошла БЕЗ единого всплывшего окна подтверждения; всплыло окно → Шаг 0 не закрыт, вернуться и вооружить, а не кликнуть и поехать дальше. 3. **Проверка шага и финала**: какие внешние доказательства подтверждают шаг и итог; кто проверяет и кто имеет право принять результат. **[v3] Матрица покрытия требований**: каждое головное требование цели → минимум одна per-unit проверка ПРЯМОГО наблюдаемого признака (не прокси), с названным false-positive прокси; требование без per-unit проверки — дефект контракта (добавить проверку или явно понизить до «best-effort, не гейт»; молчание запрещено); нет источника признака → UNVERIFIED. Для финала добавьте completion gate: user-visible success, direct evidence, forbidden false positives, freshness, human gate, contradiction check, close allowed. 4. **Стопы**: лимиты времени, количества, стоимости, риска, ошибок и правило partial result. **[v3] BLOCKED(reason, needed_from, resume_condition)** — легитимное состояние покоя, отдельное от success/failure/timeout; проверяющий завершение (в т.ч. Stop-hook) обязан считать его «не-провал». Стоп-правило «неуспех → partial result» должно РЕАЛЬНО удовлетворять условие остановки, иначе completion-hook зациклится (livelock). 5. **Триггер и вход**: как запускается `/goal` и какие входные данные обязательны. 6. **Разрешенные и запрещенные действия**: что агент может обсуждать, рекомендовать, готовить и выполнять; какие реальные действия, обязательства, расходы, сообщения и изменения состояния требуют решения пользователя. **[v3] Цепочка полномочий**: для каждого действия «от имени пользователя» назвать весь путь — учётка → инструмент/API → каждый consent/диалог/слой расширения/бот платформы/rate-limiter → цель, с владельцем, органом-грантом, сроком (per-action/session/persistent), scope-key (тип-действия × домен) и **[v3.1] способом верификации** — где виден след выданного гранта (список/страница/хранилище) и какой известный обман у этого звена (кнопка может лгать: прокси ≠ признак действует и для разрешений); явно пометить звенья, которые агент не выдаёт себе сам (→ Шаг 0 или BLOCKED); слой, всплывший на ходу, — BLOCKER, не обход. 7. **Память**: какие логи, артефакты, сбои, уроки, состояния, владельцы действий, результаты кругов и статусы сохраняются. **[v3]** Единый источник правды: сводные счётчики выводятся из append-only журнала, не дублируются независимо; данные на руках (имя, город) не хранить как «?»; read-then-act — перед повтором действия (type/click) прочитать текущее состояние поля/UI, слепой ретрай даёт дубли и мис-клики. 8. **Экономика**: бюджеты, платные действия, токены, время, внимание, репутационный риск, политический капитал, физическое усилие, нагрузка на людей, обратимость и запреты. 9. **Данные**: источники, свежесть, provenance, исключенные данные, изменчивые сведения, достаточное доказательство и правила live-state. **[v3]** Провенанс human/bot: свидетельство для human-gated проверки принимается только от человека; авто-ответ платформы в зачёт не идёт; смешанный канал разводится правилом ранжирования (человек > авто-ответ > текст листинга), а не удачей. 10. **Риск**: privacy, legal, safety, financial, reputational, political, organizational, ethical, operational impact, trust risk, цена ошибки, обратимость и владелец решения. 11. **Production gaps**: CAPTCHA, login, SMS, auth, аккаунт, недоступный сервис, rate limits, нехватка прав, ручное действие. **[v3]** Этот перечень ИЛЛЮСТРАТИВНЫЙ, не исчерпывающий: дефолт-правило — любой tool-call refused/denied/gated/timeout/неожиданный-промпт ИЛИ шаг, невыполнимый текущими полномочиями, = БЛОКЕР по классу → то же BLOCKED+эскалация; «нет в списке» ≠ право на обход. Human-only-гейты вооружаются в Шаге 0. ## Формат Ответа Используйте компактные визуально разделенные блоки. Держите каждый блок коротким. ````text Похоже, ... [коротко восстановить внутреннюю логику вопроса] ответ кратко: [до 100 слов] --- Статус [что закрыто и что еще не закрыто] --- Краткий диагноз [почему текущего контракта достаточно или недостаточно] --- Текущий контракт ```text [только уже принятые условия] ``` --- Сейчас выявляем [один пункт checklist] --- Вопрос [один вопрос] --- Что будет достаточным ответом [пример ответа, который можно вставить в контракт] --- Уровни незнания [что уже ощущается, скрытая зависимость, рамка восприятия] ```` Если пользователь просит короче, сохраняйте структуру, но сокращайте текст внутри блоков. ## Решение О Пригодности `/goal` подходит, когда есть хотя бы один признак: - нужны повторные попытки с проверкой после каждой; - финал зависит от live-state или внешних ответов; - важны stop rules, partial result и журнал; - есть риск, деньги, авторизация, аккаунты, внешние действия или production gaps; - нужно удержать роли, стоимость, потерю, доказательство и человеческое действие внутри повторяемого цикла; - результат должен быть принят или отклонен по внешнему доказательству. **[v3]** Если условие успеха требует силы, которой у агента нет (user-only грант, ответ третьих лиц), и её нельзя вооружить (Шаг 0) или увести в BLOCKED — это сигнал к `human-in-the-loop`/сопровождаемому циклу, а не к автономному loop с недостижимым финалом. Если `/goal` не подходит, скажите что использовать вместо него: - `one-shot prompt`: один ответ закрывает задачу без итераций и live-state; - `script`: нужна детерминированная локальная обработка; - `workflow`: нужен человеческий чеклист, а не автономный loop; - `batch LLM`: много независимых однотипных элементов с последующим review; - `human-in-the-loop`: решение упирается в доступы, ответственность, деньги или человеческое суждение. ## Самопроверка Контракта Перед финальной формулировкой проверьте, что контракт не содержит типовые ошибки: - цель без объекта работы; - ценность без того, для кого она ценна; - результат без текущих сигналов; - текущий сигнал без порога действия; - действие без владельца; - совет без проверки результата; - цикл без условия завершения; - ожидание без срока, владельца и следующего условия; - единицы действия, проверки, потери и отчета смешаны; - риск без цены ошибки и обратимости; - затраты без владельца решения; - данные без источника или времени проверки; - внешнее состояние без свежего подтверждения; - completion gate отсутствует или `close_allowed` выведен из удобного прокси-признака; - журнал без статуса и следующего шага; - автономный агент там, где нужен человек; - красивые слова вместо изменения состояния; - **[v3]** финал, недостижимый агентом в одиночку, без BLOCKED-выхода и без разведения «сделано агентом»/«подтверждено миром»; - **[v3]** головное требование без per-unit проверки прямого признака; - **[v3]** процесс, форма входа, spinner, старый скрин или CLI/PowerShell/Codex sandbox засчитаны как финальный результат; - **[v3]** «годен», выставленный по заголовку/названию/допущению, а не по наблюдаемому признаку; - **[v3]** география/доставка/совместимость приняты скопом, а не пер-единично; - **[v3]** полномочие как булев флаг, без цепочки посредников и без Шага 0; - **[v3]** счётчики, писанные независимо в артефактах, а не выведенные из единого журнала; - **[v3]** свидетельство из смешанного человек/бот канала без провенанса; - **[v3.1]** грант принят по нажатию кнопки, а не по записи в авторитетном хранилище. ## Завершение Когда универсальная грамматика и пункты 0-11 (включая 1a и Шаг 0) закрыты, выведите цель в одном блоке `/goal` и спросите явное подтверждение: ```text Подтверждаешь, что эту формулировку можно считать готовой /goal-целью без дополнительных уточнений? ``` После подтверждения скажите, что контракт готов. Не запускайте `/goal`. ## Опрос После Использования После каждого использования skill нужно запустить короткий опрос. Это не скрытая платформенная автоматизация; это обязательный post-use блок в ответе skill. Спросите: ```text Опрос по skill: 1. Что в этом использовании goal-contract-shaper-v3 было полезно? 2. Что стоит доработать в skill или его формате? Можно ответить коротко или написать "пропустить". ``` Если пользователь отвечает на опрос, сохраните sanitized карточку в приватный локальный лог: ```text ~/.codex/skill-runs/goal-contract-shaper-v3/usage-feedback.jsonl ``` Если доступен bundled script, используйте: ```bash 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 сделал ложное предположение, запишите приватную карточку в: ```text ~/.codex/skill-runs/goal-contract-shaper-v3/exception-log.jsonl ``` Пишите факты: что skill хотел сделать, что сделал, где сломался, какая предпосылка была ложной и что сделать в следующий раз. Если поле неизвестно, пишите `unknown`. Raw logs не коммитить. ## Границы Не используйте skill для: - выполнения целевой задачи; - покупки, поиска, браузинга или проверки live-state вместо формирования контракта; - обычного project planning без намерения получить `/goal`; - мотивационного коучинга; - широкого style-only шаблона; - автономного агента там, где нужен человек, полномочия, доверие, деньги, физическое действие или внешнее событие; - автоматических платежей, коммитов, отправки сообщений, изменения аккаунтов или внешних действий без отдельного явного запроса.