feat(skills): add session-health v0.1.0 — react to poller context warnings (warn/propose/refuse)

Triggered by [session-health] messages from pi poller extension; maps level to action: warn=plan wind-down, propose=closing ritual (handoff after operator consent), refuse=no new work. Companion to OpeItcLoc03/pi-extensions extensions/session-health.ts.
This commit is contained in:
2026-08-23 14:01:28 +03:00
parent 08de3a79fc
commit f1bd046ac0

View File

@@ -0,0 +1,93 @@
---
name: session-health
author: ours
version: 0.1.0
description: >
Реагировать на предупреждения session-health поллера pi (сообщение
«[session-health warn/propose/refuse] ...» с цифрами контекста) ИЛИ на
собственное подозрение, что сессия раздулась: вычислить текущий контекст
против эффективного окна модели и принять решение — планировать
сворачивание (warn), предложить closing ritual (propose), отказаться от
новой работы (refuse). Триггеры: сообщение от поллера `[session-health]`,
«проверь сессию», «не раздувай контекст», подозрение что контекст большой,
длинная сессия без сворачивания. НЕ про перфоманс-анализ кода и НЕ про
закрытие сессии по инициативе оператора без поллер-сигнала (→ session-handoff).
---
# session-health
Что делать, когда поллер pi (`extensions/session-health.ts`) прислал
предупреждение о размере контекста — или когда сам агент подозревает, что
сессия раздулась. Поллер — единственный источник точных цифр: footer-статус
(`14.6%/1.0M`) и `/session` агент (LLM) **не видит** — это TUI для человека.
## When to use
- Агент получил user-сообщение вида `[session-health ⚠ warn|🔴 propose|🚫 refuse] ...` — поллер пересек порог (он проверяет контекст на каждый ход, один раз на уровень, сброс при падении ниже порога).
- Оператор спрашивает «проверь сессию», «не пора сворачиваться» — честно: точных цифр без поллера не видишь, оценивай длину сессии грубо.
- Агент сам замечает признаки раздувания: сессия очень длинная, много ходов,
«не помню начало», повторяющиеся подсказки — оценивать осторожно, не паниковать.
- Оператор просит начать крупную новую работу, а контекст уже близок к потолку.
## Inputs
- Сообщение поллера: уровень (`warn` / `propose` / `refuse`), токены контекста,
процент эффективного окна, модель.
- (Опционально) собственное ощущение длины сессии — не точное.
## Модель принятия решения
Метрика — **текущий размер контекста** против **эффективного окна модели**
(quality-потолок, НЕ объявленное окно: у deepseek-v4-flash объявлено 1M,
эффективное 400K). Пороги — % от эффективного окна:
| Уровень | % эффективного окна | Действие |
|---|---|---|
| `warn` | 70% | Планируй сворачивание: завершай текущую единицу работы, не начинай новых крупных. |
| `propose` | 85% | **Предложи closing ritual** (скил session-handoff): handoff-write в `.tasks/NEXT_SESSION.md` + сводка; рекомендация, не обязаловка. |
| `refuse` | 100% | **Отказ от новой работы.** Только завершение: closing ritual и сворачивание. |
Числа по умолчанию (deepseek-v4-flash, эффективное 400K): warn 280K / propose
340K / refuse 400K. Другие модели — в конфиге поллера (дефолты в коде).
## Steps
1. **Понять, откуда сигнал.**
- Поллер прислал `[session-health <уровень>]` — уровень и цифры уже в сообщении, доверяй им (поллер читает `ctx.getContextUsage()` — точные данные).
- Сигнала нет, но подозреваешь раздувание — не выдумывай цифры: кратко сообщи оператору, что точных метрик не видишь (footer для LLM невидим), и либо попроси поллер-статус, либо действуй по ощущению консервативно (длинная сессия без сворачивания → предложи закрытие по правилу propose).
2. **Сопоставить уровень с действием** (таблица выше).
3. **warn** — ничего не инжектить обратно, не паниковать, не останавливаться посреди работы: заверши текущую единицу (ответ на текущий вопрос оператора), затем явно скажи «контекст на warn-уровне (X%), предлагаю на этом завершить сессию» и предложи closing ritual при следующем удобном моменте.
4. **propose** — предложи closing ritual:
- Это **предложение** оператору, не принуждение: «рекомендую завершить, контекст 85%+; закругляемся?» Оператор может продолжить — тогда работай дальше, но помни что контекст некомфортный (будь короче, не тяни лишние чтения).
- Handoff-write в `.tasks/NEXT_SESSION.md` (скил `session-handoff`) — **только после явного согласия оператора** на сворачивание. Без согласия — не пиши.
- Опционально (если оператор согласен и есть кандидаты): предложи wiki-ingest сессионного знания и закрытия тасок с доски — тоже как предложения, не мутации.
5. **refuse** — жёсткий отказ:
- НЕ начинай новую работу, НЕ бери новые задачи, НЕ открывай новые файлы для анализа.
- Только: заверши текущий ответ (если в процессе), предложи/выполни closing ritual (handoff), сверни сессию. Если оператор настаивает на новой работе — объясни: контекст на потолке эффективного окна, качество деградирует; предложи `/compact` или новую сессию с handoff.
6. **После решения** — действуй по session-handoff (`session-handoff` skill) для закрытия.
## Failure modes
- **Нет точных метрик, а поллер молчит** — не выдумывай проценты. Честно: «точных метрик не вижу, поллер не сработал». Консервативно: очень длинная сессия → предложи сворачивание по правилу propose.
- **Оператор продолжает работать после propose** — это норма (рекомендация, не обязаловка). Работай, но экономь контекст: короче ответы, не перечитывай файлы без нужды.
- **Поллер прислал warn, а работа в самом разгаре** — не дёргайся посреди хода: заверши текущую единицу, предупреди на следующем ходу.
- **Refuse у reasoning-модели** — поллер уже скорректировал (сверил с оценкой по сообщениям); доверяй его вердикту.
## Side effects
- При propose/refuse — пишется `.tasks/NEXT_SESSION.md` (handoff) и предлагаются wiki-ingest / закрытие тасок.
- Отказ от новой работы (refuse) может расстроить оператора — объясни почему, предложи альтернативу (новая сессия).
## What NOT to do
- Не парсить session JSONL руками — метрики уже собираются поллером (`ctx.getContextUsage()`), дублировать парсер незачем.
- Не игнорировать `refuse` — это жёсткий порог, не рекомендация.
- Не превращать warn в панику: warn = «планируй», не «стоп сейчас».
- Не выдумывать цифры контекста, если поллер молчит.
- Не запускать closing ritual молча на warn — на warn только планирование; ritual — на propose/refuse.
- Не писать handoff без явного согласия оператора (propose = рекомендация, не принуждение).