The module system — the architecture's core premise — is zero lines of code

Источник: dev/fera-research/docs/oc3/002-module-system-is-zero-lines.md (read-only; сгенерировано scripts/sync-docs.mjs)

The module system — the architecture’s core premise — is zero lines of code

• kind: problem
• area: modules
• severity: high

Evidence

There is no cdylib anywhere in the workspace. grep -rn "crate-type\|cdylib\|\[lib\]\|\[bin\]" --include=Cargo.toml ~/dev/fera/fera returns zero hits. Every one of the 15 crates is an rlib or a bin built from src/lib.rs / src/main.rs by cargo default.

There is no module tree. TECHSPEC.md:30-39 enumerates the canonical module layout — storage-sanakirja, search-milli, renderer-*, style-{macos,win,linux}, feature-{macos,win,linux}, native-{macos,linux-gtk,winui}, media-decoder-baseline, media-decoder-ffmpeg, calls-tgcalls, core.dll. find ~/dev/fera/fera -type d shows core/crates/{protocol,domain,storage,search,media,predictor,ui-contract,ui-engine-vello,ui-elm,notification,trust} + launcher + plugins-sdk + tools/{manifest-signer,bench-scene}. Zero module cdylibs. core.dll itself — “module zero”, the entire client per ADR-013 — does not exist as a build artifact target.

There is no runtime dependency. ~/dev/fera/fera/Cargo.lock has 201 packages. grep -c "^name = \"grammers\"" Cargo.lock → 0. Same for ractor (0), sanakirja (0), heed (0), wasmtime (0), ed25519 (0), serde_json (0), sha2 (0). The only real dependency in the entire ecosystem-side workspace is vello = "0.10" + parley = "0.11" in core/crates/ui-engine-vello/Cargo.toml:14-15.

fload is not even cloned. ls ~/dev/fera/ contains chroix*, community, dead-or-not, demo-site, fera, lattice, project-design, re-call, rstgcalls, site — fload, mikkaj, grmrs are absent from the local tree. OQ.md:511-548 (OQ-025) still lists them as a pending phase-1 repo list.

define_plugin! does not exist. TECHSPEC.md:301 — “nylon-ring (host + define_plugin! macro on the module side)”. No such macro anywhere.

The whole workspace compiles in 2.89 s with zero external I/O:

$ cd ~/dev/fera/fera && cargo check --workspace --offline
    Checking fera-ui-elm v0.1.0-epoch0.edition0
    Checking fera-ui-engine-vello v0.1.0-epoch0.edition0
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 2.89s

Total: 3821 LOC across 34 files. Real code = protocol 763, ui-contract 823, domain 724, ui-elm 549, ui-engine-vello 470, storage 413 = 3742. Placeholders = media 5, notification 5, predictor 5, search 5, trust 8, plugins-sdk 10, launcher 20, manifest-signer 12 = 58 LOC, every one of which is a doc comment plus a println! saying it is a skeleton.

Суть

TECHSPEC §10 step 4 is the pivot of the whole project: “nylon-ring module boundary for StorageEngine — prove hot-swap works before generalizing the pattern to other subsystems” (TECHSPEC.md:461-462). Everything before it is a proof of concept; everything after it is architecture. The repo is at step 3 with the boundary not started.

The three named engine dependencies — fload (module runtime), mikkaj (search on sanakirja), grmrs (protocol) — do not exist on this machine at all. They are not depended upon, not vendored, not even cloned. So step 1’s actual deliverable (“Protocol layer + typestate client”) is satisfied by a Transport trait with no transport implementation whatsoever (protocol/src/state.rs:52, documented honestly at state.rs:13-17: “The concrete MTProto transport is injected through the Transport trait, so the state machine can be unit-tested with a fake transport (no network, no grmrs) — the real binding lands in the grmrs integration pass”). Same for storage: StorageEngine has one impl and it is a BTreeMap (storage/src/memory.rs:20-25). There is no sanakirja, no LMDB, no disk I/O, no network socket anywhere in the workspace.

