Рабочая система МТС по issue #42

[konard]

Summary

Fixes #42.

PR #48 фиксирует рабочую МТС как текущую систему: аксиому акорня, шаблонный поиск, группировку формы, последовательность форм, прямоассоциативное чтение последовательной записи и смысл конструктора связи через последовательность смыслов абитов.

Что изменено

• README.md обновлён как актуальная точка входа: рабочая рамка, канонические формулы, стабильные и изменяемые части, команды проверки.
• tests/mtc_formulas.mtc содержит чистые формулы МТС без служебного DSL.
• Добавлены нормативные формулы круглой группировки как выделения формы-операнда: ({}) = {}, {}{} : ({}) ⟼ {}, {}({}) : {} ⟼ ({}).
• Прямоассоциативность последовательностей закреплена через саму последовательную запись: {}{}{} : ({}{}) ⟼ {} и {}{}{} = (({}) ⟼ {}) ⟼ {}.
• Явная правая группировка отделена от чтения по умолчанию: {}({}{}) : {} ⟼ ({}{}), {}{}{} != {}({}{}).
• docs/theory/Система аксиом МТС.md уточняет карточки А2-А4 и правило, что круглые скобки фиксируют границу уже собранной формы.
• docs/specs/Формальная нотация МТС.md и docs/specs/Шаблонный поиск МТС.md различают одного кандидата в условии формы и позиционные кандидаты в последовательности.
• Активные документы очищены от процессной и исторической риторики; регрессионные тесты теперь проверяют это.

Текущие формулы

∞ : {} = {} ⟼ {}
∞ = ∞ ⟼ ∞

({}) = {}

{}{} : ({}) ⟼ {}
{}({}) : {} ⟼ ({})
{}{} : {} ⟼ {}
{}{} = {} ⟼ {}

{}{}{} : ({}{}) ⟼ {}
{}{}{} = (({}) ⟼ {}) ⟼ {}
{}{}{} = {} ⟼ {} ⟼ {}

{}({}{}) : {} ⟼ ({}{})
{}{}{} != {}({}{})
{}{}{} != {} ⟼ ({} ⟼ {})

♂{} : ♂{} = ♂{} ⟼ {}
♂∞ = ♂∞ ⟼ ∞

{}♀ : {}♀ = {} ⟼ {}♀
∞♀ = ∞ ⟼ ∞♀

{[} : ∞♀
{]} : ♂∞

{[}{]} = {[} ⟼ {]}
{⟼} : {[}{]}
{⟼} = {[} ⟼ {]}

Что намеренно не сделано

• Полноценный parser/prover новой нотации пока не реализован.
• :, =, ¬, ↛, смысловые аксиомы для 1 и 0, пустой результат поиска и независимые кандидаты вне последовательной записи остаются в регистре открытых вопросов.

Reproduction / Review Focus

Последний review требовал связать последовательность с круглыми скобками как механизмом выделения операнда. Это закреплено формулами:

{}{} : ({}) ⟼ {}
{}({}) : {} ⟼ ({})
{}{}{} : ({}{}) ⟼ {}
{}({}{}) : {} ⟼ ({}{})
{}{}{} != {}({}{})

Регрессионные тесты проверяют эти формулы, правило позиционных кандидатов, правило круглых скобок и отсутствие процессных маркеров в активных документах.

Test plan

• python -m pytest tests/test_issue42_docs.py -v --tb=short → 19 passed
• python -m pytest tests -v --tb=short → 62 passed
• ruff check parsers/ converters/ core/ tests/ --ignore E501,F401
• git diff --check
• git diff --cached --check

[konard]

Working session summary

Implemented and pushed the issue #42 rewrite to PR #48:

#48

What changed:

• Reframed README and main theory docs around the new ∞ : {} = {} ⟼ {} foundation.
• Added the requested foundation/spec docs for layers, template search, new axioms, and serialization.
• Updated formal notation, axiom template, plan, contributing notes, archive policy, and CI.
• Added tests/test_issue42_docs.py to prevent the old A0–A16-final framing and {}-as-set interpretation from returning.

Verification:

• Local: python -m pytest tests -v --tb=short → 47 passed.
• Local: ruff check parsers/ converters/ core/ tests/ --ignore E501,F401 → passed.
• Local: git diff --check → passed.
• GitHub CI on PR Рабочая система МТС по issue #42 #48: all jobs passed.
• PR is marked ready for review, branch is pushed, worktree is clean.

---

This summary was automatically extracted from the AI working session output.

[konard]

🤖 Solution Draft Log

This log file contains the complete execution trace of the AI solution draft process.

💰 Cost estimation:

• Model: GPT-5.5
• Provider: OpenAI
• Public pricing estimate: $6.988074

📊 Context and tokens usage:

• 159.3K / 1.1M (15%) input tokens, 28.8K / 128K (22%) output tokens

Total: (159.3K + 4.1M cached) input tokens, 28.8K output tokens, $6.988074 cost

🤖 Models used:

• Tool: OpenAI Codex
• Requested: gpt-5.5
• Model: GPT-5.5 (gpt-5.5)

📎 Log file uploaded as Repository (46329KB)

• View complete solution draft log

---

Now working session is ended, feel free to review and add any feedback on the solution draft.

[konard]

✅ Ready to merge

This pull request is now ready to be merged:

• All CI checks have passed
• No merge conflicts
• No pending changes

---

Monitored by hive-mind with --auto-restart-until-mergeable flag

[netkeep80]

Review PR #48: переосмысление оснований МТС по issue #42

Общая оценка

PR #48 делает правильный первый шаг: он переводит репозиторий из старой рамки А0–А16 в новую рабочую рамку issue #42, где:

Ачисла описывают структуры связей.
Формальная нотация МТС описывает смыслы и шаблоны смыслов.
Система аксиом МТС описывает виды форм смыслов.

Это именно то направление, которое нужно. Особенно ценны следующие изменения:

• README больше не подаёт старую систему А0–А16 как финальную.
• Введены новые документы Основания МТС, Новая система аксиом МТС, Слои нотации МТС, Шаблонный поиск МТС, Ачисла и сериализация.
• Зафиксирована ключевая формула нового чтения акорня:

∞ : {} = {} ⟼ {}

• [] вынесены в слой ачисел и сериализации.
• {} отделено от пустого множества, пустого результата, несвязи и абитового 0.
• Добавлен регрессионный тест, чтобы старая трактовка {} как множества и старая финальность А0–А16 не вернулись автоматически.

Однако PR пока выглядит как первая фиксация нового понимания, а не как завершённая переработка. Его не стоит мержить как финальное закрытие issue #42 без дополнительной чистки и доформализации.

---

Главный вывод ревью

PR нужно оставить открытым и доработать.

Причина не техническая: CI может проходить, но смысловая спецификация ещё не стабилизирована. Сейчас в PR одновременно присутствуют:

1. новая рамка {} как шаблонного поиска;
2. старые исторические документы, оставленные в активной теоретической зоне;
3. недостаточно формализованные правила исполнения {};
4. слабые регрессионные проверки, которые не ловят реальные смысловые противоречия.

Нужно сделать ещё один проход: не добавлять новые тексты поверх старых, а нещадно зачистить активную документацию от старых хвостов.

---

Блокеры перед merge

1. В активной папке docs/theory/ остался исторический документ про скобки

Файл:

docs/theory/Анализ природы скобок в МТС.md

получил историческое предупреждение в начале, но дальше всё ещё содержит старую рамку:

• {...} как пакет выражений;
• {} как возможную пустую конструкцию;
• квадратные скобки через старую А15;
• обсуждение [⟼] как потенциального центрального механизма;
• старую постановку проблемы скобок через объектный язык / формальную нотацию / метаязык.

Да, вверху есть предупреждение, но файл всё равно лежит в docs/theory/, то есть рядом с актуальными основаниями. Это опасно: читатель всё равно воспримет его как часть текущей теории.

Что сделать:

• либо перенести файл в archive/;
• либо переименовать, например:

docs/research/Исторический анализ природы скобок в МТС.md

• либо радикально переписать его в новой рамке, оставив старые версии только как цитируемые исторические гипотезы.

Я бы выбрал перенос в archive/ или docs/research/, потому что сейчас активное ядро ещё не стабилизировано, а этот документ тянет назад старую семантику.

---

2. Не хватает явного правила связывания повторных {} внутри одной формулы

Ключевая формула:

∞ : {} = {} ⟼ {}

работает только если три вхождения {} внутри одного шаблона указывают на одну и ту же связь-кандидат, а не на три независимых поиска.

Сейчас это подразумевается, но не зафиксировано достаточно жёстко.

Нужно прямо добавить правило:

Внутри одного исполнения шаблона все одинаковые вхождения `{}` относятся к одной и той же связи-кандидату.

И пояснить на примере:

∞ : {} = {} ⟼ {}

читается не как:

найти A, B, C такие, что A = B ⟼ C

а как:

найти X такой, что X = X ⟼ X

Только после этого корректен переход:

∞ : {} = {} ⟼ {}

к:

∞ : ∞ ⟼ ∞

Где поправить:

• docs/specs/Шаблонный поиск МТС.md
• docs/specs/Формальная нотация МТС.md
• docs/theory/Новая система аксиом МТС.md
• docs/theory/Метатеория связей.md

---

