Context Compression

Context Compression — скилл сжатия исторического контекста

Зачем этот скилл

meeting-processing должен разбирать текущую встречу, а не держать всю историю контура в окне контекста. Этот скилл поддерживает отдельный сжатый слой истории, чтобы агент мог восстановить причинную цепочку без чтения десятков старых встреч.

Главный выход скилла — meetings/README.md в головном проекте контура или в папке встреч проекта. Это не пересказ всех встреч, а навигационная память: что решили, что изменили, что устарело, какие вопросы ещё открыты и какие встречи являются якорными.

meetings/README.md не заменяет текущую картину проекта или продукта. Если нужен ответ «что сейчас главное», он живёт в отдельной текущей картине, объявленной в README.md или context.md, по правилу Память vault.

Принципы

1. Сжатие отдельно от разбора. Скилл не извлекает задачи из новой встречи и не маршрутизирует их в plan.md / tasks.md. Это делает meeting-processing.
2. Ограниченное чтение. Запрещено читать все старые встречи целиком. Полностью читаются только ближайшие и явно связанные встречи.
3. Решения важнее пересказа. В сжатой истории хранятся цепочки решений: «было → изменилось → почему → ссылка».
4. Устаревшее видно явно. Если старое решение отменено или переопределено, оно остаётся в сжатой истории как superseded, чтобы агент не принял его за актуальное.
5. Каждый пункт со ссылкой. Любой сжатый факт должен ссылаться на исходную встречу или log.md.
6. Сжатие тоже ограничено. meetings/README.md не должен становиться новым длинным архивом: если он разрастается, старые цепочки сворачиваются в годовой файл истории.
7. Публичность проверяется до записи. Сжатый слой часто видят больше людей, чем отдельные заметки. Не концентрируй в нём персональные оценки, конфликты, деньги и чувствительные детали без явного основания.
8. История не равна текущей картине. После обновления meetings/README.md проверь, не нужно ли отдельно обновить текущую картину проекта или продукта. Не подменяй её сжатой историей встреч.
9. Сводка не равна истине. Сжатая история хранит ссылку на источник, тип утверждения, основание и статус доверия для важных цепочек решений.
10. Слабое не повышается молча. Пункты с evidence.strength: low, историческими ссылками без источника или устаревшим last_verified не используются как факты текущей картины.
11. Конфликт сохраняется. Если старое и новое утверждения противоречат друг другу, создать или обновить конфликт, а не сглаживать формулировку.

Когда запускать

Запускай скилл в трёх режимах:

Алгоритм

Шаг 0. Определить место сжатой истории

1. Определи контур или проект по правилам AGENTS.md.
2. Найди папку встреч:
   • для контура: <головной проект>/meetings/ или путь из карты контура;
   • для проектной папки: <project>/materials/meetings/ или существующая папка, где уже лежат встречи.
3. Основной файл сжатия: meetings/README.md.
4. Если папка встреч содержит меньше 3 встреч, отдельный файл сжатия обычно не нужен. Достаточно ссылок из log.md.
5. Для новых индексов используй шаблон meetings_readme.md.

Шаг 1. Собрать карту без полного чтения

Сначала собери список встреч по именам файлов, frontmatter, заголовкам и секциям ## Суть / ## Связи. Не читай тела всех встреч.

Минимум для каждой встречи:

• дата;
• тема;
• участники, если есть;
• 1–2 предложения из ## Суть;
• ссылки из ## Связи;
• явные маркеры: «реверс», «отменено», «предыдущая встреча», «после паузы», «возвращаемся».

Шаг 2. Выбрать окно полного чтения

Полностью можно читать только:

• последние 2–3 релевантные встречи;
• до 2 явно связанных старых якорных встреч;
• встречу, на которую новая встреча ссылается как на источник отменённого или подтверждённого решения.

Жёсткий предел: если выбранные старые встречи суммарно становятся больше примерно 25–35 тысяч слов, сократи окно и работай через уже сжатые секции.

Если встреча содержит ссылку вида «как обсуждали раньше», но источник не найден:

• не читай всю историю;
• зафиксируй историческая ссылка без источника;
• попроси владельца уточнить или оставь пометку в meetings/README.md.

Шаг 3. Проверить публичность и чувствительность

Перед записью в meetings/README.md классифицируй слой:

Если сомневаешься, в сжатой истории оставь нейтральную формулировку и ссылку на исходную встречу. Деталь остаётся в исходнике, если он уже имеет правильную область видимости.

Шаг 4. Обновить meetings/README.md

Рекомендуемая структура:

# Meetings

## Суть
Краткая память по встречам контура: последние встречи, цепочки решений, открытые вопросы и якорные источники.

## Последние встречи
| Дата | Встреча | Главный итог | Ссылка |
|------|---------|--------------|--------|

## Цепочки решений
### <тема>
- YYYY-MM-DD: было принято <решение> → [встреча](./meeting-....md)
  - Trust: `claim_type: decision`; `confidence: high | medium | low`; `last_verified: YYYY-MM-DD`; `write_policy: human_review_required`
  - Evidence: <короткая цитата или точное основание>