That is not a criticism of the typing — the typestate client, the StorageEngine contract, the Elm loop, and the Vello lowering are real, readable, well-commented work (see docs/oc3/007-what-is-actually-solid.md). It is a statement about what the current tree can be called. Steps 1-3 have produced the shapes of the offline-first read/write path with every I/O binding left as a seam. Which is a legitimate milestone, provided nobody reads it as “steps 1-3 done.”

Of the 96 QA gates the spec enumerates (cc’s count of QA.md), 30 sit in the module/trust and launcher sections (QA.md:121-159 = 13 gates, QA.md:161-170 = 3 gates, plus the trust-dependent ones), and every one of them is unreachable: they test behavior of a module system that has no code. QA.md:105-107 asks for “Engine-module swap (even to a stub) requires no changes to ui-elm/domain — verified by actually performing such a swap in a test build”. There is nothing to swap.

Варианты решения (с tradeoffs)

Option A — treat steps 1-3 as “seams only”, write that down, keep building.

• Cost: none now. Cost later: the risk that a green cargo check in 2.89 s reads as “offline-first path proven” when no byte has ever touched a disk or a socket.
• Benefit: honest bookkeeping; the shapes are genuinely reusable.

Option B — land the three missing repos (fload, grmrs, mikkaj) before more typing.

• Cost: they do not exist yet as working trees on this machine (OQ-025:511-548 still lists them as uncreated). fload is a fork of nylon-ring with a rewritten internals plan (OQ-024), so it is a real project, not a clone.
• Benefit: unblocks §10 steps 1 (real transport), 3→4 (real boundary), 6 (real search), 8 (real calls) simultaneously, because all three are on the critical path.
• Risk: three large C++-adjacent efforts at once. grmrs is a grammers fork and ADR.md:506-517 (ADR-026) says vanilla grammers does not expose what v1 needs (secret chats ADR-025, passkeys ADR-027) — so grmrs is a fork-with-work, not a clone.

Option C — build one module boundary end-to-end with a trivial module (prove step 4 with storage-sanakirja as a stand-in).

• Cost: one module crate + a hand-rolled or minimal loader if fload isn’t ready.
• Benefit: converts 30 unreachable QA gates into reachable ones, and validates ADR-020’s three-tier granularity claim (common.dll / X-types.dll / X.dll) which is currently an untested assertion in a design doc.
• Risk: if fload later lands with an incompatible API, the throwaway loader is wasted — but the manifest and the contract test survive, which is where the real cost is.

Предлагаемое решение

C first, then B in parallel — and treat A as mandatory bookkeeping either way.

1. Immediately: nothing in the repo currently distinguishes “the offline-first read path is proven” from “the seams of the offline-first read path exist”. The cheapest fix is a STATUS-level statement of which §10 steps are shaped vs wired. TECHSPEC.md:451-453 already calls §10 “not a committed roadmap, a dependency ordering” — the repo is honoring that, but the README ("Pre-code" / "Alpha development (no test builds yet)") and a green CI run leave a different impression.
2. Then: prove step 4 with the smallest honest module. The contract test suite already exists and is generic (storage/src/engine.rs:103 — pub fn run<S: StorageEngine>(mut fresh: impl FnMut() -> S)), so a second engine is a drop-in. This is the cheapest possible way to satisfy ADR-014/QA.md:29-30 for real and to make QA.md:105-107 executable.
3. In parallel: the dependency situation needs a decision from the owner. fload, grmrs, mikkaj are simultaneously (a) required by §10 steps 1, 4, 6, 8, (b) absent from the machine, and (c) not created per OQ-025. That is a sequencing fact, not a code defect — but it is the thing that actually gates the client, more than any typing.

Cross-references

• docs/oc1/009 (EBR protects data, not code — makes the step-4 boundary harder than assumed) and docs/oc4/idea-08 (dev mode and hermetic production mode are the same build; StaticLoader vs DylibLoader) are both about making step 4 land safely and are complementary to this finding rather than duplicates.
• oc5/003 (unpinned git deps) is a prerequisite for any of this becoming reproducible.