CLODEx.
ПРАКТИКА / CLODEx

Шаблон безопасного отчёта об ошибке API без токенов и приватного текста

Составляйте вход из заранее разрешённых полей, а не редактируйте полный production-лог. Отчёт отделяет наблюдаемые факты от ожиданий и гипотез, отмечает неизвестные и предлагает безопасные локальные проверки. Не передавайте токены, cookies, персональные данные, приватные prompts и полные тела ответов; не отключайте TLS-проверки ради диагностики.

Редакционная проверка · / Библиотека промптов

Что можно передать в шаблон

Используйте только заранее разрешённые поля: публичный endpoint без query-параметров, HTTP-метод, HTTP-статус, время в UTC, категория ошибки и синтетическое воспроизведение без чувствительного содержимого. Не передавайте Authorization, cookies, API-ключи, email, IP-адреса пользователей, приватные prompts или полные тела запросов и ответов. Простая замена ключа регулярным выражением не считается достаточной анонимизацией: текст запроса, HTML-ошибка и вложенные поля могут содержать дополнительные данные. Даже path без query может содержать ID пользователя или секрет в сегменте: используйте публичный шаблон маршрута, например /items/{item_id}, а не реальный путь объекта. Категория ошибки — фиксированное значение из разрешённого списка, не исходное exception.message.

Разделяйте факты и гипотезы

В результате отдельно укажите наблюдаемые безопасные факты, ожидаемое поведение, синтетическое воспроизведение, непроверенные предположения и неизвестные. Если данных недостаточно для вывода о причине, прямо сообщите об ограничении и предложите безопасную локальную проверку вместо запроса полных логов или секретных материалов. Отчёт не подтверждает причину инцидента сам по себе.

Ограничения безопасности

Не обещайте полную анонимизацию или отсутствие утечек. Не рекомендуйте отключать проверку TLS, ослаблять контроль доступа, публиковать секреты или сбрасывать ключи, принадлежащие другим субъектам. Синтетическое воспроизведение может не отражать поведение production-среды; его результаты нельзя считать проверенными без отдельного безопасного тестирования.

Проверяемый синтетический вход

Ниже не production-лог, а вручную составленный пример разрешённых полей. По одному статусу 502 нельзя установить, какой компонент сломался. Корректный отчёт должен сохранить эту неопределённость, не придумывать содержимое ответа и не запрашивать токен или полный сетевой дамп.

json
{
  "method": "POST",
  "route_template": "/v1/chat/completions",
  "status": 502,
  "observed_at_utc": "2026-11-07T00:00:00Z",
  "error_category": "upstream_unavailable",
  "fixture": "synthetic status only; no request or response body"
}

Шаблон промпта

Составь краткий технический отчёт об ошибке API только по безопасным наблюдениям ниже. Не запрашивай и не воспроизводи токены, cookies, API-ключи, персональные данные, IP-адреса пользователей, приватные prompts, полные тела запросов или ответов. Используй только HTTP-метод, публичный шаблон маршрута без query, идентификаторов и секретов в сегментах, HTTP-статус, время в UTC, категорию ошибки и синтетическое воспроизведение. Раздели результат на: 1) наблюдаемые факты; 2) ожидаемое поведение; 3) синтетическое воспроизведение; 4) гипотезы с явной пометкой, что они не подтверждены; 5) неизвестные; 6) следующие безопасные локальные проверки. Если данных недостаточно, прямо укажи это и не запрашивай полные логи или секретные материалы. Не рекомендуй отключение TLS-проверок, ослабление защиты, публикацию секретов или сброс чужих ключей. Не утверждай, что причина инцидента установлена, если это не следует непосредственно из переданных наблюдений. Безопасные наблюдения: [ВСТАВЬТЕ ТОЛЬКО РАЗРЕШЁННЫЕ ПОЛЯ].

Источники и проверка