- YYYY-MM-DD: решение изменено: <что стало иначе>; причина: <коротко> → [встреча](./meeting-....md)
  - Supersedes: <старое решение>
  - Related conflict: <ссылка, если есть>
- Текущий статус: <актуальная формулировка>

## Устаревшие решения
- <решение> — устарело с YYYY-MM-DD, заменено на <новая формулировка> → [источник](./meeting-....md)

## Открытые вопросы
- <вопрос> — с какой встречи тянется, где искать следующий вход.

## Якорные встречи
- [YYYY-MM-DD — тема](./meeting-....md): почему это якорь.

## Архивные цепочки
- Если активных цепочек стало больше 7 или файл стал слишком длинным, старые цепочки перенести в `history-YYYY.md` и оставить здесь 1 строку-ссылку.

## Исторические ссылки без источника
- <формулировка из встречи> — источник не найден; `evidence.kind: unknown`; `evidence.strength: low`; нужна ручная привязка. Не использовать как основание текущей картины.

Не добавляй длинные пересказы. Один пункт — одна мысль — одна ссылка.

Ограничения размера:

• ## Последние встречи: максимум 5 строк;
• ## Цепочки решений: максимум 7 активных цепочек;
• ## Открытые вопросы: максимум 10 пунктов;
• длинные архивные цепочки выносить в meetings/history-YYYY.md только когда это реально нужно, не заранее.

Шаг 5. Использование перед meeting-processing

Перед разбором новой встречи верни для meeting-processing компактный пакет:

## Сжатый исторический контекст
- Файл сжатия: <путь>
- Читать полностью: <список 2–3 последних встреч и якорей>
- Не читать полностью: <старые встречи, покрытые сжатием>
- Актуальные цепочки решений: <3–7 пунктов>
- Устаревшие решения, которые нельзя принимать за актуальные: <список>
- Исторические ссылки без источника: <список, если есть>
- Слабые или спорные утверждения: <список>
- Конфликты памяти: <список>

meeting-processing использует этот пакет как часть линзы разбора и не углубляется в старые встречи за пределами окна.

Шаг 6. Обновление после новой встречи

После записи саммари встречи обнови meetings/README.md, если выполнено хотя бы одно условие:

• встреча отменила или изменила прежнее решение;
• появилась новая стратегическая развилка;
• закрыт или открыт долгий вопрос;
• после последнего сжатия накопилось 3+ новых встречи;
• встреча стала якорной для будущего разбора.

Если новая встреча обычная и ничего не меняет, достаточно добавить её в ## Последние встречи.

Шаг 7. Кросс-контурные встречи

Если встреча затрагивает несколько контуров:

• сжатая история живёт в основном контуре встречи;
• во втором контуре не дублируй цепочку решений целиком;
• во втором контуре допустима короткая ссылка в log.md или одна строка в meetings/README.md: «связано с решением в <основной контур>»;
• если решение реально меняет два контура независимо, в каждом контуре фиксируется только его собственная часть решения и ссылка на основное саммари.

Шаг 8. Отчёт о чтении

В конце работы покажи короткий отчёт:

Полностью прочитано:
- <файл встречи>

Использовано через сжатие:
- <meetings/README.md>

Не читалось:
- старые встречи вне окна

Если полностью прочитано больше 5 старых встреч, объясни почему. Без объяснения это считается нарушением принципа ограниченного чтения.

Что скилл НЕ делает

• Не маршрутизирует задачи, обещания и блокеры.
• Не пишет в context.md эпизодические факты.
• Не заменяет log.md: события всё равно фиксируются в log.md, а meetings/README.md хранит историческую навигацию.
• Не заменяет текущую картину проекта или продукта.
• Не создаёт отдельный файл сжатия на каждую тему, пока meetings/README.md справляется.
• Не читает всю папку встреч целиком ради осторожности.
• Не дублирует сжатые цепочки в нескольких контурах.
• Не делает публичный индекс местом для чувствительных деталей.

Проверка

Перед завершением проверь:

• Старые встречи не читались целиком без отбора.
• Полное окно чтения ограничено последними / явно связанными встречами.
• Все пункты сжатой истории имеют ссылки на источники.
• Важные пункты имеют claim_type, confidence, last_verified и основание.
• Устаревшие решения отделены от актуальных.
• Слабые, спорные и исторические пункты не поданы как текущая реальность.
• Конфликты не сглажены в сводке.
• Проверена публичность: чувствительные детали не сконцентрированы в общем meetings/README.md.
• Размер meetings/README.md не нарушает ограничения; при необходимости старое вынесено в history-YYYY.md.
• Для кросс-контурной встречи нет полного дублирования цепочек решений.
• Отчёт о чтении показывает, какие старые встречи читались полностью, а какие использованы через сжатие.
• meeting-processing получает краткий пакет, а не список всех старых файлов.
• Если создан или изменён meetings/README.md, обновлены связанные README.md / log.md по протоколу записи.
• Если README.md или context.md объявляет текущую картину, проверено, нужно ли её пересобрать отдельно.