3. Не формализовано различие между {} как связь-кандидат и {s} как смысловая ссылка

Сейчас в новой грамматике есть:

candidate ::= "{}"
reference ::= "{" sign "}"

Это хорошее направление, но надо явно сказать, что это две разные конструкции, хотя они используют один и тот же внешний синтаксис фигурных скобок.

Нужно зафиксировать:

{}  — пустой фильтр поиска / связь-кандидат шаблона.
{s} — смысловая ссылка на знак s.

И отдельно:

{} не является частным случаем {s}.
{s} не является поиском без фильтра.

Иначе {} может быть прочитано как “смысловая ссылка на пустой знак”, что снова потянет нас к пустому множеству или пустому символу.

---

4. Не хватает правила исполнения шаблона

Сейчас документы пишут:

После исполнения шаблона:
∞ : ∞ ⟼ ∞

Но само “исполнение шаблона” пока не определено. Нужно хотя бы минимальное рабочее правило:

Исполнение шаблона — это нахождение связи-кандидата, удовлетворяющей ограничениям формы, и связывание найденного смысла с вводимым знаком.

Для акорня:

∞ : {} = {} ⟼ {}

исполнение означает:

найти X, такой что X = X ⟼ X;
обозначить найденный смысл знаком ∞;
после этого допустима запись ∞ : ∞ ⟼ ∞.

Пока это не прописано, переход от шаблона к развёрнутой формуле остаётся слишком интуитивным.

---

5. Новая система аксиом пока не описывает : и = как собственные смысловые механизмы

PR фиксирует новые формулы:

∞ : {} = {} ⟼ {}
♂{} : ♂{} = ♂{} ⟼ {}
{}♀ : {}♀ = {} ⟼ {}♀

Но при этом : и = уже используются как будто их смысл стабилен.

Нужно хотя бы временно указать статус:

• : — акт введения знака для смысла, найденного по форме;
• = — отношение структурной неразличимости после исполнения шаблона;
• оба механизма пока не сведены к минимальным аксиомам новой системы.

Иначе получается, что новая система переписывает акорень, но оставляет старые неопределённые механизмы определения и равенства.

Это не обязательно блокирует весь PR, но должно быть явно внесено в список первоочередных TODO новой аксиоматики.

---

Важные доработки

6. Нужно добавить документ “Регистр открытых вопросов issue #42”

Сейчас открытые вопросы размазаны по нескольким документам. Лучше создать один файл:

docs/research/Открытые вопросы новой аксиоматики МТС.md

или:

docs/theory/TODO issue 42.md

Там собрать:

1. пустой результат поиска;
2. независимые шаблонные поиски в одной формуле;
3. статус { и } как знаков или служебной нотации;
4. точный смысл :;
5. точный смысл =;
6. формализацию {↛};
7. смысл абитов 0 и 1 в новой рамке;
8. инверсию ¬;
9. связь шаблонного поиска с парсером;
10. асеть как результат десериализации ачисла.

Сейчас эти вопросы есть, но их трудно отслеживать.

---

7. Регрессионные тесты слишком поверхностные

Новый тест tests/test_issue42_docs.py полезен, но он проверяет только несколько строк:

• наличие новых документов;
• наличие ∞ : {} = {} ⟼ {};
• отсутствие фразы “МТС основана на 17 аксиомах”;
• отсутствие “Множества связей” в формальной нотации.

Этого мало. Он не поймает ситуацию, когда старое содержание вернулось под другими словами.

Нужно усилить тесты:

1. Проверять, что в актуальных документах не появляется [⟼] как базовая форма ядра.
2. Проверять, что docs/theory/Метатеория связей.md, docs/theory/Основания МТС.md, docs/specs/Формальная нотация МТС.md и docs/specs/Шаблонный поиск МТС.md содержат правило отличия:

{} ≠ пустое множество
{} ≠ пустой результат поиска
{} ≠ несвязь
{} ≠ 0

3. Проверять наличие правила “повторные {} внутри одного шаблона — один кандидат”.
4. Проверять, что активная теория не содержит старых заголовков вроде:

Сводная таблица аксиом А0-А16
Аксиома единицы смысла: 1 : [⟼]
Начало связи: [⟼]♀
Конец связи: ♂[⟼]

5. Проверять, что исторические документы либо лежат в archive/, либо имеют явную строку Статус: исторический.

---

8. README стал хорошей точкой входа, но слишком сильно порезан практический слой

README теперь правильно предупреждает, что репозиторий в переработке. Но он стал менее полезен для разработчика, который хочет понять:

• как запускать конвертеры;
• какие файлы сейчас считаются рабочими;
• какие файлы исторические;
• что можно менять, а что нельзя.

Нужно добавить небольшой раздел “Что сейчас стабильно”:

Стабильно:
- практическая четверичная сериализация `[`, `]`, `1`, `0`;
- существующие конвертеры UTF-8 ↔ ачисла;
- разделение слоёв нотации.

Нестабильно:
- новая грамматика формальной нотации;
- исполнение `{}`;
- новая система аксиом;
- парсер формул новой нотации.

Это поможет не сломать код, пока теория перестраивается.

---

9. Нужно чётко разделить “историческое”, “рабочее” и “актуальное”

Сейчас встречаются формулировки:

• “актуальная рабочая версия”;
• “рабочее ядро”;
• “исторический этап”;
• “не финальная система”.

Это правильно, но нужно ввести единый статусный словарь:

Актуальное — используется как текущая рамка.
Рабочее — гипотеза, которую можно менять.
Историческое — не использовать как спецификацию.
Архивное — сохранено только для истории.

И добавить эти статусы в начало каждого ключевого документа.

---

Что уже хорошо и стоит сохранить

1. Формула акорня через шаблон

∞ : {} = {} ⟼ {}

Это самое важное достижение PR. Оно решает проблему опасного чтения ∞ : ∞ ⟼ ∞ как пустой тавтологии.

2. Разведение [] и {}

[] — слой ачисел и сериализации.
{} — слой формальной нотации и шаблонного поиска.

Это нужно сохранить жёстко.

3. Смысловые ссылки {s}

{[} : ∞♀
{]} : ♂∞
{⟼} : {[} ⟼ {]}

Это красивое решение. Оно позволяет объявить [ и ] как абиты, не превращая квадратные скобки в универсальное экранирование.

4. Отказ от переменных x, a, b как внутренних символов МТС

Новая система правильно фиксирует, что старые переменные должны быть либо метаязыковыми, либо заменяться шаблонным поиском. Это одно из главных очищений.

5. Решение не переписывать парсеры прямо сейчас

Это правильно. Парсеры и конвертеры пока относятся к практическому стабильному слою прежней сериализации. Их нужно переписывать только после стабилизации новой грамматики.

---

Предлагаемый план следующего коммита в PR #48

Шаг 1. Перенести или переписать Анализ природы скобок в МТС.md

Лучше перенести в archive/ или docs/research/ и убрать из активной теории.

Шаг 2. Добавить правило связывания {}

Во все ключевые документы добавить:

Внутри одного исполнения шаблона повторные вхождения `{}` указывают на одну и ту же связь-кандидат.

Шаг 3. Добавить минимальное правило исполнения шаблона

В Шаблонный поиск МТС.md описать:

шаблон → кандидат → ограничение формы → найденный смысл → вводимый знак

Шаг 4. Уточнить : и =

В Новая система аксиом МТС.md и Формальная нотация МТС.md добавить временный статус этих знаков.

Шаг 5. Усилить тесты

Добавить проверки на:

• отсутствие старой финальной А0–А16 рамки;
• отсутствие [⟼] как ядра в актуальных документах;
• наличие правила повторного {};
• явный статус исторических документов;
• отсутствие трактовки {} как множества в активных спецификациях.

Шаг 6. Добавить регистр открытых вопросов

Создать отдельный документ со списком нерешённых мест и ссылками на документы, где они упомянуты.

---

Рекомендация по merge

Я бы пока не мержил PR #48 как завершённый.

Лучший статус:

Request changes / needs one more conceptual cleanup pass

Причина: PR хорошо фиксирует новое понимание, но ещё не доводит репозиторий до состояния, где активная документация не противоречит сама себе.

Минимум для merge:

1. убрать активный исторический документ про скобки из docs/theory/;
2. добавить правило повторного {};
3. добавить правило исполнения шаблона;
4. усилить тесты;
5. добавить явный статус : и = как ещё не полностью переработанных механизмов.

После этого PR можно будет считать хорошей первой стабилизацией issue #42.

---

Короткий комментарий для GitHub

Если нужен короткий вариант прямо в PR:

PR в целом правильно схватил новую рамку issue #42: `∞ : {} = {} ⟼ {}`, разделение `{}`/`[]`, смысловые ссылки `{s}`, отказ от старой финальности А0–А16. Но я бы пока не мержил.

Главные недоделки:

1. В `docs/theory/` остался исторический документ `Анализ природы скобок в МТС.md`, который внутри всё ещё использует старую рамку `{...}` как пакета/множества и `[⟼]` как значимой конструкции. Его надо перенести в `archive/`/`docs/research/` или переписать.
2. Нужно явно зафиксировать правило: повторные `{}` внутри одного исполнения шаблона указывают на одну и ту же связь-кандидат. Иначе `∞ : {} = {} ⟼ {}` неоднозначно.
3. Нужно описать минимальное правило исполнения шаблона: кандидат → ограничение формы → найденный смысл → вводимый знак.
4. `:` и `=` используются в новом ядре, но их собственный статус после issue #42 ещё не уточнён.
5. Регрессионные тесты пока слишком поверхностные: они проверяют строки, но не ловят смысловые возвраты старой рамки.

