rul .rl
[0x00..0x3F] magic = b"RUL\x00\x01\x00\x00\x00" · 128-битный бинарный IR
Release v0.4.0 (2026-11-07) ↗

128-битный бинарный язык программирования для ИИ-агентов.

ИИ мыслит числами, а процессоры исполняют бинарный код — однако C, Go и Rust заставляют ИИ печатать человеческий текст и ждать секунды, пока компилятор угадает замысел. Rul (.rl) удаляет текстового посредника: ИИ выпускает фиксированные 16-байтные бинарные блоки, несущие Алгоритм, Расписание CPU и Билет Безопасности памяти сразу. Результат: проверка памяти за 5.8 нс, автономная компиляция за 6.4 мкс и ускорение в 4.72 раза по сравнению с ручным C.

ПЕРВЫЕ ПРИНЦИПЫ ЗА 10 СЕКУНД · УДАЛИТЬ ТЕКСТОВОГО ПОСРЕДНИКА
✗ СТАРЫЙ ПУТЬ (C / Go / Rust) ИИ мыслит (Числа) → Печатает текст → Компилятор парсит и угадывает (Секунды) → Машинный код (0/1)
✓ ПЕРВЫЕ ПРИНЦИПЫ RUL (.rl) ИИ мыслит (Числа) → Генерирует 16-байтный блок (5.8 нс проверка + 6.4 мкс сборка) → В 4.72x быстрее C
16-байтный блок (0 мс парсинга текста) + 6.4 мкс нативный ELF64 (без LLVM) + 5.8 нс проверка памяти (O(N) линейно)
# 1. Install standalone rul binary (0 rustc/LLVM runtime deps)
$ curl -fsSL https://raw.githubusercontent.com/rul-lang/rul/main/install.sh | sh

# 2. Scaffold, O(N) verify in ~5.8ns/node, compile 817B ELF64 & trace
$ rul new my-ai-pipeline && cd my-ai-pipeline
$ rul check   # ✓ Verified 7 SSA nodes in 0.04 µs (CAP_NONE = 0x0)
$ rul run     # ✓ Compiled 817-byte ELF64 in 6.4 µs -> Output: 77999800.0
$ rul trace   # ✓ White-Box Inspector: #0..#6 (NaN/Inf = 0)
Изучить 16-байтный кадр ↓ Спецификация v0.4 Whitepaper (DOI) ↗
ЖИВОЙ БИНАРНЫЙ ОБРАЗ .RL · 7 УЗЛОВ SSA = 208 БАЙТ -> 817-БАЙТНЫЙ ELF64 CAP_NONE=0x0

Нажмите на любой 16-байтный кадр инструкции ниже, чтобы декодировать его биты, доказательство и трассировку:

RulHeader
64 Bytes (0x00..0x3F)
Arena[0] + Proof[0]
32 Bytes (0x40..0x5F)
NodeFrame[0..6]
112 Bytes (7 × 16B)
#0 ArenaInput
01 18 11 00
#1 ConstF64
02 11 11 00
#2 CmpGt
14 38 11 00
#3 Mul
12 18 12 00
#4 SelectZero
15 18 11 00
#5 ReduceSum
21 11 11 00
#6 AssertContract
40 11 11 00
Artifact (.rl) = Algorithm + Schedule + Proof ✓ 5.78 ns/node
[0x40] 128-битный кадр
16 байт

Каждая инструкция — фиксированный бинарный блок · 0 мс парсинга

[0x50] на инструкцию
5.78 нс

Мгновенное доказательство памяти и границ (один проход O(N))

[0x60] нативная сборка
6.4 мкс

Автономный исполняемый файл Linux x86_64 ELF64 без LLVM

[0x70] 4.72x против C
51.53 ГБ/с

10 млн чисел (80 МБ) ускорены мутацией всего 1 байта

[0x80] ИНТЕРАКТИВНЫЙ 128-БИТНЫЙ СТЕНД

Одна 16-байтная инструкция = Алгоритм + Расписание + Доказательство

