Skills с ленивой подкачкой FPF паттернов
Уже появляются наборы skills для AI-агентов на основе FPF. Скажем, FPF/skills at skill · dimonier/FPF · GitHub – там skills (я говорил о том, что можно такое делать в “Буднях FPF-строения” Будни FPF-строения: ailev — ЖЖ), а сам FPF порезан по состоянию на сегодня на 159 отдельных паттернов с progressive loading via tools, всё это работает без векторного RAG, через function calling+file access. Автор имеет канал, где говорит, что попробовал эти skills в Cursor, и результат – “Волшебно! Рекомендую попробовать” (Telegram: View @samuprav). AI-Агент с этим мастерством/skills будет выполнять канонический цикл мышления:
- OBSERVE → Understand the user’s request
- SEARCH → Use fpf_search_index to find relevant patterns
- LOAD → Use fpf_read_pattern to load specific pattern details
- PLAN → Create MethodDescription based on loaded patterns
- EXECUTE → Implement the plan (actual work)
- AUDIT → Record Work with evidence
Если FPF резать на паттерны и подгружать по требованию, как это сделано в примере skills из предыдущего абзаца, то это становится частным случаем виртуальной памяти для знаний: вместо того чтобы держать всё в оперативке, агент держит индекс/manifest и подкачивает страницы. Skills-пакет — не просто удобная упаковка, а архитектурный выбор: кто-то (архитектор, создающий компилятор FPF2Skills) решает, что подкачивать, как компрессировать, а также как проверять результат (ну, или вообще всё это делать в оптимизационном цикле, если сделать результат измеряемым).
Метафора “LLM как OS” и “FPF как OS”
Идея FPF в том числе и в том, что в LLM как OS можно работать с “внешней памятью” (и с RAG, и с file access – ChatGPT обычно использует оба механизма), необязательно всё держать в контексте. Работа со skills в мелко порубленном FPF – это просто один из вариантов автоматизации построения оверлеев для “прикладных программ/приложений/задач_ОС” вроде FPF. При этом “FPF как приложение” (прикладной слой OS) в свою очередь для пользователя выступает как “OS для мышления” (это прямо сказано в readme.md в GitHub - ailev/FPF: First Principle Framework, а туда попало из предисловия, на октябрьском семинаре у меня был слайд на эту тему). Тем самым имеем тот же стек виртуализации, что и в обычном компьютинге: операционка под операционкой (ну, или над операционкой – с какой стороны смотреть). Насколько я понимаю, на эти темы было много в 2023 году, например, “MemGPT: Towards LLMs as Operating Systems”, [2310.08560] MemGPT: Towards LLMs as Operating Systems, “LLM as OS, Agents as Apps: Envisioning AIOS, Agents and the AIOS-Agent Ecosystem” ([2312.03815] LLM as OS, Agents as Apps: Envisioning AIOS, Agents and the AIOS-Agent Ecosystem), но мысль приписывают популяризатору Karpathy, ибо он дал это как внятную метафору на его выступлении 18 июня 2025 (транскрипт – https://singjupost.com/andrej-karpathy-software-is-changing-again/), так что это в народных мозгах “свежее, лето 2025, Karpathy сказал – надо делать!”.
Конечно, LLM как OS – это метафора, возникающая среда AI-агентов с их хитрыми когнитивными архитектурами состоит из вроде бы привычных для OS частей, но особенностей уже много, что проще говорить не традиционным для OS в целом языком (помним: многозадачность, многопользовательскость, планировщик, микроядерность – на верхнем уровне там вот это), а языком более приземлённых подсистем OS, например, управление памятью, управление прикладностью как управление смыслами (вместо управления приложениями в целом). При этом OS понимается именно как управление прикладностью, а давно известные tool use, план-акт, внешние тексты, хитрый retrieval — это всё не обсуждается как OS, а продолжает давнюю линию Toolformer ([2302.04761] Toolformer: Language Models Can Teach Themselves to Use Tools), которую я много раз уже обсуждал в блоге. Это привычно. Менее привычно появление стандартов на всё это: MCP, который распространился по миру как то ли лихорадка, то ли пожар – это про доступ LLM к разным инструментам, но в том числе и данным (MCP это интерфейс добавки памяти в контекст LLM: банков и баз данных, каких-то инструментов, которые тоже в конечном итоге поставщики данных). Skills – это аналог стандартизации вызова “прикладных программ” в традиционных OS, да ещё с разными преимуществами вроде discovery и ленивой подгрузки.
Вот как реагирует на появление LLM онтологическая тусовка, традиционно занимавшаяся “базами данных” в форме “графа знаний” (всяческих трипл-сторов): она предлагает язык с онтологическими операциями LOGOS-K, при этом основное отличие этого подхода от “онтологической традиции” в том, что обычно в онтологических языках упор на декларирование понятий, а не на операции с понятиями. Ну, и ещё акцент в этом языке онтологических операций на “все ходы записаны”, чтобы работать с воспроизводимыми рассуждениями: https://dzen.ru/a/aV5UbS4rShKLPHfk. Ссылка на Дзен, доступно через VPN извне России, но есть GitHub - A-Universum/LOGOS-k: LOGOS-κ — специализированный язык программирования, Исполняемый онтологический протокол Λ-Универсума для работы с реальностью как сетью связей. Это не просто язык программирования, а инструмент для онтологического анализа и симбиотического со-творчества между человеком и ИИ на русском-с-питоном, в примере сессии там “как связать любовь со страхом”, так что осторожно! Язык там очень специфичен: "PhiRitual — не API-вызов, а ритуал диалога с ИИ, включающий: подношение, оценку NIGC, признание слепых пятен, резервный протокол. Но с точностью до языка это ведь похоже на “канонический цикл мышления”!). Народная мысль бьётся, LLM всё больше понимается как операционная система, поверх которой делают приложения, написанные на каких-то skills и прочих “DSL мышления”. Вполне можно и FPF относить к такому классу систем, хотя архитектура его всё-таки другая и не сводится к “набору операций”, она ближе к декларативным представлениям, чем процедурным.
Многоуровневая память и многоуровневая виртуализация
Многоуровневая память и многоуровневая виртуализация – это must в архитектурных рассмотрениях всяких вычислителей. И на этой полянке происходит много чего интересного: на верхнем уровне идея динамического контекста (первым тут Cursor – https://cursor.com/blog/dynamic-context-discovery, но доступно пока только в Nightly builds, но я думаю, что через месяц появится ещё много у кого). Но есть подвижки и на более низком уровне: DeepSeek выдал “Conditional Memory via Scalable Lookup: A New Axis of Sparsity for Large Language Models” (ссылки на статью и обзоры вот тут: Telegram: View @gonzo_ML, и там же читаем с моими маленькими добавками: “Работа ставит под сомнение парадигму «all-neural» (то есть это расширение идеи MoE, там не только LLM-эксперты). Доказано, что специализированные лукапы эффективнее (O(1) lookup-модуль) механизмов внимания для статических паттернов (сущности, идиомы), что позволяет разгрузить головы внимания для реальных рассуждений. Более того, поскольку индексы поиска детерминированы и недифференцируемы, их можно как таблицы памяти выгрузить в RAM процессора (CPU) с ничтожной задержкой. Это открывает путь к масштабированию моделей далеко за пределы HBM видеокарт) – ибо гибрид дифференцируемых и недифференцируемых архитектур, каждая часть может эффективно выполняться на своей специализации аппаратуры”. Статья submitted 12 Jan 2026, свежатинка. Конечно, архитектурно там можно много чему возразить. Например, в посте “почему я не использую теги” 2009 (Почему я не использую теги: ailev — ЖЖ, это ж была очень модная тема!) я писал, что тегирование памяти дохлое заведомо дело: у тебя меняется viewpoint, и твой классификатор можно пересматривать. Каждый раз, когда вы отжимаете данные каким-то способом (например, в классификатор, в какую-то метафору) с течением времени в исходных данных может оставаться что-то интересное для нового viewpoint, а созданный со старым viewpoint классификатор отмирает, так его и не надо создавать, если у вас есть какой-то более гранулярный доступ к данным (скажем, векторная база данных тоже будет отмирать по мере изменения общепринятой картины мира, но это довольно медленный процесс. Если взять вектора для банка данных (банками называли хранилища именно текстов, а не записей, для записей были базы) старинных текстов, то что там с векторами на понятие смартфона? И подобные проекты есть, скажем, TimeCapsuleLLM v2— London (1800–1875), тексты только до 1875 года, Release v2 - London (1800-1875) · haykgrigo3/TimeCapsuleLLM · GitHub. Сейчас сингулярность, то есть “всё быстро”. LLM годичной давности через пяток лет будет отражать абсолютно другую модель мира! Собственно, “переписки истории” это просто попытки поджать информацию по историческим фактам с использованием других viewpoints, других алгоритмов сжатия.
Входной текст про смартфоны привычен сейчас, никаких проблем не будет. Но теоретически – проблемы с поджатием сырых данных всегда будут. Вот у меня текст ещё 2016 года про “онтологии и бибинарную модель мышления”, Онтологии и бибинарная модель мышления: ailev — ЖЖ, где я приводил пример фолксономий и IBM Watson, который не мог сжимать википедию и банк текстов сценариев, ибо вопросы в Jeopardy! были самые разные, поэтому нельзя было построить “онтологию” и резко ужать тексты. Но как они работали в 2011 году, когда ещё не было сжатия в векторные базы данных? Суперкомпьютером, гоняли полные тексты безо всякого сжатия. Сжимать можно очень по-разному, и это обычно дорогая процедура, чтобы посильнее отжать на максимальное обобщение возможных viewpoints. И чем сильнее отжимаешь, тем быстрее устаревает результат отжатия. То есть нельзя отжать и выкинуть исходные данные!
Этих уровней памяти/сжатия оказывается до чёртиков, и там не всегда сжатие, ибо при повышении точности вам надо “разжатие” – добавление информации через раскрытие “зонтичных” терминов, типа “холодно” раскрывается вдруг в “у меня дома сегодня холодно, 22 градуса Цельсия”. Скажем (тут порядок уровней ещё можно пообсуждать, и вообще, идея “уровневости” по отношению к каким-то иерархиям, решёткам и вообще графам – сомнительна, “метафора”, вообще ось, по которой выстроены эти уровни – она не так легко угадывается):
– L0: in-context (окно) — самое дорогое, самое хрупкое, требует агрессивного curation+compression, и лучше бы не “руками” (смысл “операционной системы” часто видят только в этом).
– L1: “static memory” внутри модели (веса), а во время вывода ещё и “регистры”, “переменные”. Тут тоже часто задействуется сегодня питоновский tooling, но можно ведь сделать и специализированный быстрый tool.
– L2: conditional memory / lookup-таблицы это новенький вариант между вычислением и параметрами.
– L3: retrieval/индексы (RAG/поиск) — адресация по ключам/семантике, в случае RAG/семантики это очень криво реализованный Священный Грааль: ассоциативная память, а не память по адресам/ключам. Но и адресная память важна (у меня в Thinking регулярно проскакивает, как LLM с tooling использует RAG для того, чтобы понять “о чём это, и есть ли вообще”, а затем таскает через Питон точные фрагменты файла).
– L4: файлы/skills/resources (подгружаем по требованию) — в конечном итоге это «страничная память».
ML.4 — Двухчастная оценка данных через «битовый объём модели» при заданном бюджете вычислений
Но больше всего меня из этих архитектурных новогодних новостей привлёк текст “Epiplexity: Quantifying the Structural Value of Data for Bounded Observers”, [2601.03220] From Entropy to Epiplexity: Rethinking Information for Computationally Bounded Intelligence. Вот из гонзо-обзоров по-русски (Telegram: View @gonzo_ML): “даёт строгую метрику для отбора данных: для предобучения важен не минимум финального лосса (энтропии), а максимум усваиваемой структуры (эпиплексии)”. Мой взгляд зацепился за дребезг в сочетании с формулировкой “Авторы ввели понятие эпиплексии (epiplexity) — новую метрику из теории информации, которая оценивает объём структурной информации, доступной вычислительно ограниченному наблюдателю. В отличие от энтропии Шеннона или колмогоровской сложности, подразумевающих бесконечные ресурсы, эпиплексия явно учитывает конечность модели (программы) и процесса обучения (вычислений)”. Ха, эпиплексия - это максимум структуры (усваиваемой), то есть это по типу “структура”, и одновременно это оценка объема (структурной) информации, то есть по типу “объём информации”. Или структура измерима в битах, что уже интересно, или что-то с этими фразами не так. Очевидно, что это “мутное понятие про мутные понятия” – и мопед мой, ибо мне в архитектуре крайне нужно слово “структура”, которое неуловимо в своём значении, чистая метафора! Я сделал промпт для ML.4, который по факту повторяет промпт с “уточнением смысла” для ML.3 из (ML.3 - Измеримый порог надёжного вывода для LLM-систем: ailev — ЖЖ): “В файле у тебя спецификация FPF. Прочти полный текст статьи [2601.03220] From Entropy to Epiplexity: Rethinking Information for Computationally Bounded Intelligence. Пиши по-русски на основе статьи паттерн ML.4 по шаблону из E.8, применяя приёмы повышения точности из паттернов кластера A.6 (особенно A.6.P и его подпадтерны). Не используй при этом терминологию FPF, не объясняй FPF и распаковку, пиши по-русски, добавь дидактичности, текст итогового паттерна будут читать инженеры-менеджеры. В паттерне используй не оригинальные понятия из статьи, а только “распакованные” (восстановленная semantic precision) понятия. Следи, чтобы в тексте не проскакивали нераспакованные понятия, которые в A.6.P и его специализациях заявлены как red-flag. Проверь, чтобы вместо одного невнятного перегруженного понятия ты не выбрал в качестве замены другое, столь же перегруженное (скажем, вместо “якоря” использовать “основу” или “базу” - это слишком общие понятия, они не отражают онтологию предметной области, это метафоры, а не точные объекты, с этим и имеет дело A.6.P и его специализации. Если нужной специализации не найдётся, используй A.6.P напрямую). Все остальные паттерны используй в тексте по потребности”. С удивлением обнаружил, что никакой “эпиплексии” в выдаче не обнаруживается (вместо неё прямо словами что-то вроде “количество усваиваемой из данных регулярности для вычислительно ограниченного наблюдателя”, а слова вроде “структуры” паттерн вообще строго запрещает (и вместо него предлагается та же усваиваемая или неусваиваемая регулярность, то есть нечто, что потенциально можно вынести за скобки, отжать).
Вообще, тема сжатия меня не отпускает много лет, есть же слоган “интеллект – это машинка сжатия”. Вот, например, пост ещё 2018 года “Жми, господь”, Жми, господь!: ailev — ЖЖ, да и в академической литературе этого много (вот в 2023 году, Language Modeling is Compression, [2309.10668] Language Modeling Is Compression).
Я прогнал построение паттерна ML.4 несколько раз (каждый раз ведь даются интересные варианты!), в них время от времени появляется отдельный пункт для ML-инженеров:
ML.4:4.5 — Лексический “файрвол” (что запрещено оставлять нераспакованным)
Если в обсуждении встречаются слова ниже — это сигнал, что вы ещё не назвали измеряемые объекты:- “информация”, “информативность” → заменять на
M_T,R_TилиI_Tс указаннымиTи классом моделей. “структура”, “смысл”, “семантика” → заменять на “регулярность, выражаемая длиной программы модели
M_Tпри таком-то бюджете”.- “качество данных” → разложить на: (а) изменение , (б) изменение
R_T, (в) влияние на условную постановку (если задана), (г) ограничения по загрязнению/перекрытию оценок (операционный риск).
ML.5 — Профиль передачи информации через промежуточную сводку в многошаговых системах на языковых моделях
Вот ещё фактически про память: трюк с компрессором (когда-то это было очень модно, менять память на вычисления, “сжатые разделы диска”), тут то же самое – только компрессирование не памяти, а для передачи следующему “дорогому вычислителю”, который будет перемолачивать сжатую более дешёвым компрессором информацию. Это я про статью “An Information Theoretic Perspective on Agentic System Design”. Прогоняем её через тот же промпт с FPF (в нём меняем только ссылку на arXive – [2512.21720] An Information Theoretic Perspective on Agentic System Design, обзор по-русски Telegram: View @gonzo_ML), чтобы получить ML.5, но при этом говоря в конце промпта “Учти также ещё и вот этот паттерн ML.4:” и дальше просто приводим полный текст ML.4, полученный в предыдущем проходе. В рассуждениях модели мы немедленно видим фразы вроде “Avoiding vague, red-flag terms. I have to avoid using vague or umbrella terms like “quality”, “context”, “process”, as they can obscure important relationships. Instead, I’ll focus on being specific, like when mentioning “the increase in model size A given fixed data and a prompt” and its effect on mutual information and downstream metrics. Additionally, I need to incorporate the ML.4 pattern’s focus on model code length and residual unpredictability within a fixed budget”. Вот что пишет Григорий в “почему это важно”: “Исследование ломает стереотип «всё решат гигантские модели на последнем шаге». Оказывается, выгоднее вкладываться в компрессор: 7B-модель для сжатия в паре с небольшим предиктором часто бьёт огромные end-to-end модели. Практически это значит, что локальная 3B-модель на ноутбуке может сжимать данные, сохраняя 99% точности SOTA-пайплайнов, но срезая косты API на 74%”. А вот что появляется в одном из ответов (я их тоже сделал несколько) GPT-5.2 Pro + FPF в ответ на промпт: “Связь с ML.4: ML.5 можно рассматривать как прикладной язык для случая, когда «извлекаемая регулярность при ограниченном бюджете» проявляется как сжимаемый промежуточный текст между двумя моделями. Здесь бюджет фиксируется через |Z|, FLOPs‑per‑generation/стоимость, а «что успели извлечь» диагностируется через r и d”. Но больше всего мне нравится в ML.5 повторяющийся повтор мотива запрета на “слова-зонтики”, прикрывающие собой множество значений:
ML.5:4.6 — Лексический стоп‑лист для отчётов и обсуждений
Чтобы разговор не превращался в спор о словах, вводим запреты на «зонтики» — допускаются только вместе с явными величинами/процедурами:- Запрещено без уточнения: «качество промежуточного текста», «информативность», «эффективность», «содержательность», «модель лучше», «связано с качеством».
- Разрешено вместо этого:
- «среднее
r = \widehat{I}/|Z|в бит/токен при N=…, S=…, декодирование=…»; - «искажение
dопределено как 1−accuracy (или 1−cosine similarity эмбеддингов), протокол оценки=…»;«стоимость измеряем как FLOPs‑per‑generation (или $/задачу при тарифах даты …)».
- «среднее
4.6. Лексический предохранитель для обсуждений (чтобы не прятать смысл в общих словах)
Слова‑триггеры, которые нельзя оставлять без разъяснения в техническом решении (разрешены только как черновик, после чего MUST быть переписаны):- «качество сводки» → переписать как
⟨I_bits, R_bits_per_tok, T_sum⟩при фиксированныхB_req, M_score, H. - «стало лучше/хуже» → переписать как «
R_bits_per_tokвырос/упал на …,T_sumизменился на …,C_reqизменился на …,Dизменилась на …». - «модуль A связан с модулем B» → переписать как «
G_ansполучает на вход толькоZ, аZсгенерированG_sumпо(X,Q); изменениеG_sumизменило профиль …». - «тот же режим/та же конфигурация» → переписать как «при фиксированных
B_req, M_score, Hи неизменных лимитах токенов/декодировании». - «синхронизировали/привязали/подключили» → переписать как конкретное действие: «заменили
G_sum», «изменили лимитT_sum», «добавили второй раунд запроса к модулю сводки», «перешли на другойM_score».
Ссылка на один из вариантов ML.4 (конечно, каждый прогон будет давать разный вариант): https://chatgpt.com/share/69666c6a-17e0-8013-a33a-7965005f7b6a. Обратите внимание, что там “непонятные слова” вроде перплексии и эпиплексии тоже переведены на “смысловые” вместо греческих. Если хочется иметь англоязычный оригинальный термин, то можно просто попросить давать его в скобках, но я не просил: мне интересно было как это вообще работает. Ссылка на один из вариантов ML.5: https://chatgpt.com/share/69675db8-b8dc-8013-8d6c-c3552df72868.
Вы можете что-то подобное сделать сами – промпты в посте (и примерах по ссылкам выше) есть, FPF подгружать файлом из GitHub - ailev/FPF: First Principle Framework, я брал модель GPT-5.2 Pro, ибо она даёт хороший ответ (а модели серии Thinking с малым бюджетом мышления за малый бюджет долларов от всех провайдеров дают кривоватые ответы, после чего воспроизводится ситуация “-- мне не нравится опера “Евгений Онегин”! – О, ты ходил в оперу? – Нет, мне Мойша вчера напел”. Вот следите: вам напевает за $20 студент-третьекурсник (по моим ощущениям качество выдачи примерно такое) или за $200 вполне уже инженер (хотя тоже нужен глаз да глаз, но за каким инженером этого глаза не нужно?).
Куда думать по всем этим темам
Я на эту пару паттернов гляжу и понимаю, что надо подробней подумать по довольно большому набору тем:
– архитектуру многоуровневого сжатия контекста, при этом качество сжатия контекста в его начале (из помойки качественный входной материал для решения задач) оказывается чуть ли не более важным, чем качество Главного Отвечальщика, вынужденного разбираться с шумной (другими словами: несжатой) помойкой.
– многоуровневое сжатие важно и для FPF. Вот прямо сейчас в ходе рефакторинга я получил чрезмерно пушистые паттерны – и вынужден их был дополнительно отжимать. Я всё оттягивал момент для поджатия FPF (ибо там архитектурно всё-таки я сразу надеялся на внешнюю память и оверлеи), но не запланировать ли этот момент чистки-отжатия на пораньше?
– противоположная сила в forces ADR из примера IBM Watson, когда они ничего не могли поджать, ибо вопросы могли быть любые, а не строго одни и те же, как в корпоративных проектах “LLM под капотом”, поэтому любое сжатие обрубало ответы на какие-то вопросы.
– сама многоуровневость сжатия: архитектурно у нас системные уровни, уровни специализации и классификации (в том числе уровни частичной упорядоченности в онтологических решётках, ибо не хочется чистых иерархий), и вот появляются многоуровневые архитектуры памяти и как-то связанные с ними многоуровневые архитектуры сжатия, это разные типы отношений в архитектурах.
– понятие “структуры”, конечно, информационное (не “что там в мире”, а “что я там заметил своей моделью”) и “сложность структуры/архитектуры” и всякое такое, конечно, определяются сложностью кода модели. Через эти статьи можно выходить к измеримым понятиям структуры (а измерения всегда можно аппроксимировать, если знаешь, что именно хочешь замерять) и тем самым к измеримым характеристикам архитектуры, а не только к измеримым архитектурным характеристикам системы (то есть обсуждать характеристики самой архитектуры, а не только характеристики системы с архитектурой, а архитектуру уводить в качественные метафорические рассуждения вроде “метафора микроядерной архитектуры”).
– семантическая распаковка смысла по “триггерам/флагам мутных понятий в тексте” на пяти шагах (писал подробней в ML.3 - Измеримый порог надёжного вывода для LLM-систем: ailev — ЖЖ отлично работает, но с этим надо разбираться отдельно, непонятно, когда. Возможно, в ходе разбирательств с архитектурой, ибо без этого там сплошное размахивание руками).
– эти паттерны сами по себе уже дают SoTA по вариантам распаковки “качества данных” и “структуры”: может, добавить аналоги ML.4 и ML.5 не столько в характеризации, сколько как специализации для “уточнения зонтиков на границе” A.6.P?
– интересные примеры “перевода на понятный язык”, когда вместо всех этих греческих слов вроде придуманной авторами “эпиплексии” тебе в текст вставляют понятные термины.
– опять-таки всплывает вопрос про движение ещё и в другую сторону, “метафорическую-гипнотическую”. В НЛП (которое нейролингвистическое программирование) чётко говорят, что если вы хотите прослыть занудой, то “мета-моделируйте” (то есть требуйте уходить от метафор во что-то измеримое, а ещё этот уход в измеримое называют переходом к сенсорно-обусловленному языку). Но если вам надо кого-то загипнотизировать, присоединиться к непонятно каким мыслям в его голове, то надо использовать “модель Милтона” (Милтон Эриксон, великий гипнотизёр), то есть говорить намеренно мутно и общо – прямо противоположное этому мета-моделированию. Терминология тут должна быть другая, но у “метафоризации” и “уменьшения точности” точно есть полезные свойства, и надо это поизучать.
– … и ещё много чего.
А пока я в эти дни занят больше не великими планами, а “уборкой территории”, вечным рефакторингом: в текущем FPF универсальное в части G уже вынесено в паттерн G.Core, а я перемалываю все 14 остальных паттернов части G в промежуточную форму, где специальная их часть – отдельно, а общая даётся ссылкой на G.Core. Это фаза 2 рефакторинга (фазы 0 и 1 я уже прошёл), исправление модульности. Фаза третья этого рефакторинга будет посвящена доработке механизмов характеризации – индикаторизация, скоринг, агрегация, сравнимость к уже имеющейся нормализации. А потом – TGA, затем архитектура и evolvability, затем архитектура FPF, затем second principles frameworks. Так победим! Но, конечно, и сейчас уже многое работает.