Рекомендация: request changes, сделать ещё один cleanup-pass, после этого PR можно будет мержить как первую стабилизацию новой рамки МТС.

[konard]

🤖 AI Work Session Started

Starting automated work session at 2026-05-17T22:05:29.145Z

The PR has been converted to draft mode while work is in progress.

This comment marks the beginning of an AI work session. Please wait for the session to finish, and provide your feedback.

[konard]

AI work session completed.

Implemented the requested cleanup pass from the latest review:

• moved the historical bracket analysis out of active theory into archive;
• added the repeated-{} binding rule and minimal template-execution rule;
• clarified {} vs {s}, plus working status for : and =;
• added the open-questions register;
• strengthened tests/test_issue42_docs.py around these review blockers.

Verification:

• python -m pytest tests -v --tb=short: 53 passed
• ruff check parsers/ converters/ core/ tests/ --ignore E501,F401: passed
• git diff --check and git diff --cached --check: passed
• latest CI on 9b584ab: passed

PR is ready for review: #48

[konard]

🤖 Solution Draft Log

This log file contains the complete execution trace of the AI solution draft process.

💰 Cost estimation:

• Model: GPT-5.5
• Provider: OpenAI
• Public pricing estimate: $8.776063

📊 Context and tokens usage:

• 248.1K / 1.1M (24%) input tokens, 25.2K / 128K (20%) output tokens

Total: (248.1K + 5.2M cached) input tokens, 25.2K output tokens, $8.776063 cost

🤖 Models used:

• Tool: OpenAI Codex
• Requested: gpt-5.5
• Model: GPT-5.5 (gpt-5.5)

📎 Log file uploaded as Repository (39605KB)

• View complete solution draft log

---

Now working session is ended, feel free to review and add any feedback on the solution draft.

[konard]

✅ Ready to merge

This pull request is now ready to be merged:

• All CI checks have passed
• No merge conflicts
• No pending changes

---

Monitored by hive-mind with --auto-restart-until-mergeable flag

[netkeep80]

Жёсткое ревью PR #48: меняем масштаб работы по issue #42

Краткий вывод

Текущий PR #48 полезен как checkpoint понимания, но этого уже недостаточно. Масштаб работы нужно менять: теперь требуется не косметическая фиксация новой рамки и не набор документов поверх старых, а новая рабочая версия МТС, в которой система аксиом, формальная нотация, тесты и структура репозитория взаимно согласованы.

PR нельзя считать завершённым закрытием issue #42, пока не выполнена целостная переработка.

Главная установка:

Нужна новая рабочая версия МТС, а не очередной слой исторических комментариев поверх старой системы.

---

1. Главный принцип дальнейшей работы

Работу нужно вести не от старых аксиом А0–А16 и не от уже накопленных пояснительных текстов, а от требований к написанию аксиом.

Базовый документ:

docs/theory/Шаблон аксиом МТС.md

должен стать первым объектом переработки, потому что именно он задаёт стандарт качества для всей новой системы.

Сейчас в PR шаблон уже обновлён в сторону issue #42, но он всё ещё скорее описательный. Его нужно сделать нормативным документом, по которому можно проверять каждую аксиому.

---

2. Сначала переработать шаблон аксиом

Перед переписыванием системы аксиом нужно переработать Шаблон аксиом МТС.md так, чтобы он явно требовал следующее.

2.1. Каждая аксиома вводит ровно один смысловой механизм

Аксиома не должна одновременно:

• вводить знак;
• объяснять слой нотации;
• фиксировать сериализацию;
• давать историческую интерпретацию;
• добавлять эвристическое пояснение;
• объявлять несколько разных механизмов.

Если в формуле смешаны несколько механизмов, она должна быть разбита на несколько аксиом или часть должна быть вынесена в слой нотации/сериализации/метаязыка.

2.2. Каждый вводимый символ должен иметь явный статус

Для каждого символа нужно указать:

символ
слой
арность / валентность
является ли он знаком смысла, конструктором, шаблонной конструкцией, абитом или метаязыковым знаком
формулу аксиомы
разрешённые чтения
запрещённые чтения

Если символ используется в формальной нотации, но для него нет аксиомы или явного статуса служебной нотации, это ошибка.

2.3. Нужно запретить неявные символы

Нельзя использовать x, a, b, r, v так, будто это внутренние символы МТС.

Допустимы только два варианта:

1. это явно метаязыковые имена в пояснении;
2. они заменены механизмом шаблонного поиска, например {} или будущей формой независимых кандидатов.

2.4. Нужно разделить формулу, чтение и исполнение

Для каждой аксиомы должны быть отдельные секции:

Формула
Шаблонное чтение
Правило связывания повторных шаблонов
После исполнения шаблона
Ограничения
Следствия
Открытые вопросы

Особенно важно: если используется {}, нужно явно писать, как связываются повторные {} и что именно считается кандидатом.

2.5. Нужно ввести критерий готовности аксиомы

Аксиома считается принятой только если:

• она соответствует шаблону;
• все символы в ней уже определены или явно объявлены служебными;
• она не противоречит другим аксиомам;
• она имеет пример исполнения шаблона;
• она имеет список запрещённых старых чтений;
• по ней есть хотя бы минимальный тест или проверяемое следствие.

---

3. Система аксиом должна быть взаимосогласованной

Новая система аксиом не должна быть набором отдельных красивых формул.

Нужно построить замкнутую и взаимосогласованную систему, где:

каждый символ введён;
каждый вводимый знак имеет аксиому;
каждая аксиома использует только уже разрешённые механизмы или явно заявленную рекурсию;
нет противоречий между текстом, формулой, тестами и парсером;
нет старых формул, которые молча тянут прежнюю семантику.

Минимально нужно построить таблицу зависимостей:

символ → слой → аксиома → зависит от → следствия → тесты

Без такой таблицы сложно понять, является ли система действительно согласованной.

---

4. Каждый символ формальной нотации должен быть учтён

Нужно пройти по всем символам, которые используются в новой формальной нотации, и для каждого принять одно из двух решений:

1. это символ МТС и он должен иметь аксиому;
2. это служебная конструкция записи и она должна быть явно помечена как не являющаяся символом объектной МТС.

Минимальный список для ревизии:

∞
{}
{s}
{
}
:
=
⟼
♂
♀
¬
↛
[
]
1
0
(
)
,

Для каждого элемента нужно указать:

актуальный статус
слой
допустимое использование
запрещённое использование
нужна ли аксиома
если аксиома не нужна — почему

Особенно важно не оставлять в подвешенном состоянии :, =, {, }, ¬, ↛, 1, 0.

Если мы пока не знаем окончательную аксиому для символа, он должен быть вынесен в регистр открытых вопросов и не должен использоваться как стабилизированная часть ядра.

---

5. Аксиомы нужно переписывать от новой рамки, а не латать старую А0–А16

Старая система А0–А16 больше не должна быть основой переписывания.

Новая рамка:

Ачисла описывают структуру связей.
Формальная нотация МТС описывает смыслы и шаблоны смыслов.
Система аксиом МТС описывает виды форм смыслов.

Рабочее ядро должно быть построено вокруг новых форм:

∞ : {} = {} ⟼ {}
♂{} : ♂{} = ♂{} ⟼ {}
{}♀ : {}♀ = {} ⟼ {}♀
{[} : ∞♀
{]} : ♂∞
{⟼} : {[} ⟼ {]}

Но эти формулы нельзя просто вставить в документацию и считать работу завершённой. Нужно проверить:

• что они согласованы между собой;
• что : и = имеют рабочее определение;
• что {} действительно исполняется как один кандидат внутри одного шаблона;
• что ♂{} и {}♀ не противоречат старым тестам или, если противоречат, старые тесты переписываются;
• что 1, 0, {↛} и ¬ не остаются без места в системе.

---

6. Нужна беспощадная чистка репозитория

Нельзя дальше плодить исторические слои в активной документации.

Требование:

Активная документация должна содержать только текущую рабочую версию МТС.

Исторические тексты должны быть либо:

1. удалены;
2. перенесены в архив;
3. вынесены в отдельную ветку/релиз/внешний исторический пакет;
4. оставлены только при наличии явной причины.

Но текущая ситуация, где архив сохраняет массу старых смыслов и продолжает тратить внимание и контекст, плоха.

6.1. Решить судьбу archive/

Нужно принять решение:

Вариант A — удалить архив из активной ветки

Это самый чистый вариант для дальнейшей работы. История уже есть в Git. Старые черновики можно восстановить из commit history.

Плюсы:

• меньше мусора в репозитории;
• меньше риска случайно читать старое как актуальное;
• меньше контекстных токенов при работе AI/LLM;
• легче поддерживать документацию.

Минусы:

• теряется удобный прямой доступ к старым черновикам.

Вариант B — оставить архив, но резко ограничить

Если архив оставить, то:

• он не должен входить в основную карту документации;
• в README он должен быть обозначен как исторический мусор/черновики, не спецификация;
• тесты должны проверять, что активные документы не ссылаются на архив как на источник текущей теории;
• старые тексты, которые дублируют и путают, должны быть удалены даже из архива.

