Задание автору статьи
Карта утверждений из прошлого урока даёт основания для объяснения, но ещё не является заданием автору. Автору нужны результат, исходные условия, достаточный пример и границы. Оформим карточку BR-01 для публикации PUB-01 о сохранении старого адреса при переносе страницы в Markdown. После урока другой участник сможет подготовить текст, не восстанавливая договорённости по разрозненным заметкам.
В локальной лаборатории ProfessorWeb продолжаются те же роли и материалы. Карточка в lesson-05 архива серии учебная: сроки, имена и решения придуманы. Мы не передаём задание реальному сотруднику и не утверждаем, что новый материал прошёл техническую проверку.
Результат и исходное состояние
Начните задание с действия читателя: «После урока вы сможете отделить публичный URL старой страницы от имени нового исходника». Такой результат ограничивает тему. Формулировка «написать качественную статью о Markdown» не объясняет, какие понятия нужны, а какие можно оставить для другой главы. Размер текста, количество изображений и поисковые фразы не заменяют эту часть задания.
Исходное состояние описываем отдельно. У читателя есть старый HTML-сайт и ссылка /my/LINQ/linq_xml/level7/7_1.php. Он понимает назначение URL, но не знает устройство конкретного генератора. Пример должен показать прежний адрес и фрагмент метаданных будущей страницы. Данные нужны для объяснения, поэтому нельзя без причины заменить старый путь красивым новым адресом: это изменит саму задачу миграции.
Зададим минимальную последовательность: определить прежний путь, связать его с материалом, назначить этот путь в метаданных и описать ожидаемую выдачу страницы. Каждому действию соответствует причина. Реестр предотвращает случайную потерю маршрута; метаданные отделяют адрес от исходника; проверка выдачи связывает сохранённую строку с поведением сайта. Автору не нужно придумывать механизм по названию темы.
Основания и ограничения
В BR-01 внесём утверждения F-01 и F-02 из интервью. Их статус пока требует сверки по проекту. Автор вправе использовать их как объяснение устройства учебного примера с оговоркой, но не выдавать за проверенное поведение любого сборщика. В задании указываем не просто «использовать официальные источники», а какие именно вопросы должны быть подтверждены источником или чтением конфигурации.
| Часть задания | Содержание | Признак готовности |
|---|---|---|
| Результат | Разделить путь и исходник | Читатель объясняет различие |
| Пример | Прежняя .php-страница |
Путь показан полностью |
| Граница | Без настройки почты и DNS | Нет скрытого расширения |
| Ограничение | Сервер должен выдавать путь | Условие названо явно |
К границам добавим обещания, которых статья не делает. Она не гарантирует рост посещаемости, не доказывает сохранение всех поисковых позиций и не переносит динамические функции сайта автоматически. Эти ограничения связаны с конкретным результатом. Они полезны автору и читателю, потому что помогают понять, какой вывод можно сделать по примеру, а какой потребует отдельной работы.
Различайте обязательный элемент и предложенный приём. Полный прежний путь обязателен: без него не раскрывается задача. Таблица сравнения имени файла и URL — подходящий приём, но автор может заменить её ясным разбором двух строк. Задание управляет результатом, а не подавляет все решения автора. Иначе редактор получит формально точный текст, в котором нет связного объяснения.
Для приложений укажем, какой файл нужен и что он означает. В нашем случае artifact.md содержит саму карточку, а after.json — решение о её готовности к написанию. Ни один из них не является архивом выполненной сборки. Если в статье позднее появится пример конфигурации, необходимо обозначить его полноту, расположение и непроверенную часть. Многоточие не должно скрывать действие, без которого результат невозможен.
Передача и исправление
Карточку принимает Лена, учебный автор из редакционной модели. Она уточняет вопрос: нужно ли объяснять перенаправление? Ольга отвечает, что основной пример сохраняет прежний путь; вариант переезда на новый адрес будет отдельным материалом. Это решение записывается в задание. Короткое уточнение предотвращает написание главы, которая решает другую задачу и затем требует серьёзной переделки.
У задания есть версия. BR-01 v1 фиксирует начальный результат и границы. Если позже редактор добавит вариант отсутствующей страницы, версия меняется, а причина записывается. Нельзя оценивать готовый текст по новым требованиям, которые автор не видел. История нужна для согласования содержания, а не для подсчёта виноватых в изменении срока.
Срок в нашем учебном процессе относится к передаче полного черновика на рецензию. Он не означает дату внешней публикации. Назовём условные затраты: два редакционных блока на текст и один на предметную сверку. Блок — единица планирования нашей модели, его продолжительность зададим в следующем уроке. Не выдаём такую оценку за измеренную скорость авторов ProfessorWeb или норматив для любого урока.
Проверить задание можно обратным чтением: возьмите предполагаемый готовый текст и сопоставьте каждый существенный раздел с результатом. Абзац о регистрации домена не поддерживает BR-01; его стоит убрать или объяснить, зачем он нужен. Абзац о том, почему старый путь сохранён, поддерживает задачу напрямую. Эта проверка помогает выявить и лишнее содержание, и пропущенную предпосылку.
Ещё одна проверка касается самостоятельности читателя. Если текст требует «использовать прежний реестр», а в задании не указано, откуда он взялся, автор должен показать хотя бы одну исходную строку. Ссылка на большую таблицу может дополнить урок, но не должна скрывать смысл её полей. В нашей карточке предусмотрен полный одинарный пример, достаточный для понимания связи.
Особенно внимательно опишите ожидаемую ошибку. Для BR-01 это ситуация, когда исходник переименован, а адрес назначен автоматически по новому имени. Читатель должен увидеть, почему сама операция переименования не доказывает сохранение маршрута. В задании нет требования намеренно ломать рабочий сайт. Автор показывает различие состояний на учебных данных. Такой контрпример остаётся безопасным редакторским объектом и помогает проверить полноту объяснения ещё до исполнения технической части.
В after.json появляется BR-01 со статусом accepted_for_draft, а PUB-01 получает следующего ответственного. Это ожидаемое редакционное состояние локального примера, не действие в системе управления проектами. Попробуйте изменить результат на «обслужить новый адрес и перенаправить старый». Вам придётся пересмотреть механизм и критерий наблюдения, а не только заголовок. Так задание защищает учебную последовательность от случайной смены задачи.