Дмитрий
fe922c3091
Groups documentation produced during 2026-05-28 brain-retro session: retro notes 8 (carryover) and 9, self-retrospect 1, sanity check JSON, three Phase plans for router-hooks fixes. All implementation already pushed in earlier commits — this commit groups artifact metadata. Plus typo fixes in self-retrospect (agregatov, seryj) and cspell vocab extensions for session-specific terms (PAMYATKA / procs / russian verbs). Pure documentation. No code, no normative drift.
16 KiB
brain-retro #8 — 2026-05-27 13:00 UTC
Период: 2026-05-27 03:55 UTC (после retro #7) → 2026-05-27 12:38 UTC (≈8.7 ч). Эпизодов: 67 (после dedupe + observer-errors filter; observerErrors=0). Задач (grouping): 33. Reviewer: batch mode (67 ≥ 20), Opus 4.7 / ProxyAPI, 67/67 reviewed, 0 errors, wall-clock 140.7с.
1. Семь обязательных цифровых срезов
[1] Path-type breakdown
| path_type | count | % |
|---|---|---|
| improvised | 65 | 97.0% |
| regulated | 2 | 3.0% |
65 из 67 — improvised. На уровне retro #7 (95.7%), второй день подряд почти без skill-invocation.
[2] node_chosen distribution (top-15)
| node | count | % |
|---|---|---|
| direct | 64 | 95.5% |
| superpowers:using-git-worktrees | 1 | 1.5% |
| superpowers:brainstorming | 1 | 1.5% |
| subagent-driven-development | 1 | 1.5% |
64 из 67 — direct. Только 3 явных skill-вызова за 8.7 часов работы.
[3] recommended_node distribution
| recommended | count | % |
|---|---|---|
| null (нет рекомендации) | 60 | 89.6% |
| #37 (mermaid-skill) | 4 | 6.0% |
| #18 (Pest) | 1 | 1.5% |
| #25 (Semgrep) | 1 | 1.5% |
| #11 (Pint) | 1 | 1.5% |
60 эпизодов классификатор оставил без рекомендации (типично для коротких вопросов и notification'ов). 7 эпизодов получили конкретную рекомендацию.
[4] GAP «рекомендован, но выбран direct»
| recommended | count | rework | rework_rate |
|---|---|---|---|
| #37 | 4 | 1 | 25.0% |
| #18 | 1 | 1 | 100.0% |
| #25 | 1 | 1 | 100.0% |
| #11 | 1 | 0 | 0.0% |
| итого GAP | 6 | 3 | 50.0% |
Из 6 GAP-эпизодов половина (3) переоценена reviewer как rework. См. §5 «Расследование 6 GAP».
[5] outcome × node_chosen group (после Opus-review)
| group | count | success | soft_success | rework | blocked | rework_rate |
|---|---|---|---|---|---|---|
| skill_used | 3 | 1 | 1 | 0 | 1 | 0.0% |
| direct_no_rec | 58 | 15 | 29 | 10 | 4 | 17.2% |
| direct_ignored_rec | 6 | 0 | 3 | 3 | 0 | 50.0% |
| итого | 67 | 16 | 33 | 13 | 5 | 19.4% |
Ключевой разрыв: deterministic analyzer показывал 0 rework (см. §3), Opus-reviewer нашёл 13 переделок + 5 блокировок (27% не-успешных). Inference из prompt_signal не ловит rework в коротких рабочих днях (мало эпизодов подряд, signal-кадр не пересекается). Полагаться только на анализатор без reviewer — слепо за 13 rework.
[6] classifier_output presence by source
| source | count | % |
|---|---|---|
| llm | 29 | 43.3% |
| prefilter | 23 | 34.3% |
| regex | 10 | 14.9% |
| prefilter_inherited | 3 | 4.5% |
| cache | 2 | 3.0% |
| null | 0 | 0% |
Классификатор живой и здоровый — 0 NULL за весь день, ни одного парс-фейла или таймаута. LLM-source 43% — typical после feedback_windows_tls_handshake.md фикса (timeout 60s).
[7] Per-classification: trigger-match + via-skill
| classification | total | trigger_matched | via_skill |
|---|---|---|---|
| other | 37 | 4 | 3 |
| question | 13 | 0 | 0 |
| release | 7 | 0 | 0 |
| monitoring | 7 | 0 | 0 |
| bugfix | 1 | 0 | 0 |
| planning | 1 | 0 | 0 |
| cleanup | 1 | 0 | 0 |
other доминирует (55%), как обычно. question+release+monitoring (40%) — это reactive-режим (отвечать/смотреть/наблюдать), navigation-skills там не уместны. Зато 0 via_skill в bugfix/planning — нетипично, мини-задача, требует наблюдения.
2. Состояние классификатора
Здоровый: 0 NULL, source distribution распределена (llm 43% / prefilter 34% / regex 15%). Сравнение с retro #7: тогда был аналогичный паттерн (LLM работает, prefilter ловит короткие).
Стоимость классификатора: 3 373 input + 23 382 output токенов за 67 эпизодов ≈ $0.10-0.15 (грубо, по ProxyAPI rate). Дешёво.
3. Reviewer-судьи: распределение вердиктов
Node quality (выбор узла)
| verdict | count | % |
|---|---|---|
| correct | 25 | 37.3% |
| disputable | 31 | 46.3% |
| wrong_node | 11 | 16.4% |
46.3% disputable — половина выборов спорные. 16.4% wrong_node — каждый шестой эпизод узел выбран неправильно. Высокая доля «спорных» в день вопросов — нормально (нет однозначного правильного ответа), но 11 wrong_node не нормально.
Agent self-assessment accuracy
| verdict | count | % |
|---|---|---|
| accurate | 38 | 56.7% |
| no_self_assessment | 29 | 43.3% |
43.3% эпизодов БЕЗ self-assessment вообще. Хук self-assessment не отрабатывает на каждом ходе. Когда self-assessment есть — он accurate в 100% (38/38).
4. Sanity check (заказчик)
Три вопроса, заданы простым языком:
| вопрос | ответ |
|---|---|
| Direct ignored 6 рекомендаций — ложные или реальные промахи? | «Не помню — проверь сам» |
| 97% direct — день вопросов или procedure bypass? | «Сложно сказать» |
| 0 rework в analyzer — реально чисто или наблюдатель пропустил? | «Не помню» |
Ответы записаны в docs/observer/sanity-checks/2026-05-27.json (PII-фильтр прогнан).
Заказчик делегировал расследование (Q1: «проверь сам») — см. §5.
5. Расследование 6 GAP (по запросу заказчика)
| # | время | task | recommended | reviewer node_quality | outcome | вердикт |
|---|---|---|---|---|---|---|
| 1 | 04:05 | b11f6b8d | #37 | disputable | soft_success | защитимо |
| 2 | 04:09 | b11f6b8d | #37 | wrong_node | rework | промах |
| 3 | 05:32 | b11f6b8d | #18 | wrong_node | rework | промах |
| 4 | 07:16 | 0ade4c82 | #25 | wrong_node | rework | промах |
| 5 | 08:14 | 0ade4c82 | #37 | disputable | soft_success | защитимо |
| 6 | 12:31 | 0ade4c82 | #11 | disputable | soft_success | защитимо |
3 защитимых, 3 промаха.
Все 3 промаха — короткие task-notification'ы от background-команд (Bash run_in_background → завершение фоновой задачи → router-вход с trigger'ом). Pattern:
- Notification приходит как обычная user-задача
- Классификатор смотрит триггеры (release/Pest/Semgrep) → рекомендует узел
- Я отвечаю direct, потому что «это просто notification, реальной работы нет»
- Override не объявляю — Pravila §17 этого не предусматривает для bg-notification
- Reviewer Opus справедливо говорит: «или зови узел, или явно override»
Это не «лень не вызывать узел» — это разрыв в Pravila §17 + ADR-016 (universal skill-coverage): правила не описывают bg-notification как отдельный класс, поэтому я либо нарушаю их direct'ом, либо вынужденно зову неуместный узел.
6. Missed activations
analyzer.missedActivations.totalMissed: 0 за период (типичный show-stopper для день-вопросов).
7. Causal chains
analyzer.causalChains.length: 0. Анализатор не нашёл явных «error → fix» пар. Reviewer нашёл 13 rework, но они без явной коррекции в этом же ходе (исправление вынесено в следующий ход или вообще не происходит).
8. Self-retrospect trigger
Counter docs/observer/.self-retrospect-counter.json:
episodes_since_last: 609 (после +67 за этот retro)last_run_at: null (никогда не запускали)- Порог: 50 эпизодов
Сильно превышен. Опт-ин предложение заказчику — см. §11.
9. Cost report
| метрика | значение |
|---|---|
| input_tokens (main loop) | 1 313 |
| output_tokens (main loop) | 453 422 |
| cache_read | 159 238 917 |
| cache_create | 8 548 887 |
| classifier_in | 3 373 |
| classifier_out | 23 382 |
| reviewer (batch direct API) | ~$0.10-0.20 (грубо, 67 × Opus-call) |
| self_assessment | 0 (хук молчит) |
| total tool_calls | 181 |
| total iterations | 505 |
Cache-hit-rate ≈ 95% (159M read / 8.5M create). cost-daily.json файла нет (~/.claude/runtime/cost-daily.json не существует — отдельный TODO для cost-tracker).
10. Candidates for owner review
C1 — Override pattern для bg-notification
Что: Pravila §17 + ADR-016 не описывают background task-notification как класс. Сейчас 100% таких эпизодов идут через router, классификатор рекомендует release/Pest/Semgrep по триггерам в Bash-команде, я выбираю direct, reviewer ловит как wrong_node + rework.
Где источник: tools/observer-routing-detector.mjs (router treats notifications as regular tasks), Pravila §17.
Предлагаемая правка:
- Вариант А: добавить
prompt_signal: "bg_notification"детектируемый по pattern<task-notification>в prompt; routing-gate пропускает direct без override - Вариант Б: формализовать override-фразу «bg-notification ack» как разрешённый short-circuit
Rationale: 3 из 3 wrong_node в GAP — это bg-notification. Снижение rework на ≈8 эпизодов в день (по экстраполяции на reactive-дни).
Альтернатива: отклонить — оставить как есть, считать что reviewer-Opus просто consistently недооценивает defaulting direct в bg-кейсах.
C2 — Self-assessment hook молчит в 43% эпизодов
Что: 29 из 67 эпизодов вообще без self-assessment (agent_self_assessment_accuracy: no_self_assessment). Когда self-assessment есть — 100% accurate.
Где источник: хук self-assessment, скорее всего в .claude/settings.json Stop-hook chain.
Предлагаемая правка:
- Расследовать почему 43% пропусков (timeout? exception? early-return?)
- Если хук работает условно (например только при
tool_calls > 0) — пересмотреть условие или формализовать exception
Rationale: без self-assessment reviewer теряет доступ к моей собственной оценке низкой уверенности → менее точные verdicts. Self-assessment накладные 80-200 токенов, удешевляет downstream review.
Альтернатива: отклонить — оставить как фичу (self-assessment только когда я уверен что он нужен).
C3 — self-retrospect долг (609 эпизодов)
Что: episodes_since_last: 609, last_run_at: null. Порог 50. Skill self-retrospect существует в .claude/skills/, ни разу не запускался.
Где источник: docs/observer/.self-retrospect-counter.json + spec §4.8.
Предлагаемая правка: заказчик запускает /self-retrospect (опт-ин) для разовой self-review.
Rationale: контроллер 12+ дней роутит без рефлексии собственного паттерна → паттерны wrong_node могут быть систематическими, self-retrospect выделит их раньше следующего retro.
Альтернатива: счётчик не показатель — отключить пороговое предложение из /brain-retro.
C4 — Reviewer как обязательный шаг каждого retro
Что: Без Opus-reviewer этот retro показал бы «0 rework, всё чисто» (deterministic inference из prompt_signal не сработал). С reviewer — 13 rework, 5 blocked.
Где источник: brain-retro skill, §5b — сейчас «batch mode default». Возможно усилить как mandatory.
Предлагаемая правка: в SKILL.md §5b ужесточить: для retro с ≥20 эпизодами batch reviewer обязателен, текущий fallback direct_api_batch — единственный mode.
Rationale: статический inference из prompt_signal требует плотности эпизодов (соседство в JSONL), на reactive-днях не работает. Reviewer — единственный достоверный источник outcome.
Альтернатива: оставить batch как default, не повышать формального обязательства.
11. Эскалации заказчику
- C3: self-retrospect долг 609 эпизодов — запустить
/self-retrospect(опт-ин). При нежелании — отключить пороговое предложение в /brain-retro skill. - C1 vs C4: выбор как покрывать bg-notification GAP — нормативно (C1) или процедурно (C4 reviewer fishes их каждый retro).
- C2: разобраться с self-assessment-хуком (43% пропуск) или формализовать exception.
12. Сравнение с retro #7 (тренд)
| метрика | retro #7 (11.5ч) | retro #8 (8.7ч) | тренд |
|---|---|---|---|
| эпизодов | 23 | 67 | +191% |
| improvised | 95.7% | 97.0% | стабильно |
| via_skill | 1/23 = 4.3% | 3/67 = 4.5% | стабильно |
| classifier NULL | 0 | 0 | стабильно |
| reviewer rework | (нет данных в #7 отчёте) | 19.4% | новая точка |
| wrong_node | (нет данных) | 16.4% | новая точка |
Retro #8 первый, где встроенные digital tables дают плотный срез по reviewer-вердиктам. Следующий retro будет иметь точку сравнения.
Запись завершена
Никакой автоматической правки нормативки не выполнено. Все §10 кандидаты ждут решения заказчика.