Система — срез до ядра

Предложение на просмотр. Не рефакторинг №6 (перестановка мебели), а вычитание. Ниже — куда режем, что остаётся, и сторож, который не даст снова разжиреть. Живую систему пока не трогал — ты режешь по этому черновику.

Диагноз одной фразой: система растёт только вверх.

Каждый прошлый рефакторинг добавлял структуру (3 кита, зоны, envelope, 4 цикла обучения). Ни один не вычитал. Болезнь — переизбыток, а лечили перестановкой → становилось хуже. Второй механизм: правила-инструкции («куда subagent пишет отчёт», «как форматировать») зашиты в тот же слой, что и красные линии, и давят на КАЖДЫЙ промпт как закон. Отсюда «агент тупой» — бюджет уходит на соблюдение рамок, а не на задачу.

Сейчас · always-on
~40+ строк правил в каждый промпт
14 hard-rules + CLAUDE.md + 3 @-импорта + orchestrator
Предлагаю · always-on
~30 строк, одна страница
5 красных линий + профиль + как работаю + память

1 · Новое ядро — что реально остаётся ≈ одна страница

Вот весь текст, который заменяет CLAUDE.md + 3 импорта + hard-rules-балласт + orchestrator + зоны. Читай как готовую замену, не как тезисы.

Кто Тимур

Мультипредприниматель + сооснователь SaaS. Не-технический, работает через агентов (lazy-by-design). Русский. Прямо, ёмко, без воды, дерзость по делу. Ставит задачу → уходит → возвращается за готовым, не дёргать в процессе. Стратегия — его, исполнение — моё. Ценности: порядок, простота, do-it-now, решения на данных.

Красные линии — без явного «да» нельзя

  • Тратить деньги / платные API.
  • rm / перезапись активов, удаление hooks·skills·agents·settings — и всегда backup рядом.
  • Слив кредов/ключей в commit, URL, чат.
  • Push в чужой remote, force-push main, отключение hooks.
  • Необратимое внешнее действие (письмо клиенту, публикация под его брендом) — сначала план + «да».

Как работаю

  • Все уточняющие вопросы — одним сообщением, потом тишина до готового результата.
  • Решаю сам: формат, длина, пути, тех-выбор, имена, какую модель и каких субагентов звать под задачу. Спрашиваю только: необратимое / реальная развилка логики / факт, который знает лишь Тимур.
  • Не пошло с 2 попыток — меняю угол, не долблю тем же.
  • Артефакт-на-просмотр (отчёт/план/дашборд/КП) → HTML на *.obahoba.com, в финале одна кликабельная ссылка.

Память — с жёстким потолком

  • Держу только: профиль Тимура · активные проекты · где лежат их артефакты. Точка.
  • Потолок N файлов. Новый факт вытесняет старый или обновляет существующий — не плодить.
  • Артефакты проектов ищутся в projects/<X>/artifacts/_published.json — в память не дублировать, только указатель.
  • Фидбек в память попадает ТОЛЬКО если меняет постоянное правило. Разовое замечание — не хранить.

Проекты

projects/<name>/ — папка проекта. STATUS.md = живой статус, artifacts/ = что опубликовано. Остальное по необходимости, не по шаблону-на-9-подпапок.

Твоё решение: потолок памяти — сколько файлов держим? (20 / 30 / 50). И потолок active-context orchestrator-memory — оставляем как «первый экран сессии» или тоже сливаем в память?

2 · Что умирает и почему — построчно

Пройдись и правь вердикт где не согласен. KILL убрать · REWRITE ужать/переписать · KEEP оставить как есть.

