dev-skills/decisions/68-task-from-plain-text.md

# 68. Постановка текстом — вторая полноправная форма входа (2026-08-13)

## Что было

`code-resolve` объявлял вход широким: «путь к файлу, имя файла, слаг или просто
текст». Дальше текст жил на правах исключения. Разведка своё исключение
проработала — вопрос формулируется самим скиллом, адрес ответа назначается им
же, и оба показываются в первой реплике. У решения и обслуживания не было
ничего: шаг «прочитать задачу» читал разделы записи, шаг закрытия закрывал
запись, признак обслуживания опирался на тип, объявленный автором записи, а
критерии приёмки приходили «от проекта». Что со всем этим делать, когда записи
нет, не говорилось нигде, кроме одной строки про непрогнанный `ready`.

Владелец назвал случай: задачу часто нужно решить прямо по описанию в разговоре,
без файла в каталоге, — так же, как её берёт `opsx:propose`, которому размеченная
запись тоже не нужна.

## Решено

**Р245. Форм постановки две, и они равноправны: запись каталога и текст.** Это
ось, а не оговорка о вырожденном случае: по ней ветвятся три вещи в трёх местах
скилла. Дом перечня осей — `av-dev/shared/axes.md`, и строка там заведена вместе
с этим решением.

**Р246. Форма постановки не влияет ни на сценарий, ни на метку, ни на глубину.**
Развилка «есть ли очевидный способ» и «меняется ли спека» у обеих форм общая,
текстом идут все три сценария. Иначе текст стал бы четвёртым сценарием — коротким
путём, выбираемым по форме вызова, то есть ровно той лазейкой, против которой
написан весь [Р223](63-maintenance-third-scenario.md).

**Р247. Отпадают ровно те шаги, у которых пропал предмет.** `ready` гонять
нечего — записи нет; закрывать нечего — записи нет. Ни один шаг, у которого
предмет остался, не выпадает: гейт, ревью, синк, коммит и чекпоинт идут как
обычно. Тот же приём, которым сложено обслуживание ([Р222](63-maintenance-third-scenario.md)
и соседи): шаг без предмета выпадает, шаг с предметом — никогда.

**Р248. Запись задним числом не заводится.** Ни перед работой, ни ради того,
чтобы было что закрыть. Учёт получил бы задачу, которой никто не ставил, и
закрытие без единой минуты открытого состояния; граница «скилл беклогом не
владеет» действует и здесь. Работа не уместилась в прогон или должна пережить
разговор — скилл говорит это строкой и предлагает `av-dev:task-track`.

**Р249. Понимание постановки показывается первой репликой.** Рядом с названным
сценарием, одной-двумя фразами: что считается предметом работы и где проходит
граница. Запись толкуется по разделам, текст — молча, и расходится он с замыслом
там, где его никто не показал. Обоснование то же, что у названного вслух
сценария: поправка стоит одной фразы, пока работа не пошла.

**Р250. Тип у текстовой постановки называет исполнитель, и это делает его
признаком только вслух и только до работы.** Связка обслуживания стоит на двух
источниках — тип от автора, отсутствие дельт от исполнителя ([Р222](63-maintenance-third-scenario.md)),
— а текст типа не несёт, и оба признака оказываются в одних руках. Разведённость
восстанавливается **местом**: тип и предмет объявляются до первой правки, когда
автор текста ещё в разговоре и опровергает их одной фразой. Названный после
работы тип — не признак, а объяснение уже сделанного: готовый дифф всегда
подтверждает тот тип, под который писался.

**Р251. Критерии приёмки исполнитель по-прежнему себе не проставляет, но у
решения появилось место их предложить.** Чекпоинт: предложенные там критерии
человек подтверждает или правит, и данными они становятся только после ответа. У
обслуживания такого места нет — чекпоинта нет вовсе, — и там отсутствие критериев
называется строкой доклада: приёмка идёт по докладу. Правило «критерии приходят
снаружи» не ослаблено ни там, ни там; ослаблением было бы молчаливое сочинение
себе оракулов.

**Р252. У обслуживания вместе с критериями текст не даёт и границ**, а раздел
«Затрагивает» у него не украшение: границы обслуживания лежат не в коде — конфиг,
версия зависимости, команда сборки, файл CI. Поэтому границы называются в той же
первой реплике, что и тип. Невидимая граница расползание не удержит, а
обслуживание расползается чаще прочих сценариев.

## Следствия

**С237. Стоп «нашлась дельта» получил третий вариант ответа — и не получил
третьего решения.** Решений по-прежнему два ([Р226](63-maintenance-third-scenario.md)),
но «переформулировать запись» у текстовой постановки переформулировывать нечего:
человек либо запускает следующий прогон тем же текстом, и тот пойдёт решением,
либо заводит запись через `av-dev:task-track`. Выбор между этими двумя — его, не
исполнителя, потому что заводить запись скилл не вправе — Р248 выше.

**С238. Похожая запись в беклоге не разыскивается.** Человек назвал работу
текстом — предмет прогона этот текст, а не строка индекса, которая на него
похожа. Замеченная по ходу называется строкой доклада и не закрывается:
закрытие — это приёмка, и поручали её не исполнителю.

**С239. У разведки отсутствие записи безопаснее, чем кажется, но ровно по одной
причине.** Её след — не код, а записанный по названному адресу ответ, и он уезжает
в коммит. Если ответ записать было некуда и он остался в докладе, от прогона не
осталось ничего — и это говорится прямо, а не строкой среди прочих.

**С240. Доклад называет форму постановки.** Пришла текстом — сказано, как она
понята, что `ready` не гонялся и что закрывать было нечего. Иначе пропуск двух
шагов неотличим от их молчаливого обхода на задаче, у которой запись была.