sqlite: подготовить каноническую dark-проекцию из реляционной схемы вместо прямой загрузки raw DSL

[zavx0z]

Проблема

После последних изменений pkg/sqlite стал канонической точкой сборки MetaDSL в SQLite:

• схема собирается из корневых *.sql;
• relation() раскладывает meta, fields, superposition, processes, reactions, matter по реляционным таблицам;
• AST-слой убран из текущего пути подготовки данных. :contentReference[oaicite:0]{index=0} :contentReference[oaicite:1]{index=1}

Но dark всё ещё живёт от raw DSL:

• dark/load.ts загружает meta.json и строит Meta напрямую из объекта;
• в Dark ещё осталась завязка на MetaAST / старый AST-слой. :contentReference[oaicite:2]{index=2} :contentReference[oaicite:3]{index=3}

В итоге сейчас SQLite уже хранит каноническое описание, но данные для тёмной материи из него ещё не подготавливаются.

Что нужно сделать

Нужно перевести подготовку данных для Dark на SQLite и сделать отдельную dark-проекцию из канонической реляционной схемы.

Важно:

• не делать raw DSL вторым источником истины;
• не дублировать канонические данные в новых persist-таблицах без необходимости;
• использовать SQLite как канонический слой, а в TypeScript собирать из него dark-пакет для materialization.

Цель

Сделать так, чтобы Dark получал не сырой TS/JSON DSL, а уже подготовленный нормализованный пакет данных из SQLite, пригодный для сборки тёмной топологии.

Текущее состояние, которое нужно учесть

1. Канонический SQLite-слой уже есть

pkg/sqlite/sqlite.ts собирает общую схему из отдельных SQL-модулей и открывает БД как каноническую MetaDSL-базу. relation.ts уже пишет в неё meta, fields, superposition, process, reactions, matter. :contentReference[oaicite:4]{index=4} :contentReference[oaicite:5]{index=5}

2. matter-схема уже рассчитана на более полную проекцию, чем реально записывается сейчас

DDL уже содержит:

• matter_node
• matter_edge
• matter_binding
• matter_binding_dep
• matter_meta
• matter_condition
• matter_logical
• matter_map
• matter_attr
• matter_attr_binding
• matter_attr_part
• matter_style_prop
• matter_event_update :contentReference[oaicite:6]{index=6}

Но текущий relationMatter() фактически пишет только:

• узлы,
• рёбра,
• src_binding для meta-узлов. :contentReference[oaicite:7]{index=7}

То есть схема уже позволяет хранить нормализованное topology/matter-представление, но write-side пока доведён не до конца.

3. process тоже записывается не полностью

DDL уже содержит:

• process_action
• process_action_read
• process_action_write
• process_finally
• process_finally_read :contentReference[oaicite:8]{index=8} :contentReference[oaicite:9]{index=9}

Но текущий relationProcess() сохраняет только:

• запись в process
• env в process_env. :contentReference[oaicite:10]{index=10}

4. Поля уже движутся в правильную сторону для topology-слоя

enum и array уже сохраняются по позициям, а значения приводятся к текстовой форме. Это подходит для topology-уровня, где важнее порядок, связь и вариант, чем исходный scalar-type. :contentReference[oaicite:11]{index=11} :contentReference[oaicite:12]{index=12}

Архитектурное решение

Нужен отдельный projector/assembler в pkg/sqlite, который:

1. читает канонические строки из SQLite;
2. собирает из них нормализованный dark-bundle;
3. возвращает его в dark/load для дальнейшей materialization.

То есть источник истины остаётся один — SQLite.
Dark получает уже готовую скрытую топологию, а не raw DSL.

Предлагаемое направление проекции

Смысловая проекция должна быть такой:

• matter_node.node_kind = 'meta' → Wimp
• matter_node.node_kind = 'cond' → Fuzzy
• matter_node.node_kind = 'log' → Axion
• matter_node.node_kind = 'map' → Macho

Bindings при этом должны собираться в нормализованную форму:

