NovЧерновая пометка из админки не должна случайно попасть на публичную страницу
Почему внутренние статусы редакции и публичные состояния объекта нужно разделять, не скрывая при этом существенную неопределённость для покупателя.
Материал отражает практическую позицию указанного эксперта. Как готовятся и проверяются публикации — в редакционной политике NovAsia.
Внутренней системе нужны короткие рабочие слова. «На проверке», «не готово», «источник ждём», «черновик», «скрыть до сверки» — такие пометки помогают команде организовать работу. Но они описывают процесс команды, а не обязательно состояние объекта для покупателя.
Когда внутренняя метка случайно попадает на публичную страницу, проблема не сводится к некрасивому тексту. Человек начинает интерпретировать рабочий статус как факт о недвижимости. «Черновик» может выглядеть как черновой проект строительства. «Не подтверждено» — как вывод о ненадёжности объекта, хотя редактор мог иметь в виду только отсутствие одного источника в системе. Внутренний словарь получает внешний смысл, которого никто не собирался ему давать.
Служебный статус и пользовательский статус отвечают на разные вопросы
У команды может быть запись «цена требует повторной проверки». Для покупателя полезный смысл — не название внутренней задачи, а ясное состояние цены: например, что текущую цену нужно подтвердить по конкретной квартире перед решением. Внутри при этом могут существовать ответственный, срок, причина и очередь проверки. Показывать всё это публично не нужно.
Обратная ситуация тоже опасна. Иногда служебную метку просто скрывают, и вместе с ней исчезает важное ограничение. Если команда знает, что существенный факт пока не подтверждён, публичная страница не должна выглядеть уверенно только потому, что рабочий ярлык предназначен не для читателя.
Поэтому мне нужна не схема «всё внутреннее скрыть», а разделение смыслов. Внутренняя система хранит состояние процесса. Публичный слой показывает состояние знания, которое действительно важно человеку.
Условный пример: карточка проекта имеет служебный статус «ожидает документов». Это может означать десятки вещей — от одного недостающего приложения до полной проверки нового пакета. Покупателю нельзя автоматически показывать эту фразу. Сначала нужно определить, какой публичный факт зависит от ожидания. Если без документа нельзя подтвердить срок, публично нужно честно обозначить именно срок. Если документ не влияет на уже показанные сведения, внутренний статус может вообще не иметь публичного аналога.
Утечка часто происходит через повторное использование данных
Я бы не искал проблему только в шаблоне страницы. Служебная метка может попасть наружу через поиск, карточку каталога, выгрузку, структурированный блок, уведомление или резервный вывод при ошибке. Компонент получает поле «статус» и честно показывает его, не зная, что это статус редакционного процесса.
Такие ошибки особенно вероятны, когда одно поле пытаются использовать для нескольких задач. Внутреннее «готово к публикации» не равно публичному «готовый проект». Внутреннее «закрыто» может означать закрытую задачу, а не закрытые продажи. Совпадающие слова опасны именно потому, что выглядят правдоподобно.
Хорошая модель должна разделять типы статусов до уровня данных, а не надеяться, что каждый шаблон помнит исключения. Один статус описывает рабочий процесс команды, другой — публичное состояние объекта, третий — состояние конкретного утверждения или источника. Они могут быть связаны правилами, но не должны быть взаимозаменяемыми.
Здесь полезен и негативный тест: что увидит человек, если публичный компонент случайно получит внутреннее поле? Система должна либо не позволить такой связи, либо отобразить безопасное отсутствие данных, а не рабочий жаргон. Это не значит скрывать реальные проблемы. Это значит не заставлять покупателя расшифровывать устройство редакции.
Публичная формулировка должна объяснять факт, а не нашу очередь
Если важное ограничение действительно существует, человеку нужен его смысл. «Проверить позже» ничего не говорит о том, можно ли принимать решение сейчас. «Источник ждём» не объясняет, какой именно вывод пока нельзя сделать. Публичная версия должна отвечать на вопрос, который возникает у покупателя.
Например, вместо внутреннего «на повторной проверке» может быть уместно: «наличие конкретной квартиры подтверждается перед бронированием». Вместо «не прошёл контроль» — точное указание, что площадь из двух источников расходится и пока не используется в сравнении. Формулировка зависит от факта, а не от названия этапа внутри команды.
При этом публичный язык не должен становиться мягким способом спрятать проблему. Если значение неизвестно, писать уверенный эквивалент нельзя. Разделение внутренних и внешних статусов нужно для ясности, а не для косметики.
Для меня хороший выпуск страницы происходит только тогда, когда оба слоя согласованы. Внутри команда видит достаточно информации, чтобы продолжать работу. Снаружи покупатель видит только те статусы, которые помогают понять объект, источник и границу знания. Ни один служебный ярлык не появляется случайно, и ни одно существенное ограничение не исчезает только потому, что его внутреннее название не предназначено для публикации.