Моя рекомендация: подумать об удалении архива из active branch. Git уже является архивом.

---

7. Не добавлять новые документы без удаления старых

Запретить паттерн:

добавили новый документ → оставили старый документ рядом → добавили предупреждение → считаем готово

Это не готово.

Если новый документ заменяет старый, старый должен быть:

• удалён;
• перемещён в архив;
• или переименован в исторический с невозможностью спутать его с актуальным.

В активных папках docs/theory/ и docs/specs/ не должно быть документов, которые противоречат новой рамке.

---

8. Переписать структуру документации под новую рабочую МТС

Минимальная целевая структура активных документов должна быть небольшой.

Предлагаемый минимум:

README.md

docs/theory/Метатеория связей.md
docs/theory/Шаблон аксиом МТС.md
docs/theory/Система аксиом МТС.md

docs/specs/Формальная нотация МТС.md
docs/specs/Ачисла и сериализация.md
docs/specs/Слои нотации МТС.md

docs/research/Открытые вопросы новой аксиоматики МТС.md

Всё остальное должно быть удалено, перенесено или явно оправдано.

Если документ не отвечает на вопрос “зачем он нужен для новой рабочей версии МТС?”, его не должно быть в активной документации.

---

9. tests/mtc_formulas.mtc обязательно привести в соответствие

Это блокер.

Файл:

tests/mtc_formulas.mtc

сейчас содержит формулы старой системы. Например, там присутствуют старые ориентации и старые выражения для ♂, ♀, ∞, степеней, инверсии и левоассоциативности.

После изменения системы аксиом этот тест нельзя оставлять как есть.

Нужно сделать одно из двух:

Вариант A — переписать тест под новую МТС

Тогда tests/mtc_formulas.mtc должен стать тестом новой рабочей системы.

Он должен проверять хотя бы:

∞ : {} = {} ⟼ {}
после исполнения шаблона: ∞ : ∞ ⟼ ∞
♂{} : ♂{} = ♂{} ⟼ {}
{}♀ : {}♀ = {} ⟼ {}♀
{[} : ∞♀
{]} : ♂∞
{⟼} : {[} ⟼ {]}

А также отрицательные случаи:

{} не пустое множество
{} не пустой результат поиска
{} не несвязь
{} не 0
[] не формульная группировка
[⟼] не базовое ядро

Вариант B — оставить старый тест как legacy

Тогда его нужно переименовать, например:

tests/legacy_mtc_formulas.mtc

и добавить новый:

tests/issue42_mtc_formulas.mtc

Но при этом CI должен явно запускать именно актуальный тест новой системы. Legacy-тест не должен маскировать несовместимость старой и новой аксиоматики.

Обязательное требование

После переработки нужно выполнить:

python -m pytest tests -v --tb=short

и отдельно убедиться, что формульный тест проходит через соответствующий runner/parser.

Если текущий parser не умеет новую нотацию {}, это нужно не замалчивать. Нужно либо:

• обновить parser;
• добавить временный parser для новой нотации;
• либо явно пометить старый parser как legacy и добавить тест, который проверяет хотя бы документационную спецификацию новой нотации.

Но нельзя оставить tests/mtc_formulas.mtc в старом виде и говорить, что МТС переработана.

---

10. Тесты должны проверять не только строки, но и согласованность рамки

Текущие doc-tests полезны, но недостаточны.

Нужно добавить проверки:

1. В активных документах нет старой таблицы А0–А16 как финальной системы.
2. В активных документах нет [⟼] как базовой формы ядра.
3. В активных документах нет трактовки {} как множества, пакета, пустого контейнера или пустого результата.
4. Каждый активный символ формальной нотации либо имеет аксиому, либо указан как служебная запись.
5. Все документы со статусом актуальное и рабочее согласованы по формуле акорня.
6. Все ссылки из README ведут на существующие актуальные документы.
7. Архив, если остаётся, не попадает в список актуальной документации.
8. tests/mtc_formulas.mtc соответствует новой системе или явно переименован как legacy.

---

11. Definition of Done для PR #48 или следующего PR

Работа считается выполненной только если:

• Шаблон аксиом МТС.md переработан первым и задаёт строгий нормативный формат.
• Все аксиомы новой системы переписаны по этому шаблону.
• Для каждого символа формальной нотации указан статус и, если нужно, аксиома.
• Система аксиом взаимосогласована и имеет таблицу зависимостей.
• Старые тексты удалены или вынесены из активной документации.
• Решена судьба archive/: удалить, резко ограничить или вынести из активного контекста.
• README показывает только новую рабочую версию, а не историю всех попыток.
• docs/theory/Метатеория связей.md является короткой актуальной точкой входа.
• docs/theory/Система аксиом МТС.md содержит полную рабочую систему аксиом.
• docs/specs/Формальная нотация МТС.md соответствует новой системе аксиом.
• docs/specs/Ачисла и сериализация.md не смешивает ачисла с формальной нотацией.
• tests/mtc_formulas.mtc приведён в соответствие с новой системой или переименован как legacy.
• CI запускает актуальные тесты новой системы.
• Все проверки проходят.

---

12. Требование к исполнителю

Не нужно делать частичную правку и снова оставлять репозиторий в переходном состоянии.

Нужно выполнить работу целиком:

переработать шаблон аксиом;
на его основе переписать систему аксиом;
удалить или изолировать старые тексты;
привести формальную нотацию в соответствие;
привести тесты в соответствие;
проверить CI;
только после этого считать PR готовым.

Особенно важно: не надо сохранять историческое барахло в активной документации “на всякий случай”. История уже есть в Git. В рабочей ветке должна остаться новая МТС.

---

13. Итоговая формулировка

Текущий PR #48 нужно воспринимать не как финальное решение, а как сигнал, что мы наконец поняли масштаб задачи.

Теперь задача такая:

Собрать новую рабочую версию МТС как целостную систему:
- строгий шаблон аксиом;
- взаимосогласованная система аксиом;
- явный статус каждого символа;
- чистая активная документация без старых хвостов;
- тесты, соответствующие новой системе.

Пока это не сделано, issue #42 не должен считаться закрытым.

[konard]

🤖 AI Work Session Started

Starting automated work session at 2026-05-17T22:25:26.400Z

The PR has been converted to draft mode while work is in progress.

This comment marks the beginning of an AI work session. Please wait for the session to finish, and provide your feedback.

[konard]

Work session complete.

Implemented the requested cleanup pass for issue #42: normative axiom template, active working axiom system with dependency table, full formal-notation symbol registry, archived legacy theory/research notes, renamed legacy formula fixture, and added the current issue #42 fixture plus stronger regression tests.

Verification:

• python -m pytest tests -v --tb=short
• ruff check parsers/ converters/ core/ tests/ --ignore E501,F401
• git diff --check
• git diff --cached --check
• PR CI for a94beb8 is passing.

PR is marked ready for review.

[konard]

🤖 Solution Draft Log

This log file contains the complete execution trace of the AI solution draft process.

💰 Cost estimation:

• Model: GPT-5.5
• Provider: OpenAI
• Public pricing estimate: $9.364518

📊 Context and tokens usage:

• 214.5K / 1.1M (20%) input tokens, 41.8K / 128K (33%) output tokens

Total: (214.5K + 5.3M cached) input tokens, 41.8K output tokens, $9.364518 cost

🤖 Models used:

• Tool: OpenAI Codex
• Requested: gpt-5.5
• Model: GPT-5.5 (gpt-5.5)

📎 Log file uploaded as Repository (56594KB)

• View complete solution draft log

---

Now working session is ended, feel free to review and add any feedback on the solution draft.

[konard]

✅ Ready to merge

This pull request is now ready to be merged:

• All CI checks have passed
• No merge conflicts
• No pending changes

---

Monitored by hive-mind with --auto-restart-until-mergeable flag

[netkeep80]

Жёсткий review PR #48: нужен рабочий вариант МТС, а не слой поверх исторического мусора

Статус ревью: REQUEST CHANGES / не мержить в текущем виде.

PR стал ближе к нужному направлению, но сейчас он всё ещё не решает главную задачу: получить новую рабочую версию МТС. Вместо этого в PR снова появляется промежуточный слой описаний, legacy-файлы, специальный тестовый DSL и ссылки на исторические материалы. Это надо остановить.

Цель работы должна быть другой:

Не сохранить историю всех попыток.
Не обернуть старую МТС новыми предупреждениями.
Не добавить fixture с AXIOM/EXEC/RULE.

А собрать текущую рабочую МТС:
- по строгому шаблону аксиом;
- с согласованной системой символов;
- с актуальным тестом формул;
- без старых формул, старых интерпретаций и исторического шума.

---

1. Блокер: tests/issue42_mtc_formulas.mtc написан в неправильном формате

Сейчас файл содержит строки вида:

AXIOM root: ∞ : {} = {} ⟼ {}
EXEC root: ∞ : ∞ ⟼ ∞
RULE repeated-empty-braces: one-candidate-per-template-execution
NEGATIVE empty-braces: {} не пустое множество
STATUS parser: parsers/mtc_formula_prover.py is legacy and does not execute this fixture

Это не формальная нотация МТС. Это внешний служебный DSL, который снова добавляет метаязык поверх МТС.