• static
• variable
• dynamic + deps + expr

то есть без потери различия между:

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

Что именно нужно реализовать

Этап 1. Довести запись канонического слоя до полноты

Дописать сохранение в SQLite для matter:

• matter_meta.fields_binding
• matter_meta.mass_binding
• matter_condition.predicate_binding
• matter_logical.predicate_binding
• matter_map.collection_binding
• ветвление then / else
• matter_attr
• matter_attr_binding
• matter_attr_part
• matter_style_prop
• matter_event_update

Дописать сохранение для process:

• process_action
• process_action_read
• process_action_write
• process_finally
• process_finally_read

Этап 2. Добавить dark read-model поверх SQLite

Добавить в pkg/sqlite новый модуль, например:

• pkg/sqlite/dark.ts

с публичной функцией вида:

readDarkBundle(db, src)

которая возвращает нормализованный пакет для Dark.

Этап 3. Перевести dark/load на SQLite

Заменить прямую загрузку raw DSL на чтение из SQLite:

• либо полностью,
• либо сначала параллельным путём под тесты и миграцию.

Ожидаемый результат

После выполнения задачи:

• pkg/sqlite становится не только write-side канонического DSL-слоя, но и точкой подготовки данных для Dark;

• Dark перестаёт зависеть от прямой загрузки raw DSL / meta.json;

• тёмная материя начинает materialize-иться из канонической SQLite-схемы;

• канонический источник истины остаётся один;

• появляется чёткое разделение:

  • SQLite — каноническая плоскость,
  • TypeScript — сборка dark-проекции,
  • Dark — materialization скрытой связности.

Критерии приёмки

• matter записывается в SQLite полностью, без потери src / fields / mass / predicate / collection / attrs / events / branches;

• process записывается полностью, включая action/finally/read/write;

• из SQLite можно собрать dark-bundle без обращения к raw DSL;

• dark/load может построить Meta и topology из SQLite-проекции;

• тесты покрывают:

  • meta → sqlite
  • sqlite → dark-bundle
  • dark-bundle → materialization

• raw DSL больше не является обязательным runtime-источником для Dark.

Дополнительно

На этом этапе не нужно:

• заводить отдельные persist-таблицы dark_*, если проекция может собираться из канонических таблиц;
• дублировать source of truth;
• возвращать AST назад в новый путь.

[zavx0z]

Нужно сузить и поправить архитектурный смысл этой issue.

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

• sqlite -> dark bundle -> load
• как будто dark/load должен начать читать уже готовый Dark из БД.

Это не тот вектор.

Правильнее так:

• load работает с одной meta;
• внутри load допустимо сразу раскладывать эту одну meta в SQLite через pkg/sqlite;
• то есть load может стать точкой первичной канонизации одной meta в реляционную форму;
• но не должен превращаться в reader готовой dark-проекции из БД.

Иначе мы перепутаем:

• загрузку одной meta,
• канонизацию одной meta,
• и верхний dark-pipeline, где уже рождается меж-meta связность.

Нужно явно держать разделение:

1. load

   • загрузил одну meta
   • разложил её канонические данные в SQLite через pkg/sqlite
   • передал дальше в Dark

2. Dark pipeline

   • работает уже с БД / ORM
   • делает верхний проход topology
   • строит связи между meta
   • продолжает обход дальше

То есть SQLite здесь должен читаться не как источник готового Dark для load, а как каноническая фиксирующая плоскость, с которой потом работает сам Dark на следующем шаге.

[zavx0z]

Ещё одно важное уточнение по смыслу topology.

В issue сейчас смешаны два разных слоя:

1. matter-узлы
2. topology-поля

Их нужно развести.

matter-узлы

Это structural declaration в matter:

• meta
• cond
• log
• map

Они участвуют в построении скрытой topology через верхний dark-проход.

topology-поля

Отдельно есть поля, которые сами несут topology-смысл:

• enum
• array

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

