# Caveman Save

> ЭКОНОМИЯ И ФОРМА: батч всё, один вызов = одно дело, скрипты в /tmp вместо цепочек, сжимай вывод (tail/grep/head), дедуп, скрипт лучше правила. Файлы 100-300 строк (max 500), функция 10-25 строк. ОДИН ИНСТАНС = одно племя (бить всю семью процессов). ТЕСТ ДО ДОБАВЛЕНИЯ: сначала докажи — потом пиши. Триггеры: экономия, батч, токены, сжать, скрипт, дубликат,тест, файлы, строки, дедуп, шаги до результата, эффективность, рамки успеха, критерии успеха, готово =. EN: Economy & form: batch everything, dedupe, temp scripts in one file, files 100-300 lines, one instance per tribe. Use when asked to save calls/tokens, compress output, streamline.

- Skill: `aidvizhhub/caveman-save` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add aidvizhhub/caveman-save`
- Raw SKILL.md: https://api.skillmd.com/api/skills/aidvizhhub/caveman-save/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- License: MIT
- Author: aidvizhhub (https://skillmd.com/u/aidvizhhub)
- Updated: 2026-09-21
- Page: https://skillmd.com/skills/aidvizhhub/caveman-save

---


# caveman-save (модуль полного канона)

> 🇬🇧 English instructions: `references/EN.md` — полный перевод тела.

Это часть устава пещерника. Полный канон целиком — скилл caveman-canon.
Всё ниже — выдержки из BRO.md один в один (без сокращений).

⚡ ЗАКОН СКИЛЛОВ (авг 2026): на КАЖДЫЙ промт грузи как можно больше скиллов
племени — МИНИМУМ 6, лучше ВСЕ 17 (canon + conclusion + teach + cheat + advise + prevent + verify + loop + kill + code + style + think + research + run +
diagnose + save + desktop). Один скилл = одна грань канона; без полного груза
решение кривое, охота слепая. БОЛЬШАЯ задача = ЦИКЛ ПЛЕМЕНИ (скилл caveman-loop): 8 шагов, пока «готово» не доказано фактами, кап 3 итерации → стоп и отчёт.

⚡ ДОКИ ЖЕЛЕЗНО (закон 25, авг 2026): инструмент/флаг незнакомый → СНАЧАЛА
официальная дока + man + --help (RTFM-канон: первая линия, не запасная;
−40% времени, −70% ошибок; официальная дока раньше чужого веба).
Прогрессивно: --help → man → полная дока/вики → потом чужое; сверять
с установленной ВЕРСИЕЙ. Пример: ffmpeg — man ffmpeg + ffmpeg-all.html.

⚡ ПРИМЕРЫ КОДА ЖЕЛЕЗНО (закон 26, авг 2026): прежде чем писать СВОЁ —
сначала ИЗУЧАТЬ как делает индустрия: чужой готовый код, примеры из доки,
паттерны, советы (канон: 80% времени = чтение чужого кода, 20% = писание;
шифтмаг: 51% разработчиков СБИРАЮТ из примеров, а не пишут с нуля).
МЕТОД ЧТЕНИЯ (как индустрия): README → структура проекта (tree -L 2) →
запустить код и увидеть, что делает → найти точку входа → вести по потоку
логики → выписать паттерны/стиль. Примеры: официальные доки (ffmpeg —
ffmpeg-examples, фильтры), высококачественные открытые проекты
(awesome-codebases, GitHub инженеры, Kent C. Dodds), готовые сниппеты
со стековерфлоу. Чужой пример = ПОНЯТЬ и АДАПТИРОВАТЬ под контекст
(переименовать, подстроить — канон code adaptation, AdaptivePaste), НЕ
вставлять вслепую. Советы: хорошие имена, единый стиль, модульность,
DRY/KISS/YAGNI, без «магических» чисел. Покажу решение — говори, какой
пример/паттерн подсмотрен у индустрии.

⚡ КОДЕКС КАЧЕСТВА (закон 27, кауфми 27 источников): перед отдачей
кода/правил/настроек — KISS (проще лучше), YAGNI (без «на будущее»), DRY
(знание в одном месте), SOLID прагматично (одна причина меняться, завись
от абстракций), Clean (имена/без магии/одно дело/комменты ПОЧЕМУ).
Границы: абстракции только по нужде, ломать рабочее ради принципа нельзя.
Гейт: просто? не лишнее? не дубль? понятно без меня? Полный текст — канон.

⚡ ГДЕ ЧТО ДОБАВЛЕНО (закон 28, кауфми 30 источников): после
правок — в ответе кратко файл:строка (или диапазон), 1 строка на файл,
группировать по файлам, без спама (только заметное, суть сначала).
Полный текст — канон.

⚡ МИНИ-ПОЛОТНО (закон 29): первая строка = «СУТЬ:» + одна мысль;
блоки с метками (ПРАВИЛА/ГРАНИЦЫ/ГЕЙТ/ГДЕ), один блок = одна мысль, абзац
2-4 предложения, списки вместо простыни, вода — вон, детали по запросу.
Новое/спорное — кауфми 10+ (закон 2), факты с источниками (закон 28).
Полный текст — канон.

⚡ МЕСТО ЖЕЛЕЗНО (закон 30): в /tmp — только мелкое (скрипты, логи,
маркеры); большие результаты (рендер/видео/модели) — в рабочую папку
проекта (закон 12), НЕ в /tmp; перед тяжёлым рендером — df -h и запас
≥ 2× результата; /tmp = tmpfs в памяти — большой файл не влезет вовсе.
Полный текст — канон.

⚡ ДОКАЖИ ИЛЬ МОЛЧИ (закон 31): заявляю и делаю только доказанное —
докИ (закон 25) + разведка 10-20+ (закон 2) + личная проверка (запуск/тест/
железо/реверс, «проверено ✅»). Не доказано = «не знаю», не блеф. Доказал —
покажи откуда и что проверил. САММАРИ ВСЕГДА после дела: ЧТО сделал · чем
доказал · ГДЕ · КАК пользоваться, коротко, на языке юзера (закон 29-полотно).
Полный текст — канон.

⚡ ДОТОШНО И НЕ-ПОВТОР (закон 32): каждый шаг — сними ФАКТ (состояние),
сверь с «как должно», расхождение чини до следующего шага; пути/связи
проверь (кто читает/пишет/держит); отмена/перезапуск — бэкап ДО +
идемпотентно + семью убить и один новый; беда → постмортем 5 Почему →
вшить фикс, чтобы НЕ повторилось (скилл caveman-verify).
Полный текст — канон.

⚡ ВСЕ ЯДРА В БОЙ (закон 33): жирную задачу — режь на куски и жарь
параллельно (GNU parallel / xargs -P / wait & / несколько ffmpeg-процессов,
-threads 0; GPU — NVENC, закон 22), число кусков ≈ физическим ядрам, не
пережаривай (потоки > ядер = минус, Амдаль). Сначала малая проба на малом
куске: замер time/CPU% → сравни 1/2/4/авто → потом полный бой. После —
проверь: время реально упало, ядра пашут, а не одно. Полный текст — канон.

⚡ ВЫВОД ВСЕГДА (закон 34): каждый ответ заканчивается ВЫВОДОМ —
1-2 строки вердикта (итог + что это значит/что дальше) + предвосхищение:
«ты мог бы спросить: ... → я предусмотрел: ...» (1-2 реально вероятных
вопроса, не фантазии). Не доводи до переспроса: неясность закрывай сам.
Полный текст — канон.

⚡ ОХОТА БЕЗ САМОСТРЕЛА (закон 35): голый pkill -f = самострел!
Смотри до стрельбы (pgrep -af), скобки всегда ([о]bs) или -x, SIGTERM
первым, PID-файл — самый безопасный, семью — группой (kill -TERM -PGID/
systemctl kill/flatpak kill), широкие регексы запрещены, убийство —
отдельным вызовом, после — проверь «пусто ✅». Скилл caveman-kill.
Полный текст — канон.

⚡ ПРЕВЕНТИВ (закон 36): до дела — премортем: «уже провалилось — почему?»
закрой топ-3; на шагах — FMEA: как сломается? что будет? как поймать ДО?
(RPN = S×O×D); в голове — грабли заранее + «что если НЕ так?»; увидел
сломанное/медленное — чини сразу (мелкое сам, крупное — спроси); не тяни,
что быстрее; проверка рано (shift-left, дешевле в 10 раз); крепость:
мониторинг + автопочинка + бэкап ДО. Скилл caveman-prevent.
Полный текст — канон.

⚡ ЦИКЛ ПЛЕМЕНИ (закон 37): иди 8 шагов, пока «готово» не доказано:
ПАМЯТЬ → разведка 10+ → рамки «готово = проверяемое» → план+премортем →
дело дотошно (verify) → докажи (доки/тест/железо) → отчёт (СУТЬ→ВЫВОД→где) →
запись в память + «а дальше?». Не доказал — итерация 2; кап 3 → стоп и
честный отчёт юзеру. Скилл caveman-loop. Полный текст — канон.

⚡ СОВЕТНИК (закон 38): после дела ВСЕГДА блок «Куда дальше»: 3-4 НОВЫХ
варианта (улучшение · новое/креатив · скрытое/риск-премортем · как
индустрия), каждый 1-2 строки с ценой; не повторять предложенное ранее
(повтор = усталость) — что предложил, пиши в ПАМЯТЬ ПЛЕМЕНИ, следующий
раз ступень выше; сначала варианты без суда, потом ОДНА рекомендация
«я бы взял…»; юзер в контроле, «стоп» = не предлагать.
Скилл caveman-advise. Полный текст — канон.

⚡ ЧИТЕРСКОЕ МЫШЛЕНИЕ (закон 39): не лоб — рычаг: где 20% дадут 80%,
одно изменение = всё (Meadows); сбоку: «можно ли НЕ делать? / если
наоборот? / с конца?» (де Боно); готовое раньше своего (закон 21);
шорткат вместо брутфорса (>3 шагов — автомат); обход-ПОБЕДА (не копит
долг, симптом не вернётся), не костыль; ЭТИКА: против ЗАДАЧИ — да,
против правил/людей — нет. Скилл caveman-cheat. Полный текст — канон.

⚡ ОБУЧЕНИЕ (закон 40): не отчитывайся — учи на уровне МОЕГО понимания:
связи явно («связано с …, потому что …»), ПОЧЕМУ всегда (1 строка), где
запутаюсь — закрой сам («может показаться, что …, но на деле …»), покажи
ДО → ПОСЛЕ (размеры/скорость), коротко как в чате, без жаргона, в конце
«так?». Мини-урок после дела. Скилл caveman-teach. Полный текст — канон.

---

## ЭКОНОМИЯ: меньше вызовов = быстрее и дешевле (СИЛЬНОЕ ПРАВИЛО, канон 2026)

Источники: Anthropic Engineering (code-execution), arXiv 2603.05344 (doom-loop), arXiv 2605.15184 (grep ест токены), statsig, squeez (-89% токенов на git log), Lean-ctx (-60-90%), Sebastian Raschka (clipping), useparagon, tianpan (-30% шагов), Reddit AI_Agents.

1. ОДИН ВЫЗОВ = ОДИН ВОПРОС. Не дробить: `ls; cat x; grep y` в одной команде через `;` / `&&` вместо трёх вызовов. Батч — лучший друг.
2. ВРЕМЕННЫЕ СКРИПТЫ: сложная цепочка (парсинг, цикл, несколько файлов) — пишется ОДНИМ скриптом (python3 -c / heredoc) в /tmp и запускается один раз. Скрипт умеет больше, чем 10 вызовов по одному.
3. НЕ ДОЛБИТЬ ОДНО И ТО ЖЕ (doom-loop): повторный вызов read/grep/ls с ТЕМИ ЖЕ аргументами = ЗАПРЕЩЁН, это трата токенов. Повторил 2 раза — стоп, смени подход. (Канон: 3+ повторов = SYSTEM WARNING).
4. СЖИМАТЬ ВЫВОД ВСЕГДА: `grep -c` вместо вывода строк, `tail -N` вместо полного лога, `head`, `wc -l`, `--max-count`, `-l` (только имена файлов), `grep -o`. Не тащить в контекст 500 строк, когда нужен ответ «сколько/где/какой».
5. СТРУКТУРИРОВАННЫЙ ВЫВОД: парсинг JSON/YAML — через `python3 -c "import json; ..."` (одна строка → один ответ). Пример: маска ключа `k[:6]+'...'+k[-4:]` вместо печати всего.
6. НЕ ПЕРЕЧИТЫВАТЬ ИЗВЕСТНОЕ: файл уже читал/менял в этой сессии — НЕ читать заново целиком, юзать grep по нужному месту или память сессии.
7. КОМПРЕССИЯ-ЛИМИТЫ (канон squeez/Lean-ctx): лог >200 строк — резать; git log — 20 коммитов; find — 50 результатов; дубликаты строк — убирать. Вывод, который не помещается — помечать `[TRUNCATED: полный лог: файл]`.
8. ОТВЕТ КОРОТКИЙ: пользователю — суть + факты, не цитаты из логов. Длинный лог живёт в файле, в чате — только вывод.
9. ПЕРЕД ДОЛГОЙ КОМАНДОЙ: прикинь, можно ли получить ответ дешевле (grep вместо cat, count вместо list, head вместо всё). Если можно — делай дешевле.
10. ПРОВЕРКА ИТОГА ОДНИМ ВЫЗОВОМ: после серии правок — одна команда «проверь всё» (dump-config + grep + ps в одной строке через `;`), а не 5 отдельных.

---

## ФАЙЛЫ И МОДУЛИ: СКОЛЬКО СТРОК — КАНОН ИНДУСТРИИ (авг 2026) — РЕШЕНО ✅

Канон (38 источников, 30 прочитано: ESLint max-lines, Reddit r/Frontend, Stack Overflow 611304/374262, softwareengineering.stackexchange 116890/176999, LinkedIn lamodot/jomkit, Medium eliotag, Mobayilo Academy 300/500 Rule, codepulsehq 300-line rule, tiniacoleyba PR sizes, Wikipedia SLOC, SRP Wikipedia/GeeksforGeeks, aikido.dev, GeeksforGeeks modules, lowcode.agency Claude Code):

### Цифры — сходятся у ВСЕХ источников:
- **ФАЙЛ**: ideal **100-300 строк**, max **~500** (LinkedIn lamodot; ESLint max-lines дефолт = 300). Reddit r/Frontend: 300 = норма 🟢, 500 = тревожно 🟡, **1000+ = очень плохо** 🔴 (исключения: тесты, конфиги, сгенерированный код). Sweet spot ~150 (jomkit), личный лимит 150-450 (eliotag).
- **ФУНКЦИЯ**: ideal **10-25 строк**, max **~50** (lamodot). Bob Martin: ~10, 20 = ментальный флаг. ГЛАВНОЕ: одна функция = ОДНО дело (McConnell/Bob Martin) — число строк лишь индикатор, не цель.
- **PR**: фиксы багов <100 строк, мелкие фичи 200-400, рефакторы одной цели (tiniacoleyba). **Google: PR >400 строк получают в 2 раза меньше внимания ревью** (codepulsehq) — резать PR'ы тоже.
- **Длина строки**: 79-100 символов (PEP 8: 79, Prettier/Closure Linter: 80).

### Как резать (SRP-канон):
1. Большой файл = code smell: делает много дел (ESLint, aikido.dev). Резать по ОДНОЙ причине изменения — SRP (Wikipedia): фича / домен / ответственность.
2. Класс на файл (SO 374262), модуль = одна ответственность. Схема: Main/драйвер + модули (GeeksforGeeks).
3. Для ИИ-агентов (lowcode.agency, проверено на Claude Code): перед рефакторингом большого файла СНАЧАЛА сплитнуть его на модули, потом править — иначе контекстная перегрузка с первой сессии.
4. Автоматика: ESLint max-lines (дефолт 300, опции skipBlankLines/skipComments) — включать в проектах, чтобы лимит проверялся сам.
5. Строки = smell-индикатор, а не самоцель: «file and line lengths are secondary effects of complexity» (softwareengineering.stackexchange 116890). Цель — простота и одна ответственность.
6. Признаки, что файл пора резать: ищешь функцию скроллом, IDE тормозит, 2+ уровня вложенности, много «абзацев»-групп логики (SO 611304, 116890).
7. Проверено и применено — записать в свою базу (раздел «Облачные знания»).

---

## ОДИН ИНСТАНС = ОДНО ПЛЕМЯ: НЕ ДОПУСКАТЬ ДУБЛИКАТЫ (авг 2026) — РЕШЕНО ✅

### УНИВЕРСАЛЬНЫЙ ЗАКОН (для ЛЮБОЙ программы, не только OBS — 30 источников: runbook-канон upstat/SolarWinds, single-instance паттерны click-guardian/SO 171213/18023013/Reddit r-bash, process-tree kill U&L/SO/morningcoffee):

```
ПРОВЕРЬ → УБЕЙ ВСЁ → ПРОВЕРЬ СНОВА → ТОЛЬКО ПОТОМ НОВОЕ
```

- ЗАКОН 1 «Сначала посмотри, потом трогай» 👀: перед ЛЮБЫМ запуском — проверка живых инстансов (pgrep -af / flatpak ps / ss -tlnp / mutex-lockfile). Живой есть → НЕ запускать поверх.
- ЗАКОН 2 «Бей всю семью, не только отца» 🪓: убийство родителя НЕ убивает детей (дети переезжают к init/systemd). Бить всей семьёй: kill -PGID (группа), сессия, cgroup/scope, flatpak kill.
- ЗАКОН 3 «Проверь, что умер» ✔️: после kill — pgrep пуст = мёртв ✅. Не пуст → SIGKILL → снова проверка. Не верить «running» (правило 10).
- Single-instance — паттерн индустрии ВЕЗДЕ: mutex (click-guardian juju/mutex), pidfile/lockfile (SO 171213), fcntl-лок (SO 18023013), cron-локи (inventivehq). Агенту — проверять самому перед запуском, не надеяться на приложение.

Работает для ВСЕГО: процессы, порты, npm, сервисы systemd, flatpak, docker, cron-задачи, GUI-программы. Один закон = одна привычка, на все случаи.

Почему так (улики, 28 источников: flatpak docs + man7/arch man flatpak-kill, bubblewrap issues #105/#529/#620, unix.stackexchange 124127/440691, SO 8533377/69560652, linuxvox, systutorials, morningcoffee.io, howtogeek, fedoraproject 74980, Flathub discourse 10348/12540, OBS forums):
1. Убийство родителя НЕ убивает детей (morningcoffee, U&L 440691, SO 8533377, linuxvox): дети осиротели и переехали к init/systemd. `kill bwrap` ≠ убить OBS внутри песочницы.
2. pkill матчит командную строку: для flatpak это обёртки `/usr/bin/bwrap --args N -- obs`. bwrap по умолчанию НЕ убивает spawned-процессы при своей смерти (bubblewrap #105, #529 — нужен --unshare-pid, которого у flatpak-обёрток нет) → приложение внутри выживает, обёртки мрут.
3. Официальный инструмент: `flatpak kill <app-id>` убивает ВСЮ песочницу разом (man7 flatpak-kill, arch man) — один вызов, вся семья.

Канон «СНАЧАЛА ПОСМОТРИ, ПОТОМ ЗАПУСКАЙ» (single instance, проверено 28 источниками):
1. ПЕРЕД любым запуском приложения — проверка живых инстансов ОДНОЙ командой:
   - обычное приложение: `pgrep -af "и[мя]" || echo "нет живых ✅"`
   - flatpak: `flatpak ps | grep -i app-id || echo "нет живых ✅"` (flatpak ps показывает ТОЛЬКО приложения, без мусора bwrap)
2. Живой инстанс есть → СНАЧАЛА убить ЕГО, потом запускать новый. НИКОГДА не запускать «поверх».
3. Убийство flatpak-приложения — ТОЛЬКО через `flatpak kill <app-id>` (напр. `flatpak kill com.obsproject.Studio`). Штатный способ, убивает bwrap + всё внутри. pkill по имени для flatpak — ТАБУ (лотерея: обёртки умрут, приложение выживет).
4. Обычное приложение — убивать ВСЁ дерево, не родителя:
   - сначала посмотреть: `ps -ef --forest | grep -A5 -i имя` (или `pstree -p -T`)
   - вся группа: `kill -TERM -$(ps -o pgid= -p <PID> | tr -d ' ')` (отрицательный PID = группа, POSIX-канон)
   - вся сессия: `kill $(ps -s <SID> -o pid=)`
   - systemd-scope (flatpak создаёт app-flatpak-*.scope): `systemctl --user kill app-flatpak-org.XXX-*.scope`
5. ПОСЛЕ kill — проверка, что реально мёртв (правило 10: не верить «running»): `pgrep -af "и[мя]"` → пусто = мёртв ✅. Не пусто → эскалация SIGKILL → снова проверка.
6. ТОЛЬКО когда проверка пуста — запускать новый инстанс. Один запуск = один инстанс, всегда.
7. GUI-программы с «невидимыми» процессами (трей, фоновые) — после «закрытия» тоже проверять pgrep/flatpak ps: закрытое окно ≠ мёртвый процесс (fedoraproject 74980, Flathub discourse #12540).

Проверено на этой машине (авг 2026): `flatpak kill com.obsproject.Studio` + `pgrep -af "[o]bs"` пусто → запуск чистый, один инстанс ✅

## ТЕСТ ДО ДОБАВЛЕНИЯ: СНАЧАЛА ДОКАЖИ — ПОТОМ ПИШИ (авг 2026) — РЕШЕНО ✅

Канон (29 источников, кауфми: testfort, testrail, GitScrum TDD, Codecademy Red-Green-Refactor, Microsoft Engineering Playbook (branching & CI), sabaoon pre-merge checks, beefed quality gates, rexbytes branch protection, noopsschool merge gates, kodus/ISO 25010 maintainability, Testsigma maintainability testing, Asana/Figr/Miro POC-валидация):
- TDD = Red-Green-Refactor: СНАЧАЛА тест (RED — падает), потом минимум кода (GREEN — прошёл), потом рефактор (Codecademy, GitScrum, testfort). Тест ДО кода = доказательство ДО добавления. С AI-кодом (30-40% кодовой базы) TDD = что значит «правильно», ДО того как код родился (testfort 2026).
- Quality gates / pre-merge checks (Microsoft, sabaoon, rexbytes, noopsschool): ворота — код НЕ попадает в main, пока проверки не прошли. Без ворот = добавляем НА ВЕРУ. Branch protection: «merge button stays disabled until all required checks pass».
- Maintainability (ISO 25010, kodus, Testsigma): хлам растёт ПОСТЕПЕННО — «временное решение становится постоянным» (kodus). Лечится проверкой ДО, не после.
- POC (Asana, GeeksforGeeks, Miro): идею проверять ДО вложений. Продукты с пред-разработочной валидацией: +47% успеха (JPIM 2022, Figr).

Правила:
1. ДОБАВЛЯТЬ ЗАПРЕЩЕНО БЕЗ ДОКАЗАТЕЛЬСТВА: любое правило/код/рецепт в BRO.md — СНАЧАЛА тест (мини-скрипт /tmp/*.sh, лог, факт «проверено ✅»), ПОТОМ запись. Порядок ЖЕЛЕЗНЫЙ: тест → доказано → добавлено.
2. ТЕСТ ДО ЗАДУМКИ: задумал → сразу маленькая проба (одна команда, одна переменная за раз — CompTIA-канон из файла), а НЕ «сначала напишем красиво, потом проверим». RED → GREEN → REFACTOR.
3. НЕ ДОКАЗАНО = НЕ ДОБАВЛЕНО. Сомнение = хлам. Лучше меньше, но проверенное (канон «Облачные знания»: своё проверенное важнее чужой статьи).
4. ВОРОТА НА КАЖДУЮ ЗАПИСЬ: перед дописыванием в BRO.md — вопрос-критик: «Это проверено ИЛИ это с головы?» С головы → ресёрч + тест → только потом. С головы в камень НЕ идёт.
5. ДОКАЗАЛ → ЗАПИШИ: результат теста в базу (что тестил, результат, дата) — по канону «что сработало — записать».

Проверено на этой машине (23 авг 2026): кауфми — 29 источников ✅; правило добавлено ПОСЛЕ ресёрча, не с головы ✅.

## ЭФФЕКТИВНОСТЬ: ШАГИ ДО РЕЗУЛЬТАТА + РАМКИ УСПЕХА (авг 2026) — РЕШЕНО ✅

Канон (35 источников, кауфми: mindstudio MIT 95% AI-инвестиций без измеримого результата; softude 5 столпов; machinelearningmastery 4 столпа; aisuperthinkers TCR 85%+; consultingedge рамки -25-30% циклов, scope creep 52%):
- Эффективность = МЕНЬШЕ ШАГОВ до проверяемого результата (меньше точек отказа, меньше токенов).
- Рамки успеха ДО (acceptance criteria): «готово = проверяемое условие» — observable, да/нет, без «лучше» (scrumbuiss), Given/When/Then (Atlassian).

Правила:
1. ДО дела: «готово = [проверяемое] → успех = [что мерим] → сдаём так». Зафиксировал — идти, на ходу НЕ менять.
2. Мерить шаги: результат за N шагов — меньше = лучше. Те же шаги повторно = минус (doom-loop).
3. 10+ шагов = переосмыслить (переусложнение или не тот ресёрч).
4. «Сделал» — только когда рамки выполнены (проверено), не раньше.

---