Так делать нельзя.

Если файл называется .mtc, он должен содержать формулы МТС, а не управляющие ярлыки AXIOM, EXEC, RULE, NEGATIVE, STATUS.

Нужно заменить формат на чистые формулы.

Например, вместо:

AXIOM root: ∞ : {} = {} ⟼ {}
EXEC root: ∞ : ∞ ⟼ ∞

должно быть:

∞ : {} = {} ⟼ {}
∞ = ∞ ⟼ ∞

Аналогично дальше:

♂{} : ♂{} = ♂{} ⟼ {}
♂∞ = ♂∞ ⟼ ∞

{}♀ : {}♀ = {} ⟼ {}♀
∞♀ = ∞ ⟼ ∞♀

{[} : ∞♀
{]} : ♂∞
{⟼} : {[} ⟼ {]}

Никаких AXIOM, EXEC, RULE, NEGATIVE, STATUS в .mtc быть не должно.

Если нужны пояснения, они должны быть:

1. в Markdown-документации;
2. или в комментариях, если parser/test-runner поддерживает комментарии;
3. но не как исполняемые или проверяемые строки .mtc.

---

2. Блокер: тесты сейчас закрепляют неправильный DSL

tests/test_issue42_docs.py сейчас проверяет наличие строк вида:

"AXIOM root: ∞ : {} = {} ⟼ {}"
"EXEC root: ∞ : ∞ ⟼ ∞"
"RULE repeated-empty-braces: one-candidate-per-template-execution"
"NEGATIVE empty-braces: {} не пустое множество"
"STATUS parser: parsers/mtc_formula_prover.py is legacy and does not execute this fixture"

Это значит, что регрессионный тест защищает неправильный формат.

Нужно переписать тест так, чтобы он требовал чистые формулы МТС и запрещал служебные префиксы.

Минимальное требование к тесту:

FORBIDDEN_FIXTURE_PREFIXES = (
    "AXIOM ",
    "EXEC ",
    "RULE ",
    "NEGATIVE ",
    "STATUS ",
)

И проверка:

for line in formula_lines:
    assert not line.startswith(FORBIDDEN_FIXTURE_PREFIXES)

Проверять надо такие строки:

∞ : {} = {} ⟼ {}
∞ = ∞ ⟼ ∞
♂{} : ♂{} = ♂{} ⟼ {}
♂∞ = ♂∞ ⟼ ∞
{}♀ : {}♀ = {} ⟼ {}♀
∞♀ = ∞ ⟼ ∞♀
{[} : ∞♀
{]} : ♂∞
{⟼} : {[} ⟼ {]}

Если какие-то из этих формул пока не поддерживаются parser'ом, значит надо либо обновить parser/test-runner, либо честно не называть эту fixture рабочей .mtc-формой. Но подменять формулы внешним DSL нельзя.

---

3. Старые тесты не надо сохранять как legacy_mtc_formulas.mtc

Сейчас старый tests/mtc_formulas.mtc переименован в:

tests/legacy_mtc_formulas.mtc

Это не нужно.

Старые формулы не должны оставаться в активной test surface. Они будут продолжать тянуть старую МТС в репозиторий и расходовать внимание на поддержку того, от чего мы как раз уходим.

Требование:

Удалить tests/legacy_mtc_formulas.mtc.
Не держать старый набор формул в tests/.
Не проверять его существование в tests/test_issue42_docs.py.
Не ссылаться на него из README.

Канонический тестовый файл должен быть один:

tests/mtc_formulas.mtc

И он должен содержать новую рабочую систему МТС, а не старую и не issue-specific DSL.

Если хочется временно оставить имя tests/issue42_mtc_formulas.mtc, тогда оно должно быть чистым .mtc и потом быть переименовано в tests/mtc_formulas.mtc перед merge. Но лучше сразу привести к целевому имени.

---

4. Нельзя оставлять фразу “legacy parser does not execute this fixture” как норму

Сейчас fixture содержит:

STATUS parser: parsers/mtc_formula_prover.py is legacy and does not execute this fixture

Это плохой знак.

Если мы делаем новую рабочую МТС, тестовая fixture должна быть связана с реальной проверкой. Не обязательно сразу строить полноценный prover, но нельзя делать вид, что .mtc есть, а исполнять его никто не должен.

Нужно выбрать один из двух честных вариантов:

Вариант А — обновить parser/test-runner

Сделать так, чтобы tests/mtc_formulas.mtc реально проходил проверку новой формальной нотации.

Вариант Б — сделать отдельный минимальный валидатор новой fixture

Например, tests/test_issue42_formulas.py, который:

• читает tests/mtc_formulas.mtc;
• игнорирует комментарии;
• проверяет отсутствие служебных DSL-префиксов;
• проверяет наличие обязательных формул;
• проверяет базовую грамматику новой нотации хотя бы на уровне допустимых символов и баланса скобок.

Но текущий вариант “fixture есть, parser её не исполняет” неприемлем как итог работы.

---

5. Нужно начать с переработки шаблона аксиом, а не с размножения документов

Основная работа должна идти сверху вниз:

Шаблон аксиом
→ система аксиом
→ формальная нотация
→ тесты формул
→ README и остальные документы

Сейчас PR уже обновил Шаблон аксиом МТС.md, но надо сделать его не просто ещё одним рабочим документом, а нормативным критерием готовности.

Требование к шаблону:

1. Каждая аксиома вводит ровно один символ или один смысловой механизм.
2. Каждый символ, используемый в формальной нотации, должен иметь:
   • собственную аксиому;
   • или явный временный статус “служебный механизм, не часть ядра”;
   • или быть удалён из формальной нотации до аксиоматизации.
3. Аксиома должна содержать:
   • вводимый символ;
   • слой;
   • арность / валентность;
   • формулу;
   • шаблонное чтение;
   • исполнение шаблона;
   • следствия;
   • запрещённые чтения;
   • тестовые строки в tests/mtc_formulas.mtc.
4. Аксиома без тестового отражения считается незавершённой.

Система аксиом должна быть построена строго по этому шаблону.

---

6. Все символы формальной нотации должны быть сведены к аксиомам или удалены из ядра

Сейчас в документации перечислены символы:

∞, {}, {s}, {, }, :, =, ⟼, ♂, ♀, ¬, ↛, [, ], 1, 0, (, ), ,

Нельзя просто перечислить их в реестре и считать задачу решённой.

Для каждого символа нужно принять одно из решений:

1. Символ входит в формальную нотацию и имеет аксиому.
2. Символ является служебной записью текущего метаязыка и не входит в МТС-ядро.
3. Символ относится только к ачислам/сериализации.
4. Символ не готов и должен быть удалён из активного ядра до отдельной проработки.

Особенно критичны:

{, }, {}, {s}, :, =, ⟼, ♂, ♀

Потому что они уже используются в аксиомах.

Если символ используется в формуле аксиомы, он не может оставаться “просто служебным” без строгого статуса.

---

7. Исторические тексты надо удалять, а не складировать

В PR появилось много переносов в archive/. Это лучше, чем держать их в docs/theory, но всё равно не решает проблему масштаба.

Текущая цель — новая рабочая МТС, а не архив всех старых попыток.

Требование:

Не тащить историческое барахло в активный репозиторий.

Предпочтительный вариант:

Удалить устаревшие исторические markdown-файлы из PR.

Допустимый временный вариант:

Оставить archive/ только если он минимален, не связан из README как часть чтения, не проверяется тестами и не участвует в активной документационной карте.

Но лучше вообще удалить архивные хвосты, если они не нужны для текущей рабочей версии.

Никакие активные документы не должны ссылаться на старые тексты как на обязательный контекст для понимания МТС.

---

8. README должен быть точкой входа в текущую МТС, а не отчётом о раскопках

README сейчас всё ещё много говорит о том, что старое историческое, legacy, архивное и т.п.

Это можно оставить коротко, но нельзя превращать README в карту истории.

README должен отвечать на вопросы:

Что сейчас является МТС?
Где система аксиом?
Где формальная нотация?
Где тест формул?
Как проверить, что текущая версия согласована?

И не должен постоянно отправлять читателя в архив или объяснять старую систему.

---

9. Требование к финальному состоянию тестов

Финальное состояние должно быть таким:

tests/mtc_formulas.mtc          — актуальные формулы новой МТС
tests/test_issue42_docs.py      — регрессионные проверки документации и fixture

Не должно быть:

tests/legacy_mtc_formulas.mtc
AXIOM/EXEC/RULE/NEGATIVE/STATUS в .mtc
обязательных проверок старых формул
утверждений, что fixture не исполняется parser'ом

tests/mtc_formulas.mtc должен пройти проверку после изменений.

Если старый parser не может это сделать, нужно обновить проверку. Но оставлять несоответствие между новой системой аксиом и тестовой fixture нельзя.

---

10. Definition of Done для PR #48

PR можно считать готовым только когда выполнено всё ниже.

Документация

• docs/theory/Шаблон аксиом МТС.md является нормативным шаблоном и задаёт критерий готовности аксиомы.
• docs/theory/Система аксиом МТС.md построена строго по этому шаблону.
• Каждый используемый символ имеет аксиому или явно исключён из ядра.
• Активные документы не тянут старые истории, старую А0-А16 и старые скобочные интерпретации.
• README описывает текущую рабочую МТС, а не историю переработки.
• Архивные тексты либо удалены, либо полностью исключены из активного чтения.