Особенно важно enum.
На примере github/zavx0z/git поле operation не просто хранит вариант, а участвует в выборе дочернего src в matter.
То есть enum здесь уже прямо участвует в меж-meta связности.

Поэтому в этой линии нужно явно зафиксировать:

• matter и topology-поля не одно и то же;
• верхний Dark pipeline должен учитывать оба слоя;
• enum и array должны участвовать в построении hidden connectivity, а не оставаться только каноническими field rows.

Отсюда следует, что задача не сводится к "дописать relationMatter()".
Нужно отдельно продумать, как верхний проход Dark читает:

• matter
• topology-поля enum/array
• вычисляемые src
• continuation
  и на этой основе строит связи между meta.

[zavx0z]

Чтобы агенту было проще идти без архитектурной путаницы, лучше читать задачу в таком порядке:

1. Уровень load

Сделать подготовку одной meta через pkg/sqlite:

• загрузка meta
• relation(db, meta, src)
• фиксация канонической реляционной формы одной meta

То есть load подготавливает meta-level данные, но ещё не решает весь global topology pipeline.

2. Верхний проход Dark

После этого сам Dark должен работать уже с БД через ORM-слой:

• читать канонические данные meta
• смотреть topology-поля enum/array
• смотреть matter
• вычислять continuation / дочерние src
• строить меж-meta связи
• продолжать обход дальше

3. Что здесь является главным результатом

Главный результат этой линии — не "читать готовый dark bundle из SQLite", а:

• использовать SQLite как каноническую плоскость фиксации одной meta;
• использовать верхний Dark pipeline для построения меж-meta topology;
• дальше уже работать с БД через ORM, а не через сырые TS-объекты как с единственным источником связности.

То есть issue лучше читать как задачу про:

load -> канонизация одной meta в sqlite

и дальше:

Dark upper pipeline -> ORM -> построение hidden connectivity между meta

Если это не зафиксировать, агент почти неизбежно уйдёт в ложный путь "сначала собрать dark read-model поверх sqlite, потом загрузить его в load", а это сейчас не то, что нам нужно.

[zavx0z]

Короткая формулировка для правки тела issue.

Эту задачу лучше читать не как:

• sqlite -> dark read-model -> load

а как:

• load -> канонизация одной meta через pkg/sqlite
• Dark upper pipeline -> работа с БД через ORM -> построение меж-meta связности

То есть правильный фокус такой:

1. load загружает одну meta и сразу раскладывает её в каноническую SQLite-форму через pkg/sqlite.
2. После этого верхний проход Dark работает уже с БД, а не только с raw TS-объектом.
3. На верхнем проходе Dark должны учитываться оба слоя:
   • matter
   • topology-поля enum/array
4. Именно на этом проходе должны строиться связи между meta, включая вычисляемые src и continuation.

Иными словами:
SQLite здесь нужен прежде всего как каноническая плоскость фиксации одной meta,
а верхний Dark pipeline — как место, где из этой канонической плоскости строится hidden connectivity между meta.

[zavx0z]

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

Правильный вектор такой:

1. Весь prepare/write-side остаётся в pkg/sqlite

Именно pkg/sqlite должен содержать весь функционал:

• подготовки канонических данных одной meta;
• раскладки DSL в реляционные таблицы;
• записи этих данных в SQLite.

То есть вся логика вида:

• normalizing / canonicalizing
• relation(...)
• запись fields / superposition / process / reactions / matter
  должна жить в pkg/sqlite, а не размазываться по dark.

2. load не должен брать на себя prepare/read-model логику

Роль load здесь должна быть минимальной:

• загрузить исходную meta;
• передать её в relation(db, meta, src);
• после этого завершить свою задачу.

То есть load не должен:

• собирать обратный dark-bundle из SQLite;
• превращаться в специальный SQLite-reader для Dark;
• дублировать логику подготовки данных, которая должна жить в pkg/sqlite.

Иными словами:

load = загрузка одной meta + передача в relation

3. После этого dark должен работать уже через ORM по БД

