Минимум два инженера-менеджера сейчас смотрят в сторону того, чтобы вместо “библиотеки промптов к FPF” сделать что-то похожее, но в формате agent skills – нового стандарта. Новое тут только в слове “стандарт” и поэтому – переносимости между разными AI-ассистентами. По большому счёту, успех quint code (GitHub - m0n0x41d/quint-code: Structured reasoning framework for Claude Code, Gemini, Cursor, and Codex — hypothesis-driven decision making with auditable evidence trails - 1.1K stars, 86 forks на момент написания) как дистилляции FPF – это примерно те же skills, но а) без стандарта и б) без отсылок к полному FPF, но уже с эволюцией в более сильную MCP-архитектуру, чтобы управлять данными (в том числе FPF как “данные аж на 4MB”). Процедурная часть – это эти самые agent skills, которые устроены довольно просто: папка со SKILL.md + опциональные папки scripts/, references/, assets/. Агент подгружает описания всех skills, а полные инструкции/референсы — только когда активирует skill. Представьте, если у вас было бы что-то вроде “набора команд сильного мышления” (skills), где-то 20-30 команд. Устроено это было бы как 20-30 коротких промптов (хотя стандарт позволяет много больше, чем “просто промпты”, там целые “папки”), которые бы вполне помещались в контекст, но ссылались на полный FPF в тамошних папках references. Вот тут мой разговор с GPT-5.2 Pro о том, как это могло бы быть устроено: https://chatgpt.com/share/695e6eb4-f658-8013-bce1-470bf9918339. Разные инженеры-менеджеры могли бы выпустить разные FPF skills pack, которые имели бы разные направленности – кто-то бы выпячивал canonical reasoning cycle, а кто-то бы выпячивал повышение точности языка.
FPF реально большой, и он продолжает расти: наборов по 30-40 удобных “команд” (skills - это по факту “команды языка программирования LLM”) можно сделать довольно много разных, и ещё ж там можно думать о развитии в сторону MCP-архитектур со всем тамошним богатством возможностей. Skills не равно MCP, но они могут существенно дополнить друг друга: skills описывают как думать (процедурно), MCP говорит про то, где лежат для этого данные (и это важно, потому как FPF ни в какой контекст не влезет даже при избирательной подгрузке, там нужны продвинутые опции вроде RAG. Ну, или ещё более продвинутые: нет сил смотреть, как RAG даёт произвольно порезанный на чанки FPF, очень хочется помочь – нарезать на блоки покрупнее (паттерны и крупные разделы в них, как пример) и отгружать их через MCP. Хотя не уверен, что это хоть как-то ускорит работу, надо проверять.
FPF skills-pack - это упаковка процедур обращения к знаниям FPF. Но и сам FPF тоже надо упаковывать. 4 января 2026 я жаловался, что попытка заняться архитектурой FPF привела к появлению огромного задания на 120Кзнаков (lytdybr: ailev — ЖЖ). В результате разбирательства с этой архитектурой я удалил из FPF понятие архитеории. Оно родилось из различия трансдисциплин, выражаемых какими-то транс-теориями (но слово ужасное, поэтому выбрано было “архи” – как у “архетипов”, вот сделали “архитеории”, более общие, чем у типов). Поводом было то, что у нас ведь иерархия принципов: нулевые, первые, вторые и т.д., а не просто два уровня. Но разбирательство показало, что текущая спецификация везде выпячивает микроядерную архитектуру (ядро “про архитеории” и архитеории как плагины), а отношение там оказалось – “часть-целое”, сигнатуры там интерфейсы, а по интерфейсам идут “вызовы одних теорий другими”. Ай, нехорошо, недоглядел! Если базировать архитектуру FPF на принципах (теориях), а не архитеориях (которые подразумевали выполнение, то есть там механизмы с эффектами, ведущие к методам, а не теории), то главными начинают быть не связи “вызова” одного метода из другого, а специализации. Сразу всё другое: традиционные модульные архитектуры перестают быть релевантными, вместо “микроядро и плагины” появляются “общие принципы и специализации”. Обсуждение с людьми показало, что иерархию специализаций и иерархию частей-целых вполне себе путают. Контрольные вопросы тут вроде “в специализациях не говорят о границах, а в мереологии говорят о границах”, а путающие соображения вроде “но в специализации же границы между множествами!”. Ага, “квадрат – это прямоугольник”, явная специализация – где тут границы, где тут интерфейсы? Но запросто можно навести иерархию, “прямоугольник выше по иерархии, чем квадрат”. А дальше можно говорить, что стек “уровней” (ну, или “слоёв”, поскольку “не модули”) по специализации. Дальше “стек” распаковываем в иерархию, это не стек – и тут обычно много неожиданностей. Иерархию специализаций мыслят чаще как решётку понятий (General Concept Lattice - Wikipedia ), и это про концепты. С принципами, теориями, механизмами тут всё ещё запутанней, а ведь дальше нужно ещё и смотреть не только на обобщения/специализацию принципов, но и на их композицию – те же контрфактуальность и причинность оказываются гибридной конструкцией из самых разных нулевых и даже первых принципов, нужных для их понимания (я подробней об этом говорил на втором – декабрьском 2025 – семинаре по FPF). Итого: из FPF удалены понятия архитеории, а также плагинной архитектуры. Осталось ядро и расширения, вместо “архитеорий” пока говорим о паттернах, понимая при этом, что паттерн тут синтаксическая/публикационная форма, а модуль – это что-то содержательное. Вроде как “модуль языка программирования” не равен “файлам, используемым для записи модулей какого-то кода на языке программирования”, но разбирательство с этими нюансами мы отложим до “когда-нибудь”, когда разберёмся с архитектурой в целом и модульностью в частности. Будем надеяться, что это случится ещё зимой.
Сама модульность чаще всего рассматривается как работа с конструктивными объектами (говорим о холонах: и системах, и эпистемах). Если заметить, что эти конструктивы существуют не сами по себе, а выделяются из окружающего фона вниманием (“острым глазом”, будем тут метафоричны) инженера, то модульность оказывается инженерным view. Модули выделяются из мира по границам, которые проводятся инженерами с их специфическим viewpoint. Сама “модульность” – это публикационная/презентационная штука, никаких модулей “на самом деле”. Это тоже тонкость, которая ведёт к совсем другим принципам обсуждения модульности, дальше там будет “два архитектора – три архитектурных описания с разной модульностью”. Вот над этим надо поразмышлять подольше: модуль обсуждаем как часть архитектурного описания или как часть холона? Отдельный вопрос про конструктивные модули и функциональные единицы: в чём там разница. Тут тоже мутноватое место, из авторитетов с особым мнением тут упомяну Wim Gielingh (некоторые помнят “диаграмму гамбургера”) и Ian Dietz (который возражал против “функционального” и “физического” во второй книжке по DEMO), а у нас текущий вариант брался из ISO 15926, а это только один из вариантов. Поскольку мы хотим привязаться к архитектуре с графом трансдукций, надо это будет ещё раз обсуждать, что там на сегодня SoTA – и вернуться к вопросам из мая 2024, почти уже двухлетней давности текста Методолог -- то, что не вошло из старого в современного архитектора и осталось в разработчике: ailev — ЖЖ, я как раз обсуждал там похожие вопросы. В любом случае, вопрос об архитектуре FPF и модульности FPF надо ставить после того, как в FPF будет полноценный набор паттернов по архитектуре – и вот тогда мы просто применим его к самому FPF, раскрутка/bootstrapping.
После всех этих обновлений архитектуры я сделал:
– A.6.9 - CrossContextSamenessDisambiguation, это ещё одна специализация A.6.P как общей процедуры поднятия семантической точности при описании ситуаций “на границе”, в этот раз на границе ограниченных контекстов (boundedContexts).
– сделал два раздела в preface, чтобы описать “пограничный” кластер A.6 в целом и особо A.6.P для распаковки “лексика - онтика - математика - онтология - точная лексика” с его специализациями.
– удивился тому, сколько народу пытаются засунуть 4MB файл спецификации FPF в контекст (и в чате отвечал, и даже было прислано issue), так что ответил всем сразу: вписал в несколько мест ReadMe.md в GitHub, что надо add file (в RAG), а не read file (в контекст). Надеюсь, это поможет. FPF не надо помещать весь в контекст, с ним отлично (насколько он вообще может работать “отлично”, ибо есть технические ограничения) работает RAG! Там для RAG довольно много сделано в самом файле, чтобы и “машиночитаемость” была, и “человекочитаемость” (а я точно знаю, что люди любопытные – и таки пытаются FPF читать. Ну, я тоже когда-то словари читал, и энциклопедии я тоже читал, это нормально – но только для сильных духом).
– дальше я сдвинулся к реализации плана по suite механизмов характеризации и заодно универсализации части G – CHR-arch.md — Яндекс Диск. Удалось сделать не очень много, но как минимум A.15.3 - SlotFillingsPlanItem, а а также A.6.7.CHR - CHRMechanismSuite и ещё добавил профили проверок для suits и P2W в E.19, на чём и закончил фазу вторую плана. Это не так много, но даже длинные планы, если заниматься их выполнением, имеют тенденцию быть выполненными. Так что я продолжу с характеризацией и частью G, а затем вернусь к TGA (там ведь тоже немало!). И уж дальше – архитектура и модульность.