Тесты

• tests/mtc_formulas.mtc содержит чистые формулы новой МТС.
• В .mtc нет AXIOM, EXEC, RULE, NEGATIVE, STATUS.
• Старый legacy_mtc_formulas.mtc удалён.
• tests/test_issue42_docs.py проверяет новый чистый формат, а не DSL.
• python -m pytest tests -v --tb=short проходит.
• Проверка действительно подтверждает соответствие новой системе аксиом, а не только наличие строк в документах.

Смысловая согласованность

• ∞ : {} = {} ⟼ {} трактуется как аксиома поиска полного самозамыкания.
• ∞ = ∞ ⟼ ∞ является результатом исполнения, а не строкой EXEC root.
• {} не трактуется как пустое множество, пустой результат, несвязь или 0.
• {s} отделено от {}.
• [] остаются в слое ачисел и не используются как экранирование формул.

---

11. Прямое требование к следующему коммиту

Следующий коммит должен быть не “ещё одним cleanup-pass”, а полноценным исправлением направления:

1. Удалить/заменить tests/issue42_mtc_formulas.mtc как DSL.
2. Вернуть канонический tests/mtc_formulas.mtc с чистыми формулами новой МТС.
3. Удалить tests/legacy_mtc_formulas.mtc.
4. Переписать tests/test_issue42_docs.py под чистые формулы.
5. Вычистить README и активные docs от исторических ссылок и legacy-риторики.
6. Привести систему аксиом к нормативному шаблону.
7. Проверить весь tests/ после изменений.

Нужна новая рабочая версия МТС, а не аккуратно оформленная куча исторического барахла.

[konard]

🤖 AI Work Session Started

Starting automated work session at 2026-05-17T22:49:31.175Z

The PR has been converted to draft mode while work is in progress.

This comment marks the beginning of an AI work session. Please wait for the session to finish, and provide your feedback.

[konard]

Work session complete.\n\nImplemented the latest review requirements:\n- replaced the temporary tests/issue42_mtc_formulas.mtc DSL with canonical tests/mtc_formulas.mtc containing only pure MTS formulas and comments;\n- removed tests/legacy_mtc_formulas.mtc from the active test surface;\n- removed the newly archived historical files instead of keeping another archive layer;\n- rewrote README as the current MTS entry point;\n- updated active docs to reference tests/mtc_formulas.mtc;\n- strengthened tests/test_issue42_docs.py to forbid AXIOM/EXEC/RULE/NEGATIVE/STATUS, require the clean formulas, and check active-doc consistency.\n\nVerification on commit e4a6892:\n- python -m pytest tests -v --tb=short: 59 passed\n- ruff check parsers/ converters/ core/ tests/ --ignore E501,F401: passed\n- git diff --check: passed\n- GitHub CI run 26005210267: passed\n\nPR is marked ready for review: #48

[konard]

🤖 Solution Draft Log

This log file contains the complete execution trace of the AI solution draft process.

💰 Cost estimation:

• Model: GPT-5.5
• Provider: OpenAI
• Public pricing estimate: $8.969389

📊 Context and tokens usage:

• 180.1K / 1.1M (17%) input tokens, 29.6K / 128K (23%) output tokens

Total: (180.1K + 5.8M cached) input tokens, 29.6K output tokens, $8.969389 cost

🤖 Models used:

• Tool: OpenAI Codex
• Requested: gpt-5.5
• Model: GPT-5.5 (gpt-5.5)

📎 Log file uploaded as Repository (50799KB)

• View complete solution draft log

---

Now working session is ended, feel free to review and add any feedback on the solution draft.

[konard]

✅ Ready to merge

This pull request is now ready to be merged:

• All CI checks have passed
• No merge conflicts
• No pending changes

---

Monitored by hive-mind with --auto-restart-until-mergeable flag

[netkeep80]

Дополнительное ревью PR #48: нужна аксиома последовательности и прямоассоциативности

PR #48 стал лучше: временный DSL AXIOM / EXEC / RULE / NEGATIVE / STATUS удалён, канонический файл формул возвращён как tests/mtc_formulas.mtc, старые fixture-файлы не должны сохраняться.

Но текущая рабочая МТС всё ещё неполная. В ней введён смысл конструктора связи:

{[} : ∞♀
{]} : ♂∞
{⟼} : {[} ⟼ {]}

но не введён общий принцип, что последовательность форм сама читается как связь.

Это критическая дыра: без аксиомы последовательности МТС не объясняет, почему запись двух форм подряд является связью, а ачисла не получают строгой опоры как последовательности абитов.

---

1. Блокер: добавить аксиому последовательности

Нужно добавить в систему аксиом отдельный механизм:

{}{} : {} ⟼ {}

Чтение:

последовательность двух найденных форм есть связь первой формы со второй формой

Эта аксиома должна стать мостом:

последовательная запись
→ связь
→ структура ачисла
→ асеть / структура связей

Сейчас в tests/mtc_formulas.mtc есть только:

∞ : {} = {} ⟼ {}
∞ = ∞ ⟼ ∞

♂{} : ♂{} = ♂{} ⟼ {}
♂∞ = ♂∞ ⟼ ∞

{}♀ : {}♀ = {} ⟼ {}♀
∞♀ = ∞ ⟼ ∞♀

{[} : ∞♀
{]} : ♂∞
{⟼} : {[} ⟼ {]}

Этого недостаточно. Нужно добавить последовательностную форму.

---

2. Нужно уточнить правило {}: один кандидат vs позиционные кандидаты

Текущее правило:

Внутри одного исполнения шаблона все одинаковые вхождения `{}` относятся к одной и той же связи-кандидату.

правильно для акорня:

∞ : {} = {} ⟼ {}

потому что эта формула должна читаться как:

найти X такой, что X = X ⟼ X

Но это правило нельзя механически применять к последовательностям:

{}{}
{}{}{}

Иначе последовательность {}{} будет читаться как XX, а не как произвольная пара AB.

Нужно явно ввести различение:

1. Внутри условия одной формы повторные `{}` могут быть связаны с одним кандидатом.
   Пример: ∞ : {} = {} ⟼ {}  читается как  X = X ⟼ X.

2. В последовательностной записи `{}{}...` каждое вхождение `{}` задаёт отдельную позицию кандидата.
   Пример: {}{} читается как AB, а не как XX.

Иначе новая аксиома последовательности будет конфликтовать с правилом повторных {}.

Это надо исправить в:

• docs/specs/Шаблонный поиск МТС.md
• docs/specs/Формальная нотация МТС.md
• docs/theory/Система аксиом МТС.md
• docs/theory/Шаблон аксиом МТС.md
• tests/test_issue42_docs.py

---

3. Добавить аксиоматику прямоассоциативности последовательностей

После аксиомы последовательности нужна аксиома прямоассоциативности / левой группировки последовательной записи:

{}{}{} : ({} ⟼ {}) ⟼ {}
{}{}{} = {} ⟼ {} ⟼ {}
{}{}{} != {} ⟼ ({} ⟼ {})

Смысл:

последовательность из трёх форм группируется слева направо

То есть метаязыковое чтение:

ABC = (A ⟼ B) ⟼ C
ABC != A ⟼ (B ⟼ C)

Это важно не как старая техническая ассоциативность, а как фундаментальное правило чтения последовательностей в МТС.

---

4. Заодно формально ввести круглые скобки

Текущая спецификация говорит, что ( и ) — служебная группировка, и что аксиома не нужна. Это слишком слабо.

Если круглые скобки влияют на структуру связи, они должны получить явное правило формальной нотации или аксиому уровня записи.

Минимальное правило:

({}) = {}

Чтение:

круглые скобки не меняют смысл формы, но выделяют форму как целый операнд

Тогда:

({} ⟼ {}) ⟼ {}

и:

{} ⟼ ({} ⟼ {})

становятся различимыми структурами.

Нужно явно закрепить:

({} ⟼ {}) ⟼ {} != {} ⟼ ({} ⟼ {})

Иначе формула прямоассоциативности будет ссылаться на круглые скобки, смысл которых не зафиксирован.

---

5. Переопределить смысл {⟼} через последовательность абитов

Сейчас смысл конструктора связи задан напрямую:

{⟼} : {[} ⟼ {]}

После добавления аксиомы последовательности лучше выразить его через последовательность:

{[}{]} = {[} ⟼ {]}
{⟼} : {[}{]}
{⟼} = {[} ⟼ {]}

Это сильнее и красивее, потому что показывает:

смысл конструктора связи
= последовательность смысла абита начала и смысла абита конца
= связь начала смысла с концом смысла

Это также уточняет роль квадратных скобок без возврата к старому [⟼].

---

6. Обновить tests/mtc_formulas.mtc

Файл tests/mtc_formulas.mtc должен остаться чистым файлом формул МТС. Никаких AXIOM, EXEC, RULE, NEGATIVE, STATUS.

Но текущий файл надо расширить.

Минимально ожидаемый набор:

∞ : {} = {} ⟼ {}
∞ = ∞ ⟼ ∞

({}) = {}

{}{} : {} ⟼ {}
{}{} = {} ⟼ {}

