docs: register BUG-05 and BUG-06 in bug backlog

TODO.md

@@ -492,6 +492,24 @@
   - **Диагностика**: в `app/static/js/modules/ui.js` (строка 28) функция `shuffleArray(array)` возвращает новый скопированный массив (`return arr;`), не мутируя оригинал на месте. В `app/static/js/modules/lesson.js` (строка 778) и `app/static/js/modules/srs.js` (строка 461) написано `shuffleArray(options);`, но результат возврата игнорируется (`options` не перезаписывается), из-за чего правильный ответ, добавленный первым в `[correctText, ...]`, всегда остаётся на позиции 0.
   - **Варианты решения**: переписать вызовы на `options = shuffleArray(options);` (или сделать `shuffleArray` мутирующим).
   - **Статус**: зафиксировано, ожидает команды на исправление.
+- [ ] **BUG-05: Поломка верстки и отображение сырых HTML-тегов/JSON при импорте статей Википедии (например, Linux)**:
+  - **Симптом**: при открытии импортированной из Википедии статьи «Linux» в читалке в 1-й главе («Overview») отображается фрагмент сырого JSON (`"},"title":{"wt":"Linux"}...`), а в главе «Pronunciation» — искажённый тег `<tdTimes New Roman...` и сырые теги цитат `{{ cite newsgroup...`.
+  - **Диагностика**:
+    1. В `app/reader.py` (`clean_wiki_html`): MediaWiki Parsoid HTML вставляет метаданные шаблонов в атрибут `data-mw='{"parts":...}'` (например, у `<span class="mw-empty-elt">` и `<table class="infobox">`). Внутри значения этого атрибута содержатся незаэкранированные угловые скобки (например, `<ref name="...">`). Регулярное выражение удаления HTML-тегов `re.sub(r'<[^>]+>', ' ', s)` встречает первый же символ `>` внутри кавычек атрибута, преждевременно обрывает удаление тега, и остаток JSON-строки вываливается в текст статьи.
+    2. В `clean_data_table` regex удаления стилей `style=["'][^"']*["']` спотыкается о вложенные одинарные кавычки в `style="font-family:'Times New Roman'..."`, оставляя сломанный HTML `<tdTimes New Roman...`.
+    3. В `app/static/js/modules/reader.js` повреждённые теги не распознаются парсером таблиц и выводятся как обычный экранированный текст.
+  - **Варианты решения**: предварительно полностью вырезать атрибуты `data-mw` и `about` регулярным выражением или через санитизацию до удаления тегов, улучшить regex очистки стилей таблиц и перезагрузить повреждённые статьи.
+  - **Статус**: зафиксировано, ожидает команды на исправление.
+- [ ] **BUG-06: Не работает поиск и обратный перевод с русского на английский в словаре**:
+  - **Симптом**: при попытке ввести в поле перевода словаря русское слово (например, «собака» или «яблоко») перевод не находится, возвращается пустой результат или ошибка.
+  - **Диагностика**:
+    1. В `app/dictionary.py` функция `lookup_term` жестко закодирована только под направление «English -> Russian»:
+       - В локальной БД поиск ведется только по полю английского слова `WHERE term = ? COLLATE NOCASE` (русские переводы хранятся в поле `translation` и по ним поиск не производится).
+       - Во внешнем сервисе `fetch_mymemory` жестко зашит параметр `langpair="en|ru"`, из-за чего сервис пытается переводить русское слово как английское и возвращает ошибку или пустую строку.
+       - Запросы к Wiktionary и FreeDictionaryAPI идут в англоязычные эндпоинты (`en.wiktionary.org`, `api.dictionaryapi.dev`), где нет русских словарных статей.
+    2. В интерфейсе [`app/static/js/modules/dictionary.js`](file:///home/ai-projects/services/study.qpid.pro/app/static/js/modules/dictionary.js) результат выводится в поле карточки без учёта обратного направления перевода (когда найденный английский эквивалент должен стать `term`, а введенное русское слово — `translation`).
+  - **Варианты решения**: автоматически определять язык ввода по наличию кириллицы `[\u0400-\u04FF]`. При кириллице: переключать `langpair` MyMemory на `"ru|en"`, выполнять обратный поиск в `offline_dictionary` по `translation`, и корректно заполнять форму добавления карточки (найденное английское слово в `term`, русский запрос в `translation`).
+  - **Статус**: зафиксировано, ожидает команды на исправление.
 
 ---