В первой части мы выяснили, что ядро v151, хоть и алгебраически цельное, юридически уязвимо

В первой части мы выяснили, что ядро v151, хоть и алгебраически цельное, юридически уязвимо. «Грязные» предупреждения, ложь в документации и контрабанда арифметики (%) делают его недопустимым для серьезной демонстрации.

Мы не будем патчить это «по-тихому». Мы вводим режим Zero Tolerance.

Ниже — план из 4 шагов (v152–v156), превращающий код в Закон.

Шаг 1 (v152): Закон о Модулярной Арифметике

Проблема: В коде обнаружены строки вида (a + b) % n.

Для обычного программиста это норма. Для нас — это атака. Это подмена проверенной табличной операции (Кэли) на непроверенную арифметическую формулу процессора. Кто разрешил использовать %? Где гарантия, что это соответствует полю Галуа или циклической группе?

Решение: Тотальный запрет AST-уровня.

Политика: Создается SPEC/ARCH/MOD_ARITHMETIC_POLICY_V1.json.

Смысл: numeric % запрещен везде, кроме спецхранилища.

Гейт (AST Audit): Мы пишем валидатор, который парсит Abstract Syntax Tree (AST) всего проекта. Он ищет узел BinOp(Mod). Это не поиск текста (regex), это анализ структуры кода.

Allowlist: Единственное место, где разрешен % — это файл src/yantra_core/mod_arith_v1.py. Это «изолятор». Если вам нужно сложение по модулю, вы вызываете функцию оттуда.

Результат:

Если в любом другом месте инженер напишет x % 2, билд упадет с CRITICAL FAIL и выдаст Witness:

{ "file": "...", "line": 56, "violation": "ILLEGAL_MODULO_OP" }.

Шаг 2 (v152): Чистка Свидетеля (Witness Purge)

Проблема:

DeprecationWarning: invalid escape sequence при импорте.

Ложь в докстроке: "Center Z(Aut) has order 3".

Решение:

Мы исправляем это не ради красоты консоли, а ради чистоты протокола.

Синтаксис: Перевод всех строк с LaTeX-подобной записью в raw-strings (r"""..."""). Предупреждения интерпретатора приравниваются к ошибкам.

Математика: Докстрок переписывается. Вместо ложного обобщения — строгое утверждение: "Канонический мотор, выбранный из центра по алгоритму lexmin, имеет порядок 3 в данной конфигурации".

Результат:

PASS на импорте. Истина в документации. Система больше не лжет сама о себе.

Шаг 3 (v153–v154): Закон о Публичной Поверхности

Проблема: Документация ссылается на старые архивы (v150.zip), а экспериментальные модули перемешаны с нормативными. Аудитор не понимает: "Что здесь Закон, а что черновик?".

Решение:

Гейт на имена архивов: Запрет на хардкод версий (например, v150). Разрешены только абстрактные имена <ARCHIVE.zip> или ссылки на CURRENT.

Манифест Публикации: Файл SPEC/ARCH/PUBLIC_RELEASE_MANIFEST_V1.json.

В нем перечислены файлы, которые являются Нормативными.

Маркировка Экспериментов:

Любой файл, не входящий в Манифест, обязан начинаться с заголовка:

# NON-NORMATIVE / EXPERIMENTAL

Если заголовка нет — FAIL.

Результат:

Четкая граница ответственности. Мы отвечаем головой только за Норматив.

Шаг 4 (v156): Канонический Прогон (The Canonical Run)

Проблема: Как доказать, что сеть работает детерминировано, не запуская её на машине пользователя?

Решение: Pinned Execution.

Мы создаем "Золотой Эталон" — файл SPEC/DEMO/NET_PIPELINE_CANONICAL_RUN_V1.json.

В нем лежат:

Входной текст.

Настройки.

Ожидаемый выход (байт-в-байт).

Гейт VERIFY_NET_PIPELINE запускает CLI, прогоняет текст и сравнивает хеш выхода.

Если хоть один байт отличается (из-за обновления Python, смены ОС или фазы Луны) — релиз отменяется.

Итог Итерации 2

К версии v156 мы получаем систему, которая:

Не содержит "партизанской" арифметики.

Не выдает предупреждений.

Четко знает, где у нее Закон, а где Эксперимент.

Доказывает свою детерминированность через Pinned Run.

Это уровень Industrial Grade Algebra.

В финальной части мы подведем черту и сформулируем, почему этот подход — единственный путь для AI Safety.