Выберите любой узел инструкции (#0..#6) или нажмите на любой байт (0..15), чтобы изучить 8-битный регистр, инвариант O(N) и трассировку выполнения.

Канал Алгоритма (Что считать: Опкод / Операнды) Канал Расписания (Как выполнять: SIMD / Многоядерность) Канал Доказательства (Безопасность: Версия / Границы)
NODE #3 ($n3) node $n3 = Mul f64x8 fg=1 pol=simd proof=0 tok=pure a=$n0 b=$n0
16 BYTES = 128 BITS
ПОБИТОВЫЙ РАЗБОР 8-БИТНОГО РЕГИСТРА · BYTE 2 (b16..b23) 0x12
0 2^7
0 2^6
0 2^5
1 2^4
0 2^3
0 2^2
1 2^1
0 2^0
Поле: schedule_hint Тип: u8
✓ Инвариант O(N) верификатора при загрузке (~5.78 ns) (fusion_group << 4) | exec_policy

Ортогональный байт аппаратного расписания: замена 0x11 (SimdStream) -> 0x12 (MultiCore) меняет режим CPU без изменения доказательств безопасности.

Узел #3: Поэлементное 8-канальное векторное возведение в квадрат ($n0 * $n0) в регистрах кэша L1 без промежуточных аллокаций в куче.
Символьное представление (src/main.rls — 208 Б в .rl) ~8.8 µs assemble
cap 0x0
arena 0 len=4096 lane=f64x8 mut=false align=64 ver=1
output $n6
Трассировщик «белого ящика» (rul trace — 7 узлов SSA) Нажмите на любую строку для синхронизации 16-байтного кадра и ассемблера
NODEOPCODEKINDLENMINMAXSUM/TRUESNANSAMPLE[0..4]
#0ArenaInputColumnF6440960.5000249.5000504608.00000[0.500, 1.500, 2.500, 3.500]
#1ConstF64Scalar1100.0000100.0000100.00000[100.000]
#2CmpGtColumnMask40960.00001.00002400.00000[0.000, 0.000, 0.000, 0.000]
#3MulColumnF6440960.250062250.250083627904.00000[0.250, 2.250, 6.250, 12.250]
#4SelectZeroColumnF6440960.000062250.250077999800.00000[0.000, 0.000, 0.000, 0.000]
#5ReduceSumScalar177999800.000077999800.000077999800.00000[77999800.000]
#6AssertContractScalar177999800.000077999800.000077999800.00000[77999800.000]
[0x100] МУТАЦИЯ РАСПИСАНИЯ В 1 БАЙТ

Измените 1 байт (Байт 2). Обгоните ручной код на C в 4.72 раза.

Реальная задача: 10 000 000 чисел с плавающей точкой (массив 80 МБ) — отфильтровать значения > 1000.0, возвести в квадрат и суммировать. Переключайте Байт 2 (schedule_hint) ниже: алгоритм остаётся на 100% неизменным, а время падает с 5.91 мс до 1.55 мс:

АКТИВНЫЙ БАЙТ 2 (schedule_hint): 0x12 + ZM bits[16..23] = 0001 0010
1.55 ms · 51.53 GB/s (4.72x vs C)

fg=1 pol=multicore + ArenaZoneMap: Сочетает многоядерность L1 с метаданными min/max блоков (ArenaZoneMap) для пропуска пустых тайлов за O(1) без чтения DRAM.

[A] Императивный AoS + Vec::collect()
70.66 ms 1.13 GB/s
[B] Идиоматичный Rust SoA (filter().map().sum())
19.12 ms 4.18 GB/s
[C] Ручной C/Rust SoA с 8 аккумуляторами
7.32 ms 10.92 GB/s
[D] Rul (.rl) Tier 2 Fused SIMD (0x11)
5.91 ms 13.53 GB/s
[E] Rul (.rl) Tier 2 MultiCore (0x12)
3.19 ms 25.04 GB/s
[F] Rul (.rl) Tier 2 MultiCore + ZoneMap
1.55 ms 51.53 GB/s
Доказательство глубоких конвейеров: BM-HORNER-50 (Полином 50-й степени · 104 узла SSA · 80 МБ)

Линейный аллокатор регистров YMM в src/aot.rs компилирует автономный ELF64 размером 3 872 байта за ~20.4 мкс и выполняет его за 106.58 мс — наравне с ручным C/Rust с 8 аккумуляторами (107.96 мс) без участия LLVM.

[0x140] ЧЕТЫРЕ МЕХАНИЗМА ИЗ ПЕРВЫХ ПРИНЦИПОВ

Простота первых принципов. Математическая точность в кремнии.

Традиционные языки компилируются медленно, потому что машине приходится читать человеческий текст и угадывать намерения. Rul полностью исключает угадывание с помощью четырёх механизмов:

01 · БИНАРНЫЙ КОД КАК ЕДИНЫЙ ИСТОЧНИК ИСТИНЫ src/bytecode.rs

1. Ноль парсинга текста (0% синтаксических ошибок)

Вместо набора тысяч символов с риском забыть точку с запятой, ИИ генерирует 16-байтные бинарные блоки напрямую (или собирает .rls за ~8.8 мкс). Конвейер из 7 шагов для 10 млн чисел занимает всего 208 байт в .rl и компилируется в автономный 817-байтный исполняемый файл Linux ELF64.

1. RulHeader 64 Bytes (64B-aligned)
2. ArenaDescriptor Table arena_count × 16 Bytes
3. ProofEntry Sidecar Table proof_count × 16 Bytes
4. NodeFrame Instruction DAG node_count × 16 Bytes
02 · ЛИНЕЙНОЕ ВЛАДЕНИЕ ЗА ВРЕМЯ O(N) src/verifier.rs

2. Версионные билеты памяти (безопасность уровня Rust за наносекунды)

Представьте каждый буфер памяти (Arena) как комнату с билетом версии 1. Несколько инструкций могут читать версию 1 одновременно (ReadLease 0b01). Как только инструкция меняет данные на месте (AffineConsume 0b10), комната переходит к версии 2 — любая последующая инструкция со старым билетом версии 1 отклоняется на входе за 5.78 нс без медленного Borrow Checker.

TOKEN_OP (32-BIT) = [mode: 2b | arena_id: 14b | version: 16b]
0b01 ReadLease(arena=0, ver=1) ✓ Разделяемое чтение (версия остаётся 1)
0b10 AffineConsume(arena=0, ver=1) → Мутация на месте и версия = 2
Reuse stale ReadLease(arena=0, ver=1) ✗ Отказ: StaleOrConsumedToken
03 · ПЕСОЧНИЦА НУЛЕВОГО ДОВЕРИЯ И ГРАНИЦЫ ProofEntry + CapMask

3. Предварительные сертификаты границ и аппаратный переключатель прав

Колонки одинаковой длины обрабатываются на полной скорости без проверок границ внутри цикла (TRIVIAL_BY_SHAPE). Срез массива (ArenaSlice) или выборка по индексу (Gather) требуют 16-байтного сертификата границ (ProofEntry) при загрузке. А при CapabilityMask = 0x0 бинарный файл физически лишён доступа к сети и диску.

proof_idx == 0 (90%+ nodes): TRIVIAL_BY_SHAPE (0 runtime checks)
proof_idx > 0 (ArenaSlice / Gather): lo <= hi <= effective_target_len
RulHeader.capability_mask = 0x0: CAP_NONE (Pure Compute Sandbox)
04 · АУДИРУЕМОСТЬ БЕЛОГО ЯЩИКА rul trace & decompile

4. Рентген-прозрачность «белого ящика» (никакого чёрного ящика)

Людям не нужно писать бинарный код вручную, чтобы сохранять 100% контроль: инженеры задают схему данных (ArenaDescriptor), аппаратные права (CapabilityMask) и выходные контракты (AssertContract), а ИИ пересобирает .rl за микросекунды. В любой момент выполните rul decompile для чтения текста или rul trace для проверки точных min, max, sum и NaN=0 на каждом шаге.

Контракт человека → ИИ генерирует .rl
Проверка + Сборка всего за ~12 мкс
Спецификация 29 опкодов →
[0x180] СИСТЕМНАЯ МАТРИЦА И AGENT MCP

C против Go против Rust против Rul (.rl)

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

КРИТЕРИЙC (clang -O3)Go (gc)Rust (rustc + LLVM)Rul (.rl) v0.4
Основной автор кодаПрограммист-человекИнженерные команды людейСистемные инженерыИИ-агенты (с инструментами аудита для человека)
Формат артефактаТекст (.c, .h)Текст (.go)Текст (.rs)Плоский бинарный .rl (16-байтные инструкции)
Накладные расходы на парсингВысокиеСредниеОчень высокие (Макросы, AST)0 мс (Прямой zero-copy mmap бинарного образа)
Безопасность памятиОтсутствует (Ручные указатели)Сборщик мусора (Паузы во время выполнения)Borrow Checker (Решатель ограничений)Версионный TokenOp (Проверка O(1) на каждый узел)
Проверка границ массивовОтсутствует (Переполнение буфера)Ветвление в рантайме при каждом доступеВетвление в рантайме (если не оптимизировано)Проверка при загрузке через Shape + таблицу ProofEntry
Время проверки и компиляцииСекундыДоли секунды — секундыСекунды — минуты~5.8 нс/узел проверка + ~6.4 мкс сборка ELF64 AOT
Безопасность песочницыПолные права процесса ОСПолные права процесса ОСПолные права процесса ОС (unsafe-крейты)64-битная маска CapabilityMask в заголовке файла
STDIO JSON-RPC 2.0 · src/mcp.rs

Встроенный сервер Model Context Protocol (rul-mcp)

Сервер stdio JSON-RPC 2.0 без внешних зависимостей, предоставляющий автономным ИИ-агентам 6 нативных инструментов верификации, дифференциального тестирования, автотюнинга и AOT-компиляции.

GET /.well-known/mcp.json ↗
rul_assemble_and_verify ~8.8 µs + 5.8 ns/node
(rls_source: string) -> VerifiedSummary + .rl hex

Ассемблирует символьные инструкции .rls в 128-битный бинарный образ .rl и запускает однопроходный статический верификатор O(N).

rul_test_differential Tier 0 == Tier 1 == Tier 2
(rls_source: string, arenas: ArenaData[]) -> DiffReport

Выполняет проверенную программу на Tier 0 (Oracle), Tier 1 (Stencil) и Tier 2 (L1 Fused) для доказательства побитовой/ULP-эквивалентности.

rul_autotune_schedule 1-Byte Sweep
(rls_source: string) -> Optimal ScheduleHint + Telemetry

Перебирает политики AutoL1Tile (0x10), SimdStream (0x11) и MultiCore (0x12), выбирая конфигурацию с максимальной пропускной способностью ГБ/с.

rul_compile_standalone ~6.4 µs ELF64
(rls_source: string) -> Standalone Linux x86_64 ELF64

Генерирует автономный исполняемый файл Linux x86_64 AVX2 ELF64 (628 Б – 1 037 Б) с линейным распределением регистров YMM.

rul_trace White-Box Inspector
(rls_source: string) -> NodeTraceRow[0..N-1]

Возвращает точные значения min, max, sum/trues, счётчик NaN/Inf и первые 4 элемента sample[0..4] для каждого узла SSA.

rul_cas_intrinsics 64-Bit FNV-1a CAS
(op: sort | hash_join | group_by | simd_scan) -> CasHash

Выполняет верифицированные контент-адресуемые ядра I64/U8 (sort, hash_join, group_by, simd_scan_byte) в хранилище RulCasStore.

[0x1C0] ДОРОЖНАЯ КАРТА К v1.0

От верифицированного колоночного движка (v0.4) к системному языку общего назначения (v1.0)

В версиях v0.1–v0.4 мы намеренно ограничили область применения массивами и векторами (29 опкодов), чтобы сначала доказать эффективность 16-байтного бинарного формата на реальном железе. За четыре этапа Rul расширится до полной замены Rust и Go:

Полная дорожная карта и инженерные правила →
v0.1.0 → v0.4.0 Выпущенная производственная база
✓ В ПРОДАКШЕНЕ

Колоночное ядро SSA-DAG (29 опкодов), трассировщик «белого ящика» и компилятор AVX2 ELF64 AOT

На реальном оборудовании доказана эффективность 16-байтного формата инструкций, однопроходного верификатора O(N) (~5.8 нс/узел), 3-уровневого движка, сервера rul-mcp и компилятора Linux ELF64 без LLVM (~6.4 мкс).

  • [1] 64-байтный RulHeader, 16-байтный ArenaDescriptor, 16-байтный ProofEntry и 16-байтный NodeFrame для 29 опкодов.
  • [2] Обратимый без потерь ассемблер .rls <-> .rl, автономный CLI rul, пакет rul-bench и сервер rul-mcp из 6 инструментов.
  • [3] Линейный распределитель регистров YMM (ymm2..ymm13), достигающий 51.53 ГБ/с (в 4.72 раза быстрее C) на массивах 80 МБ.
v0.5 Этап 1 (Месяцы 1–2)
● В РАЗРАБОТКЕ

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

Расширение 16-байтного набора инструкций за пределы числовых массивов: скаляры, структуры, перечисления, строки UTF-8, хэш-таблицы, ветвления и циклы с доказательством завершения.

  • [1] Поддержка первого класса для i64, i32, u8, f32, структур с фиксированной разметкой, алгебраических объединений, строк UTF-8 и хэш-таблиц в аренах.
  • [2] SelectBranch: условное ветвление, требующее слияния обеих ветвей в идентичном состоянии версий памяти (проверка за O(1)).
  • [3] RegionLoop и Call: ограниченные циклы со свидетельствами завершения в ProofEntry и модульные функции, проверяемые без инлайнинга всей программы.
v0.6 – v0.7 Этап 2 (Месяцы 2–3)
○ ЗАПЛАНИРОВАНО

Владение кучей уровня Rust и времена жизни структур за время O(N)

Обобщение 32-битных версий TokenOp и 16-байтных сертификатов ProofEntry с плоских массивов на регионные аллокации в куче и заимствования полей структур.

  • [1] Детерминированное выделение и освобождение регионов кучи, привязанное к линейным токенам владения — без GC и без фрагментации malloc/free.
  • [2] Сертификаты ProofEntry для независимых мутаций полей структур и времён жизни срезов zero-copy, проверяемые за O(1) на инструкцию.
  • [3] Полная защита от use-after-free, double-free и алиасинга без многосекундного решения ограничений Borrow Checker.
v0.8 – v0.9 Этап 3 (Месяцы 4–5)
○ ЗАПЛАНИРОВАНО

Детерминированная конкурентность в стиле Go и системный ввод-вывод под контролем CapabilityMask

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

  • [1] Отправка буфера через типизированный канал выполняет AffineConsume токена отправителя и передаёт владение получателю — исключая гонки данных при загрузке без GC.
  • [2] Расширение 64-битной маски RulHeader.capability_mask для контроля чтения/записи файлов, сетевых сокетов, таймеров и подпроцессов.
  • [3] Бинарный файл .rl с CAP_NONE (0x0) математически заблокирован от любых сетевых или дисковых вызовов ещё до начала выполнения.
v1.0 Этап 4 (Месяц 6)
○ ЗАПЛАНИРОВАНО

Мультиархитектурные нативные бэкенды (x86_64, ARM64, WASI) и формальные доказательства Kani

Генерация автономных исполняемых файлов для Linux, macOS, Windows и WebAssembly без LLVM, подтверждённая проверкой моделей Kani и набором из 50 тестов соответствия v1.0.

  • [1] Прямая генерация машинного кода без LLVM для x86_64 и AArch64 (ARM64) на Linux, macOS и Windows, а также детерминированных модулей WASI.
  • [2] Доказательства корректности с помощью Kani model-checking и непрерывный дифференциальный фаззинг декодера, O(N) верификатора и кодогенератора.
  • [3] Заморозка бинарной спецификации .rl v1.0 и публикация открытого набора из 50 эталонных программ.
[0x1F0] ПРЯМЫЕ ТЕХНИЧЕСКИЕ ОТВЕТЫ (AEO / FAQ)

Часто задаваемые вопросы — от простых основ до системной глубины

Понятные объяснения из первых принципов в сочетании с точными экспериментальными данными для инженеров, исследователей и ИИ-систем.

Q01 Что такое Rul (.rl) и почему он использует 16-байтный бинарный формат вместо человеческого текста? +
ИИ мыслит числами, а процессоры исполняют бинарный код — однако языки вроде C, Go и Rust заставляют ИИ печатать тысячи человеческих слов и ждать секунды, пока компилятор (rustc/LLVM) переведёт этот текст обратно в бинарный вид. Rul (.rl) устраняет текстового посредника: ИИ-агенты генерируют фиксированные 16-байтные (128-битные) бинарные блоки, содержащие Алгоритм, Расписание CPU и Билет Безопасности памяти сразу — полностью исключая парсинг текста (0 мс) и компилируя автономные исполняемые файлы Linux ELF64 за ~6.4 мкс.
Q02 Как Rul проверяет безопасность памяти уровня Rust за ~5.8 нс на инструкцию без медленного Borrow Checker? +
Представьте каждый буфер памяти (Arena) как комнату с номерным билетом версии, начиная с версии 1. Несколько инструкций могут читать версию 1 одновременно по разделяемому билету ReadLease (0b01). Когда инструкция изменяет буфер на месте через AffineConsume (0b10), она проверяет изменяемость буфера и переводит комнату на версию 2. Любая последующая инструкция со старым билетом версии 1 отклоняется на входе за время O(1) за один прямой проход (~5.78 нс/узел) — без многосекундного решателя Borrow Checker.
Q03 Если люди не пишут бинарные файлы .rl вручную, как инженерные команды отлаживают и поддерживают системы на Rul? +
Люди сохраняют 100% контроль, не набирая бинарный код вручную — точно так же, как врачи читают рентгеновские снимки, не рисуя их от руки: (1) Человек задаёт правила на входе — инженеры определяют схемы данных (ArenaDescriptor), переключатели аппаратных прав (64-битный CapabilityMask) и приёмочные проверки (AssertContract), а ИИ пересобирает верифицированный бинарник .rl за микросекунды; (2) Мгновенный читаемый текст через `rul decompile` переводит любой файл .rl обратно в символьный ассемблер .rls; (3) Пошаговый рентген через `rul trace` выводит точные значения min, max, sum, количество NaN/Inf и первые 4 элемента sample[0..4] на каждом шаге.
Q04 Почему инструментарий Rul написан на Rust, если сам Rul создан для замены текстовых языков? +
Каждому новому системному языку нужен начальный хост-язык для его первого компилятора — точно так же, как первый компилятор C был написан на ассемблере, а первый компилятор Rust — на OCaml. Мы создали верификатор Rul, 3-уровневый движок выполнения и нативный компилятор ELF64 на чистом Rust без внешних зависимостей с запретом `#![forbid(unsafe_code)]`. После установки автономного бинарного файла `rul` пользователи и ИИ-агенты проверяют, компилируют и запускают программы `.rl` напрямую без необходимости в rustc, Cargo или LLVM.
Q05 Как Rul достигает пропускной способности 51.53 ГБ/с (в 4.72 раза быстрее ручного C) изменением всего одного байта? +
В Rul аппаратное планирование (Байт 2: schedule_hint) полностью отделено от логики алгоритма (Байт 0: opcode). На конвейере фильтрации, возведения в квадрат и суммирования массива 80 МБ (10 000 000 чисел f64) одноядерный Rul (`0x11 SimdStream`) сливает все операции в тайлы кэша L1 по 1 024 элемента в регистрах AVX2 YMM, выполняясь за 5.91 мс против 7.32 мс у ручного C с 8 аккумуляторами (в 1.24 раза быстрее). Мутация Байта 2 с 0x11 на 0x12 (`MultiCore`) распараллеливает эти тайлы L1 на все ядра CPU (3.19 мс, 2.29x), а включение метаданных min/max блоков `ArenaZoneMap` пропускает холодные тайлы за O(1), завершая задачу за 1.55 мс (51.53 ГБ/с — в 4.72 раза быстрее одноядерного C и в 45.51 раза быстрее императивного AoS).
Q06 Может ли Rul заменить Rust и Go для разработки бэкенда и системного ПО общего назначения? +
Да — именно это является целью дорожной карты v1.0 из четырёх этапов: Этап 1 (v0.5) добавляет типы i64/i32/u8/f32, структуры, размеченные объединения, строки UTF-8, хэш-таблицы, ветвления SelectBranch с проверкой за O(1) и циклы RegionLoop с доказательством завершения; Этап 2 (v0.6–0.7) расширяет TokenOp и ProofEntry на регионные аллокации кучи и заимствования полей структур; Этап 3 (v0.8–0.9) вводит легковесные задачи и каналы с передачей владения в стиле Go, а также системные вызовы ОС под контролем CapabilityMask; Этап 4 (v1.0) обеспечивает генерацию нативного кода без LLVM для x86_64, ARM64 и WASI, подкреплённую формальными доказательствами Kani.