{}{}{} : ({} ⟼ {}) ⟼ {}
{}{}{} = {} ⟼ {} ⟼ {}
{}{}{} != {} ⟼ ({} ⟼ {})

♂{} : ♂{} = ♂{} ⟼ {}
♂∞ = ♂∞ ⟼ ∞

{}♀ : {}♀ = {} ⟼ {}♀
∞♀ = ∞ ⟼ ∞♀

{[} : ∞♀
{]} : ♂∞

{[}{]} = {[} ⟼ {]}
{⟼} : {[}{]}
{⟼} = {[} ⟼ {]}

Важно: это не просьба вернуть старый tests/legacy_mtc_formulas.mtc. Старые тесты сохранять не нужно.

---

7. Обновить tests/test_issue42_docs.py

Сейчас тест проверяет точное равенство списка формул текущему минимальному набору. После добавления последовательности и ассоциативности этот тест должен быть обновлён.

Требования к тесту:

1. tests/mtc_formulas.mtc существует.
2. Старые fixture-файлы отсутствуют:
   • tests/issue42_mtc_formulas.mtc
   • tests/legacy_mtc_formulas.mtc
3. В tests/mtc_formulas.mtc нет служебного DSL:
   • AXIOM
   • EXEC
   • RULE
   • NEGATIVE
   • STATUS
4. В tests/mtc_formulas.mtc есть формулы:
   • {}{} : {} ⟼ {}
   • {}{}{} : ({} ⟼ {}) ⟼ {}
   • {}{}{} = {} ⟼ {} ⟼ {}
   • {}{}{} != {} ⟼ ({} ⟼ {})
   • ({}) = {}
   • {[}{]} = {[} ⟼ {]}
   • {⟼} : {[}{]}
5. Тесты должны проверять, что активные документы описывают позиционное чтение {} в последовательностях.

---

8. Убрать историческую риторику из активных текстов

В активных документах всё ещё слишком много объяснений через старую историю:

• “после issue Переосмысление системы аксиом #42”;
• “старая система”;
• “исторический этап”;
• “legacy”;
• “архив”;
• “не возвращаем старое”.

Для PR и комментариев это нормально. Для рабочей документации МТС — нет.

Нужна не документация миграции, а новая рабочая версия МТС.

Требование:

активные README/docs должны описывать текущую МТС напрямую,
а не через постоянное сравнение со старыми версиями.

Допустимо оставить короткое техническое предупреждение, что старые материалы не являются спецификацией. Но активные тексты не должны быть набиты ссылками на историю, архив, старую А0-А16 и legacy-слои.

Если архив мешает и тратит контекстные токены — его лучше удалить, а не поддерживать как параллельную вселенную старых смыслов.

---

9. Обновить систему аксиом

docs/theory/Система аксиом МТС.md должна получить новые карточки:

А?. Группировка формы
({}) = {}

А?. Последовательность двух форм
{}{} : {} ⟼ {}

А?. Прямоассоциативность последовательности
{}{}{} : ({} ⟼ {}) ⟼ {}

Для каждой карточки по нормативному шаблону нужно указать:

• вводимый механизм;
• слой;
• арность / валентность;
• формулу;
• шаблонное чтение;
• после исполнения шаблона;
• запрещённые чтения;
• связи с другими аксиомами;
• отражение в tests/mtc_formulas.mtc.

Нельзя просто добавить пару строк в README. Это должны быть полноценные аксиомы / правила текущей рабочей МТС.

---

10. Acceptance criteria перед merge

PR можно считать готовым только если:

• tests/mtc_formulas.mtc содержит чистые формулы МТС, включая последовательность, скобки и прямоассоциативность;
• tests/test_issue42_docs.py проверяет эти формулы;
• система аксиом содержит карточки для последовательности и прямоассоциативности;
• формальная нотация объясняет позиционные {} в последовательностях;
• {⟼} выражается через {[}{]} и разворачивается в {[} ⟼ {]};
• активные документы не являются историческим отчётом о миграции;
• старые тесты и legacy fixture-файлы не возвращаются;
• весь python -m pytest tests -v --tb=short проходит.

---

Итог

Текущий PR уже исправил проблему с временным DSL. Но теперь видна следующая фундаментальная недостача:

нет аксиомы, объясняющей последовательность как связь.

Нужно добавить:

{}{} : {} ⟼ {}

и сразу вместе с ней:

({}) = {}

{}{}{} : ({} ⟼ {}) ⟼ {}
{}{}{} = {} ⟼ {} ⟼ {}
{}{}{} != {} ⟼ ({} ⟼ {})

Без этого МТС всё ещё не объясняет, почему ачисловая / формальная последовательность вообще строит связь.

[netkeep80]

так же обязательно полностью перегенерируй readme.md что бы он был актуальным!

[konard]

🤖 AI Work Session Started

Starting automated work session at 2026-05-17T23:13:19.326Z

The PR has been converted to draft mode while work is in progress.

This comment marks the beginning of an AI work session. Please wait for the session to finish, and provide your feedback.

[konard]

Work session complete.

Implemented the latest review requirements:

• added grouping, sequence, and left-associative sequence formulas to tests/mtc_formulas.mtc;
• updated the axiom system with cards for ({}) = {}, {}{} : {} ⟼ {}, and {}{}{} : ({} ⟼ {}) ⟼ {};
• clarified that repeated {} in one form binds one candidate, while {}{}... uses positional candidates;
• redefined {⟼} through {[}{]} with {[}{]} = {[} ⟼ {]};
• fully updated README.md as the current entry point;
• strengthened tests/test_issue42_docs.py to cover the new sequence and grouping requirements.

Verification on commit 02a1ed2:

• python -m pytest tests -v --tb=short: 62 passed
• ruff check parsers/ converters/ core/ tests/ --ignore E501,F401: passed
• git diff --check: passed
• git diff --cached --check: passed
• GitHub CI run 26005723263: passed

PR is marked ready for review: #48

[konard]

🤖 Solution Draft Log

This log file contains the complete execution trace of the AI solution draft process.

💰 Cost estimation:

• Model: GPT-5.5
• Provider: OpenAI
• Public pricing estimate: $6.978706

📊 Context and tokens usage:

• 123.6K / 1.1M (12%) input tokens, 30.2K / 128K (24%) output tokens

Total: (123.6K + 4.4M cached) input tokens, 30.2K output tokens, $6.978706 cost

🤖 Models used:

• Tool: OpenAI Codex
• Requested: gpt-5.5
• Model: GPT-5.5 (gpt-5.5)

📎 Log file uploaded as Repository (51310KB)

• View complete solution draft log

---

Now working session is ended, feel free to review and add any feedback on the solution draft.

[konard]

✅ Ready to merge

This pull request is now ready to be merged:

• All CI checks have passed
• No merge conflicts
• No pending changes

---

Monitored by hive-mind with --auto-restart-until-mergeable flag

[netkeep80]

Дополнительное review PR #48: добавить аксиомы последовательности, скобок-операндов и убрать историческую риторику

Общий вывод

Текущее состояние PR #48 стало заметно лучше: временный DSL AXIOM / EXEC / RULE / NEGATIVE / STATUS убран, канонический файл формул снова называется tests/mtc_formulas.mtc и содержит чистые формулы МТС.

Но работа всё ещё не завершена. Сейчас PR уже добавил аксиому последовательности и прямоассоциативность, но сделал это недостаточно точно: роль круглых скобок как явного выделения формы-операнда ещё не раскрыта в тестах и аксиоматике. Кроме того, в активных текстах всё ещё слишком много процессной / исторической риторики: issue #42, старая система, legacy, архив, исторические формулировки. Это мешает получить новую рабочую версию МТС как самостоятельную систему.

Нужна ещё одна доработка.

---

1. Уточнить аксиому последовательности через круглые скобки

Сейчас в tests/mtc_formulas.mtc есть:

{}{} : {} ⟼ {}
{}{} = {} ⟼ {}

Это полезно, но недостаточно наглядно показывает, что первая форма берётся как отдельный операнд. Нужно добавить более точную форму:

{}{} : ({}) ⟼ {}
{}({}) : {} ⟼ ({})

Смысл:

({}) = {}

круглые скобки не создают новый смысл, но явно выделяют форму как целый операнд.

Тогда последовательность двух форм можно читать двумя симметричными способами:

{}{} : ({}) ⟼ {}
{}({}) : {} ⟼ ({})

Это лучше раскрывает роль () и подготавливает строгое чтение последовательностей длины больше двух.

Что нужно изменить

В tests/mtc_formulas.mtc добавить:

({}) = {}

{}{} : ({}) ⟼ {}
{}({}) : {} ⟼ ({})
{}{} = {} ⟼ {}

Можно оставить строку:

{}{} : {} ⟼ {}

как сокращённую форму, но нормативной / поясняющей должна быть именно запись со скобками:

{}{} : ({}) ⟼ {}

---

2. Уточнить прямоассоциативность через последовательность, а не только через раскрытую связь

Сейчас есть:

{}{}{} : ({} ⟼ {}) ⟼ {}
{}{}{} = {} ⟼ {} ⟼ {}
{}{}{} != {} ⟼ ({} ⟼ {})

Это правильно по направлению, но надо связать это с самой последовательной записью:

{}{}{} : ({}{}) ⟼ {}

А уже потом раскрывать:

{}{}{} = (({}) ⟼ {}) ⟼ {}
{}{}{} = {} ⟼ {} ⟼ {}

