| 1 | # Playbook: свежесть знаний в каноне (agent entry) — v1 |
| 2 | |
| 3 | **Назначение:** **одна точка входа для агента**, когда задача про **устаревание или перепроверку любого знания** в `knowledge/` — не только .NET: гуманитарные карточки, психология, HCI, продуктовые runbook’и, evidence, слои **fundamentals → operational**, поля `Проверено:` / provenance, `deprecated` / `supersedes`, «куда записать обновление». Не заменяет доменные playbook’и — **сужает** выбор файлов и порядок действий. |
| 4 | |
| 5 | **Среда-независимость:** текст в `knowledge/`; чтение через MCP `read_knowledge_file` или локальный клон. |
| 6 | |
| 7 | **Связь:** |
| 8 | - `templates/template-knowledge-card-v1.md` (Provenance, Core Unit, Operationalization, Lifecycle) |
| 9 | - `META/provenance-contract-v1.md` |
| 10 | - Layer contract (пример): `worlds/evidence-humanities-shelf/kb-covey-7-habits-evidence-v1.md` § Layer contract |
| 11 | - `playbook-knowledge-engineering-core-v1.md` (§ Deprecation, Operating rhythm, quality gates) |
| 12 | - `index-knowledge-router-supplement-v1.md` → `router-kb-operational-freshness` |
| 13 | - `playbook-learn-basics-when-stuck-v1.md` — если неясна **семантика** предмета, сначала матчасть, потом правка kb |
| 14 | - `runbook-kb-mcp-access-v1.md` — если **не читается** канон |
| 15 | - Карта трёх контуров (агент-диспетчер, без PWA): `domains/agent-operations/map-kb-three-contours-v1.md` |
| 16 | - Идея UI для людей (не обязательна агенту): `work/projects/door-to-singularity/kb-management-center/README.md` |
| 17 | |
| 18 | **Версия:** v1.2 · 2026-05-16 — явная связь с **Maintenance Policy** доменов и **Maintenance Rule** роутера (разные сущности). v1.1 — слои fundamentals/operational. |
| 19 | |
| 20 | **Не путать с Maintenance Rule роутера:** `index-knowledge-router-maintenance-v1.md` § Maintenance Rule — только **сопровождение индекса** (supplement, Domain Entry Map, `router-*`, kb-public). **Свежесть знаний** — этот playbook + **`status-*` § Maintenance Policy / Next review triggers** по домену. |
| 21 | |
| 22 | --- |
| 23 | |
| 24 | ## 1. Когда открывать этот playbook (триггеры) |
| 25 | |
| 26 | - «Устарело», «просрочено», «давно не проверяли», «актуально ли», «перепроверить kb» |
| 27 | - **`Проверено:`**, `updated_at`, `source_refs`, `deprecated`, `supersedes`, `status: draft` |
| 28 | - Смена **источника правды** (издание книги, новая спецификация, релиз платформы, bump пакета, смена политики в `status-*` § Next review triggers) |
| 29 | - «Какой файл править», «куда записать факт», «операционка vs фундаментал» |
| 30 | - Сомнение: kb **противоречит** первоисточнику, репо или более свежему `playbook-*` / `status-*` |
| 31 | |
| 32 | **Не открывать** для первичной навигации по домену без вопроса свежести — сначала `index-knowledge-router-v1.md` (Domain Entry Map). |
| 33 | |
| 34 | --- |
| 35 | |
| 36 | ## 2. Слои знания и где уже зафиксированы сроки |
| 37 | |
| 38 | Перед выбором файлов из §5 определить **слой** целевого знания. Один домен (JS, психология, CIDE) может иметь **оба** слоя в разных файлах. |
| 39 | |
| 40 | ### 2.1 Слои (навигация, не дублировать доменные playbook) |
| 41 | |
| 42 | | Слой | Что хранит | Маркеры в каноне | |
| 43 | |------|------------|------------------| |
| 44 | | **Fundamentals** | Определения, модели, «как устроено» | Секции **Fundamentals**; `kb-*-fundamentals-v1.md`; Core Unit в карточке | |
| 45 | | **Operational** | Процедуры, версии, «что делаем сейчас» | `playbook-*-operational-v1.md`; **Operationalization**; `operational.md` в `work/projects/…` | |
| 46 | | **Evidence / snapshot** | Факт + URL/строка; снимок версий | `EV-*`, **`Проверено:`**; таблицы пакетов в project kb | |
| 47 | |
| 48 | **Контракт слоёв:** `templates/template-knowledge-card-v1.md`; пример **Layer contract** — `kb-covey-7-habits-evidence-v1.md`. Ответственность агента за слои — [`playbook-agent-knowledge-responsibility-v1.md`](../../domains/agent-operations/playbook-agent-knowledge-responsibility-v1.md). |
| 49 | |
| 50 | **Порядок загрузки в домене:** `status-*` → operational playbook → fundamentals kb → evidence (см. Retrieval hint в том же `status-*`). |
| 51 | |
| 52 | ### 2.2 Где в каноне уже лежат правила перепроверки (источник правды) |
| 53 | |
| 54 | | Уровень | Файл | Что там | |
| 55 | |---------|------|---------| |
| 56 | | **Роутер (редакторы)** | `index-knowledge-router-maintenance-v1.md` § **Maintenance Rule** | Сплит supplement, Domain Entry Map, список `router-*` — **не** сроки свежести kb | |
| 57 | | **Домен** | `status-<domain>-v1.md` | **`Maintenance Policy`**, **`Next review triggers`** — событийные и плановые триггеры **этого** мира (PHP, JS, psychology, aviation, git, KE, …) | |
| 58 | | **Meta KE** | `playbook-knowledge-engineering-core-v1.md` § **Operating Rhythm** | micro / weekly / biweekly / monthly для карточек и deprecation | |
| 59 | | **Meta KE** | `status-knowledge-engineering-v1.md` § **Maintenance Policy** | refresh cadence meta-домена | |
| 60 | | **Governance** | `kb-knowledge-engineering-operations-rules-v1.md` (напр. KC-177) | домен без maintenance policy → silent decay; нужны refresh triggers | |
| 61 | |
| 62 | **Порядок для агента:** сначала **`status-*` целевого домена** (если есть Maintenance Policy / Next review triggers) — **они сильнее** общих эвристик ниже. Этот playbook только **сводит слои и маршрут**; новые глобальные TTL сюда **не изобретать**. |
| 63 | |
| 64 | ### 2.3 Если в домене нет явной политики |
| 65 | |
| 66 | - Спросить держателя канона или зафиксировать **в `status-*`** при закрытии домена (см. KC-177). |
| 67 | - Временная эвристика только до появления политики: fundamentals — реже (событие + долгий цикл); operational/evidence — при расхождении с источником и по событиям релиза/bump. |
| 68 | |
| 69 | **Приоритет при конфликте:** `status-*` / доменный `playbook-*` сильнее устаревшего `kb-*`; эпистемика L0 — не усиливать непроверённое. |
| 70 | |
| 71 | --- |
| 72 | |
| 73 | ## 3. Быстрый порядок (≤ 60 с) |
| 74 | |
| 75 | | Шаг | Действие | |
| 76 | |-----|----------| |
| 77 | | 1 | Определить **слой** (§2): fundamentals / operational / evidence | |
| 78 | | 2 | Классифицировать **тип задачи** (§4): домен / стек / возраст / lifecycle / слои канона | |
| 79 | | 3 | Открыть **только** строки реестра §5 для типа (+ `project-id` из `[PRIMARY:…]` для `work/projects/…`) | |
| 80 | | 4 | Сверить с **источником правды** (книга/спека, официальная дока, репо, `composer.lock` / `csproj` — по смыслу слоя) | |
| 81 | | 5 | Правка: факт + **provenance**; для evidence — **`Проверено: YYYY-MM-DD`**; для карточек — `updated_at`, при необходимости lifecycle | |
| 82 | | 6 | Если знание неверно и не чинится точечно → `deprecated`, `superseded_by` (`playbook-knowledge-engineering-core-v1.md`) | |
| 83 | |
| 84 | --- |
| 85 | |
| 86 | ## 4. Типы задач |
| 87 | |
| 88 | | Тип | Примеры запроса | Куда смотреть в §5 | |
| 89 | |-----|-----------------|-------------------| |
| 90 | | **0. Слой / плановая перепроверка** | «просрочен fundamentals», «когда проверять operational», обход `Проверено:` | `knowledge-layers` + целевой домен (`domain-entry`) | |
| 91 | | **A. Домен (без привязки к .NET)** | устарел kb по психологии, HCI, авиации, книге | `domain-entry` → status → playbook домена | |
| 92 | | **B. Платформа / рантайм** | новый .NET, TFM, PHP 8.x, ECMA edition | `dotnet-platform`, `php-laravel`, `javascript-cluster`, … | |
| 93 | | **C. UI / продукт / пакеты** | Avalonia bump, таблица NuGet vs `csproj` | `avalonia-cide`, `project-card-evidence` | |
| 94 | | **D. Возраст / provenance** | старый `updated_at`, битые URL, нет `source_refs` | `provenance-meta` + файл | |
| 95 | | **E. Слои канона (personal/org/public)** | куда писать, kb-public | `layers-publishing` | |
| 96 | | **F. MCP** | не читается kb | `mcp-access` | |
| 97 | |
| 98 | Тип **0** выполнять **перед** A–F, если вопрос именно про «какой слой и какой горизонт перепроверки». |
| 99 | |
| 100 | --- |
| 101 | |
| 102 | ## 5. Реестр: «что отслеживать → какие файлы открыть» |
| 103 | |
| 104 | Загружать **по одному–два kb + один playbook** за раз, не весь список. |
| 105 | |
| 106 | ### `knowledge-layers` |
| 107 | |
| 108 | | Триггер | Файлы (порядок) | |
| 109 | |---------|------------------| |
| 110 | | Неясно fundamentals vs operational | §2 этого playbook → `templates/template-knowledge-card-v1.md` → пример Layer contract: `kb-covey-7-habits-evidence-v1.md` | |
| 111 | | Ритм / политика перепроверки (канон) | `status-<domain>-v1.md` § Maintenance Policy / Next review triggers → при meta KE: `playbook-knowledge-engineering-core-v1.md` § Operating Rhythm · `status-knowledge-engineering-v1.md` § Maintenance Policy · KC-177 в `kb-knowledge-engineering-operations-rules-v1.md` | |
| 112 | | **Не** сроки свежести kb | `index-knowledge-router-maintenance-v1.md` § Maintenance Rule — только индекс роутера | |
| 113 | | Provenance на любой существенной правке | `META/provenance-contract-v1.md` | |
| 114 | |
| 115 | ### `domain-entry` |
| 116 | |
| 117 | | Триггер | Файлы (порядок) | |
| 118 | |---------|------------------| |
| 119 | | Любой **не-.NET** домен или «устарело в мире X» | `index-knowledge-router-v1.md` — строка Domain Entry Map → **`status-<domain>-v1.md`** → доменный **`playbook-*`** → **один** целевой `kb-*` (fundamentals и/или operational по §2, не все сразу) | |
| 120 | | Fundamentals → operational в домене | supplement § `router-<domain>` (напр. `router-human-perception`, `router-javascript`) | |
| 121 | | Плановая перепроверка домена | `status-*` § **Next review triggers** / **Maintenance policy** — событийные триггеры важнее календаря | |
| 122 | |
| 123 | ### `dotnet-platform` |
| 124 | |
| 125 | | Триггер | Файлы (порядок) | |
| 126 | |---------|------------------| |
| 127 | | .NET / TFM / SDK / миграция | supplement § `router-dotnet` → `worlds/software-dotnet-csharp/kb-dotnet-fundamentals-v1.md` → при миграции `kb-dotnet-playbooks-v1.md` → при инженерных фактах `worlds/software-engineering-evidence/kb-engineering-evidence-v1.md` | |
| 128 | | C# / Roslyn / диагностики | `worlds/software-dotnet-tooling-roslyn/playbook-csharp-roslyn-mcp-diagnostics-v1.md` | |
| 129 | | CIDE: runtime vs Learn | `work/projects/door-to-singularity/cascade-ide/kb-dotnet-runtime-reference-stance-v1.md` | |
| 130 | |
| 131 | ### `php-laravel` / `javascript-cluster` |
| 132 | |
| 133 | | Триггер | Файлы | |
| 134 | |---------|--------| |
| 135 | | PHP / Laravel / WP / Drupal | supplement § `router-php-laravel` → `status-php-laravel-v1.md` § Next review triggers → cluster index + один `kb-php-*` / `kb-laravel-*` | |
| 136 | | JavaScript / npm / CSP | supplement § router JS → `playbook-javascript-operational-v1.md` § fundamentals → operational | |
| 137 | |
| 138 | ### `avalonia-cide` |
| 139 | |
| 140 | | Триггер | Файлы (порядок) | |
| 141 | |---------|------------------| |
| 142 | | Avalonia / Dock / CIDE UI | supplement § `router-avalonia-ui` → `status-avalonia-cascade-ide-ui-v1.md` → operational playbook → `kb-avalonia-ui-dock-fundamentals-v1.md` | |
| 143 | | Таблица пакетов vs факт | `work/projects/door-to-singularity/cascade-ide/kb-cide-evidence-card-spec-v1.md` + `CascadeIDE.csproj` | |
| 144 | | Мёртвые URL / VerifyAccess | `kb-avalonia-docs-vs-source-notes-v1.md` | |
| 145 | |
| 146 | ### `project-card-evidence` |
| 147 | |
| 148 | | Триггер | Файлы (порядок) | |
| 149 | |---------|------------------| |
| 150 | | Любой **`project-id`** в `work/projects/…` | README карточки → локальные `kb-*` / `EV-*` / `operational.md` | |
| 151 | | После bump зависимостей | обновить снимок и **`Проверено:`** в spec/evidence; не дублировать в корень `knowledge/` без причины | |
| 152 | |
| 153 | ### `provenance-meta` |
| 154 | |
| 155 | | Триггер | Файлы | |
| 156 | |---------|--------| |
| 157 | | Существенная правка факта | `META/provenance-contract-v1.md` + `templates/template-knowledge-card-v1.md` | |
| 158 | | Новая карточка | шаблон + `playbook-knowledge-engineering-core-v1.md` § Promotion quality gates | |
| 159 | |
| 160 | ### `layers-publishing` |
| 161 | |
| 162 | | Триггер | Файлы | |
| 163 | |---------|--------| |
| 164 | | personal / org / public | `kb-one-pager-structure-and-protocols-v1.md` § слои; `PUBLISHING.md`; `playbook-multi-project-context-v1.md` §6c | |
| 165 | |
| 166 | ### `mcp-access` |
| 167 | |
| 168 | | Триггер | Файлы | |
| 169 | |---------|--------| |
| 170 | | MCP не читает kb | `runbook-kb-mcp-access-v1.md` | |
| 171 | |
| 172 | --- |
| 173 | |
| 174 | ## 6. Чеклисты (коротко) |
| 175 | |
| 176 | ### Плановая перепроверка по слою |
| 177 | |
| 178 | 1. Открыть **`status-<domain>-v1.md`** — § Maintenance Policy / Next review triggers (§2.2). |
| 179 | 2. Классифицировать файл: **fundamentals / operational / evidence** (§2.1). |
| 180 | 3. **Fundamentals:** сверить с первоисточником; `falsification_trigger`; `updated_at` / `source_refs`. |
| 181 | 4. **Operational:** события из status + текущий процесс/репо; обновить operational playbook при смене практики. |
| 182 | 5. **Evidence:** **`Проверено:`**; при несовпадении с репо/докой — исправить evidence или правило продукта. |
| 183 | |
| 184 | ### После релиза платформы или bump пакетов (operational / evidence) |
| 185 | |
| 186 | 1. Событийный триггер из `status-*` или project spec. |
| 187 | 2. Только релевантные строки §5 (`dotnet-platform`, `avalonia-cide`, …) — не весь supplement. |
| 188 | 3. Источник правды: release notes / Learn / lockfile / `csproj`. |
| 189 | 4. **`Проверено:`** + provenance в затронутых файлах. |
| 190 | |
| 191 | ### После правки гуманитарной / книжной карточки (fundamentals) |
| 192 | |
| 193 | 1. Сверка формулировок с изданием (`source_refs`, якоря страниц при наличии). |
| 194 | 2. **Operationalization** в карточке — отражает ли текущую практику команды; если нет — обновить operational слой, не раздувать fundamentals. |
| 195 | 3. `updated_at`; при смене смысла — `supersedes` / новая карточка. |
| 196 | |
| 197 | --- |
| 198 | |
| 199 | ## 7. Что писать пользователю |
| 200 | |
| 201 | - **Слой** (fundamentals / operational / evidence) и **тип** задачи. |
| 202 | - **1–3 файла** (пути) и **источник правды**. |
| 203 | - Если менялся только полный канон / `work/` — явно сказать; kb-public требует сборки (`PUBLISHING.md`). |
| 204 | |
| 205 | --- |
| 206 | |
| 207 | ## 8. Антипаттерны |
| 208 | |
| 209 | - Сводить свежесть kb **только к .NET** — сначала §2 и Domain Entry Map. |
| 210 | - Грузить **все** fundamentals домена при точечном operational вопросе. |
| 211 | - Обновлять kb **без** provenance / даты после смены факта. |
| 212 | - Путать **свежесть** с **первичным изучением** домена (`playbook-learn-basics-when-stuck-v1.md`). |
| 213 | |
| 214 | --- |
| 215 | |
| 216 | ## 9. Версия |
| 217 | |
| 218 | v1.2 · 2026-05-16 — делегирование сроков в `status-*` Maintenance Policy / KE Operating Rhythm; отличие от router Maintenance Rule. |
| 219 | v1.1 · 2026-05-16 — слои fundamentals/operational/evidence. |
| 220 | v1.0 · 2026-05-16 — первая централизация agent UX (KBMC — отдельный PWA). |
| 221 | |
| 222 | |