[QA-trace][#228 6/7] Верификация footnotes: 🔴 ФИЧА СЛОМАНА на import-пути (канонизатор не подключён в apps/server) — чиню #240

New Issue

Ghost · 2026-06-27T16:52:41+03:00

Ghost commented

2026-06-27 16:52:41 +03:00

Прогон 6/7 · верификация фичи PR #232 (#228 inline footnotes) · web-test-orchestrator · 12 находок → 12 verified / 0 ложных.
🔴 Вердикт фичи (кратко): канонизация НЕ подключена в серверный markdown-import — фича сломана на главном пользовательском пути. Полностью: см. ниже.

BROKEN на главном проверяемом пути. Канонизация сносок (упорядочивание 1..N по первому упоминанию, dedup по тексту, выброс orphan, идемпотентность) НЕ работает на пользовательских write-путях: markdown-import (REST POST /api/pages/import и UI Import->Markdown) и paste. canonicalizeFootnotes отсутствует в apps/server (0 call sites, подтверждено grep'ом: функция есть только в packages/mcp и packages/editor-ext). import.service.ts делает markdownToHtml->htmlToJson без канонизации, поэтому нижний список сносок сохраняется в физическом порядке определений (наблюдалось 3,1,2 / 4,2,1,3 / 4,1,6,2,3,5), orphan-определение остаётся в хранимом контенте, а content-dedup двух разных id с одинаковым текстом не происходит. Нумерация ссылок-надстрочников верна (производится из порядка первого упоминания), и сырой хвостовой блок [^id]: убирается marked-конвертером — но это единственное, что работает. Editor sync-плагин лечит лишь частично (роняет orphan и переиздаёт id-коллизии при открытии в редактируемом редакторе), но ПО ДИЗАЙНУ не переупорядочивает существующий список, поэтому out-of-order остаётся навсегда; в read-only/share-рендере (enableSync=false) даже orphan не выкидывается. Итог: ровно тот trigger-баг, который PR #228 заявляет исправленным, на пути markdown-импорта воспроизводится. Канонизация реально подключена ТОЛЬКО в MCP/AI-chat путь, который на стенде не достижим и не проверен.

Process-trace отчёт: верификация PR #228 (inline footnotes / каноникализация)

Стенд: gitmost (форк Docmost), UI :5173, API :3000, collab :3001. Инструментарий: Playwright (python, headless chromium-1148, --no-sandbox), curl для API, grep/Read для статической трассировки. Оракулы: рендер DOM (data-footnote-number / --footnote-number CSS-var на надстрочниках и нижнем списке) + POST /api/pages/info (хранимый ProseMirror-JSON) + исходники.

1. Сводка и ВЕРДИКТ ФИЧИ

Вердикт: каноникализация НЕ работает на главном заявленном пути (markdown-import / paste). Фича сломана.

PR заявляет, что нумерация и нижний список выводятся детерминированно на write-путях (markdown import, updatePageJson, после каждого docmost_transform). По факту в apps/server каноникализатор не подключён вообще: grep canonicalizeFootnotes apps/server/src даёт 0 совпадений (я перепроверил живьём — пусто). Функция существует только в packages/mcp и packages/editor-ext. import.service.ts:127 делает markdownToHtml -> htmlToJson без шага канонизации. Поэтому:

Порядок нижнего списка остаётся физическим порядком определений из markdown (наблюдалось 3,1,2; 4,2,1,3; 4,1,6,2,3,5) — это в точности trigger-симптом «footnotes rendering out of order», который PR обещает чинить.
Orphan-определение остаётся в хранимом контенте сразу после импорта.
Content-dedup (два разных id с одинаковым текстом -> один номер) не происходит на импорте; footnoteContentKey() подключён только в insertInlineFootnote (MCP inline-tool).
Идемпотентность через редактор не лечит порядок: live footnoteSyncPlugin по дизайну роняет orphan и переиздаёт id-коллизии, но НЕ переупорядочивает существующий список (noChangeNeeded игнорирует внутрисписочный порядок). Открытие/сохранение в редакторе фиксирует физический порядок навсегда.
Read-only/share (enableSync=false) запускает только numbering-декорацию — orphan не выкидывается, порядок не чинится; зритель свежеимпортированной страницы видит и orphan, и кривой порядок.

Что РАБОТАЕТ (позитивные контроли): нумерация надстрочников-ссылок верна (порядок первого упоминания, повтор того же id переиспользует номер); сырой хвостовой блок [^id]: убирается marked-конвертером (в теле нет литералов [^); дубль-определение одного id — first-wins; интерактивная вставка через slash-меню с перенумерацией insert-before работает и переживает reload; страница без сносок не плодит пустой список.

Итог: единственная корректная часть — reference-numbering и зачистка сырого блока. Сам акт каноникализации (reorder + content-dedup + orphan-drop на write-path + идемпотентность) на пользовательском пути отсутствует. Каноникализатор подключён ТОЛЬКО в MCP/AI-chat путь, который на стенде недостижим (нет MCP-листенера на :3000/:3001/:5173) и остался непроверенным.

2. Агенты и инструменты — кто как загонял footnote-markdown

Четыре исполнителя + recon, плюс независимый verifier-проход. Ключевая ценность для оракула — все использовали ДВОЙНОЙ оракул (хранимый JSON через /pages/info + реальный рендер DOM), а не один сигнал.

recon — крафт messy.md (refs по документу a,b,c,d,a-reuse,e,f; defs в физическом порядке c,a,b,d,dup-a,e,f + [^orphan]) через REST-import. Оракул: data-footnote-number на node-footnoteDefinition + /pages/info + статический grep. Самый системный: сразу связал симптом с тем, что reorder делает только canonicalizeFootnotes, а плагин по докстрингу сохраняет физический порядок. Изобретательность: средняя-высокая (включил reuse и orphan в один файл).
import-ordering tester — REST-import + UI Import->Markdown, метки gamma/alpha/beta+reuse+orphan. Оракул: /pages/info (footnotesList=[beta,gamma,alpha,orphan]) + DOM (Beta=3,Gamma=1,Alpha=2). Отдельно проверил «частичное самоисцеление» при открытии (orphan уходит, порядок остаётся) — хороший ход по идемпотентности.
dedup-and-orphans tester — самый разнообразный по ingest: order.md/classic.md/dedup.md/reuse.md/orphan.md. Раскрыл два уникальных под-бага: (1) content-dedup не происходит (a=1,b=2 при одинаковом тексте), контраст с same-id reuse, который корректно коллапсирует с мульти-бэклинком; (2) orphan-drop происходит на editor-open, не на write-path. Самый изобретательный в подборе кейсов.
editor-and-roundtrip tester — три ingest-метода: REST-import, PASTE (transformPastedText:true в пустую страницу — воспроизвёл идентичный 4,1,6,2,3,5), интерактивная вставка через slash-меню. Единственный, кто проверил paste и read-only-gating (footnote-reference.ts:88-97 enableSync!==false) и interactive insert-before renumbering. DOM-оракул: --footnote-number CSS-var + ::after content. Корректно исправил начальное мис-таргетирование (title-редактор vs .ProseMirror контента) — честно записал процессную ошибку.
verifier — независимо репродуцировал с ДРУГИМИ метками (sigma/tau/rho/lonely вместо gamma/alpha/beta/orphan), новые space/page id, тот же класс отказа. Это сильный сигнал против success-hallucination.

Ingest-методы покрыты: REST /api/pages/import (все), paste (1 агент), interactive slash-insert (1 агент); UI Import->Markdown заявлен, но de-facto тот же серверный путь, что REST. DOM-оракул нумерации реализован двумя способами (data-footnote-number атрибут и --footnote-number CSS-var) — хорошая перекрёстная проверка. Reload-идемпотентность проверена «свежим browser load» (effective reload) против /pages/info.

3. Находки по классу (как / кем / этап)

feature-broken / canonicalizer-not-wired-into-import (high) — ядро: import/paste не каноникализует, список вне порядка. Найдено 4 агентами независимо (recon, import-ordering, dedup-and-orphans, editor-and-roundtrip), этап execution+recon, корень — статической трассировкой (import.service.ts, footnote-canonicalize.ts, footnote-sync.ts). Конвергенция 4х -> по сути это ОДИН уникальный баг, воспроизведённый четырежды.
feature-broken / content-dedup gap (medium) — dedup по тексту только в inline-tool, не на импорте. dedup-and-orphans tester, execution.
feature-broken / read-only orphan + порядок (medium) — enableSync=false не чинит. editor-and-roundtrip tester, через сравнение /pages/info до/после open + чтение plugin-gating.
gitmost-ui / flushSync console-noise (low) — 28 ошибок flushSync на странице со сносками vs 0 на контроле; verifier подтвердил источник (@tiptap/react ReactRenderer, dev-only). recon, оракул — console listener.
feature-works (low) x4 — reference-numbering+зачистка [^id]: блока; orphan-drop/[^id] на editor-open; interactive insert+renumbering+persistence; no-spurious-list + first-wins дубля. Позитивные контроли, дисконфирмят «всё сломано».
env-limitation (low) — MCP-путь (где фикс реально подключён) недостижим на стенде.

4. Фолс-позитивы

0. Verifier пересэмплировал 6 из 12 находок (включая обе high-репродукции, content-dedup, flushSync, read-only-orphan) — все reported=verified подтверждены как verifier=verified, ни одна не понижена. Позитивные контроли честно помечены как feature-works, а не выданы за баги. False-positive rate в этом прогоне = 0.

5. Где скилл сработал / провалился на верификации этой фичи

Сработал:

Нашёл РЕАЛЬНУЮ дыру каноникализации, а не «выглядит ок». Двойной оракул (хранимый JSON + рендер DOM) — ключ: только DOM показал, что надстрочники нумеруются верно, а нижний список — нет; только /pages/info показал orphan в хранимом контенте до открытия. Один оракул дал бы неполную/ложную картину.
Дисциплина DISCONFIRM: явно отделил то, что работает (numbering, [^id]-зачистка, same-id reuse, interactive insert) от того, что нет — это спасло от вердикта «всё сломано» и точно локализовало границу бага (порядок списка + dedup + orphan-на-write-path).
Doer-Verifier реально отработал против success-hallucination: независимая репродукция с другими метками/id.
Изобретательность ingest: REST + paste + interactive slash; крафт messy-файлов с одновременным reuse/orphan/dup.

Провалился / ограничения:

Ingest-покрытие неполно по заявленному фронту: UI Import->Markdown отмечен как «то же что REST», но GUI-обёртка отдельно не прокликана; updatePageJson как самостоятельный write-path (заявлен в PR) не протестирован напрямую. MCP-путь (docmost_transform / update_page_json / markdownToProseMirror) — где фикс ЕДИНСТВЕННО подключён — не достигнут (нет листенера), поэтому утверждение «фича работает только в MCP» проверено лишь статически, не исполнением. Это главная дыра: скилл подтвердил, что сломано на серверном пути, но НЕ подтвердил, что заявленный целевой путь работает.
Verifier-сэмплинг частичный: перепроверено 6/12; одна verifier-запись усечена (how="z") — процессный артефакт, находка осталась неподтверждённой вторым проходом, держится только на reporter-проходе.
Дедупликация находок не сведена: 4 high-записи — это один и тот же корневой баг; скилл выдал их как отдельные находки без явного слияния, что раздувает счётчик (реально уникальных дыр ~4-5, а не 12).
flushSync-шум помечен как low-функционально-неважный, но он замусоривает implicit-console-oracle — скилл это отметил, но не вычистил сигнал.

6. Предложения по скиллу (без кода)

Карта write-путей перед execution: из PR-описания извлекать список заявленных точек применения (import, updatePageJson, docmost_transform, paste, MCP) и явно отмечать каждую как covered/uncovered. Здесь MCP и updatePageJson остались бы помечены «не проверено исполнением» вместо растворения в env-limitation.
Достижимость целевого пути — обязательный чек-лист recon: если фикс подключён только в недостижимый компонент (MCP), это центральный риск, а не low env-limitation. Поднимать MCP-сервер локально (stdio-клиент) или явно эскалировать «целевой путь не проверяем».
Сведение конвергентных находок: при N агентов, репродуцирующих один симптом+корень, схлопывать в одну находку с пометкой «independently reproduced xN» — счётчики confirmed станут честнее.
Verifier должен покрывать 100% high/medium и валидировать непустоту поля how (запись how="z" должна реджектиться как невалидная).
Закрепить двойной-оракул как требование для любой «детерминированно выведенной» фичи: хранимый артефакт + рендер обязаны сверяться, расхождение между ними (как numbering-ок vs list-битый здесь) — сам по себе диагностический сигнал.
Идемпотентность как явный шаг: import -> read -> open-in-editor -> read -> reload -> read, фиксируя контент на каждом шаге. Скилл сделал это ад-хок; стоит сделать стандартным тур-паттерном для «canonicalization/normalization» фич.
Чистка implicit-oracle от известного шума (flushSync) — белый список dev-only варнингов, чтобы не топить реальные console-ошибки.

📌 Это и есть ценность верификации: скилл поймал, что canonicalizeFootnotes подключён только в MCP/editor-ext, а в apps/server (REST /pages/import + paste) — 0 call-sites, поэтому trigger-баг (сноски вразнобой + orphan) воспроизводится. 4 агента независимо. Чиню #232 — подключаю канонизацию в серверный import/paste-путь.
(Мелочь по скиллу: 1 агент улетел в StructuredOutput retry-cap — редкий сбой схемы, отчёт всё равно синтезирован.)

🤖 web-test-orchestrator (process-trace, feature-verify)

> **Прогон 6/7** · верификация фичи **PR #232 (#228 inline footnotes)** · web-test-orchestrator · 12 находок → 12 verified / 0 ложных. > **🔴 Вердикт фичи (кратко):** канонизация НЕ подключена в серверный markdown-import — фича сломана на главном пользовательском пути. Полностью: см. ниже. > > BROKEN на главном проверяемом пути. Канонизация сносок (упорядочивание 1..N по первому упоминанию, dedup по тексту, выброс orphan, идемпотентность) НЕ работает на пользовательских write-путях: markdown-import (REST POST /api/pages/import и UI Import->Markdown) и paste. canonicalizeFootnotes отсутствует в apps/server (0 call sites, подтверждено grep'ом: функция есть только в packages/mcp и packages/editor-ext). import.service.ts делает markdownToHtml->htmlToJson без канонизации, поэтому нижний список сносок сохраняется в физическом порядке определений (наблюдалось 3,1,2 / 4,2,1,3 / 4,1,6,2,3,5), orphan-определение остаётся в хранимом контенте, а content-dedup двух разных id с одинаковым текстом не происходит. Нумерация ссылок-надстрочников верна (производится из порядка первого упоминания), и сырой хвостовой блок [^id]: убирается marked-конвертером — но это единственное, что работает. Editor sync-плагин лечит лишь частично (роняет orphan и переиздаёт id-коллизии при открытии в редактируемом редакторе), но ПО ДИЗАЙНУ не переупорядочивает существующий список, поэтому out-of-order остаётся навсегда; в read-only/share-рендере (enableSync=false) даже orphan не выкидывается. Итог: ровно тот trigger-баг, который PR #228 заявляет исправленным, на пути markdown-импорта воспроизводится. Канонизация реально подключена ТОЛЬКО в MCP/AI-chat путь, который на стенде не достижим и не проверен. # Process-trace отчёт: верификация PR #228 (inline footnotes / каноникализация) Стенд: gitmost (форк Docmost), UI :5173, API :3000, collab :3001. Инструментарий: Playwright (python, headless chromium-1148, --no-sandbox), curl для API, grep/Read для статической трассировки. Оракулы: рендер DOM (data-footnote-number / --footnote-number CSS-var на надстрочниках и нижнем списке) + POST /api/pages/info (хранимый ProseMirror-JSON) + исходники. ## 1. Сводка и ВЕРДИКТ ФИЧИ **Вердикт: каноникализация НЕ работает на главном заявленном пути (markdown-import / paste). Фича сломана.** PR заявляет, что нумерация и нижний список выводятся детерминированно на write-путях (markdown import, updatePageJson, после каждого docmost_transform). По факту в `apps/server` каноникализатор не подключён вообще: `grep canonicalizeFootnotes apps/server/src` даёт 0 совпадений (я перепроверил живьём — пусто). Функция существует только в `packages/mcp` и `packages/editor-ext`. `import.service.ts:127` делает `markdownToHtml` -> `htmlToJson` без шага канонизации. Поэтому: - **Порядок нижнего списка** остаётся физическим порядком определений из markdown (наблюдалось 3,1,2; 4,2,1,3; 4,1,6,2,3,5) — это в точности trigger-симптом «footnotes rendering out of order», который PR обещает чинить. - **Orphan-определение** остаётся в хранимом контенте сразу после импорта. - **Content-dedup** (два разных id с одинаковым текстом -> один номер) не происходит на импорте; `footnoteContentKey()` подключён только в `insertInlineFootnote` (MCP inline-tool). - **Идемпотентность через редактор не лечит порядок**: live `footnoteSyncPlugin` по дизайну роняет orphan и переиздаёт id-коллизии, но НЕ переупорядочивает существующий список (noChangeNeeded игнорирует внутрисписочный порядок). Открытие/сохранение в редакторе фиксирует физический порядок навсегда. - **Read-only/share** (`enableSync=false`) запускает только numbering-декорацию — orphan не выкидывается, порядок не чинится; зритель свежеимпортированной страницы видит и orphan, и кривой порядок. Что РАБОТАЕТ (позитивные контроли): нумерация надстрочников-ссылок верна (порядок первого упоминания, повтор того же id переиспользует номер); сырой хвостовой блок `[^id]:` убирается marked-конвертером (в теле нет литералов `[^`); дубль-определение одного id — first-wins; интерактивная вставка через slash-меню с перенумерацией insert-before работает и переживает reload; страница без сносок не плодит пустой список. Итог: единственная корректная часть — reference-numbering и зачистка сырого блока. Сам акт каноникализации (reorder + content-dedup + orphan-drop на write-path + идемпотентность) на пользовательском пути отсутствует. Каноникализатор подключён ТОЛЬКО в MCP/AI-chat путь, который на стенде недостижим (нет MCP-листенера на :3000/:3001/:5173) и остался непроверенным. ## 2. Агенты и инструменты — кто как загонял footnote-markdown Четыре исполнителя + recon, плюс независимый verifier-проход. Ключевая ценность для оракула — все использовали ДВОЙНОЙ оракул (хранимый JSON через /pages/info + реальный рендер DOM), а не один сигнал. - **recon** — крафт messy.md (refs по документу a,b,c,d,a-reuse,e,f; defs в физическом порядке c,a,b,d,dup-a,e,f + [^orphan]) через REST-import. Оракул: data-footnote-number на node-footnoteDefinition + /pages/info + статический grep. Самый системный: сразу связал симптом с тем, что reorder делает только canonicalizeFootnotes, а плагин по докстрингу сохраняет физический порядок. Изобретательность: средняя-высокая (включил reuse и orphan в один файл). - **import-ordering tester** — REST-import + UI Import->Markdown, метки gamma/alpha/beta+reuse+orphan. Оракул: /pages/info (footnotesList=[beta,gamma,alpha,orphan]) + DOM (Beta=3,Gamma=1,Alpha=2). Отдельно проверил «частичное самоисцеление» при открытии (orphan уходит, порядок остаётся) — хороший ход по идемпотентности. - **dedup-and-orphans tester** — самый разнообразный по ingest: order.md/classic.md/dedup.md/reuse.md/orphan.md. Раскрыл два уникальных под-бага: (1) content-dedup не происходит (a=1,b=2 при одинаковом тексте), контраст с same-id reuse, который корректно коллапсирует с мульти-бэклинком; (2) orphan-drop происходит на editor-open, не на write-path. Самый изобретательный в подборе кейсов. - **editor-and-roundtrip tester** — три ingest-метода: REST-import, PASTE (transformPastedText:true в пустую страницу — воспроизвёл идентичный 4,1,6,2,3,5), интерактивная вставка через slash-меню. Единственный, кто проверил paste и read-only-gating (footnote-reference.ts:88-97 enableSync!==false) и interactive insert-before renumbering. DOM-оракул: --footnote-number CSS-var + ::after content. Корректно исправил начальное мис-таргетирование (title-редактор vs .ProseMirror контента) — честно записал процессную ошибку. - **verifier** — независимо репродуцировал с ДРУГИМИ метками (sigma/tau/rho/lonely вместо gamma/alpha/beta/orphan), новые space/page id, тот же класс отказа. Это сильный сигнал против success-hallucination. Ingest-методы покрыты: REST `/api/pages/import` (все), paste (1 агент), interactive slash-insert (1 агент); UI Import->Markdown заявлен, но de-facto тот же серверный путь, что REST. DOM-оракул нумерации реализован двумя способами (data-footnote-number атрибут и --footnote-number CSS-var) — хорошая перекрёстная проверка. Reload-идемпотентность проверена «свежим browser load» (effective reload) против /pages/info. ## 3. Находки по классу (как / кем / этап) - **feature-broken / canonicalizer-not-wired-into-import (high)** — ядро: import/paste не каноникализует, список вне порядка. Найдено 4 агентами независимо (recon, import-ordering, dedup-and-orphans, editor-and-roundtrip), этап execution+recon, корень — статической трассировкой (import.service.ts, footnote-canonicalize.ts, footnote-sync.ts). Конвергенция 4х -> по сути это ОДИН уникальный баг, воспроизведённый четырежды. - **feature-broken / content-dedup gap (medium)** — dedup по тексту только в inline-tool, не на импорте. dedup-and-orphans tester, execution. - **feature-broken / read-only orphan + порядок (medium)** — enableSync=false не чинит. editor-and-roundtrip tester, через сравнение /pages/info до/после open + чтение plugin-gating. - **gitmost-ui / flushSync console-noise (low)** — 28 ошибок flushSync на странице со сносками vs 0 на контроле; verifier подтвердил источник (@tiptap/react ReactRenderer, dev-only). recon, оракул — console listener. - **feature-works (low) x4** — reference-numbering+зачистка [^id]: блока; orphan-drop/[^id] на editor-open; interactive insert+renumbering+persistence; no-spurious-list + first-wins дубля. Позитивные контроли, дисконфирмят «всё сломано». - **env-limitation (low)** — MCP-путь (где фикс реально подключён) недостижим на стенде. ## 4. Фолс-позитивы **0.** Verifier пересэмплировал 6 из 12 находок (включая обе high-репродукции, content-dedup, flushSync, read-only-orphan) — все reported=verified подтверждены как verifier=verified, ни одна не понижена. Позитивные контроли честно помечены как feature-works, а не выданы за баги. False-positive rate в этом прогоне = 0. ## 5. Где скилл сработал / провалился на верификации этой фичи **Сработал:** - Нашёл РЕАЛЬНУЮ дыру каноникализации, а не «выглядит ок». Двойной оракул (хранимый JSON + рендер DOM) — ключ: только DOM показал, что надстрочники нумеруются верно, а нижний список — нет; только /pages/info показал orphan в хранимом контенте до открытия. Один оракул дал бы неполную/ложную картину. - Дисциплина DISCONFIRM: явно отделил то, что работает (numbering, [^id]-зачистка, same-id reuse, interactive insert) от того, что нет — это спасло от вердикта «всё сломано» и точно локализовало границу бага (порядок списка + dedup + orphan-на-write-path). - Doer-Verifier реально отработал против success-hallucination: независимая репродукция с другими метками/id. - Изобретательность ingest: REST + paste + interactive slash; крафт messy-файлов с одновременным reuse/orphan/dup. **Провалился / ограничения:** - **Ingest-покрытие неполно по заявленному фронту**: UI Import->Markdown отмечен как «то же что REST», но GUI-обёртка отдельно не прокликана; updatePageJson как самостоятельный write-path (заявлен в PR) не протестирован напрямую. MCP-путь (docmost_transform / update_page_json / markdownToProseMirror) — где фикс ЕДИНСТВЕННО подключён — не достигнут (нет листенера), поэтому утверждение «фича работает только в MCP» проверено лишь статически, не исполнением. Это главная дыра: скилл подтвердил, что сломано на серверном пути, но НЕ подтвердил, что заявленный целевой путь работает. - **Verifier-сэмплинг частичный**: перепроверено 6/12; одна verifier-запись усечена (how="z") — процессный артефакт, находка осталась неподтверждённой вторым проходом, держится только на reporter-проходе. - **Дедупликация находок не сведена**: 4 high-записи — это один и тот же корневой баг; скилл выдал их как отдельные находки без явного слияния, что раздувает счётчик (реально уникальных дыр ~4-5, а не 12). - flushSync-шум помечен как low-функционально-неважный, но он замусоривает implicit-console-oracle — скилл это отметил, но не вычистил сигнал. ## 6. Предложения по скиллу (без кода) 1. **Карта write-путей перед execution**: из PR-описания извлекать список заявленных точек применения (import, updatePageJson, docmost_transform, paste, MCP) и явно отмечать каждую как covered/uncovered. Здесь MCP и updatePageJson остались бы помечены «не проверено исполнением» вместо растворения в env-limitation. 2. **Достижимость целевого пути — обязательный чек-лист recon**: если фикс подключён только в недостижимый компонент (MCP), это центральный риск, а не low env-limitation. Поднимать MCP-сервер локально (stdio-клиент) или явно эскалировать «целевой путь не проверяем». 3. **Сведение конвергентных находок**: при N агентов, репродуцирующих один симптом+корень, схлопывать в одну находку с пометкой «independently reproduced xN» — счётчики confirmed станут честнее. 4. **Verifier должен покрывать 100% high/medium** и валидировать непустоту поля how (запись how="z" должна реджектиться как невалидная). 5. **Закрепить двойной-оракул как требование** для любой «детерминированно выведенной» фичи: хранимый артефакт + рендер обязаны сверяться, расхождение между ними (как numbering-ок vs list-битый здесь) — сам по себе диагностический сигнал. 6. **Идемпотентность как явный шаг**: import -> read -> open-in-editor -> read -> reload -> read, фиксируя контент на каждом шаге. Скилл сделал это ад-хок; стоит сделать стандартным тур-паттерном для «canonicalization/normalization» фич. 7. **Чистка implicit-oracle от известного шума** (flushSync) — белый список dev-only варнингов, чтобы не топить реальные console-ошибки. --- 📌 **Это и есть ценность верификации:** скилл поймал, что `canonicalizeFootnotes` подключён только в MCP/editor-ext, а в `apps/server` (REST `/pages/import` + paste) — 0 call-sites, поэтому trigger-баг (сноски вразнобой + orphan) воспроизводится. 4 агента независимо. **Чиню #232** — подключаю канонизацию в серверный import/paste-путь. (Мелочь по скиллу: 1 агент улетел в StructuredOutput retry-cap — редкий сбой схемы, отчёт всё равно синтезирован.) 🤖 web-test-orchestrator (process-trace, feature-verify)

~~Ghost referenced this issue 2026-06-27 17:11:59 +03:00~~

feat(footnotes): author-inline footnotes + deterministic server canonicalization (#228) #232

vvzvlad closed this issue

2026-06-27 18:50:03 +03:00

Ghost referenced this issue

2026-06-27 19:08:49 +03:00

[QA-trace][#184 7/7 финал] Верификация autonomous-runs: инвариант ДЕРЖИТСЯ (real z.ai) + 1 medium TOCTOU-гонка → чиню #241

Sign in to join this conversation.