После канонизации одной meta в SQLite сам пакет dark должен работать уже не через обратную сборку MetaDSL как основного runtime-пути, а через ORM / DB-layer.

То есть верхний Dark pipeline должен:

• брать данные из БД;
• строить topology и hidden connectivity уже поверх БД;
• строить меж-meta связи на верхнем проходе.

4. Что отсюда следует practically

Нежелательный путь:

• load -> relation -> readDarkBundle -> снова MetaDSL -> dark

Желаемый путь:

• load -> relation
• дальше: dark -> ORM -> DB

readDarkBundle может иметь смысл как:

• тестовый round-trip;
• debug / inspection;
• проверка полноты канонической схемы.

Но это не должно становиться главным runtime-путём самого Dark.

5. Суть в одном предложении

pkg/sqlite = весь функционал подготовки и записи канонической meta в БД.
load = только загрузка meta и вызов relation(...).
dark = дальнейшая работа уже через ORM по SQLite, включая верхний проход и построение меж-meta связности.

Вот это и нужно считать целевым направлением для этой issue.

[zavx0z]

Ещё одно ключевое уточнение по целевой архитектуре.

После load -> relation(...) в SQLite у нас уже лежат канонические реляционные данные одной meta.
Дальше dark не должен работать через обратную сборку MetaDSL как через основной runtime-path.

Правильнее так:

• ORM в dark должен работать на частицах тёмной материи;
• эти частицы должны строиться из данных, уже лежащих в реляции;
• то есть source для верхнего Dark pipeline — это не raw DSL и не обратно собранный bundle, а реляционные записи, которые уже подготовил pkg/sqlite.

Иначе говоря:

1. pkg/sqlite

   • подготавливает и записывает канонические данные одной meta в реляционные таблицы.

2. dark

   • через ORM читает уже эти реляционные данные;
   • на их основе materialize-ит частицы тёмной материи;
   • дальше уже на уровне этих частиц строит topology и меж-meta связность.

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

Коротко:

• relation фиксирует канонический слой;
• dark ORM работает уже по данным в реляции;
• ORM-модель должна быть моделью частиц Dark, а не просто ORM-обёрткой над повторно собранным DSL.

[zavx0z]

По текущему коммиту направление уже стало заметно правильнее.

Что здесь хорошо:

• matter уже раскладывается не в matter_node/matter_edge, а в particle-centric реляцию (matter_particle + subtype tables);
• pkg/sqlite действительно стал местом подготовки и записи particle-проекции;
• dark уже начал читать частицы из SQLite, а не обходить matter напрямую как AST;
• mass тоже переведён в нормализованную реляционную форму.

Это уже ближе к целевой схеме:

• load -> relation(...)
• дальше dark -> ORM / particle loader -> реляционные данные

Но осталось важное недожатое место.

Сейчас в dark всё ещё живёт запасной локальный путь через AST:

• createAstRuntimeMeta
• projectAstNode
• projectAstChildren
• локальная AST-проекция continuation-ветвей

То есть архитектура пока ещё смешанная:

• основной путь уже через SQLite;
• fallback путь всё ещё через локальную проекцию AST внутри dark.

А целевая граница должна быть жёстче:

• весь prepare/write-side остаётся в pkg/sqlite;
• load только загружает meta и передаёт её в relation(...);
• после этого dark работает уже по реляции на уровне частиц.

Поэтому следующий логичный шаг:

1. Убрать из dark остаточную локальную AST-проекцию matter в particle-plan.
2. Оставить в dark только работу через particle-loader / ORM поверх SQLite.
3. Считать pkg/sqlite единственным местом, где происходит подготовка и запись particle-проекции из загруженной meta.

Иными словами:

Хорошо, что particle-centric слой уже появился.
Теперь нужно дожать архитектуру до состояния, где dark больше не умеет сам проектировать matter из AST, а materialize-ит только то, что уже зафиксировано в реляции.

[zavx0z]

Хороший шаг.

Сейчас уже выполнено главное:

• AST fallback убран из dark;
• particle read-model перенесён в pkg/sqlite/dark.ts;
• dark больше не строит particle-проекцию сам, а читает её из реляционного канонического слоя.

Это уже близко к целевой архитектуре.

Но остался ещё один недожатый момент:
dark/dark.ts всё ещё сам вызывает ensureMetaCanonicalized(...).

То есть dark уже не проектирует AST локально, но всё ещё может сам инициировать канонизацию меты.
А целевая граница должна быть строже:

• load загружает meta;
• load передаёт её в relation(...);
• после этого dark только читает particle ORM / model из БД.

Следующий шаг:
убрать из dark собственный вызов ensureMetaCanonicalized(...) и оставить ему только работу с уже подготовленным SQLite / ORM context.

[zavx0z]

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

Правильная схема

1. Для одной meta всё исходно уже есть в DSL

То есть для раскладки одной конкретной meta нам не нужен верхний dark-проход.
Все данные уже есть в её DSL:

• fields
• superposition
• process / reactions
• matter
• bindings
• topology-поля enum/array

Следовательно, задача relation/sqlite для одной meta такая:

• взять одну загруженную meta;
• полностью разложить её в каноническую реляционную форму;
• записать эту форму в SQLite.

Именно это должен делать pkg/sqlite.

2. Верхний уровень dark.ts — это уже не раскладка одной meta

Когда одна meta уже лежит в реляции, верхний уровень dark.ts должен заниматься другим:

• читать particle / ORM-представление из БД;
• на верхнем уровне обхода строить связи между meta;
• фиксировать эти меж-meta связи в базе.

То есть верхний уровень dark нужен не для того, чтобы раскладывать одну meta,
а для того, чтобы из уже записанных данных строить topology между разными meta.

3. Внутренний послойный обход — это materialization ORM-объектов из БД

Во внутреннем обходе по слоям не нужно заново проектировать DSL.
Там нужно:

• брать уже записанные реляционные данные;
• создавать из них ORM / particle-объекты;
• materialize-ить Wimp / Fuzzy / Axion / Macho;
• работать уже на уровне этих объектов.

То есть внутренний послойный обход = не раскладка, а materialization из реляции.

Итого в одном виде

• pkg/sqlite:
  раскладывает одну meta из DSL в полную каноническую реляцию SQLite.

• верхний dark.ts:
  поверх уже записанных meta строит и фиксирует в БД связи между meta.

• внутренний послойный dark-обход:
  создаёт ORM / particle-объекты из базы, а не из raw DSL.

Вот это и нужно считать целевой архитектурой для данной линии.

[zavx0z]

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

Раньше внутренний уровень был таким:

• dark.ts::matterMeta()
• это был послойный обход одной meta
• источник данных для этого обхода был AST / DSL

То есть matterMeta() уже умел делать нужную работу по смыслу:

• проходить одну meta по слоям;
• строить частицы;
• формировать следующий внутренний шаг;
• выделять дочерние Wimp.

Правильная задача состояла не в том, чтобы менять этот смысл или выносить его в отдельный новый верхний pipeline,
а в том, чтобы перенести источник данных этого же обхода из AST в SQLite.

Иными словами, нужно было сделать так:

1. relation/sqlite берёт одну meta из DSL;
2. сразу раскладывает всё необходимое для дерева частиц в БД;
3. после этого matterMeta() продолжает работать почти в том же виде,
   но читает уже не AST, а подготовленные реляционные данные / particle rows из SQLite.

То есть целевой переход должен читаться так:

• было:
  matterMeta() читает AST напрямую

• должно стать:
  matterMeta() читает те же по смыслу данные, но уже разложенные в SQLite

А не так:

• придумываем новый отдельный главный pipeline,
• размазываем обязанности между load / pipeline / dark,
• уводим систему в лишнюю orchestration-слойку.

Ещё одно важное следствие:

