[bug] knowledge_reindex_source молча пропускает FPF-Spec.md (12.8 МБ): индекс отдаёт версию старше 12.07, errors пуст

[AVNechaev]

Что произошло

knowledge_reindex_source находит FPF-Spec.md, не выдаёт ошибку и не обрабатывает файл: он уходит в skipped при каждом вызове. Индекс FPF из-за этого отдаёт содержимое неизвестной давности, а ответ инструмента выглядит как успешный прогон.

Впервые зафиксировано 23.07.2026, воспроизведено сегодня, 10.08.2026, на IWE 0.38.2 — за это время спека сменила несколько версий, поведение не изменилось.

Это тот же класс, что #3 (skipped как общая корзина), но другая причина: там отказ бэкенда эмбеддингов, здесь файл обрабатывается выборочно при живом бэкенде. Соседние файлы того же источника индексируются штатно, и поиск по FPF работает — падения бэкенда нет.

Воспроизведение (10.08.2026, IWE 0.38.2)

1. Файл виден предпросмотром:

knowledge_reindex_source(source="FPF", dry_run=true)
-> {"files_found": 3, "sample_files": ["FPF-Spec.md", "Narrativization-...md", "Readme.md"]}

2. Явный вызов только на спеке:

knowledge_reindex_source(source="FPF", files=["FPF-Spec.md"])
-> {"processed": 0, "deleted": 0, "skipped": 1, "errors": []}

3. Индекс отдаёт текст, которого в источнике нет. Поиск по A.15.1:1 - Problem Frame возвращает формулировку:

«That concept is U.Work: the dated run-time occurrence of enacting a MethodDescription ... anchored to a domain referent that actually changes (asset/product/dataset)»

Проверка по репозиторию ailev/FPF:

grep -c "anchored to a domain referent that actually changes" FPF-Spec.md   -> 0   (HEAD 036c056, 08.08.2026)
git show 44dd881:FPF-Spec.md | grep -c "... to a domain referent ..."       -> 0   (версия от 12.07.2026)

Фразы нет ни в текущей версии, ни в июльской. Значит индекс хранит содержимое старше 12.07 — устаревание накопленное, а не сегодняшнее.

4. Разделы, добавленные в спеку позже, в индексе отсутствуют. Поиск near-verbatim фразой из A.15.PROD («Separate production work, when this exact entity first exists, and when production was completed») даёт top-1 = E.17.AUD.OOTD:End со счётом 0.43, самого раздела в выдаче нет. Локально A.15.PROD встречается в файле 251 раз.

5. Бэкенд при этом жив: тот же knowledge_search по FPF отвечает содержательно и без ошибок, а SPF реиндексируется штатно (processed: 5, skipped: 41).

Что ожидалось

Одно из двух:

• файл обрабатывается; либо
• вызов сообщает, почему не может его обработать — запись в errors с причиной, а не молчаливый skipped.

Сейчас «пропущен, потому что не изменился» и «пропущен, потому что обработать не удалось» неразличимы для вызывающего. Это ровно тот инвариант, который сформулирован в #3: «проверить не удалось» ≠ «всё хорошо».

Предполагаемая причина

FPF-Spec.md — 12.78 МБ / 104 565 строк (на 23.07 было 11 МБ / 100 054 строки, то есть файл продолжает расти). Похоже на предел по размеру файла или по числу чанков, при превышении которого файл помечается skipped вместо попадания в errors. Локальный HEAD совпадает с origin/main, на GitHub лежит актуальная версия — дело не в устаревшем удалённом репозитории.

Не проверено (нет доступа к серверу): точное значение лимита, есть ли лог с причиной пропуска, когда индекс FPF последний раз обновлялся успешно.

Почему важно

FPF — базовый источник в цепочке отката DS → Pack → Base. Поиск по FPF используется скиллом /fpf и при сверке различений: агент сверяет термины по онтологии и получает ответ из версии, которой больше месяца, без единого признака, что ответ устарел. Молчаливый отказ здесь дороже громкого — пользователь не знает, что нужно перепроверять.

Дополнительно: сам масштаб устаревания измерить нечем. «Skipped: 1, errors: []» не отвечает на вопрос «насколько индекс отстал».

Обходной путь

При работе с FPF читать FPF-Spec.md напрямую из локального клона (grep/awk по разделам), не полагаясь на knowledge_search(source="FPF").

Окружение

• IWE 0.38.2, Linux (Manjaro), VS Code
• MCP iwe-knowledge, инструменты knowledge_reindex_source, knowledge_search
• Источник FPF = ailev/FPF, FPF-Spec.md на коммите 036c056