First and Second Principles Framework: выплачиваем архитектурный долг, но сначала разгоняем RAG

Ура, всё работает, причём не только у меня! У репо, где лежит FPF (https://github.com/ailev/FPF), уже 59 звёзд и 18 форков, я принял один PR и решил один issue. Не обо всех форках мне известно, но вот Иван Закутний в закрытом чате семинара по FPF рассказал о том, как он дистиллировал при помощи Claude FPF в небольшой размер (порядка 5% от исходного) и дальше использует его в Claude Code для целей принятия архитектурных решений и их документирования при программировании сложных задач (https://github.com/m0n0x41d/quint-code), A set of slash commands for AI coding tools that implement hypothesis-driven reasoning. You generate competing ideas, verify them logically, test them empirically, and document the rationale. Based on the First Principles Framework (FPF). У этого проекта уже самого 41 звезда и 2 форка! Он пишет: "Несколько дней и над разными дежурными и не дежурными, большими задачами (в том числе инженерно-менеджерскими) я поработал с таким Claude Code. Результаты впечатляющие, дороги назад - нет". The core loop: 1. Generate multiple hypotheses 2. Verify them logically 3. Test them empirically 4. Audit for blind spots 5. Decide with full rationale documented Ещё Иван пишет интересные эвристики, когда использовать FPF в его Quint Code, а когда просто использовать vanilla Claude Code:

Use FPF When Architectural decisions — Long-term consequences need documented rationale Multiple viable approaches — Systematic comparison prevents anchoring bias Team decisions — Auditable trail for async review and future onboarding Unfamiliar territory — Structured research reduces "confident but wrong" outcomes Decisions you'll need to defend — Evidence is stored; re-evaluation becomes trivial Don't Use FPF When Quick fixes — Just fix it Genuinely obvious solutions — Implement directly. But be honest: is it actually obvious, or just familiar? Obvious to whom? Easily reversible choices — Try it, iterate, learn Time-critical situations — Use Claude's built-in plan mode instead Well-understood patterns — Apply known patterns. Same caveat as "obvious" applies. Decision Heuristic Is this decision: □ Hard to reverse? □ Affecting more than a few days of work? □ Involving multiple unknowns? □ Likely to be questioned later? If any checked → Consider FPF If none → Skip FPF, use Claude's plan mode or just decide

Ещё один проект у Станислава Недбайлова, https://github.com/venikman/ACP-inspector, A holon-centric, model-based protocol conformance harness that acts as a passive proxy between ACP clients and agents. FPF найти там трудно, но в ReadMe есть строчка: This repo adds a First Principles Framework (FPF) view on assurance and observability. И ещё один проект -- прямо внутри мастерской, FPF уже используется в программе рабочего развития. Предварительный план резидентуры по "распожаризации" (6 недель): 0. Установочная встреча – знакомство, настройка на прохождение резидентуры 1. Отличать модели и физический мир 2. Отслеживать трату ресурсов на выполнение работ 3. Различать метод и работу 4. Общаться на правильно выбранном языке (рабочее название) 5. Концентрироваться на важном За время прохождения этой резидентуры вы: – выделите себе время на разбирательство с вашими проектами – начнёте понимать, что такое First Principles Framework (FPF) и будете применять его для решения ваших рабочих задач с LLM – разберётесь с основными причинами, почему вы не понимаете ваших менеджеров, а они не понимают вас – начнёте лучше понимать важное Second Principles Framework начинается с выплаты архитектурного долга Довольно много времени потратил на архитектурные изыскания вокруг "инструкции по созданию SPF", second principles framework. Если FPF - это нулевые и первые принципы, то дальше должны быть фреймворки прикладные, по вторым, третьим и так далее принципам (я об этом рассказывал на семинаре). Танцы, медицина, теплообменники, программная инженерия -- мало ли что, главное, что прикладное. Сказано -- сделано, какой-то драфт инструкции уже есть, но пока не верьте ему, он даже не в формате языка паттернов, просто "большой текст". Чтобы отладиться, я даже добавил туда сгенерированное по инструкции SFP-Min-EA (минимальный вариант для evolutionary architecture), пропмты там вроде таких: "В файле у тебя спецификация FPF, а ниже в тексте SPF-задание и SPF-Min-EA. Найди, какие проблемы в SPF-задании приводят к проблемам полезности SPF-Min-EA в реальных проектах. Текст SPF-Min-EA разрабатывался в соответствии с SPF-заданием. По итогам дай правки в unified diff в code block в SPF-задание и краткий коммент о том, что сделал и что надо делать дальше". И дальше два текста, всё вместе сейчас где-то на 80Кзнаков. Эксперименты с этими SPFs для разных дисциплин делаю не только я, это ж "производственные регламенты", это всем нужно. Это только я тренируюсь на чём-то более-менее абстрактном типа той же evolutionary architecture, остальные -- сразу "быка за рога", поближе к корпоративным стандартам. Сейчас у меня задача превратить инструкцию по созданию SPF в просто паттерн G.14 с подпаттернами, а для этого нужно выполнить довольно большой рефакторинг FPF в целом. Так что день-два повожусь ещё с архитектурными долгами (принцип телевизора, который чем сложнее устроен, тем меньше кнопок в его управлении и настройках -- а самый сложный телевизор управляется вообще с голоса и всегда знает, что надо показывать и какой громкости должен быть звук, и с каких входов или антенн брать сигнал и какой канал показывать): -- удаление ATS harness (E.11) отовсюду в пользу GateCrossing hooks (а A.21, задающий гейты в TGA, я уже сгенерировал) -- доделка механизмов скоринга, индикатризации и так далее, одновременно вытаскивание универсальной части из паттернов G -- и только после этого можно думать о переходе с трансдисциплин и дисциплин на иерархию нулевых, первых, вторых и так далее принципов. В этой работе прямо в промпты приходится писать и вот такие фразы, ибо мы не можем подойди сейчас нормально к понятию архитектуры, оно ведь многоуровнево: "замечание про плохую модульность схемы, где есть только трансдисциплины и прикладные дисциплины. По идее, есть в ядре часть про "нулевые принципы", про первые принципы (условно это всё было трансдисциплинами), а дальше будут SPF, но может быть и TPF, фреймворк третьих принципов, знание ведь иерархично, а не строго дихотомично. С этим бы тоже разобраться. В частности, где есть структура и значимые решения агента, там есть и архитектура (понятие, очень похожее на нулевой принцип), где есть архитектура, там есть evolutionary architecture как первый принцип, относящийся к любой архитектуре, ибо эволюция пронизывает все картины мира, а ещё есть evolutionary software architecture по мотивам ThoughtWorks, как в примере SPF, это как раз будет удобно представлять как SPF. Тут тоже нужно решение". Результаты даже с этими ни разу не модульными черновиками получаются более чем убедительные у всех, кто с ними пробовал работать (пока они лежат вот тут: https://disk.yandex.ru/d/ril54NoLP2PMEw). Скажем, грузите FPF, свой прикладной SPF (корпоративный регламент) и просите проверить какую-нибудь докладную записку. Всё, ловится "несоответствие корпоративному стандарту". А как писать корпоративный стандарт? Это и есть SPF-задание. Вот этот кейс я не сам придумал, это мне прислали уже успешный успех: докладная записка от ChatGPT по поводу несоответствия проекта документа корпоративному стандарту. Так что "работает даже на черновиках". Но итоговый DoD (definition of done) -- мы можем сказать "возьми FPF и сгенерируй набор паттернов SPF для <дисциплина>". Например, повторить генерацию для evolutionary architecture и получить уже не "просто текст", а как набор прикладных паттернов-плагинов SPF-EA к FPF. Это если без нюансов, но нюансы есть, и они существенно замедляют работу. Строгаем мастерство SoTA-мышления новым рубанком Переехал с Obsidian на Sublime Text, набитый плагинами. Obsidian хорош для персонального использования для маленьких файлов, над которыми навешан Zettelkasten (граф ссылок, табличная база данных и т.д.), а мне нужно профессиональное использование для редактирования больших (3MB) файлов, на которых Obsidian виснет, и будет виснуть, там движок показа файлов Electron. Про Sublime Text мне напомнил Михаил Гусаров, а ведь я уже когда-то работал с Sublime Text, но потом перешёл на книжные редакторы (нужен был WYSIWYG с вёрсткой), затем книжные редакторы не выжили по тем же причинам -- медленно жевали большие файлы, перешёл на Word с заметками в Evernote, затем переполз на Obsidian. Но теперь вздохнул полной грудью: в Sublime Text мой трёхмегабайтный FPF просто летает. Ну, и повайбкодил немного: питоновский плагин для накатывания unified diff, получаемого от LLM. Там оказалось в итоге 1127 строк (38Кзнаков, ибо строчки дают плохое представление об объёме текста, питоновский код -- это ж как стихи Маяковского, который придумал писать "лесенкой" для увеличения суммы при построчной оплате). Я хочу, чтобы было всё хорошо с UX, но ещё и LLM выдаёт редкостно плохого качества unified diff, поэтому плагин настроен на "полуручное" накатывание: то, что в hunks есть, но не удалось найти и накатить, показывается рядом -- отфильтрованное уже от накаченных hunks и тех hunks, которые ничего не меняют (такие "удалить и тут же вставить то же самое, изменений поэтому нет" hunks обычно имеются в изобилии). Git теперь работает через плагин GitSavvy. В любом случае, "у плотника новый рубанок", примерно такой настрой, заодно чуток попрограммировал, "никогда этого не было, и вот опять". В итоге в части ручной работы с текстом всё стало происходить много быстрей и надёжней. Хотя какое-то количество проблем в текст недоотлаженный плагин накатки diff внёс (что-то он не заменял в тексте, а просто вставлял где-то рядом), я их постепенно найду и закрою. Разгон RAG На прошлой неделе подъехала GPT-5.2, но по факту никаких улучшений, кроме вечного перескока с Pro на Auto (очень раздражало!), я не заметил. Вероятно, я не математик и у меня нет олимпиадных задач. Картинки генерирует такие же безобразные по сравнению с Nano Banana Pro, как и раньше. И создаёт ложное впечатление, что режима GPT-5.2 Thinking хватает, но что это не так, осознаёшь только когда возвращаешься на Pro. При этом Pro в этой версии оказалась удивительно болтлива, она вываливает все мысли, только успевай читать. И я вроде бы разобрался, почему надо именно Pro: сетка занимается tinkering с инструментами, в том числе с RAG, решая 90% времени задачи не содержательные, а добычи информации из окружения (RAG прежде всего в мой немаленький файл) и подготовки ответа (требую unified diff, чтобы быстро накатывать изменения). И вот содержательная работа идёт быстро, а работа с RAG и созданием набора патчей -- медленно. У Thinking банально не хватает времени сделать её хорошо, а у Pro -- хватает. Но это не должно быть так! И я начал принимать меры. Много спрашивают, как у меня там внутри устроено: файл FPF ведь явно не лезет в контекст! Конечно, я надеюсь на RAG -- рассказывал подробно на семинаре. И тут тонкости. Так, ChatGPT очень качественно работает с RAG для некачественных текстов вроде FPF. За счёт чего? А просто там этим занимается "могучий ум", который решает всякие недоработки в интерфейсах. Недоработок там тьма, некоторые параметры машинки RAG, например, не присутствовали при обучении сетки, бедная тварь каждый раз тыкается в это -- и делает открытия после десятка неудачных попыток воспользоваться старым известным ей описанием, забавно читать это, но это занимает драгоценные минуты размышления дорогой модели, а не доли секунды. Но главная недоработка -- это сам текст FPF, который "для людей". Поэтому его надо оптимизировать для RAG. Долго у меня висел вопрос о том, как же делать человеко-машинночитаемый Markdown на 3MB, ибо там сразу запредельно большое число уровней заголовков, человекочитаемость не признаёт никаких JSON, а ещё надо хоть как-то помогать RAG разных производителей и даже Markdown разных рендеров, ибо нам неизвестен целевой pipeline. Представьте паттерн второго уровня в кластере какой-то части, и у него четыре подуровня, а вытаскиваете вы это клочками на 4К максимум, хотя эти клочки и с перекрытием. Всё машинное время уходит на сборку паззла, так не должно быть. Ключевое соображение тут в том, чтобы в каждом подзаголовке надо человекомашиночитаемо указывать, из какого это паттерна -- это и люди прочтут (у них на экране откроется обрывок текста, и сразу будет понятно, из какого паттерна какой части и какое примерно место этого паттерна), и не совсем люди с их RAG тоже. Поэтому заголовки будут формата вроде "#### E.8:4.1 - Canonical Pattern Template" -- и ожидается, что LLM с ним разберётся получше, чем с JSON или HTML тегами-комментариями, ибо для них "заголовки" являются первичными источниками информации, а все эти "разметки" -- вторичными. Ну, и заголовок ни один пайплайн не отрежет, а вот "разные теги" отрезаются запросто. Там ещё немного разного синтаксического сахара для RAG (и для людей), вроде явного маркирования конца паттерна как ### E.8:End. Части становятся первым уровнем Markdown (# E), а паттерны принудительно все выводятся на второй уровень (## E.8), подпаттерны идут через точки уровнево вниз, а разделы паттерна идут дальше через двоеточие. Сам E.8 я уже поправил, а дальше оказалось что заголовки и маркер End проще всего сделать вообще "руками", прямо в Sublime Text. Основная проблема теперь -- перелопатить всё. Это надо сделать через не могу, и с автоматизмами тут явно будут проблемы (я смотрю иногда, как LLM пытается находить начало и конец паттерна, и понимаю, что я точно всё сделаю руками и точнее, и быстрее, и попорчу по пути всего поменьше). Из новинок -- паттерн E.19, который проверяет паттерны и результат выдаёт в unified diff по промпту "В файле спецификация FPF, которую мы улучшаем. Проверь паттерн A.1 по нормам паттерна E.19. Прочти сначала полностью текст этих паттернов". Про "прочти полностью текст" -- это не моя отладка для RAG, это просто очень полезная напоминалка, без неё LLM читит. Это очень удобно. Я взял паттерн A.1 и проверил, как он вытаскивается без разметки и с разметкой. Разница доходила до пяти минут! При этом рассуждение тоже пошло быстрее, ибо ссылка пошла на тег/номер раздела, а не на его полное имя. Так что часть работы я уже выполнил: все паттерны уже на одном уровне ##. Если надо искать какой-то паттерн, то искать надо с regex примерно вот так: "^## B.2.5" -- и всё быстренько и точно находится уже сейчас. Но дальше надо будет сделать апдейт всех вообще паттернов, чтобы они соблюдали нормы нового E.8 (а заодно проверить там и всё остальное), это будет большое и долгое приключение. Увы, пока у меня скорость работы поменьше, чем один паттерн в день. Почему это всё надо делать? Я всех учу, что надо первым делом наладить управление конфигурацией. А кто у нас главный пользователь, которому надо точно знать, что есть и что где лежит? Этот пользователь -- RAG, он разбирается с бардаком в файле в силу своего суперинтеллекта, как и люди, которые тоже вполне могут работать в бардаке, только долго из-за неминуемых переделок/re-works. Поэтому идём lean, но без этих ваших нечитабельных JSON.