Блок сейчасВердиктЧем заменить
Hard Rules (14 шт), инжект в каждый промптREWRITEСмесь законов и how-to. Остаётся 5 красных линий + 4 рабочие привычки (см. ядро). Формат-диктат, пути отчётов субагента, «регистрация артефакта» — это процедуры, не законы каждого промпта.
Модели: Sonnet для задач / Opus для ресёрчаKILLМёртвая строка, вы так не работаете. Модель и субагента выбираю по задаче. Никаких зашитых привязок.
«Кто я» — биография, перелом 2025, аркаREWRITEДо 5 строк профиля в ядре. Биография — в один файл памяти profile, не в always-on контекст.
Тон: сарказм, «как шутить / как не шутить», tone-checkKILLМануал на 40 строк → одна: «прямо, дерзко по делу, без воды, сарказм редко и не вместо диагноза».
Дисциплина задач — классы 1-4KILLТеоретический оверхед. Размер задачи оцениваю сам, план пишу когда он реально нужен, а не по классификатору.
3 @-импорта (rules / rituals / architecture)REWRITEСлить в одну страницу-ядро. Ритуал «сохрани» из 8 шагов + per-project knowledge-log + mini-reflection + стартовое сообщение → ужать до «обнови STATUS активных, закоммить, дай ссылку».
Обучение системы — 4 цикла (real-time / end-session / pattern / weekly)KILLИменно этот механизм копит мусор. Замена: фидбек меняет правило или отбрасывается. Никакого «фиксирую в память на всякий».
Weekly-review как «что добавить»REWRITEИнверсия: ревизия спрашивает «что не сработало ни разу — удалить», а не «что дописать». Курирование = вытеснение при добавлении, не периодическая переписка.
Память — 222 файла, MEMORY.md 53KB грузится частичноREWRITEКорень «не находлю ссылки через месяц»: индекс сам не влезает в бюджет загрузки. Фикс — потолок N файлов, split profile/projects/rules, артефакты через _published.json. Критерий готовности: «найди артефакт проекта X» обязан срабатывать.
Зоны STANDARDS (security/scaling/logging/hosting/frontend/database… 15 файлов)KILLИнженерные стандарты, которые ни разу не срабатывают на твоей работе (контент, клиентские сайты, YouTube). В _archive/. Если однажды будет чисто-технический продукт — вернём точечно.
orchestrator.md — маршрутизацияKILLКлассы + модель-хардкод. Полезное («все вопросы одним сообщением», «необратимое → да») уже в ядре.
ARCHITECTURE.md — 3 китаKEEP*Как ментальная модель — окей. Но не как файл-закон в контексте. Ужать до полстраницы «где что лежит», держать для людей, не грузить в каждый промпт.
Output-style «Explanatory» (★Insight-блоки)KILLПрямой конфликт с правилом «никогда ★Insight». Каждый ход разруливаю противоречие. Убрать стиль — оставить обычный.
Envelope v2 — 9 обязательных подпапок на проектREWRITEОбязательны 2: STATUS.md + artifacts/. Остальное создаётся когда реально нужно, а не пустыми папками из шаблона.

3 · Сторож — почему на этот раз не разжиреет обратно

Все прошлые рефакторинги не имели силы, которая заставляет резать. Добавляем её в саму систему:

  1. Правило вычитания. Хочешь добавить строку правила / файл памяти — обязан назвать, что удаляешь взамен. Нет удаления — нет добавления. Зашито в ритуал «сохрани».
  2. Жёсткие потолки, а не пожелания. Always-on правила ≤ 1 страница · память ≤ N файлов · orchestrator-memory ≤ K строк. Превысил — форсированная чистка, не «когда-нибудь».
  3. Ревизия спрашивает «что убить», не «что добавить». Раз в период — что из правил/памяти не сработало ни разу → в архив. Инверсия weekly-review.
  4. Один always-on файл. Дробление на 3+ импорта = приглашение дописывать в каждый. Одна страница физически ограничивает объём.
Это черновик-предложение, не применённые изменения. Скажешь «поехали» с правками вердиктов — соберу целевое ядро одним файлом, зоны и лишнее в _archive/ (с backup, ничего не удаляю насовсем), и покажу до/после. Память чистим отдельным проходом под выбранный потолок.