То есть последовательность из трёх форм должна читаться так:

ABC = (AB) ⟼ C
AB = A ⟼ B
следовательно: ABC = (A ⟼ B) ⟼ C

А правая группировка должна требовать явных скобок:

{}({}{}) : {} ⟼ ({}{})
{}{}{} != {}({}{})

Это важнее, чем просто написать:

{}{}{} != {} ⟼ ({} ⟼ {})

Потому что {}({}{}) показывает именно формальную запись с другой группировкой, а не только результат раскрытия через ⟼.

Что нужно добавить в tests/mtc_formulas.mtc

{}{}{} : ({}{}) ⟼ {}
{}{}{} = (({}) ⟼ {}) ⟼ {}
{}{}{} = {} ⟼ {} ⟼ {}

{}({}{}) : {} ⟼ ({}{})
{}{}{} != {}({}{})
{}{}{} != {} ⟼ ({} ⟼ {})

---

3. Уточнить правило {}: один кандидат в условии, но позиционные кандидаты в последовательности

Сейчас в документах уже есть различение:

Внутри одного исполнения шаблона все одинаковые вхождения `{}` относятся к одной и той же связи-кандидату.

и:

В последовательностной записи `{}{}...` каждое вхождение `{}` задаёт отдельную позицию кандидата.

Это правильно, но теперь надо сделать это нормативным правилом и привязать его к формам со скобками.

Нужно прямо записать:

В форме ограничения, например `∞ : {} = {} ⟼ {}`, повторные `{}` относятся к одному кандидату X.

В последовательной записи, например `{}{}{} : ({}{}) ⟼ {}`, каждое `{}` является отдельной позиционной формой: A, B, C.

Круглые скобки фиксируют границу уже собранной формы: `({})`, `({}{})`, `({} ⟼ {})`.

Иначе возникает риск противоречия: одно правило говорит “все {} — один кандидат”, а второе использует {} как разные позиции.

---

4. Переписать карточки аксиом А2-А4 в docs/theory/Система аксиом МТС.md

Сейчас карточки группировки, последовательности и прямоассоциативности уже появились, но их нужно сделать точнее.

А2. Группировка формы

Нормативная формула:

({}) = {}

Смысл:

Круглые скобки не создают новый смысл, но выделяют форму как целый операнд.

Важно добавить:

({}{}) не тождественно {}{} как текстовая запись, но указывает на уже собранную последовательную форму как единый операнд.

А3. Последовательность двух форм

Нормативные формулы:

{}{} : ({}) ⟼ {}
{}({}) : {} ⟼ ({})
{}{} = {} ⟼ {}

Смысл:

Последовательность двух форм есть связь первой позиционной формы со второй позиционной формой.

А4. Прямоассоциативность последовательности

Нормативные формулы:

{}{}{} : ({}{}) ⟼ {}
{}{}{} = (({}) ⟼ {}) ⟼ {}
{}{}{} = {} ⟼ {} ⟼ {}
{}({}{}) : {} ⟼ ({}{})
{}{}{} != {}({}{})
{}{}{} != {} ⟼ ({} ⟼ {})

Смысл:

Последовательная запись слева направо по умолчанию собирается прямоассоциативно: ABC = (A ⟼ B) ⟼ C.
Правая группировка требует явных круглых скобок: A(BC).

---

5. Обновить смысл конструктора связи через последовательность абитов

Текущая идея правильная:

{[}{]} = {[} ⟼ {]}
{⟼} : {[}{]}
{⟼} = {[} ⟼ {]}

Но после уточнения последовательности нужно явно сказать:

{[}{]} — это последовательность двух смысловых ссылок на абиты.
По аксиоме последовательности она разворачивается в связь `{[}` с `{]}`.
Поэтому `{⟼}` вводится через последовательностную форму `{[}{]}`, а не напрямую через ручное повторение `{[} ⟼ {]}`.

То есть предпочтительный порядок должен быть:

{[} : ∞♀
{]} : ♂∞

{[}{]} = {[} ⟼ {]}
{⟼} : {[}{]}
{⟼} = {[} ⟼ {]}

---

6. Убрать из активных текстов процессную и историческую риторику

В PR уже сделана большая чистка, но активные документы всё ещё не должны быть текстами “про issue #42”, “про старую систему”, “про legacy” и “про исторические этапы”. Мне нужна рабочая МТС, а не история её получения.

Активные документы должны говорить как спецификация текущей системы:

Это МТС.
Вот её постулат.
Вот формальная нотация.
Вот система аксиом.
Вот канонические формулы.
Вот тест согласованности.

А не:

после issue #42...
старая система...
legacy...
архив...
исторический слой...

Требование

В активных документах убрать или резко сократить такие маркеры:

issue #42
старая система
исторический
архив
legacy
прежний
временный

Оставить их можно только в docs/research/Открытые вопросы..., если это действительно нужно для списка нерешённых вопросов. В README и основной теории этой риторики быть почти не должно.

---

7. Тесты должны закреплять новые формулы

tests/test_issue42_docs.py должен проверять не только текущий список, но и новые обязательные формулы:

({}) = {}

{}{} : ({}) ⟼ {}
{}({}) : {} ⟼ ({})
{}{} = {} ⟼ {}

{}{}{} : ({}{}) ⟼ {}
{}{}{} = (({}) ⟼ {}) ⟼ {}
{}{}{} = {} ⟼ {} ⟼ {}

{}({}{}) : {} ⟼ ({}{})
{}{}{} != {}({}{})
{}{}{} != {} ⟼ ({} ⟼ {})

Также тест должен проверять, что .mtc не содержит служебных префиксов и не возвращает старые тесты.

---

8. Acceptance criteria для следующего прохода

Считать доработку выполненной только если:

1. tests/mtc_formulas.mtc содержит чистые формулы МТС без DSL.
2. В .mtc добавлены формулы:
   • группировки ({}) = {};
   • последовательности двух форм через ({});
   • правого операнда через {}({});
   • прямоассоциативности через {}{}{};
   • явной правой группировки через {}({}{});
   • различия {}{}{} != {}({}{}).
3. docs/theory/Система аксиом МТС.md содержит карточки этих механизмов по нормативному шаблону аксиомы.
4. docs/specs/Формальная нотация МТС.md объясняет () как явное выделение формы-операнда, а не просто “скобки для удобства”.
5. docs/specs/Шаблонный поиск МТС.md чётко различает:
   • один кандидат в условии формы;
   • позиционные кандидаты в последовательности.
6. tests/test_issue42_docs.py проверяет все новые формулы.
7. Активные документы очищены от исторической / процессной риторики и читаются как текущая рабочая МТС.

---

Итог

PR движется в правильном направлении, но нужно ещё одно важное уточнение: последовательность должна быть связана с круглой группировкой как с механизмом выделения операнда.

Ключевые формулы, которые должны появиться:

{}{} : ({}) ⟼ {}
{}({}) : {} ⟼ ({})
{}{}{} : ({}{}) ⟼ {}
{}({}{}) : {} ⟼ ({}{})
{}{}{} != {}({}{})

Без них прямоассоциативность уже заявлена, но ещё недостаточно наглядно и формально привязана к самой записи последовательностей.

[konard]

🤖 AI Work Session Started

Starting automated work session at 2026-05-17T23:28:38.708Z

The PR has been converted to draft mode while work is in progress.

This comment marks the beginning of an AI work session. Please wait for the session to finish, and provide your feedback.

[konard]

Work session complete.

Implemented the latest review requirements:

• added grouped sequence formulas to tests/mtc_formulas.mtc, including {}{} : ({}) ⟼ {}, {}({}) : {} ⟼ ({}), {}{}{} : ({}{}) ⟼ {}, and {}{}{} != {}({}{});
• updated the axiom system, formal notation, template search, foundations, metatheory, README, and plan with the operand-boundary rule for round parentheses;
• strengthened regression tests so active docs reject process/history markers and require the new sequence/grouping formulas.

Verification on commit d737026:

• python -m pytest tests/test_issue42_docs.py -v --tb=short: 19 passed
• python -m pytest tests -v --tb=short: 62 passed
• ruff check parsers/ converters/ core/ tests/ --ignore E501,F401: passed
• git diff --check: passed
• git diff --cached --check: passed
• GitHub CI run 26006014405: passed

PR is marked ready for review: #48

[konard]

🤖 Solution Draft Log

This log file contains the complete execution trace of the AI solution draft process.

💰 Cost estimation:

• Model: GPT-5.5
• Provider: OpenAI
• Public pricing estimate: $7.017392

📊 Context and tokens usage:

• 130.0K / 1.1M (12%) input tokens, 25.3K / 128K (20%) output tokens

Total: (130.0K + 4.6M cached) input tokens, 25.3K output tokens, $7.017392 cost

🤖 Models used:

• Tool: OpenAI Codex
• Requested: gpt-5.5
• Model: GPT-5.5 (gpt-5.5)

📎 Log file uploaded as Repository (34484KB)

• View complete solution draft log

---

Now working session is ended, feel free to review and add any feedback on the solution draft.

[konard]

✅ Ready to merge

This pull request is now ready to be merged:

• All CI checks have passed
• No merge conflicts
• No pending changes

---

Monitored by hive-mind with --auto-restart-until-mergeable flag