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. «Сделал» — только когда рамки выполнены (проверено), не раньше.