PROP-007 shipped the workspace data model (M1.17) but deliberately left one question open — [PROP-007 §6 question 3](../modules/vibe-workspace/PROP-007-workspace.xml#open), the *per-member materialisation target*: when a dependency is resolved for member M, into which member's `spec/` does its content land?

This session answered it. The answer turned out to be far larger than picking a directory: it is a redesign of vibevm's entire **loading model** — how a dependency's content is materialised, how the boot sequence is composed across a workspace hierarchy, and how an AI agent consumes it at session start. This document records the *why* and the fork-by-fork reasoning; **PROP-009** is the contract, and it shipped.

It belongs to the workspace arc and continues [`workspace-and-qualified-naming.xml`](workspace-and-qualified-naming.xml).

PROP-007 §6 q3 reads as a narrow placement question. It is not.

vibevm's boot model ([`VIBEVM-SPEC.md` §6](../../VIBEVM-SPEC.md)) is a **flat, single, shared, mutable namespace** — `spec/boot/NN-*.md`, read in filename order, one sequence, one entry point. It is correct for exactly one project shape: one project → one boot sequence → one entry point.

A workspace breaks every one of those assumptions at once:

The flat model cannot be stretched over this. It must be replaced.

The owner's hard constraint, stated at the outset: **installing a dependency must never modify anyone's authored spec.** The owner's analogy is C++ — you do not rewrite your `#include` directives into the literal text of the dependency's headers. Merging a dependency's spec into the consuming spec is the broken option, and it is what a naïve "bubble everything into the root `vibevm/vibespecs/boot/`" would amount to.

The owner framed the loading mechanism directly as **static vs dynamic linking**, and that framing became the spine of the design.

The load-bearing consequence: **at session start, the AI agent is the loader.** Every reference the agent resolves itself costs tool calls, and tool calls are — the owner's words — *безумно дорого*. Static linking moves resolution to `vibe install` time (done once, by the machine); dynamic linking leaves it to the agent (every session, by the LLM). Exactly the C++ tradeoff: a statically-linked binary loads with no help; a dynamically-linked one needs the loader to find and map every `.so`.

**P1 — Two trees.** A node's authored `spec/` (only the node's author writes it) and the materialised dependencies (a separate tree, only `vibe` writes it) are physically separate and never intermixed. Installing a dependency never touches authored `spec/`. This is "your code vs `vendor/`". Under unified resolution a dependency is materialised **once** for the whole workspace.

**P2 — The boot sequence is computed, not assembled by hand.** Each node has an *effective boot sequence* = inherited foundation (from ancestors, flowing down) + the node's own authored boot + the boot of its transitive dependencies (flowing up) + user overrides. `vibe` computes it from the unified resolution. This is the owner's "matryoshka" — but computed directly per level from the resolution graph, not physically copied leaf-to-root (copying drifts; computation does not). Every level is self-contained: a session opened at any node gets a sequence coherent for that node's subtree. The root's sequence is the union of everything; a small member's is small — the hierarchy gives cost-scoping for free.

**P3 — One generated index per entry point; the agent never walks the graph.** `vibe install` generates, for each entry-point node, the boot artifacts (§6). The agent reads them in a flat, predictable loop — reads parallelise, collapsing latency. No recursion, no discovery, no cycle-detection on the agent's side: `vibe` did that once. Boot stays **pure file-reading** — the `CLAUDE.md` / `AGENTS.md` / `GEMINI.md` redirect points at generated files; it does *not* become "run `vibe`". This preserves the zero-dependency cross-agent property that is the whole point of VIBEVM-SPEC §6.1.

**P4 — Three inclusion types: `inline`, `static`, `dynamic`.** Declared per dependency in the consumer's `vibe.toml`; default `static`. They are the points on the linker spectrum (§6). *(As shipped after the 2026-07-16 rename: two types, `link = "static" | "dynamic"`, default `dynamic`, with the third case expressed as a `dynamic` entry carrying a `when` — see the rename note above.)*

Four forks were put to the owner. The options, the resolution, the reasoning.

Each dependency in a consumer's `vibe.toml` carries an inclusion type (working syntax of this session: `link = "inline" | "static" | "dynamic"`); the default was `static`. At `vibe install` time, for each entry-point node `vibe` generates:

Cost profile:

`dynamic` is, mechanically, the subskill `lazy-pull` delivery mode (PROP-003 §2.5) — the loading model generalises subskill delivery rather than inventing a parallel axis.