ground-truth-reconcilelisted

# Skill — Ground-truth reconciliation ## Когда подгружается Когда возникает вопрос **«что тут на самом деле сделано?»**: markdown-план говорит `pending`, БД говорит `done`, а в коде лежит рабочая реализация. Триггер-keywords: `reconcile`, `ground truth`, `source of truth`, «сверка», «статусы разъехались», «что реально сделано», «план устарел». Это **не** `drift-handling`. Разница: | | `drift-handling` | `ground-truth-reconcile` | |---|---|---| | Предмет | хэш документа vs файл на диске | статус задачи vs реализация в коде | | Симптом | `stale_export`, `edited_in_place` | «в плане pending, а в коде готово» | | Инструмент | `doc_drift`, `check_stale_refs` | чтение кода + тестов, `plan audit` | | Исход | `doc export` / `import` | `task complete` / `task status` + правка плана | ## Порядок арбитража (не переставлять) 1. **БД (`.cod-doc/state.db`) — source of truth для трекаемых задач.** Статус задачи определяется записью в БД, а не markdown-таблицей. 2. **Код — арбитр при расхождении.** Если БД и markdown спорят, смотрим, что реально реализовано, и приводим обоих к коду. 3. **markdown Progress Overview — вторичен.** Пересобирается из БД. ## Что считается доказательством «сделано» Заявить `done` можно только с **тремя** ссылками: - **Реализация** — `file.py:line` с именем функции/класса, а не «есть в сервисе». - **Покрытие** — конкретный тест-файл (лучше — имя теста), который её гоняет. - **Acceptance** — построчная сверка с полем `acceptance` задачи. Нет теста → з