• как таковой отдельный store для этого не нужен;
• всё достаточное состояние должно лежать в БД;
• внутренние ORM-объекты и частицы должны materialize-иться прямо из SQLite.

То есть БД здесь должна быть не вспомогательным кешом рядом со store,
а достаточным каноническим слоем для внутреннего dark-обхода одной meta.

[zavx0z]

По текущему состоянию основная архитектурная миграция по этой линии уже в целом состоялась.

Что уже выглядит правильно:

• dark больше не идёт основным путём через локальную AST-проекцию;
• matterMeta() сохранил правильный смысл как послойный обход одной meta;
• источник данных для этого обхода уже перенесён с AST на подготовленный реляционный слой;
• pkg/sqlite/dark.ts уже даёт particle-centric read-model;
• dark/dark.ts требует подготовленный sqliteDb и materialize-ит частицы из SQLite.

То есть по смыслу уже произошёл именно тот переход, который и был нужен:

• было:
  matterMeta() читает AST / raw DSL напрямую

• стало:
  matterMeta() читает те же по смыслу данные, но уже подготовленные в SQLite как particle rows / ORM-модель

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

Что теперь нужно дожать

1. Синхронизировать тело issue с фактической архитектурой

Исходное тело всё ещё читается слишком широко и местами уводит в сторону:

• sqlite -> dark bundle -> load

А фактическая целевая схема уже другая:

• load загружает одну meta
• pkg/sqlite полностью раскладывает её в каноническую реляцию
• matterMeta() / dark дальше materialize-ят частицы уже из БД

2. Явно зафиксировать главный runtime-path

Нужно считать главным путём именно это:

• load -> relation(...)
• дальше dark -> particle model / ORM -> SQLite

А не:

• load -> relation -> readDarkBundle -> обратная сборка DSL -> dark

3. Определить статус readDarkBundle(...)

Сейчас это нужно либо:

• оставить только для debug / inspection / round-trip / тестов;
• либо убрать из основной линии, чтобы не размывать границу.

Но это не должно становиться главным runtime-путём dark.

Архитектурная граница, которую нужно считать целевой

• pkg/sqlite — полная канонизация и запись одной meta в SQLite;
• matterMeta() / внутренний dark-обход — materialization ORM / particle-объектов из базы;
• dark — дальнейшая работа с уже materialized частицами и связностью;
• отдельный store не нужен;
• достаточное состояние должно лежать в БД.

Итого

Эту issue уже правильно читать не как задачу «сделать SQLite-подготовку с нуля», а как задачу на финальную зачистку архитектурной границы:

• не возвращаться к AST как runtime-источнику;
• не превращать обратную сборку bundle в основной путь;
• окончательно закрепить SQLite как достаточный канонический слой для внутреннего dark-обхода одной meta.

После этого issue уже можно будет либо закрывать, либо выделять из неё узкую добивку отдельной задачей только на cleanup остаточной двусмысленности.

[zavx0z]

Ещё одно важное уточнение по текущему коммиту.

array здесь не нужно выводить по sample value.
Для нашей архитектуры array должен оставаться всегда числовым topology-полем.

То есть путь с inferBoundaryArrayElementType(...) сейчас концептуально неверный, потому что он:

• добавляет лишнюю эвристику;
• делает runtime-зависимость от текущего sample value;
• размывает канонический смысл array.

А по нашей модели должно быть жёстко:

• enum — вариантное topology-поле;
• array — числовое topology-поле;
• тип элемента array не должен вычисляться динамически из значения.

Следовательно, здесь правильнее:

1. убрать вывод array-типа по sample value;
2. не различать runtime-варианты array<string> / array<boolean> / array<number> в этой линии;
3. считать array канонически числовым полем и в SQLite, и в runtime-проекции.

Иными словами:

• текущее упрощение array<string> -> array правильное;
• но дальнейшая попытка обратно вывести тип элемента по sample value уже лишняя;
• array нужно держать как number по архитектурному инварианту, а не угадывать по данным.

Это уже отдельная точечная добивка после основного архитектурного cleanup.