Два разных события: предложить и применить
Главная граница проходит не между ручным и автоматическим авторством, а между proposal и live-версией. Разбор прогона может свободно подготовить предложение, но до применения оно остаётся отдельным артефактом: целевой skill, основание, полный diff, базовая ревизия, результаты проверок и план отката.
Это закрывает два класса отказа одновременно. Слабый урок не попадает в следующие сессии до проверки, а хороший proposal не накладывается на файл, который успели изменить после анализа.
Evidence до proposal
Сам факт длинного или успешного прогона ничего не доказывает. Кандидат оправдан, когда:
- можно показать, что именно существующий skill реально использовался;
- находка повторяема или устраняет тяжёлый отсутствующий контракт;
- изменение уберёт хотя бы два будущих шага модели или инструмента;
- причина не сводится к routine success, одноразовому случаю, временной ошибке зависимости, общему совету или секрету.
Нормальный результат review — воздержаться. Иначе петля оптимизирует skill под шум последнего запуска (Harness Optimization).
Ownership — это граница автономии
creator, owner и право изменить артефакт — разные вещи. Практичный fail-closed default: неизвестный, пользовательский и импортированный skill считаются user-owned. Агент может подготовить proposal, но не применять его автономно. Auto-apply допустим только для явно machine-owned пространства с отдельной политикой и квотой.
Такой default важнее эвристики по Git author: история помогает расследовать происхождение, но не является ACL.
Proposal привязан к точной версии
Минимальная связка: target + base_hash + proposal_revision + diff. Если target изменился, старый proposal становится stale; его нельзя молча домержить и считать прежним решением. Нужны новый diff, повторная проверка и новое подтверждение (Approval Path).
Подтверждение относится именно к этой ревизии proposal. Согласие на идею «улучшить skill» не является согласием на любой последующий текст.
Проверка до и после применения
Контроль состоит из разных ворот:
- fresh-context RED показывает наблюдаемый пробел без нового текста;
- структурный валидатор и security scanner блокируют повреждённый или опасный артефакт;
- fresh-context GREEN проверяет тот же сценарий с новой версией;
- regression/trigger corpus ловит побочные маршрутизационные изменения.
Scanner проверяет ограниченный класс угроз, а не правильность совета. Прошедший scanner skill всё ещё может быть неверным или чрезмерно общим.
Атомарность, откат и версия сессии
Apply должен либо выпустить целую ревизию, либо не выпустить ничего; метаданные proposal и live-текст не могут разъехаться при сбое. Откат возвращает предыдущую известную ревизию и сам остаётся аудируемым событием.
Запущенная сессия сохраняет уже загруженный снимок skill. Новая версия начинает влиять на новые загрузки, а не переписывает контекст задним числом. Поэтому GREEN выполняется свежей сессией, а в трассе фиксируется revision фактически использованного skill (Agent Audit Log).
Что брать из OpenClaw 2.0
Брать стоит механику Workshop: proposal-first, hash binding, fail-closed ownership, изолированный reviewer, scanner на apply, атомарную ревизию и rollback metadata. Не стоит переносить default auto: для репозитория пользовательских skills безопаснее propose, пока нет отдельного machine-owned namespace и набора регрессионных evals.
Связано с
- Harness Optimization — когда опыт вообще достоин durable-правки
- Agent First Repository — жизненный цикл и progressive disclosure skills
- Approval Path — подтверждение точного артефакта, а не намерения
- Agent Identity — ownership не равен полномочию
- Agent Audit Log — evidence, proposal revision и фактически загруженная версия