diff --git a/todo.md b/todo.md
new file mode 100644
index 0000000..063b735
--- /dev/null
+++ b/todo.md
@@ -0,0 +1,26 @@
+# TODO
+
+## Утечка ПД в fail-open ветке ProcessResource
+
+`src/main/java/ru/pdguard/api/ProcessResource.java:104-109` — если `pipeline.process`
+кидает `RuntimeException`, сервис отвечает `200 {"result": <payload как есть>}`.
+
+Если сбой случился на прямом (маскирующем) шаге, наружу уходит необработанный
+исходный ПД вместо маски — прямая утечка, которую весь сервис существует, чтобы
+предотвращать.
+
+Почему не 5xx: по правилам НТ (Приложение B ТЗ) 5 подряд невалидных ответов
+останавливают весь прогон, поэтому `200` был выбран сознательно, чтобы не срывать
+проверку. Но текущий фолбэк меняет одну проблему (сорванный прогон) на другую
+(утечка ПД) — само по себе решение не устраняет риск, а сдвигает его.
+
+Пробовал фикс — затирать буквы/цифры в payload перед возвратом (без утечки,
+но и без осмысленного контента). Отклонён как сомнительный, отменён.
+
+Нужно придумать более осмысленный вариант: что именно возвращать при внутренней
+ошибке так, чтобы одновременно (а) не утекал ни один символ исходных ПД и
+(б) ответ не выглядел как случайная порча данных. Возможные направления для
+обсуждения: частичное маскирование тем, что успело определиться до сбоя;
+консервативный ответ вида "обработка недоступна" с фиксированным содержимым;
+пересмотр самой стратегии (может, лучше редкий 5xx, чем гарантия небольшой
+утечки).