PROP-034: Transitive inclusion links and the static boot-link graph

**Status: IMPLEMENTED under renamed terms** (requirements authored 2026-07-14 at the owner's request; verified against the tree 2026-07-25 by the spec-actualization campaign). `static-transitive` is live on `LinkType`, and dedup + topological ordering + tie-break emission run in `bootgen` — this repository's own `STATIC.md` is the §3 redbook closure in the flesh. [PROP-035 §12](PROP-035-spec-compiler.xml) and [PROP-038](PROP-038-hybrid-boot-linking.xml) absorbed the graph as their emission layer; read the `TERMINOLOGY-RENAME` note below before the body. Extends [PROP-009](PROP-009-loading-model.xml) (the loading model).

**Scope note (2026-08-23, PROP-050 §3):** the boot-link graph this document defines is now built over the consumer root's **effective set E(R)** — the visibility layer (access / friendship / exclude / override, PROP-050) decides which nodes exist before any link mode is read; a `static-transitive` edge propagates strength across visible edges only.

**Terminology (2026-07-16):** the `inline` / `static` / `dynamic` link types this document describes were **renamed** — read `inline` as `static` (the verbatim `STATIC.md` lane), `static` as `dynamic` (the default, a by-reference read), and the old `dynamic` as a `dynamic` entry carrying a `when`; `inline-transitive` is now `static-transitive`. See PROP-009 §2.4. The body below predates the rename and keeps the old names.

**Related:** [PROP-009 §2.4](PROP-009-loading-model.xml#inclusion-types) (the direct `inline` / `static` / `dynamic` link types this PROP makes transitive), [PROP-028](../../common/PROP-028-package-families.xml) (families / collections — the motivating consumer), [PROP-003](../vibe-resolver/PROP-003-dep-evolution.xml) / [PROP-017](../vibe-resolver/PROP-017-resolvo-resolver.xml) (version unification — one node per resolved package), [`vibevm/vibespecs/design/loading-and-boot-model.xml`](../../design/loading-and-boot-model.xml) (the static/dynamic-linking metaphor this PROP completes).

**Supersedes:** backlog `B1` (`transitive-inline` / `transitive-static`) — promoted to this PROP.

PROP-009 §2.4 gives each **direct** dependency edge an inclusion type — `inline` (verbatim into `INLINE.md`, the priority lane), `static` (a path in `INDEX.md`), or `dynamic` (a conditional INCLUDE). Two gaps make a growing dependency set fragile, and a collection like `redbook` un-loadable the way its consumer wants:

**Gap 1 — inclusion does not propagate transitively.** A consumer sets `link` only on its own direct edges.

A dependency's transitive closure takes its type from each member's own `[boot_snippet]` suggested link, or the `static` default — `bootgen` resolves `declared_link.or(suggested_link)`, and a transitive dependency's `declared_link` reads back as `None`. So a **collection** (e.g. `redbook`, PROP-028) cannot say "load my whole closure inline." The only workaround — each member self-suggesting `inline` — is wrong: it forces inline on **every** consumer of that member, not just the one collection that wanted it. Inclusion strength is a property of *how a consumer pulls a subtree*, and today that cannot be expressed.

**Gap 2 — the boot closure is not resolved as a static link graph.** A dependency closure is a graph, and assembling a boot from it is exactly **static linking**.

Three linker invariants are currently only informally met by PROP-009's "ordered list" and are load-bearing:

**Each package linked exactly once.** A package reachable through several dependency paths must appear **once** in `INLINE.md` / `INDEX.md`, never N times. Double-inclusion wastes context, and for `inline` it duplicates verbatim text and its anchors (a `duplicate-anchor` hazard). **Dependency order (topological).** A package must be emitted **before** every package that requires it, so that when a dependent's boot text is read, everything it builds on is already in context. A package needed by another (or several) comes **earlier** in the sequence. **Deterministic and acyclic.** The walk must be deterministic (stable output across runs) and reject cycles loudly at generate time — the agent-side read stays recursion-free (PROP-009 §2), so all graph work, including cycle detection, happens once in `vibe`.

Without these pinned, adding the whole `redbook`, `delegation-first`, and future collections risks a boot that double-includes packages and orders a dependent before its dependency — the failure the owner names as "we might never load cleanly."

A package can be reached by several edges and several transitive closures carrying different modes.

Its **effective inclusion mode** is the join of every mode that reaches it, under the lattice:

inline ⊐ static ⊐ dynamic

Resolution, for each package in the closure:

Collect every mode reaching it: (a) a **direct** edge to it contributes that edge's mode; (b) a **transitive** link contributes its mode to *every* package in the closure reached through it; (c) the package's own `[boot_snippet]` suggested link; (d) the `static` default when nothing else applies. The effective mode is the **strongest** (left-most) of those.

Consequences, all deliberate:

**Inline wins, monotonically.** If any path pulls a package inline (a direct `inline`, or an `inline-transitive` ancestor, or a self-suggested `inline`), it is inline. Adding a stronger link never demotes a package — a package's priority can only rise, never silently fall, as the graph grows. **`dynamic` is overridden by any unconditional need.** If one path needs a package `dynamic` (context-gated) but another needs it `static`/`inline` unconditionally, it loads unconditionally — the `when` gate cannot hide a package something else requires outright. A **direct** link never demotes a package an ancestor pulled `inline-transitive` (inline is sticky, per the monotonicity above). A consumer that truly needs a subtree *not* inline must not sit under an `inline-transitive` edge to it.

The lattice makes the effective mode a deterministic function of the graph, independent of walk order.

From the sorted, deduplicated, mode-assigned node list:

**`inline`** nodes → concatenated verbatim into `INLINE.md`, **in topological order** — a dependency's boot text precedes its dependents' within the priority lane. This is the **static-linked inline lane**: inline content, but resolved, deduplicated, and dependency-ordered by the linker rather than pasted in discovery order. **`static`** nodes → `[[entry]]` `kind = "static"` in `INDEX.md`, in topological order. **`dynamic`** nodes → `[[entry]]` `kind = "dynamic"` with their `when`, in topological order.

Both lanes are dependency-ordered: a reader (human or agent) always meets a package **before** anything that builds on it, and never meets the same package twice.

`inline-transitive` over a large collection puts that collection's **whole** boot closure into `INLINE.md`, read first and in full every session. That is the point when priority must be *guaranteed by position* (critical practices that must never be missed) — and a real cost when the closure is large. Choose `inline-transitive` for closures whose every member is boot-critical; keep `static-transitive` (still deduplicated and dependency-ordered, but read on demand from `INDEX.md`) as the default for large practice sets where INDEX-lane resolution is acceptable.

vibevm pulls `flow:org.vibevm.world/redbook` as `inline-transitive`. The effect, under §2:

Every practice `redbook` collects, plus their transitive deps, resolves to effective mode `inline`. The graph is deduplicated: a practice several members share (e.g. `git-practices`, or a common dependency) appears **once**. The graph is topologically ordered: a practice needed by another (or by `redbook` itself) is emitted **earlier** in `INLINE.md`. The whole tested edition is thus in the priority lane, verbatim, dependency-ordered, once each — the practices are guaranteed to load, which is the safety the owner is buying (over `static`, which trusts agent-side INDEX resolution).

The per-member `[boot_snippet].link = "inline"` self-suggestions used as the B1 interim (e.g. on the `git-practices` members) become unnecessary once the consumer declares `inline-transitive`, and can be dropped — the inclusion strength moves back to the consumer where §2.1 puts it.

The direct `inline` / `static` / `dynamic` types and their semantics are unchanged; the transitive variants are purely additive to the `link` enum. §2.3's dedup + topological order **pins** what PROP-009 §2 left as an "ordered list": existing manifests keep working and simply gain guaranteed single-inclusion and dependency order. Any boot that silently relied on a *non*-topological order is a latent bug this surfaces. Manifest schema (`vibe-core`): the `link` field accepts the new variants; unknown `link` values remain a manifest error. Implementation lands in `vibe-workspace` boot resolution (`bootgen`): mode propagation (§2.2), dedup, topological sort with the deterministic tie-break, and cycle rejection.
**`dynamic-transitive`.** Semantics of gating a whole closure behind one `when` (does the gate distribute to every member, or gate the subtree as a unit?) — reserved until a use case appears. **`when` inside a transitive-inline closure.** A member carrying its own `when` OS-gate that is pulled `inline-transitive`: does inline (unconditional, verbatim) or the gate win? Provisional: an explicit member `when` keeps the member `dynamic` (the gate is more specific than the ancestor's blanket inline); confirm against a real case. **Explicit demotion.** Whether to add a `link = "static-here"` escape that lets a consumer pull a package `static` *even under* an ancestor's `inline-transitive` (breaking the monotonicity of §2.2). Deferred — no demotion use case today, and monotonic priority is the safer default.
**2026-07-14 — drafted (owner-requested).** Promotes backlog B1. Defines the transitive `inline-transitive` / `static-transitive` links (§2.1), the effective-mode precedence lattice (§2.2), and the static boot-link graph — dedup + topological order + cycle rejection (§2.3) — with dependency-ordered emission into the `INLINE.md` priority lane and `INDEX.md` (§2.4). `redbook` is the motivating `inline-transitive` consumer (§3). Implementation (manifest schema + `bootgen` resolution) is the next milestone.